[Bug c++/9335] [4.3/4.4/4.5/4.6 regression] repeated diagnostic when maximum template depth is exceeded
--- Comment #25 from jason at gcc dot gnu dot org 2010-04-21 06:06 --- Subject: Bug 9335 Author: jason Date: Wed Apr 21 06:06:27 2010 New Revision: 158586 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158586 Log: PR c++/9335 gcc/cp: * init.c (constant_value_1): Treat error_mark_node as a constant if DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P is set. * cvt.c (ocp_convert): Handle getting error_mark_node from integral_constant_value. * decl.c (compute_array_index_type): Likewise. gcc/testsuite: * lib/prune.exp: Prune skipping N instantiation contexts. Added: trunk/gcc/testsuite/g++.dg/template/recurse2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/init/member1.C trunk/gcc/testsuite/g++.dg/other/fold1.C trunk/gcc/testsuite/g++.dg/parse/crash36.C trunk/gcc/testsuite/lib/prune.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug libgomp/43826] [libgomp] sharing-2..f90 has too many excess errors
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 06:56 --- Works just fine here. Are you sure you have updated also to the latest fortran/openmp.c and rebuilt f951? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43826
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #28 from mikpe at it dot uu dot se 2010-04-21 07:52 --- (In reply to comment #27) I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it first when my 4.5-based gcc regressed on this test, and found evidence that trunk regressed similary between r158417 and r158459: http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01476.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01534.html I'm now starting a C-only bootstrap+regtest of 4.5 with this one reverted to verify. Confirmed, reverting the PR43572 fix restores the expected tailcall in arm's sibcall-1.c test case. I don't know if the tailcall-blocking fix can be made to distinguish between references to local auto variables and references to formal parameters (which is what sibcall-1.c needs). If it can't, perhaps just XFAIL sibcall-1.c ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug tree-optimization/43572] [4.5 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #29 from rguenther at suse dot de 2010-04-21 08:48 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
On Tue, 20 Apr 2010, mikpe at it dot uu dot se wrote:
--- Comment #27 from mikpe at it dot uu dot se 2010-04-20 23:34 ---
(In reply to comment #22)
Subject: Bug 43572
Author: rguenth
Date: Fri Apr 16 13:21:38 2010
New Revision: 158418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158418
Log:
2010-04-16 Richard Guenther rguent...@suse.de
PR tree-optimization/43572
I think this broke gcc/testsuite/gcc.target/arm/sibcall-1.c. I noticed it
first
when my 4.5-based gcc regressed on this test, and found evidence that trunk
regressed similary between r158417 and r158459:
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01476.html
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg01534.html
I'm now starting a C-only bootstrap+regtest of 4.5 with this one reverted to
verify.
Try
Index: gcc/tree-tailcall.c
===
--- gcc/tree-tailcall.c (revision 158562)
+++ gcc/tree-tailcall.c (working copy)
@@ -469,6 +469,7 @@ find_tail_calls (basic_block bb, struct
FOR_EACH_REFERENCED_VAR (var, rvi)
{
if (!is_global_var (var)
+ TREE_CODE (var) != PARM_DECL
ref_maybe_used_by_stmt_p (call, var))
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #12 from redi at gcc dot gnu dot org 2010-04-21 09:23 --- (In reply to comment #8) By the way, there's no warning with -Wall or even -Wextra. Is there a flag -Wabsolutely_all_warnings_we_promise that I have missed and that would really enable *all* warnings ? No, sorry, there isn't. (In reply to comment #10) Nah, the pragma must stay, we have it everywhere, consistently. And I really do not understand why auto_ptr is *so* special to need more warnings to be spilled vs *all* the rest of the library in order to be used safely. Ah, yes, it's broken, forgot ;) Really, if this is the ultimate analysis of the issue, I disagree with doing *anything*. :) the reason isn't that it's broken, it's that various members of auto_ptr require the expression delete _M_ptr to be well-formed, and warning users when it's not well-formed is very useful. Previously we never added a check because the front-end warned. even if you don't care about auto_ptr (and I still do) THIS AFFECTS SHARED_PTR TOO! We no longer warn on this: struct C; C* f(); std::shared_ptrC p( f() ); Chris's patch definitely won't work, since it would affect the rest of memory not just auto_ptr. Something like #pragma pop GCC system_header would work, and would also make the attribute((deprecated)) on auto_ptr work again! For the std::shared_ptr case I will add a static_assert like we use in unique_ptr. tr1::shared_ptr will have to use an array of sizeof(T) length or something -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug debug/43828] New: Emit debug info allowing inlined functions to show in stack traces
It would be very nice if gcc emitted debug information that allowed profilers and debuggers the option to extract a stack trace which included calls to inlined functions. This would allow developers much greater insight into the behavior of optimized code. C++ programs would benefit disproportionately, especially those which use the STL heavily -- disabling inlining produces a very different executable which makes profiling worse than useless and can mask heisenbugs. Profiling would become significantly more accurate because it could determine how much of a function's overheads remain even after inlining, which is pretty much impossible right now. It would also allow profilers to generate functional call graphs which show all uses of a function, inlined or not. Debugging would also improve because the user would be able to navigate a stack trace which corresponds to the code they're trying to debug, even if the actual calls were optimized away. Questions like which of this function's 10 calls to std::vector::begin seg faulted? would suddenly be *much* easier to answer, and in an intuitive way. With some work it would probably even be possible to maintain mappings for local vars/params (assuming they exist at the time). All this virtual stack trace functionality would need to remain separate (and probably not the default) so as to not confuse (impede) folks who are used to (prefer) the current behavior. NOTE: I realize that full support for this would require changes to other projects like gdb and gprof, but gcc could solve the chicken-and-egg problem by emitting appropriate debug info as a first step; perhaps the new debug info changes introduced with 4.5.0 already do (some of) this? -- Summary: Emit debug info allowing inlined functions to show in stack traces Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scovich at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces
--- Comment #1 from scovich at gmail dot com 2010-04-21 09:29 --- (In reply to comment #0) One more way debugging would improve: it would become possible to set breakpoints in inlined functions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
[Bug c/43827] Intrinsic possibility: does not alias global data
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-21 09:29 --- They are feasible, but they do need a very strict specification to be usable. With 4.6 you can check the -alias dumps when building with -flto -fipa-pta to see if the compiler maybe can already analyze the situation correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-20 16:21:38 |2010-04-21 09:36:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug c++/43824] C++0x feature inline namespace enabled under -std=c++98; no warnings
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-21 09:40 --- Right, this is a GNU extension used to implement the library, which was later standardised. We also support 'long long' in C++03 mode. GCC is not intended to be a strict ANSI C++ verification tool, so doesn't reject all non-portable programs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
[Bug c++/29043] Constructor for POD type with const member without member initializer accepted
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien dot chene at gmail |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29043
[Bug lto/43823] [lto] ICE during linking in testsuite
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 10:01 --- It works for me on x86_64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
[Bug debug/43828] Emit debug info allowing inlined functions to show in stack traces
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 10:03 --- GCC already emits that (and emits that for quite some time already). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43828
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 10:31 --- BTW, gcc stopped emitting with http://gcc.gnu.org/viewcvs?root=gccview=revrev=129882 - PR10220 commit. Unfortunately that change isn't even mentioned in the ChangeLog entry nor I could find any discussions about it on the mailing list from that time. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:38 --- (In reply to comment #10) Unfortunately that change isn't even mentioned in the ChangeLog entry nor I could find any discussions about it on the mailing list from that time. In the bugzilla PR you reference, there are links to the gcc-patches thread: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00120.html which itself refers to a thread on the gdb list: http://www.sourceware.org/ml/gdb/2007-10/msg00205.html Now, if you're refering to this hunk of the change: --- trunk/gcc/dwarf2out.c 2007/11/04 04:34:47 129881 +++ trunk/gcc/dwarf2out.c 2007/11/04 14:43:45 129882 @@ -11356,7 +11356,8 @@ TREE_PUBLIC (decl) DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl) !DECL_ABSTRACT (decl) - !(TREE_CODE (decl) == VAR_DECL DECL_REGISTER (decl))) + !(TREE_CODE (decl) == VAR_DECL DECL_REGISTER (decl)) + !is_fortran ()) add_AT_string (die, DW_AT_MIPS_linkage_name, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl))); } well, it looks like it wasn't approved, so I wouldn't be surprised if it's just a something I had testing in my tree that I inadvertently committed at the time. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-21 10:43 --- Yeah, that's exactly the hunk I'm referring to. The gdb patch Jan provided relies on DW_AT_MIPS_linkage_name (or DW_AT_linkage_name hopefully for DWARF4) to be provided. While for most normal Fortran identifiers when modules aren't involved most implementations agree on appending _ at the end, for objects/functions in modules the mangling differs between implementations and certainly isn't something debug info consumers should hardcode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2010-04-21 10:46 --- I have googled the gcc.gnu.org domain for my name and DW_AT_MIPS_linkage_name, and came up with nothing relevant. So, I never proposed or sought to get this part approved, which confirms it's probably just human error. I am no longer a Fortran maintainer, but I'm sure the reversion will be easily approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #3 from mkuvyrkov at gcc dot gnu dot org 2010-04-21 10:47 --- There are two problems here: 1. The immediate problem is that movsi_m68k doesn't allow (const) to be moved to data register (see last alternative if movsi_m68k). 2. For reason, which I have not yet investigated, no alternative in addsi_internal match (set (reg) (plus (reg %a5) (const (unspec Andreas, do you know why movsi_m68k doesn't allow data register in the last alternative? (define_insn *movsi_m68k [(set (match_operand:SI 0 nonimmediate_operand =g,d,a) (match_operand:SI 1 general_src_operand damSnT,n,i))] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR D.3163_8, D.3164_9;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to change float to double, otherwise, we
don't have complete vectors and this is not supported).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #9 from rguenther at suse dot de 2010-04-21 11:44 ---
Subject: Re: C complex numbers, amd64 SSE, missed
optimization opportunity
On Wed, 21 Apr 2010, irar at il dot ibm dot com wrote:
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR D.3163_8, D.3164_9;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to change float to double, otherwise, we
don't have complete vectors and this is not supported).
Dependent on how D.3154_3 is used afterwards it will be much like
an interleaved/strided store (if {D.3163_8, D.3164_9} is in xmm2 and the
complex is in the lower halves of the register pair xmm0 and xmm1
we'd emit vec_extracts). On the tree level we can probably
represent this as
D.3154_3 = VIEW_CONVERT_EXPR compex_double (vec_temp_4);
where vec_temp_4 is the {D.3163_8, D.3164_9} vector.
Or similar, but with present known-to-work trees
realpart = BIT_FIELD_REF 0, .. (vec_tmp_4);
imagpart = BIT_FIELD_REF 64, .. (vec_tmp_4);
D.3154_3 = COMPLEX_EXPR realpart, imagpart;
One could also see the COMPLEX_EXPR as a root for SLP induction
vectorization (I suppose we don't do SLP induction at the moment,
induction in the sense that we pick arbitrary scalars and combine
them into vectors).
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #6 from oberlaender at fzi dot de 2010-04-21 11:48 --- A test with a g++-4.4.2 I built myself has the same problem: $ g++-4.4.2 -c -o bugtest.out -O2 bugtest.ii projects/odete/bugtest.cpp: In member function bool tBspTree2D::Intersect(const tVec2f, const tVec2f, tVec2f, double) const [with bool oriented = true]: projects/odete/bugtest.cpp:81: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. $ g++-4.4.2 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.2/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.2/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.2 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.2 (GCC) Jonathan, since 4.4.2 worked for you -- got any idea what could be different in my case? Am I doing something wrong? I installed 4.4.2 with the regular ./configure options as above; make; make install (into my $HOME/local), is there any risk of a mixup between 4.4.1 and 4.4.2? Thanks in advance for your help. I'll try 4.4.3 next... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug middle-end/43740] [4.5/4.6 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-21 11:49 --- (In reply to comment #4) Subject: Re: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error) Can you bisect the few commits that happened inbetween? Like reverting the fixes for PRs 43679 and/or 43661, 43642? Strangely, this was introduced in 157991 (change to BASE-VER). 157991 is the change to DEV-PHASE. That will turn on release-checking by default which means that tree-checking macros are omitted for dump_gimple_stmt and thus different code gets generated. You might want to check if the same issue can be reproduced on trunk with --enable-checking=release. And then dig into why dump_gimple_stmt is miscompiled w/o checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug middle-end/43570] OpenMP: Invalid read of size 1 (libgomp.fortran/vla6.f90)
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-21 11:58 --- Subject: Bug 43570 Author: jakub Date: Wed Apr 21 11:57:42 2010 New Revision: 158594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158594 Log: PR middle-end/43570 * omp-low.c (scan_sharing_clauses): Don't scan_omp_op OMP_CLAUSE_DECL for OMP_CLAUSE_COPYPRIVATE. (lower_copyprivate_clauses): Use private var in outer context instead of original var. Make sure the types are correct for VLAs. * testsuite/libgomp.fortran/vla8.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/vla8.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43570
[Bug fortran/43829] New: Scalarization of reductions
465.tonto in one of its hot loops does essentially what the following reduced testcase does: subroutine make_esss(esss,Ix,Iyz,e_x,ii_ivec) real(kind=kind(1.0d0)), dimension(:), intent(inout) :: esss real(kind=kind(1.0d0)), dimension(:,:), pointer :: Ix,Iyz integer(kind=kind(1)), dimension(:), pointer :: e_x,ii_ivec esss(:) = esss(:) + sum(Ix(:,e_x) * Iyz(:,ii_ivec), 1) end subroutine this is scalarized by the frontend to atmp4 = e_x atmp6 = ii_ivec atmp8 = Ix(:,atmp4) * Iyz(:,atmp6) atmp11 = sum (atmp8, 1) ess = ess + atmp11 where the sum is not inline-expanded. 1) the temporaries for e_x and ii_ivec are not necessary 2) the sum can easily be inline-expanded as the shape of atmp8 is well-defined 3) we can avoid atmp8 by expanding sum(Ix(:,e_x), Iyz(:ii_ivec), 1) together like atmp11(z) = 0 do z=1,size(Ix,1) atmp11(z) = atmp11(z) + Ix(z,e_x(e)) * Iyz(z,ii_ivec(e)) end do or even avoid atmp11 alltogether and expand to do e=1,size(esss,1) tem = 0 do z=1,size(Ix,1) tem = tem + Ix(z,e_x(e)) * Iyz(z,ii_ivec(e)) end do esss(e) = esss(e) + tem end do given that esss does not have the target attribute and thus cannot be aliased by e_x or ii_ivec. -- Summary: Scalarization of reductions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/42517] -fcheck=recursion does not work with -fopenmp
--- Comment #12 from burnus at gcc dot gnu dot org 2010-04-21 12:25 --- Close as FIXED. If someone feels strong about allowing -fcheck=recursion with -fopenmp, please reopen. (I think as fopenmp implies -frecursive, it does not make much sense.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #7 from oberlaender at fzi dot de 2010-04-21 12:40 --- 4.4.3 gives me the same problem, I'm starting to think I'm really doing something wrong. $ g++-4.4.3 -v Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/home/oberlaen/local/stow/gcc-4.4.3/ --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.4.3 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug fortran/43829] Scalarization of reductions with Fortran array expressions
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-21 12:51 --- Scalarization is just difficult... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-21 12:51:53 date|| Summary|Scalarization of reductions |Scalarization of reductions ||with Fortran array ||expressions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/43829] Scalarization of reductions
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 13:08 --- Wade-through-the-code dump: gfc_trans_assignment_1 gets make_esss:esss(:) (+ make_esss:esss(:) _gfortran_sum_r8[[(((* make_esss:ix(: , __convert_i4_i8[[((make_esss:e_x(FULL)))]]) make_esss:iyz(: , __convert_i4_i8[[((make_esss:ii_ivec(FULL)))]]))) (_8) ((arg not-present)))]]) the first issue is that while we can properly scalarize subroutine test0(esss,Ix,Iyz) real(kind=kind(1.0d0)), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:) :: Ix,Iyz esss = sum(Ix * Iyz, 0) end subroutine we can't handle subroutine test1(esss,Ix,Iyz) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:,:) :: Ix,Iyz esss = sum(Ix * Iyz, 0) end subroutine as gfc_conv_intrinsic_function does not handle expr-rank 0 for inline expansion. The second issue is that for subroutine test0(esss,Ix,Iyz, e_x, ii_ivec) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:) :: Ix,Iyz integer(kind=kind(1)), dimension(:) :: e_x,ii_ivec esss = Ix(e_x) * Iyz(ii_ivec) end subroutine we create temporaries for e_x and ii_ivec. Even for subroutine test0(esss,Ix, e_x) real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss real(kind=kind(1.0d0)), dimension(:) :: Ix integer(kind=kind(1)), dimension(:) :: e_x esss = Ix(e_x) end subroutine -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Scalarization of reductions |Scalarization of reductions |with Fortran array | |expressions | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug rtl-optimization/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands
--- Comment #4 from schwab at linux-m68k dot org 2010-04-21 13:22 --- Introduced in r27576. Presumably the first alternative is supposed to catch this case, through T+g, but T does not match if flag_pic, contrary to its documentation (introduced in r120961). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804
[Bug middle-end/43830] New: [4.6 regression] FAIL: gcc.dg/torture/builtin-cproj-3.c
On Linux/x86, revision 158589 gave: FAIL: gcc.dg/torture/builtin-cproj-3.c -O0 execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O1 execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O2 execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O2 -flto execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O2 -fwhopr execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -O3 -g execution test FAIL: gcc.dg/torture/builtin-cproj-3.c -Os execution test Revision 158585 is OK. -- Summary: [4.6 regression] FAIL: gcc.dg/torture/builtin-cproj-3.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43830
[Bug c++/43831] New: [C++0x] gcc-4.5.0 does not fail invalid lambda captures (against n3092 5.1.2/8)
The following code reproduces the Example in n3092 (FCD) 5.1.2/8, complete with
the comments given there:
14:36:12 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $cat _5_1_2_8.cpp
// file: _5_1_2_8.cpp
struct S2 { void f(int i); };
void S2::f(int i) {
[, i]{ }; // OK
[, i]{ };// error: i preceded by when is the default
[=, this]{ }; // error: this when = is the default
// [i, i]{ }; // error: i repeated
}
The fourth lambda-expression has been commented out to reflect the fact that
gcc-4.5.0 correctly handles this as an error. The second and third - which
should be errors according 5.1.2/8 - are left uncommented. gcc-4.5.0 compiles
this code without issuing an error, thus not handling the following from
5.1.2/8 correctly:
- If a lambda-capture includes a capture-default that is , the identifiers
in the lambda capture shall not be preceded by ; and
- If a lambda-capture includes a capture-default that is =, the lambda
capture shall not contain this.
14:33:29 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $make
i686-pc-cygwin-gcc-4.5.0 -v -save-temps -Wall -std=c++0x -pedantic -c
_5_1_2_8.cpp
Using built-in specs.
COLLECT_GCC=i686-pc-cygwin-gcc-4.5.0
COLLECT_LTO_WRAPPER=/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --prefix=/opt/gcc-4.5.0 --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as
--with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++
--disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix
--with-arch-i686 --with-tune=generic
Thread model: posix
gcc version 4.5.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++0x' '-pedantic' '-c'
'-mtune=generic' '-march=pentiumpro'
/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe -E -quiet -v
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/../include/w32api -idirafter ../../include/w32api _5_1_2_8.cpp
-mtune=generic -march=pentiumpro -std=c++0x -Wall -pedantic -fpch-preprocess -o
_5_1_2_8.ii
ignoring nonexistent directory
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/../../../../i686-pc-cygwin/include
ignoring nonexistent directory ../../include/w32api
#include ... search starts here:
#include ... search starts here:
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/include/c++
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/i686-pc-cygwin
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/backward
/usr/local/include
/opt/gcc-4.5.0/include
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/include
/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/include-fixed
/usr/include
/usr/lib/../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++0x' '-pedantic' '-c'
'-mtune=generic' '-march=pentiumpro'
/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/cc1plus.exe -fpreprocessed
_5_1_2_8.ii -quiet -dumpbase _5_1_2_8.cpp -mtune=generic -march=pentiumpro
-auxbase _5_1_2_8 -Wall -pedantic -std=c++0x -version -o _5_1_2_8.s
GNU C++ (GCC) version 4.5.0 (i686-pc-cygwin)
compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version 2.4.1,
MPC version 0.8.1
warning: GMP header version 4.3.2 differs from library version 4.3.1.
warning: MPFR header version 2.4.1 differs from library version 2.4.1-p5.
warning: MPC header version 0.8.1 differs from library version 0.8.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129712
GNU C++ (GCC) version 4.5.0 (i686-pc-cygwin)
compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version 2.4.1,
MPC version 0.8.1
warning: GMP header version 4.3.2 differs from library version 4.3.1.
warning: MPFR header version 2.4.1 differs from library version 2.4.1-p5.
warning: MPC header version 0.8.1 differs from library version 0.8.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129712
Compiler executable checksum: 81a7a49c1fa28713ff621b6b856147c0
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++0x' '-pedantic' '-c'
'-mtune=generic' '-march=pentiumpro'
as -v -o _5_1_2_8.o _5_1_2_8.s
GNU assembler version 2.20.51 (i686-cygwin) using BFD version (GNU Binutils)
2.20.51.20100410
COMPILER_PATH=/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/:/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/4.5.0/:/opt/gcc-4.5.0/libexec/gcc/i686-pc-cygwin/:/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/:/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/
LIBRARY_PATH=/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/:/opt/gcc-4.5.0/lib/gcc/i686-pc-cygwin/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c++0x' '-pedantic' '-c'
'-mtune=generic' '-march=pentiumpro'
14:33:31 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $
14:36:04 Paul bibbi...@jijou
/cygdrive/d/CPPProjects/nano/gcc_bugs $cat _5_1_2_8.ii
# 1 _5_1_2_8.cpp
# 1 built-in
# 1
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #8 from oberlaender at fzi dot de 2010-04-21 13:42 --- Just tested 4.5.0, which did not crash. $ g++-4.5.0 -c -o bugtest.out -O2 bugtest.ii $ g++-4.5.0 -v Using built-in specs. COLLECT_GCC=g++-4.5.0 COLLECT_LTO_WRAPPER=/home/oberlaen/local/stow/gcc-4.5.0/libexec/gcc/i486-linux-gnu/4.5.0/lto-wrapper Target: i486-linux-gnu Configured with: ../gcc-4.5.0/configure --prefix=/home/oberlaen/local/stow/gcc-4.5.0/ --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++ --enable-shared --disable-multiarch --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --program-suffix=-4.5.0 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-multilib --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu --with-mpc=/home/oberlaen/local Thread model: posix gcc version 4.5.0 (GCC) Also, all the 4.4.x versions work fine if I replace -O2 with -O1. The question remains, what is going wrong with my various 4.4.x tests, and why did it work for Jonathan? I've circumvented the problem in my piece of software for now by going from -O2 to -O1, as I don't feel like rebuilding everything against 4.5 just yet. :) But at least according to my tests, the problem is present in all 4.4 releases. Can anyone else reproduce the error? Thanks and best regards, Jan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug middle-end/43830] [4.6 regression] FAIL: gcc.dg/torture/builtin-cproj-3.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-21 13:43 --- It will always fail on glibc older than 2.12, which hasn't been released yet. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43830
[Bug fortran/43832] New: OPEN statement not diagnosing missing unit number
An OPEN statement needs to either have a unit number in the first item in the list, or have a UNIT= (or NEWUNIT= in F2008) keyword somewhere else. Here is an example where the unit number is not specified, yet gfortran does not issue an error: subroutine openit implicit none open (file='x') end subroutine This was tested with version 4.4.1 on Ubuntu linux. -- Summary: OPEN statement not diagnosing missing unit number Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: w6ws at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43832
[Bug libgomp/43569] libgomp: Conditional jump or move depends on uninitialised value
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-21 13:59 --- Subject: Bug 43569 Author: jakub Date: Wed Apr 21 13:58:49 2010 New Revision: 158598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158598 Log: PR libgomp/43569 * sections.c (gomp_sections_init): Initialize ws-mode. Modified: branches/gcc-4_5-branch/libgomp/ChangeLog branches/gcc-4_5-branch/libgomp/sections.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43569
[Bug libgomp/43569] libgomp: Conditional jump or move depends on uninitialised value
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-21 13:59 --- Subject: Bug 43569 Author: jakub Date: Wed Apr 21 13:58:59 2010 New Revision: 158599 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158599 Log: PR libgomp/43569 * sections.c (gomp_sections_init): Initialize ws-mode. Modified: branches/gcc-4_4-branch/libgomp/ChangeLog branches/gcc-4_4-branch/libgomp/sections.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43569
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-21 14:00 --- Subject: Bug 43706 Author: jakub Date: Wed Apr 21 13:59:39 2010 New Revision: 158600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158600 Log: PR libgomp/43706 * config/linux/affinity.c (gomp_init_affinity): Decrease gomp_available_cpus if affinity mask confines the process to fewer CPUs. * config/linux/proc.c (get_num_procs): If gomp_cpu_affinity is non-NULL, just return gomp_available_cpus. Modified: branches/gcc-4_5-branch/libgomp/ChangeLog branches/gcc-4_5-branch/libgomp/config/linux/affinity.c branches/gcc-4_5-branch/libgomp/config/linux/proc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-21 14:01 --- Subject: Bug 43706 Author: jakub Date: Wed Apr 21 14:00:10 2010 New Revision: 158601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158601 Log: PR libgomp/43706 * config/linux/affinity.c (gomp_init_affinity): Decrease gomp_available_cpus if affinity mask confines the process to fewer CPUs. * config/linux/proc.c (get_num_procs): If gomp_cpu_affinity is non-NULL, just return gomp_available_cpus. Modified: branches/gcc-4_4-branch/libgomp/ChangeLog branches/gcc-4_4-branch/libgomp/config/linux/affinity.c branches/gcc-4_4-branch/libgomp/config/linux/proc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug middle-end/43570] OpenMP: Invalid read of size 1 (libgomp.fortran/vla6.f90)
--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-21 14:01 --- Subject: Bug 43570 Author: jakub Date: Wed Apr 21 14:01:30 2010 New Revision: 158602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158602 Log: PR middle-end/43570 * omp-low.c (scan_sharing_clauses): Don't scan_omp_op OMP_CLAUSE_DECL for OMP_CLAUSE_COPYPRIVATE. (lower_copyprivate_clauses): Use private var in outer context instead of original var. Make sure the types are correct for VLAs. * testsuite/libgomp.fortran/vla8.f90: New test. Added: branches/gcc-4_5-branch/libgomp/testsuite/libgomp.fortran/vla8.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/omp-low.c branches/gcc-4_5-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43570
[Bug middle-end/43570] OpenMP: Invalid read of size 1 (libgomp.fortran/vla6.f90)
--- Comment #3 from jakub at gcc dot gnu dot org 2010-04-21 14:02 --- Subject: Bug 43570 Author: jakub Date: Wed Apr 21 14:02:39 2010 New Revision: 158603 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158603 Log: PR middle-end/43570 * omp-low.c (scan_sharing_clauses): Don't scan_omp_op OMP_CLAUSE_DECL for OMP_CLAUSE_COPYPRIVATE. (lower_copyprivate_clauses): Use private var in outer context instead of original var. Make sure the types are correct for VLAs. * testsuite/libgomp.fortran/vla8.f90: New test. Added: branches/gcc-4_4-branch/libgomp/testsuite/libgomp.fortran/vla8.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/omp-low.c branches/gcc-4_4-branch/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43570
[Bug fortran/43832] OPEN statement not diagnosing missing unit number
--- Comment #1 from w6ws at earthlink dot net 2010-04-21 14:05 --- An additional test: with just an OPEN statement with no list, gfortran issues: In file miniopen.f90:4 open () 1 Error: Syntax error in OPEN statement at (1) While the message is technically correct, it would be more helpful if it mentioned the missing unit number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43832
[Bug libgomp/43569] libgomp: Conditional jump or move depends on uninitialised value
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-21 14:05 --- Fixed for 4.4.4/4.5.1/4.6. -- 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=43569
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-21 14:05 --- GOMP_CPU_AFFINITY vs. throttling fixed for 4.4.4/4.5.1/4.6.0. -- 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=43706
[Bug middle-end/43570] OpenMP: Invalid read of size 1 (libgomp.fortran/vla6.f90)
--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-21 14:06 --- Fixed for 4.4.4/4.5.1/4.6.0. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43570
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug libgomp/43569] libgomp: Conditional jump or move depends on uninitialised value
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43569
[Bug libgcj/21935] All libjava execution tests fail on IRIX 6
--- Comment #1 from ro at gcc dot gnu dot org 2010-04-21 14:08 --- This bug is long gone. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21935
[Bug fortran/43832] OPEN statement not diagnosing missing unit number
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-21 14:09 --- Fortran 2008 (almost FDIS version) has: C904 (R904) If the NEWUNIT= specifier does not appear, a file-unit-number shall be speci ed; if the optional characters UNIT= are omitted, the file-unit-number shall be the first item in the connect-spec-list. -- burnus 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=43832
[Bug middle-end/43833] New: false warning: array subscript is above array bounds with -O3
$ cat t.c
extern unsigned char data[5];
unsigned char
foo (char *str)
{
int i, j;
unsigned char c = 0;
for (i = 0; i 8; i++)
{
j = i * 5;
if ((j % 8) 3)
c |= data[(j / 8) + 1];
}
return c;
}
$ gcc t.c -O3 -Wall -c
t.c: In function foo:
t.c:13:11: warning: array subscript is above array bounds
--
Summary: false warning: array subscript is above array bounds
with -O3
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jiez at gcc dot gnu dot org
ReportedBy: jiez at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
[Bug debug/39104] stabs debug info fails onIRIX 5.3
--- Comment #2 from ro at gcc dot gnu dot org 2010-04-21 14:11 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-21 14:11:29 date|| Summary|stabs debug info fails |stabs debug info fails |onIRIX 5.3 |onIRIX 5.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104
[Bug other/43834] New: problems when linking in XCode 3.2.2 (gcc build 5659) - static constants are messed?
Hi,
I'm experiencing problems when statically linking using particular GCC supplied
with XCode 3.2.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
5659) on Mac OS X 10.6.2. Computations become incorrect.
My application consists of main in C and computational code in Fortran (NETLIB
BLAS and slightly modified LAPACK). I'm compiling Fortran code using Intel
Fortran Compiler.
If I'm linking using the particular build, then results of my computations
become completely incorrect. When I'm linking using any other build (5646 from
XCode 3.2, or even i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build
5490)) everything computes correctly for the exactly same object files.
I'm guessing that linker somehow messes constants in my code and this results
incorrect computations. I've succeed to see in my big application that constant
ONE becomes -ONE with only this linker, however cleaning up for a smaller
reproducer I've missed such a constant, but computations results in the
reproducer are still incorrect for the build.
I've tried different versions of Intel Fortran Compiler (10.1, 11.1, etc), also
tried to compile C code with GCC and with Intel C Compiler - all this doesn't
affect results. Only GCC build matters, so I assume this is a problem of
linker. However map files produced by all mentioned builds of GCC are binary
same, so the problem somewhere deeper.
I'm attaching object files of reproducer. To link say just: gcc *.o.
Resulting a.out will show correct output like:
x[0] = {1.00, 0.00}
x[1] = {1.00, 0.00}
x[2] = {1.00, 0.00}
TEST PASSED
or report a error like:
info = 0
x[0] = {0.856000, -0.608000} - FAIL
x[1] = {1.52, 0.84} - FAIL
x[2] = {0.968000, 1.176000} - FAIL
TEST FAILED!!!
Please feel free to ask for more details. I would like to help to localize the
issue, but just don't know where to look at.
Thanks,
Alexander
--
Summary: problems when linking in XCode 3.2.2 (gcc build 5659) -
static constants are messed?
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexander dot v dot kobotov at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43834
[Bug other/43834] problems when linking in XCode 3.2.2 (gcc build 5659) - static constants are messed?
--- Comment #1 from alexander dot v dot kobotov at intel dot com 2010-04-21 14:18 --- Created an attachment (id=20452) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20452action=view) Object files and good output and bad output. File linked correctly is in a.out.good File with erroneous output in a.out.bad Also object files used to link are attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43834
[Bug libgomp/43706] scheduling two threads on one core leads to starvation
--- Comment #12 from mika dot fischer at kit dot edu 2010-04-21 14:23 --- Just to make it clear, this patch most probably does not fix the issue we're having, since it can be triggered without using GOMP_CPU_AFFINITY. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43706
[Bug debug/39104] stabs debug info fails onIRIX 5.3
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-04-21 14:24 --- Subject: Re: stabs debug info fails onIRIX 5.3 I don't think this is a gcc bug. While the native IRIX 5 tools use ECOFF debugging info embedded in ELF (mdebug), they don't know about Stabs-in-ECOFF/mdebug which is a GCC extension which IRIX 5 gdb cannot handle. Therefore it seems to be more useful to use Stabs-in-ELF instead of Stabs-in-ECOFF/mdebug instead, like gas on IRIX 6 does. In fact, I've got a patch to gas to do so. It seems like gas cannot properly handle the case where ECOFF_DEBUGGING_INFO isn't a compile time constant, but can change at runtime based on the -mdebug/-no-mdebug switch. Once this is properly tested, I'll submit it to the gas maintainers and update this PR accordingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39104
[Bug fortran/43829] Scalarization of reductions
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 14:26 ---
subroutine test0(esss,Ix, e_x)
real(kind=kind(1.0d0)), dimension(:), intent(out) :: esss
real(kind=kind(1.0d0)), dimension(:) :: Ix
integer(kind=kind(1)), dimension(:) :: e_x
esss = Ix(e_x)
end subroutine
where we create the temporary during gfc_conv_loop_setup -
gfc_add_loop_ss_code
when handling the GFC_SS_SECTION subscript e_x and want to get its array
descriptor.
To be able to specialize this we'd need to know whether at the end we're
going to need a descriptor for the GFC_SS_SECTION (because we are passing
it to a function or so) or whether we are going to access single elements only.
It looks like this is all because of the convert intrinsic called by
__convert_i4_i8[[((test0:e_x(FULL)))]] which is emitted regardless
of the type of e_x (even if it is integer(kind=kind(8))).
Testcase is fixed by
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 158590)
+++ gcc/fortran/resolve.c (working copy)
@@ -4007,8 +4007,7 @@ gfc_resolve_index (gfc_expr *index, int
index-where) == FAILURE)
return FAILURE;
- if (index-ts.kind != gfc_index_integer_kind
- || index-ts.type != BT_INTEGER)
+ if (index-ts.type != BT_INTEGER)
{
gfc_clear_ts (ts);
ts.type = BT_INTEGER;
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 158590)
+++ gcc/fortran/trans-array.c (working copy)
@@ -2434,6 +2434,7 @@ gfc_conv_array_index_offset (gfc_se * se
gfc_conv_array_data (desc));
index = gfc_build_array_ref (data, index, NULL);
index = gfc_evaluate_now (index, se-pre);
+ index = fold_convert (gfc_array_index_type, index);
/* Do any bounds checking on the final info-descriptor index. */
index = gfc_trans_array_bound_check (se, info-descriptor,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/43326] [fortran-dev Regression] dynamic dispatch with CLASS components
--- Comment #9 from pault at gcc dot gnu dot org 2010-04-21 14:29 --- Created an attachment (id=20453) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20453action=view) Version of fix for fortran-dev This hasn been fully bootstrapped but runs gfortran.dg/dynamic*, proc* and class* OK. Since this is a cut down version of the trunk fix, I will apply the patch as obvious, after bootstrapping and regtesting. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug other/43834] problems when linking in XCode 3.2.2 (gcc build 5659) - static constants are messed?
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 14:37 --- Report it to Apple. The version Apple ships does not resemble anything like an FSF release that would still be supported. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43834
[Bug tree-optimization/43833] false warning: array subscript is above array bounds with -O3
--- Comment #1 from jiez at gcc dot gnu dot org 2010-04-21 14:48 --- The patch: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01304.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
[Bug middle-end/43835] New: IPA-SRA doesn't rewrite attributes
The testcase I'm attaching shortly will be miscompiled by IPA-SRA. The problem is, that SRA splits the pointer argument 'c' of mark_cell into two new parameters, one being a pointer itself, and another int param. But it doesn't rewrite the attribute list of the fndecl, hence the nonnull attributes now apply to the new parameters. That's of course bogus and results in a null-pointer check (on c-p) being optimized out by VRP later. This happens with simply -O2 (on i686 and x86_64, but it's a generic problem). -- Summary: IPA-SRA doesn't rewrite attributes Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: i686-linux GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug middle-end/43835] IPA-SRA doesn't rewrite attributes
--- Comment #1 from matz at gcc dot gnu dot org 2010-04-21 15:08 --- Created an attachment (id=20454) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20454action=view) testcase # gcc -O2 sra-nonnull.c ./a.out Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug middle-end/43836] New: ice with -fexceptions and -fopenmp
The following causes an ICE: cat bug.f90 MODULE dbcsr_work_operations TYPE dbcsr_type END TYPE dbcsr_type TYPE dbcsr_obj TYPE(dbcsr_type) :: m END TYPE dbcsr_obj CONTAINS SUBROUTINE dbcsr_finalize(matrix) TYPE(dbcsr_obj), INTENT(INOUT) :: matrix !$omp single !$omp parallel num_threads(1) CALL dbcsr_merge_data (matrix%m, sort_data ) !$omp end parallel !$omp end single END SUBROUTINE dbcsr_finalize END MODULE dbcsr_work_operations gfortran -v -c -O0 -fopenmp -fexceptions bug.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_4_4_branch/gcc/configure --prefix=/data03/vondele/gcc_4_4_branch/build --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605] (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-O0' '-fopenmp' '-fexceptions' '-mtune=generic' '-pthread' /data03/vondele/gcc_4_4_branch/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.4/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -O0 -version -fopenmp -fexceptions -fintrinsic-modules-path /data03/vondele/gcc_4_4_branch/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.4/finclude -o /tmp/ccff06dK.s GNU Fortran (GCC) version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.4 20100421 (prerelease) [gcc-4_4-branch revision 158605], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 bug.f90: In function dbcsr_finalize: bug.f90:12: internal compiler error: Segmentation fault -- Summary: ice with -fexceptions and -fopenmp Product: gcc Version: 4.4.4 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug middle-end/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-21 15:30 --- 4.3.1 ([gcc-4_3-branch revision 135036]) does not fail, so marking as regression. 4.5.0 works as well with 4.4.4 I have this backtrace: (gdb) bt #0 bitmap_element_allocate (head=0x10284c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/bitmap.c:206 #1 0x004d076c in bitmap_set_bit (head=0x10284c0, bit=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/bitmap.c:638 #2 0x009ba0b0 in compute_dominance_frontiers (frontiers=0x1028440) at /data03/vondele/gcc_4_4_branch/gcc/gcc/cfganal.c:1278 #3 0x006d5849 in rewrite_into_ssa () at /data03/vondele/gcc_4_4_branch/gcc/gcc/tree-into-ssa.c:2256 #4 0x006171db in execute_one_pass (pass=0xf795c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:1277 #5 0x00617415 in execute_pass_list (pass=0xf795c0) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:1326 #6 0x00617735 in execute_ipa_pass_list (pass=0xf79800) at /data03/vondele/gcc_4_4_branch/gcc/gcc/passes.c:890 #7 0x00805301 in cgraph_optimize () at /data03/vondele/gcc_4_4_branch/gcc/gcc/cgraphunit.c:1237 #8 0x00490d6a in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/fortran/f95-lang.c:240 #9 0x006a7fb4 in toplev_main (argc=value optimized out, argv=value optimized out) at /data03/vondele/gcc_4_4_branch/gcc/gcc/toplev.c:970 #10 0x7f91de717436 in __libc_start_main () from /lib64/libc.so.6 #11 0x004061a9 in _start () -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.4.4 Known to work||4.3.1 4.5.0 Summary|ice with -fexceptions and - |[4.4 Regression] ice with - |fopenmp |fexceptions and -fopenmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug middle-end/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug middle-end/43835] [4.5 Regression] IPA-SRA doesn't rewrite attributes
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-21 15:51 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-21 15:51:44 date|| Summary|IPA-SRA doesn't rewrite |[4.5 Regression] IPA-SRA |attributes |doesn't rewrite attributes Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug middle-end/43835] [4.5 Regression] IPA-SRA doesn't rewrite attributes
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-04-21 16:04 --- Mine -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-21 15:51:44 |2010-04-21 16:04:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43835
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-21 16:08 --- I've just been bitten by this on Solaris 10, and I think lots more people will be now that gcc 4.5.0 has been released. The problem is made worse if libstdc++ (or libgomp etc.) is built with symbol versioning enabled because libstdc++.so.6 depends on libgcc_s.so.1 (GCC_4.2.0) rather than just libgcc_s.so.1 The 4.2.0 version is needed for _Unwind_GetIPInfo which was added in 4.2.0 (see Bug 27880 et al) and symbol versioning was not used by default on Solaris prior to 4.5.0, see Bug 38923 It is not enough to set the executable's RPATH because, as mentioned in comment 6, only the RPATH in libstdc++.so is used when resolving its dependencies, not the RPATH in the executable. I believe this is a difference between Solaris and Linux, I think Linux's ld.so uses the executable's RPATH when searching for a shared library's dependencies, Solaris' ld.so.1 *only* uses the RPATH in the shared library when searching for that library's dependncies. This forces the user to use LD_LIBRARY_PATH, rather than letting them choose whether they want to use environment variables at runtime or rely on link-time RPATH values. Whether you think LD_LIBRARY_PATH is more or less evil than RPATH is your business, but I want to be able to make my own decision. I agree that libstdc++ should set RPATH to $ORIGIN, at least on Solaris. It's less important on Linux, since setting RPATH in the final executable will find the desired libgcc_s.so I've removed i686-linux from the Host field, since this is not specific to Linux and is actually a bigger problem on Solaris, where if libgcc_s.so is installed at all it is usually a much older version than on modern Linux distros e.g. /usr/sfw/bin/gcc is 3.4.3 on Solaris 10 My workaround is to export LD_RUN_PATH='$ORIGIN' in my environment before I build gcc, but it would be nice if there was a configure option to do that for all the libs that depend on libgcc_s.so -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||redi at gcc dot gnu dot org GCC host triplet|i686-pc-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
[Bug libstdc++/32354] libstdc++.so.6 missing RPATH
--- Comment #10 from redi at gcc dot gnu dot org 2010-04-21 16:13 --- P.S. the workaround is a hack and not ideal, because it adds RPATH=$ORIGIN to every binary object that gets built including the front-end drivers, cc1plus, collect2 etc. but it is only needed by shared libs that depend on libgcc_s.so That's why I'd rather see a configure option which would cause it to be set only when building those libs -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
[Bug middle-end/43812] [4.5/4.6 Regression] compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-04-21 16:21 --- I have submitted a fix to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01315.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug c++/43818] internal compiler error: Segmentation fault
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-21 16:24 --- I tested on an x86_64 box (with -m32 because your preprocessed source was made on a 32bit box so it was necessary) so I definitely have a lot more memory available I'm still thinking it's a problem with running out of memory, PAE doesn't increase the total memory available to a single process -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43818
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
--- Comment #6 from sje at cup dot hp dot com 2010-04-21 16:27 --- This looks like what I see on ia64-debian-linux-gnu as well. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug middle-end/43812] compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-21 16:31 --- How can this possibly be a regression in 4.5 if -fwhole-program is new there? Regression means worked in an earlier release and there is no earlier release with this feature. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression]|compiling .cc file with - |compiling .cc file with - |fwhole-program results in |fwhole-program results in |ICE, in ipcp_iterate_stage, |ICE, in ipcp_iterate_stage, |at ipa-cp.c:760 |at ipa-cp.c:760 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #39 from aph at gcc dot gnu dot org 2010-04-21 16:34 --- Subject: Bug 40860 Author: aph Date: Wed Apr 21 16:34:01 2010 New Revision: 158611 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158611 Log: 2010-04-19 Andrew Haley a...@redhat.com PR libgcj/40860 * configure.ac: Handle --no-merge-exidx-entries. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug middle-end/43812] [4.5/4.6 Regression] compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-21 16:43 --- -fwhole-program is old. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|compiling .cc file with - |[4.5/4.6 Regression] |fwhole-program results in |compiling .cc file with - |ICE, in ipcp_iterate_stage, |fwhole-program results in |at ipa-cp.c:760 |ICE, in ipcp_iterate_stage, ||at ipa-cp.c:760 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug gcov-profile/43341] pragma pack changes padding in struct gcov_info on 64-bit archs
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-04-21 16:43 --- Created an attachment (id=20455) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20455action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43341
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- Comment #7 from amonakov at gcc dot gnu dot org 2010-04-21 16:45 --- *** This bug has been marked as a duplicate of 43341 *** -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
[Bug gcov-profile/43341] pragma pack changes padding in struct gcov_info on 64-bit archs
--- Comment #2 from amonakov at gcc dot gnu dot org 2010-04-21 16:45 --- *** Bug 43825 has been marked as a duplicate of this bug. *** -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||tglek at mozilla dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43341
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- Comment #8 from amonakov at gcc dot gnu dot org 2010-04-21 16:48 --- Taras, to avoid triggering the problem from firefox you can search for the file (as I remember there is only one in xulrunner) with #pragma pack(1) and does not reset it, and add #pragma pack() in the end of that file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables
--- Comment #14 from jakub at gcc dot gnu dot org 2010-04-21 16:49 ---
Subject: Bug 40040
Author: jakub
Date: Wed Apr 21 16:48:41 2010
New Revision: 158612
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158612
Log:
PR debug/40040
* dwarf2out.c (add_name_and_src_coords_attributes): Add
DW_AT_{,MIPS_}linkage_name even for Fortran decls.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040
[Bug fortran/43326] [fortran-dev Regression] dynamic dispatch with CLASS components
--- Comment #10 from pault at gcc dot gnu dot org 2010-04-21 16:50 --- Subject: Bug 43326 Author: pault Date: Wed Apr 21 16:49:28 2010 New Revision: 158613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158613 Log: 2010-04-21 Paul Thomas pa...@gcc.gnu.org PR fortran/43326 * resolve.c (resolve_typebound_function): Renamed resolve_class_compcall.Do all the detection of class references here. (resolve_typebound_subroutine): resolve_class_typebound_call renamed. Otherwise same as resolve_typebound_function. (gfc_resolve_expr): Call resolve_typebound_function. (resolve_code): Call resolve_typebound_subroutine. 2010-04-21 Paul Thomas pa...@gcc.gnu.org PR fortran/43326 * gfortran.dg/dynamic_dispatch_9.f03: New test. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev branches/fortran-dev/gcc/fortran/resolve.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug fortran/43326] [fortran-dev Regression] dynamic dispatch with CLASS components
--- Comment #11 from pault at gcc dot gnu dot org 2010-04-21 16:51 --- Fixed on fortran-dev. Thanks, as usual, for the report, Janus, and thanks for the reminder, Dominique :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug c++/43824] C++0x feature inline namespace enabled under -std=c++98; no warnings
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-21 16:54 --- (In reply to comment #2) Right, this is a GNU extension used to implement the library, which was later standardised. We also support 'long long' in C++03 mode. Yes but with -pedantic we do warn about long long: t.cc:1:1: warning: ISO C++ 1998 does not support âlong longâ (and with -pedantic-error we error out). So the argument using long long as an example is incorrect. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2010-04-21 16:54:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
[Bug gcov-profile/43341] pragma pack changes padding in struct gcov_info on 64-bit archs
--- Comment #3 from amonakov at gcc dot gnu dot org 2010-04-21 16:54 --- (In reply to comment #1) Created an attachment (id=20455) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20455action=view) [edit] proposed patch GCC generates gcov structures at runtime, and #pragma pack(1) in the source file affects their layout. We probably can reset the alignment in create_coverage to avoid that. The above patch implements a different approach -- it rearranges structure fields and manually sets alignment so that layout does not depend on current structure packing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43341
[Bug fortran/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
-- 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 Component|middle-end |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-21 16:56:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #13 from paolo dot carlini at oracle dot com 2010-04-21 17:04 --- static_asserts are fine, of course. Otherwise, if the real issue is that errors coming from system headers are suppressed and shouldn't, sometimes, from the user point of view, that is a **front-end** issue, about the semantics of the pragma. Actually, I'm sure it has been discussed already, somewhere, Ian also participated (this PR could well be a duplicate), and the front-end people should be involved in the discussion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug c++/43824] C++0x feature inline namespace enabled under -std=c++98; no warnings
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-21 17:04 --- good point then #pragma GCC system_header must disable the warning, so we can use inline namespaces and variadic templates in the standard library -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #40 from aph at gcc dot gnu dot org 2010-04-21 17:05 --- Subject: Bug 40860 Author: aph Date: Wed Apr 21 17:04:42 2010 New Revision: 158614 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158614 Log: 2010-04-19 Andrew Haley a...@redhat.com PR libgcj/40860 * configure.ac: Handle --no-merge-exidx-entries. Modified: branches/gcc-4_4-branch/libjava/ChangeLog branches/gcc-4_4-branch/libjava/configure branches/gcc-4_4-branch/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug fortran/43326] [fortran-dev Regression] dynamic dispatch with CLASS components
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-21 17:09 --- thanks for the reminder, Dominique You're welcome!-) Just another one: modulo spaces(?) gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03 in trunk and gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03 in fortran-dev are identical. It looks like gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03 in fortran-dev is a trimmed down version to cope with the regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #14 from paolo dot carlini at oracle dot com 2010-04-21 17:11 --- Forgot: before doing anything about those diagnostic issues, we should double check what other compilers do with / without our library, thus, say current ICC / something else (even among those available online, Comeau, Dinkumware...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-21 17:41 --- Comeau warns on the auto_ptr case. boost::shared_ptr refuses to compile if the type is incomplete -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug fortran/43837] New: Set TREE_NOTHROW also on libgfortran library calls
Follow up to PR 43836 and http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html It would be good to set TREE_NOTHROW also on libgfortran library calls that are known not to throw exceptions (I guess most of them, except those that do IO). POSIX lists which libc functions have to and can throw, cf. http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05 In the glibc headers one can also look for functions which use __THROW on prototypes (__THROW means the function never throws) and which don't; also the __NTH macro and __REDIRECT_NTH. In libgfortran itself, one can use __attribute__ ((nothrow)), cf. http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html In the front end (call to library routines) TREE_NOTHROW. -- Summary: Set TREE_NOTHROW also on libgfortran library calls Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43837
[Bug fortran/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-21 17:48 --- See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up at PR 43837 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug gcov-profile/43825] gcov is initialized wrong on x86_64
--- Comment #9 from tglek at mozilla dot com 2010-04-21 17:48 --- (In reply to comment #8) Taras, to avoid triggering the problem from firefox you can search for the file (as I remember there is only one in xulrunner) with #pragma pack(1) and does not reset it, and add #pragma pack() in the end of that file. This wouldn't have even crossed my mind. Works great, thanks for debugging this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43825
[Bug fortran/43836] [4.4 Regression] ice with -fexceptions and -fopenmp
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-21 17:53 --- (In reply to comment #2) See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up at PR 43837 beats the speed of light... thanks. A very practical question. Is Fortran code compiled with -fexceptions necessarily miscompiled, or will it behave properly. The reason I'm asking (and found the bug) is that openmpi adds -fexceptions by default via the mpif90 script at compilation time. -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43836
[Bug c++/43838] New: Incorrect output from abi::__cxa_demangle
g++ -v: Using built-in specs. Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux Thread model: posix gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC) Command line used to compile the example program: g++ -o main main.cpp For some template types the output of abi::__cxa_demangle is incorrect. This was working OK in version 4.3.0 Example program is attached Expected output (when compiled with gcc version 4.3.0 20080428 (Red Hat 4.3.0-8)): Mangled name: N5boost6tuples5tupleIN5abcde5xyzzz3abc4abcd3AaaENS5_4klmn16BaaaENS0_9null_typeES9_S9_S9_S9_S9_S9_S9_EE Demangled name: boost::tuples::tupleabcde::xyzzz::abc::abcd::Aaa, abcde::xyzzz::abc::abcd::klmn::Baaa, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type Actual output (when compiled with gcc version 4.4.3 20100127 (Red Hat 4.4.3-4)): Mangled name: N5boost6tuples5tupleIN5abcde5xyzzz3abc4abcd3AaaENS5_4klmn16BaaaENS0_9null_typeES9_S9_S9_S9_S9_S9_S9_EE Demangled name: boost::tuples::tupleabcde::xyzzz::abc::abcd::Aaa, abcde::xyzzz::abc::abcd::klmn::Baaa, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_ty As you can see the last occurrence of null_type gets truncated to null_ty. The mangled name is the same for both compiler versions. Note that after making some of the namespace or class names shorter the output is correct. -- Summary: Incorrect output from abi::__cxa_demangle Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: slawomir at ezono dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug c++/43838] Incorrect output from abi::__cxa_demangle
--- Comment #1 from slawomir at ezono dot com 2010-04-21 18:15 --- Created an attachment (id=20456) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20456action=view) Preprocessed source of example program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #16 from paolo dot carlini at oracle dot com 2010-04-21 18:18 --- Note I'm traveling, thus I have limited capabilities. I strongly recommend digging out that conversation about the pragma itself, with Ian too involved, and trying to put to good use static_asserts and any other template-based tricks, per boost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #17 from redi at gcc dot gnu dot org 2010-04-21 18:26 --- ok, thanks for the pointers, I'll hunt for the discussion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug rtl-optimization/31485] C complex numbers, amd64 SSE, missed optimization opportunity
--- Comment #10 from irar at il dot ibm dot com 2010-04-21 18:33 --- Thanks. So, it is not always profitable and requires a cost model. I am now working on cost model for basic block vectorization, I can look at this once we have one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
[Bug java/43839] New: libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix
libjava doesn't link libgcj with -liconv during build when
--with-libiconv-prefix=/opt/local is used, and no corresponding -L for the
-liconv is issued on the link line when running the libjava testsuite (jni.exp)
for the FAIL: PR16923 run testcase:
Executing on host: /Users/mrs/net/gcc-java/gcc/xgcc
-B/Users/mrs/net/gcc-java/gcc/
/Users/mrs/net/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.c
-bind_at_load -multiply_defined suppress -I. -I..
-I/Users/mrs/net/gcc/libjava/testsuite/libjava.jni
-I/Users/mrs/net/gcc/libjava/testsuite/../include
-I/Users/mrs/net/gcc/libjava/testsuite/../classpath/include
-fdollars-in-identifiers
-L/Users/mrs/net/gcc-java/x86_64-apple-darwin10/./libjava/.libs -ljvm
-shared-libgcc -lgcj -liconv -lm -o PR16923(timeout = 300)
The correct bit can be found in the Makefile:
$ grep LTLIBICO x86_64-apple-darwin10/libjava/Makefile
LTLIBICONV = -L/opt/local/lib -liconv -R/opt/local/lib
The spec file appears it would work:
$ cat x86_64-apple-darwin10/libjava/libgcj.spec
[ ... ]
%rename lib liborig
*lib: %{s-bc-abi:} -lgcj -lm -L/opt/local/lib -liconv -lpthread
-allow_stack_execute \
-ldl %(libgcc) %(liborig)
[ ... ]
as well.
This was reported by Jack, in http://gcc.gnu.org/ml/java/2010-02/msg3.html,
but seems unresolved.
xgcc (GCC) 4.5.0 20100324 (experimental) [trunk revision 157698]
--
Summary: libjava incorrectly uses -liconv in testsuite, jni.exp
when using --with-libiconv-prefix
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at gcc dot gnu dot org
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43839
[Bug java/43086] PR16923 fails with Assertion failed: (class_id)
--- Comment #2 from mrs at gcc dot gnu dot org 2010-04-21 18:39 --- When I run it by hand, I get: $ /Users/mrs/net/gcc-java/gcc/xgcc -B/Users/mrs/net/gcc-java/gcc/ /Users/mrs/net/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.c -bind_at_load -multiply_defined suppress -I. -I.. -I/Users/mrs/net/gcc/libjava/testsuite/libjava.jni -I/Users/mrs/net/gcc/libjava/testsuite/../include -I/Users/mrs/net/gcc/libjava/testsuite/../classpath/include -fdollars-in-identifiers -L/Users/mrs/net/gcc-java/x86_64-apple-darwin10/./libjava/.libs -ljvm -shared-libgcc -ldl -lgcj -L/opt/local/lib -liconv -lm-o PR16923 $ export CLASSPATH=~/net/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.jar $ DYLD_LIBRARY_PATH=../.libs:../../libgcc:/opt/local/lib ./PR16923 optionReceived on x86_64-apple-darwin10 so this would be just a simple matter of ensuring the setting of DYLD_LIBRARY_PATH, CLASSPATH and compiling with -L/opt/local/lib. I suspect DYLD_LIBRARY_PATH and CLASSPATH are already correct. I'm hoping you can confirm this incantation works for you. I've filed PR43839 that covers getting -L added, which I hope resolves this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43086
