[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #15 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-31 06:05:19 UTC --- I hadn't really thought of that, but now I see what a PITA a scale factor 0 is going to be (scale factor 0 is simply padding with zeros and shifting digits): We have to ignore the scale factor, until we decide that we use E editing, at which point we need an additional digit in the result. For efficiency: Maybe we can decide that we use E editing without actually overwriting the original digits at that point yet, so we can go back when we actually switch to E editing and re-do the rounding with the extra digit.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #16 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-31 06:28:25 UTC --- print (rc,g11.1), 2. ! 0.2E+01 expected 2. print (rc,g11.2), 20. ! 0.20E+02 expected 20. print (rc,g11.3), 200. ! 0.200E+03 expected 200. print (rc,g11.4), 2000. ! 0.2000E+04 expected 2000. print (rc,g11.2), .04 ! 0.40 expected 0.40E-01 print (rc,g11.3), .04 ! 0.400 expected 0.400E-01
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.31 06:40:33 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 06:40:33 UTC --- Confirmed, TARGET_MEM_REF expansion needs fixing. This started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=174282
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-05-31 07:31:02 UTC
---
The problem here is that
vol.2_8 ={v} g_324[g_97_22];
is skipped during determination of the vectorization factor, because it has no
uses. The vf is set to 4, and then the analysis fails on the char data-ref.
I think we should just not vectorize when there is a volatile access in a loop.
Is that reasonable?
Thanks,
Ira
[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49190 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-31 07:41:22 UTC --- I've reverted the offending commit. If somebody could confirm that the failures are gone, this PR can be closed. Regress is back to normal. Closing as fixed.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 07:46:22 UTC --- Created attachment 24401 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24401 gcc47-pr49235.patch Untested fix. base might be const0_rtx (seems other constants are moved into offset and base stays const0_rtx), and if there is also offset and nothing else, we end up with (plus:DI (const_int 0) (const_int 16)) and similar.
[Bug testsuite/49239] Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49239 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com Component|middle-end |testsuite --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-05-31 08:00:35 UTC --- I think the problem is I forgot to initialize the output array. I am preparing a patch.
[Bug testsuite/49239] Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49239 --- Comment #3 from irar at gcc dot gnu.org 2011-05-31 08:15:32 UTC --- Author: irar Date: Tue May 31 08:15:25 2011 New Revision: 174469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174469 Log: PR testsuite/49239 * gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c: Initialize the output array. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
--- Comment #4 from rguenther at suse dot de rguenther at suse dot de
2011-05-31 08:22:51 UTC ---
On Tue, 31 May 2011, irar at il dot ibm.com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-05-31 07:31:02
UTC ---
The problem here is that
vol.2_8 ={v} g_324[g_97_22];
is skipped during determination of the vectorization factor, because it has no
uses. The vf is set to 4, and then the analysis fails on the char data-ref.
I think we should just not vectorize when there is a volatile access in a
loop.
Is that reasonable?
I think that's reasonable for 4.6. But we don't need to make
data-ref analysis fail just because of volatile references - we for
example can easily unroll a loop with volatile loads/stores.
Of course this case seems to be special - how do we deal with
stmts with no uses during vectorization? Or do we assume
they don't happen because usually DCE gets rid of them?
Richard.
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-05-31 08:30:49 UTC --- (In reply to comment #4) I think that's reasonable for 4.6. But we don't need to make data-ref analysis fail just because of volatile references - we for example can easily unroll a loop with volatile loads/stores. Of course this case seems to be special - how do we deal with stmts with no uses during vectorization? Or do we assume they don't happen because usually DCE gets rid of them? We ignore them. But this is under the assumption that they don't have memory accesses. Ira Richard.
[Bug tree-optimization/49234] [4.4/4.5/4.7/4.7 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.4.7 Summary|-Wstrict-overflow gives |[4.4/4.5/4.7/4.7 |obviously unwarranted |Regression] |warning |-Wstrict-overflow gives ||obviously unwarranted ||warning --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 08:35:26 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=139263
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de 2011-05-31 08:43:39 UTC --- On Tue, 31 May 2011, irar at il dot ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-05-31 08:30:49 UTC --- (In reply to comment #4) I think that's reasonable for 4.6. But we don't need to make data-ref analysis fail just because of volatile references - we for example can easily unroll a loop with volatile loads/stores. Of course this case seems to be special - how do we deal with stmts with no uses during vectorization? Or do we assume they don't happen because usually DCE gets rid of them? We ignore them. But this is under the assumption that they don't have memory accesses. Ah, I see. Yes, I guess not vectorizing for volatiles is the way to go then. Richard.
[Bug ada/49240] New: Inherited equality operator of interface not visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49240 Summary: Inherited equality operator of interface not visible Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@codelabs.ch package Types is type Some_Interface is interface; type Some_Type is new Some_Interface with private; type Another_Type is new Some_Interface with private; private type Some_Type is new Some_Interface with null record; type Another_Type is new Some_Interface with null record; end Types; -- with Ada.Text_IO; with Types; procedure Reproducer is use Types; A : Types.Some_Type; begin if A = A then Ada.Text_IO.Put_Line (A is equal to itself); end if; end Reproducer; -- Compiling this code leads to the following error message: reproducer.adb:12:09: call to abstract function must be dispatching According to RM 3.9.4,19/2 the declared types should inherit the equality operator from the nonlimited interface. This problem occurs when two types extending the same interface are declared in the same package. The reproducer compiles fine with GCC 4.3.2 so it seems this is a regression.
[Bug tree-optimization/49234] [4.4/4.5/4.7/4.7 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31
09:02:29 UTC ---
We hit:
163724rguenth /* Similarly, if the new maximum is smaller or larger
than
163724rguenththe previous one, go all the way to +INF. */
163724rguenth if (cmp_max 0 || cmp_max 0)
163724rguenth {
163724rguenth if (!needs_overflow_infinity (TREE_TYPE
(vr_result.max))
163724rguenth || !vrp_var_may_overflow (lhs, phi))
163724rguenth vr_result.max = TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max));
163724rguenth else if (supports_overflow_infinity (TREE_TYPE
(vr_result.max)))
163724rguenth vr_result.max =
163724rguenth positive_overflow_infinity (TREE_TYPE
(vr_result.max));
163724rguenth }
As the IV (i) might overflow, vrp_var_may_overflow returns true.
In particular, chrec is SCEV_NOT_KNOWN. Thus it just in case sets
vr_result.max to +INF(OVF) and later on we warn about it.
Before hitting this code, vr_result contains the right range [0, 2], but it
doesn't know it can safely use that.
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093
--- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-05-31 09:06:04 UTC
---
I am testing this patch then:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 174467)
+++ tree-vect-data-refs.c (working copy)
@@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo
return false;
}
+ if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr
+{
+ if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
+{
+ fprintf (vect_dump, not vectorized: volatile type );
+ print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
+}
+ return false;
+}
+
base = unshare_expr (DR_BASE_ADDRESS (dr));
offset = unshare_expr (DR_OFFSET (dr));
init = unshare_expr (DR_INIT (dr));
Thanks,
Ira
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2011-05-31 09:09:37 UTC --- On Tue, 31 May 2011, irar at il dot ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-05-31 09:06:04 UTC --- I am testing this patch then: Index: tree-vect-data-refs.c === --- tree-vect-data-refs.c (revision 174467) +++ tree-vect-data-refs.c (working copy) @@ -2584,6 +2584,16 @@ vect_analyze_data_refs (loop_vec_info lo return false; } + if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr if (TREE_THIS_VOLATILE (DR_REF (dr))) instead. Richard.
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #9 from Ira Rosen irar at il dot ibm.com 2011-05-31 09:17:26 UTC --- (In reply to comment #8) + if (TYPE_VOLATILE (TREE_TYPE (DR_REF (dr if (TREE_THIS_VOLATILE (DR_REF (dr))) instead. OK. Thanks. Ira Richard.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||48702 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 09:23:53 UTC --- Need to make sure to also backport this then.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 09:26:59 UTC --- (In reply to comment #2) Created attachment 24401 [details] gcc47-pr49235.patch Untested fix. base might be const0_rtx (seems other constants are moved into offset and base stays const0_rtx), and if there is also offset and nothing else, we end up with (plus:DI (const_int 0) (const_int 16)) and similar. Yes, base has to be of pointer type. But I thought get_address_description would untangle this again ... if not it's probably latent pre-MEM_REF as well.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31
09:34:04 UTC ---
get_address_description only does that if TMR_INDEX2 is present:
addr-symbol = NULL_TREE;
if (TMR_INDEX2 (op))
{
gcc_assert (integer_zerop (TMR_BASE (op)));
addr-base = TMR_INDEX2 (op);
}
else
addr-base = TMR_BASE (op);
In this case TMR_BASE (op) is (void *) 0 and TMR_OFFSET is INTEGER_CST, the
rest is all NULL.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 09:44:55 UTC --- Index: gcc/tree-ssa-address.c === --- gcc/tree-ssa-address.c (revision 174469) +++ gcc/tree-ssa-address.c (working copy) @@ -365,7 +365,7 @@ create_mem_ref_raw (tree type, tree alia ??? As IVOPTs does not follow restrictions to where the base pointer may point to create a MEM_REF only if we know that base is valid. */ - if (TREE_CODE (base) == ADDR_EXPR + if ((TREE_CODE (base) == ADDR_EXPR || TREE_CODE (base) == INTEGER_CST) (!index2 || integer_zerop (index2)) (!addr-index || integer_zerop (addr-index))) return fold_build2 (MEM_REF, type, base, addr-offset); might hide the issue again (still worth fixing IMHO), and also makes sense.
[Bug libstdc++/49204] [C++0x] remaining issues in future
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-31 10:52:17 UTC --- also http://lwg.github.com/issues/lwg-active.html#2056
[Bug fortran/49241] New: memory leak with lhs realloc of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241 Summary: memory leak with lhs realloc of zero-sized array Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: xarthisius...@gmail.com Following code causes severe memory leak with gfortran 4.6.0 (also with trunk revision 174463) program ala implicit none type :: array_of_foo real, dimension(:), allocatable :: p end type array_of_foo type(array_of_foo), dimension(:), allocatable :: tab integer, parameter :: lb = 0 integer, parameter :: ub = 2 integer, parameter :: nmax = 10 integer :: i real:: ran do while(.true.) allocate(tab(lb:ub)) allocate(tab(lb)%p(0)) do i = lb+1, ub allocate(tab(i)%p(nmax)) tab(i)%p(:) = [(i,i=1,nmax)] enddo tab(lb)%p = [tab(lb)%p, tab(ub)%p] !!! mem leak if first array has size 0 ! tab(lb)%p = [tab(ub)%p, tab(lb)%p]!!! no mem leak ! clean up do i = lb, ub deallocate(tab(i)%p) enddo deallocate(tab) enddo end program ala lhs realloc of size(0) = [size(0), size(n)] leaks, whereas size(0) = [size(n), size(0)] works fine. Following code does not exhibit this behaviour with Intel compiler (11.1.072)
[Bug debug/49130] discrepancies between DW_AT_name and demangler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 --- Comment #7 from dodji at seketeli dot org dodji at seketeli dot org 2011-05-31 11:16:16 UTC --- jan.kratochvil at redhat dot com gcc-bugzi...@gcc.gnu.org a écrit: --- Comment #6 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-05-30 08:44:43 UTC --- Another issue is with DMGL_VERBOSE. nm -C does not use DMGL_VERBOSE: libstdc++.so.6.0.16.debug 000a4e50 t bool __gnu_cxx::operator==char*, std::string(__gnu_cxx::__normal_iteratorchar*, std::string const, __gnu_cxx::__normal_iteratorchar*, std::string const) But the DIE uses DMGL_VERBOSE: 21836e2: Abbrev Number: 29 (DW_TAG_subprogram) 1836e4 DW_AT_name: (indirect string, offset: 0x2e3f0): operator==char*, std::basic_stringchar 1188ab4: Abbrev Number: 103 (DW_TAG_subprogram) 188ab5 DW_AT_specification: 0x1836e2 1193100: Abbrev Number: 129 (DW_TAG_subprogram) 193102 DW_AT_abstract_origin: 0x188ab4 193106 DW_AT_low_pc : 0xa4e50 I understand that DW_AT_name and DW_AT_MIPS_linkage_name being /gratuitously/ different can be an issue. But here, I understand what you are highlighting as a different matter. nm -C is compressing[1] the output to avoid cluttering it too much. But DW_AT_name really represents the name of the operator as written in the source code[2], with its template parameters replaced with their corresponding arguments. How would that be an issue? [1]: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling, look for 'compression' (chapter 5.1.8 there). [2]: DWARF4 spec, 1.21 [Identitier Names] says: DW_AT_name attribute, whose value is a string representing the name as it appears in the source program
[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31
11:54:23 UTC ---
Smaller, self-contained testcase:
! PR fortran/49103
! { dg-do run }
integer :: a(2), b(2), i, j
open (10, status='scratch')
do j = 1, 2
a = (/ 0, 0 /)
b = (/ 1, 1 /)
do i = 1, 2
write (10, *) a
write (10, *) b
end do
end do
rewind (10)
do i = 0, 7
read (10, *) a
if (any (a .ne. mod (i, 2))) call abort
end do
close (10)
end
[Bug libgcj/49193] __sync_xxxx builtins aren't used in sysdep/*/locks.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49193 --- Comment #1 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-05-31 11:53:37 UTC --- Author: hjl Date: Tue May 31 11:53:34 2011 New Revision: 174471 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174471 Log: Use __sync_bool_compare_and_swap in x86 locks.h. 2011-05-31 H.J. Lu hongjiu...@intel.com PR libgcj/49193 * configure.host (sysdeps_dir): Set to i386 for x86_64. * sysdep/i386/locks.h (compare_and_swap): Call __sync_bool_compare_and_swap. (release_set): Call write_barrier (). * sysdep/x86-64/locks.h: Removed. Removed: trunk/libjava/sysdep/x86-64/locks.h Modified: trunk/libjava/ChangeLog trunk/libjava/configure.host trunk/libjava/sysdep/i386/locks.h
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 --- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-31 12:09:10 UTC --- Author: dodji Date: Tue May 31 12:09:06 2011 New Revision: 174472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174472 Log: Fix PR debug/49047 gcc/ * dwarf2out.c (gen_subprogram_die): Emit linkage name attribute for concrete functions containing the code of cloned functions. gcc/testsuite/ * g++.dg/debug/dwarf2/cdtor-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-31 12:17:12 UTC --- Author: dodji Date: Tue May 31 12:17:06 2011 New Revision: 174473 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174473 Log: Revert Fix PR debug/49047 This reverts commit ce20032a8ad4d9d4fa37192e2ecc73cb257094e8. Added: trunk/libjava/sysdep/x86-64/locks.h - copied, changed from r174472, trunk/libjava/sysdep/i386/locks.h Removed: trunk/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/libjava/ChangeLog trunk/libjava/configure.host trunk/libjava/sysdep/i386/locks.h
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 --- Comment #7 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-31 12:17:25 UTC --- Author: dodji Date: Tue May 31 12:17:21 2011 New Revision: 174474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174474 Log: Fix PR debug/49047 gcc/ * dwarf2out.c (gen_subprogram_die): Emit linkage name attribute for concrete functions containing the code of cloned functions. gcc/testsuite/ * g++.dg/debug/dwarf2/cdtor-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48953] [4.7 Regression] ICE: verify_gimple failed: type mismatch in array reference with -flto and struct with vararray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48953 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.7.0 |4.6.1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 12:24:14 UTC --- Fixed.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #17 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-31 12:30:00 UTC --- As you can tell, finding the magic formula with this new approach is not a trivial effort. ;) My fear is that there is an unlimited number of corner cases.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 12:34:45 UTC --- Author: jakub Date: Tue May 31 12:34:42 2011 New Revision: 174478 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174478 Log: PR rtl-optimization/49235 * tree-ssa-address.c (gen_addr_rtx): Ignore base if it is const0_rtx. (create_mem_ref_raw): Create MEM_REF even if base is INTEGER_CST. * gcc.dg/pr49235.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49235.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-address.c
[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49093 --- Comment #10 from irar at gcc dot gnu.org 2011-05-31 12:31:09 UTC --- Author: irar Date: Tue May 31 12:31:04 2011 New Revision: 174477 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174477 Log: PR tree-optimization/49093 * tree-vect-data-refs.c (vect_analyze_data_refs): Fail for volatile data references. Added: trunk/gcc/testsuite/gcc.dg/vect/pr49093.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug fortran/49241] memory leak with lhs realloc of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-31 12:36:23 UTC --- The memory the program needs increases continuously as top shows; it takes about 5min on my computer before the OS kills it (out of memory). If one does not use an endless loop but a finite loop, it shows no leakage with neither valgrind nor totalview. Also the result seems to be fine - except that the memory consumption simply grows ... Slightly reduced test case: program ala implicit none type :: array_of_foo real, dimension(:), allocatable :: p end type array_of_foo type(array_of_foo), dimension(:), allocatable :: tab integer :: i do allocate(tab(0:1)) allocate(tab(0)%p(0)) tab(1)%p = [(i,i=1,10)] ! Realloc-on assignment (fine!) tab(0)%p = [tab(0)%p, tab(1)%p] ! realloc-on-assignment. Culprit? deallocate(tab) end do end program ala
[Bug c/48985] bogus buffer overflow warning and abort on static flexible array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48985 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.1 Resolution||FIXED Target Milestone|--- |4.6.1 Known to fail|4.6.1 |4.6.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 12:26:26 UTC --- Fixed for 4.6.1.
[Bug rtl-optimization/49235] [4.7 Regression] ICE: in int_mode_for_mode, at stor-layout.c:424 with -O -fno-delete-null-pointer-checks -fno-tree-scev-cprop -ftree-vectorize -fno-vect-cost-model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49235 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 12:39:55 UTC --- Fixed.
[Bug middle-end/48953] [4.7 Regression] ICE: verify_gimple failed: type mismatch in array reference with -flto and struct with vararray
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48953 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 12:23:58 UTC --- Author: rguenth Date: Tue May 31 12:23:55 2011 New Revision: 174475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174475 Log: 2011-05-31 Richard Guenther rguent...@suse.de Backport from mainline 2011-05-11 Richard Guenther rguent...@suse.de PR middle-end/48953 * tree-inline.c (remap_gimple_op_r): Also remap types of MEM_REFs. * gcc.dg/torture/pr48953.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48953.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-inline.c
[Bug c/48985] bogus buffer overflow warning and abort on static flexible array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48985 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-31 12:25:59 UTC --- Author: rguenth Date: Tue May 31 12:25:52 2011 New Revision: 174476 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174476 Log: 2011-05-31 Richard Guenther rguent...@suse.de Backport from mainline 2011-05-19 Richard Guenther rguent...@suse.de PR middle-end/48985 * tree-object-size.c (addr_object_size): If the pointed-to variable is a decl use DECL_SIZE_UNIT instead of TYPE_SIZE_UNIT. * gcc.dg/builtin-object-size-11.c: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/builtin-object-size-11.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-object-size.c
[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49103 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 13:28:17 UTC --- Created attachment 24402 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24402 gcc46-pr49103.patch While micha's patch is the way to go for the trunk, it most likely isn't backportable. This untested hack is an attempt to avoid reverting my patch if the vars aren't stored in bbs with significant code motion. If anyone has better place to set the bit, I'd appreciate it.
[Bug libstdc++/49204] [C++0x] remaining issues in future
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49204 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-31 13:40:03 UTC --- We should also make std::async check the system load when deciding whether to run asynchronously or deferred. We should be able to reuse GNU Make's code for deciding whether to run a new job or not, see load_too_high() in job.c
[Bug bootstrap/49242] New: Bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49242 Summary: Bootstrap comparison failure Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.a.richm...@nasa.gov Host: alpha-unknown-linux-gnu Target: alpha-unknown-linux-gnu Build: alpha-unknown-linux-gnu gcc failed to bootstrap on an DEC alpha machine running Debian Linux 5.0: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-loop-im.o differs gcc/cfgexpand.o differs gcc/ira-build.o differs gcc/var-tracking.o differs gcc/df-core.o differs gcc/bb-reorder.o differs gcc/reginfo.o differs gcc/sel-sched-ir.o differs gcc/df-problems.o differs gcc/gimplify.o differs gcc/tree.o differs gcc/sparseset.o differs gcc/tree-affine.o differs gcc/varasm.o differs gcc/cfgloopmanip.o differs gcc/haifa-sched.o differs gcc/loop-invariant.o differs gcc/ipa-inline-analysis.o differs gcc/build/genrecog.o differs gcc/build/genautomata.o differs gcc/build/genattrtab.o differs gcc/build/genoutput.o differs gcc/cselib.o differs gcc/tree-into-ssa.o differs gcc/bitmap.o differs gcc/tree-eh.o differs gcc/simplify-rtx.o differs gcc/gimple-fold.o differs gcc/tree-ssa-threadedge.o differs gcc/calls.o differs gcc/tree-ssa-copy.o differs gcc/ipa-cp.o differs gcc/tree-cfg.o differs gcc/graphds.o differs gcc/lto-symtab.o differs gcc/ira-conflicts.o differs gcc/loop-unswitch.o differs gcc/c-decl.o differs gcc/optabs.o differs gcc/dwarf2asm.o differs gcc/ddg.o differs gcc/cse.o differs gcc/tree-inline.o differs gcc/stor-layout.o differs gcc/cfgloop.o differs gcc/langhooks.o differs gcc/tree-vect-slp.o differs gcc/cfglayout.o differs gcc/cfghooks.o differs gcc/dfp.o differs gcc/dwarf2out.o differs gcc/ifcvt.o differs gcc/tree-sra.o differs gcc/expr.o differs gcc/recog.o differs gcc/except.o differs gcc/df-scan.o differs gcc/tree-vect-patterns.o differs gcc/tree-vect-loop.o differs gcc/alpha.o differs gcc/sched-rgn.o differs gcc/function.o differs gcc/tree-nested.o differs gcc/ipa-prop.o differs gcc/resource.o differs gcc/builtins.o differs gcc/tree-vrp.o differs gcc/ira-lives.o differs gcc/combine.o differs gcc/tree-dfa.o differs gcc/passes.o differs gcc/cfg.o differs gcc/sel-sched.o differs gcc/lto/lto-object.o differs gcc/lto/lto-lang.o differs gcc/emit-rtl.o differs gcc/expmed.o differs gcc/tree-ssa-operands.o differs gcc/tree-complex.o differs gcc/tree-vect-stmts.o differs gcc/pretty-print.o differs gcc/sched-ebb.o differs gcc/tree-ssa-forwprop.o differs gcc/cfgrtl.o differs gcc/ebitmap.o differs gcc/sbitmap.o differs gcc/ira-color.o differs gcc/tree-ssa-loop-niter.o differs gcc/tree-data-ref.o differs gcc/loop-unroll.o differs gcc/omega.o differs gcc/tree-ssa-math-opts.o differs gcc/tree-predcom.o differs gcc/tree-ssa-loop-ivopts.o differs gcc/fold-const.o differs gcc/tree-ssa-structalias.o differs gcc/tree-ssa-reassoc.o differs gcc/tree-ssa-sccvn.o differs gcc/gimple.o differs gcc/c-family/c-format.o differs gcc/c-family/c-common.o differs gcc/fortran/resolve.o differs gcc/fortran/trans-decl.o differs gcc/fortran/trans-expr.o differs gcc/fortran/trans-intrinsic.o differs gcc/fortran/trans-types.o differs gcc/fortran/expr.o differs gcc/fortran/target-memory.o differs gcc/fortran/trans-array.o differs gcc/fortran/trans.o differs gcc/fortran/intrinsic.o differs gcc/fortran/interface.o differs gcc/fortran/trans-openmp.o differs gcc/fortran/simplify.o differs gcc/fortran/trans-io.o differs gcc/fortran/symbol.o differs gcc/fortran/arith.o differs gcc/fortran/array.o differs gcc/c-parser.o differs gcc/omp-low.o differs gcc/lto-cgraph.o differs gcc/opts.o differs gcc/tree-ssa-dom.o differs gcc/sched-deps.o differs gcc/c-typeck.o differs gcc/dominance.o differs make[2]: *** [compare] Error 1
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 --- Comment #20 from Martin Otte otte.martin at epa dot gov 2011-05-31 14:05:17 UTC --- Created attachment 24403 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24403 Example program that causes an ICE
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Martin Otte otte.martin at epa dot gov changed: What|Removed |Added CC||otte.martin at epa dot gov --- Comment #21 from Martin Otte otte.martin at epa dot gov 2011-05-31 14:12:45 UTC --- I attached a small example program that is causing an internal compiler error for me with gfortran 4.6. I was going to submit a new bug report, but a search suggests that I am probably running into this bug, so I'll submit my small example code here. I have a few codes with pointers to derived type components that don't work with gfortran 4.6, so this bug is the only thing that is keeping me from using gfortran regularly.
[Bug target/49238] [4.5/4.6/4.7 Regression] [SH] ICE in extract_insn, at recog.c:2113
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49238
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.4.5
Keywords||ice-on-valid-code
Last reconfirmed||2011.05.31 14:32:50
CC||kkojima at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|ICE in extract_insn, at |[4.5/4.6/4.7 Regression]
|recog.c:2113|[SH] ICE in extract_insn,
||at recog.c:2113
Known to fail||4.5.4, 4.6.0, 4.7.0
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-05-31
14:32:50 UTC ---
This might be a fallout of the patch in
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01211.html
I'm testing the patch below.
--- ORIG/trunk/gcc/config/sh/sh.c2011-05-31 12:06:18.0 +0900
+++ trunk/gcc/config/sh/sh.c2011-05-31 23:14:33.0 +0900
@@ -2199,6 +2199,13 @@ expand_cbranchdi4 (rtx *operands, enum r
{
operands[1] = op1h;
operands[2] = op2h;
+ if (reload_completed
+ ! arith_reg_or_0_operand (op2h, SImode)
+ (true_regnum (op1h) || (comparison != EQ comparison != NE)))
+{
+ emit_move_insn (scratch, operands[2]);
+ operands[2] = scratch;
+}
}
operands[3] = skip_label = gen_label_rtx ();
quote needed
Hello, We will like to know if you can source for this SHURE MICROPHONE andM-AUDIO SOUND CARD Kindly advice on the unit price and the availability,if you can source for the supply SHURE WIRED MICROPHONE SYSTEMS: SHURE WIRED SM58LC SM57. DMK57-52 Drum Mic Kit PGX24/SM58 M-Audio Delta 1010 LT Sound card - 96 kHz - 24-bit we will be waiting to read back from you the unit cost on each products, so that we can advice on the quantity needed on each Regards Dave
[Bug fortran/49241] memory leak with lhs realloc of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241 --- Comment #2 from Kacper Kowalik xarthisius.kk at gmail dot com 2011-05-31 15:12:19 UTC --- (In reply to comment #1) The memory the program needs increases continuously as top shows; it takes about 5min on my computer before the OS kills it (out of memory). If one does not use an endless loop but a finite loop, it shows no leakage with neither valgrind nor totalview. Also the result seems to be fine - except that the memory consumption simply grows ... Slightly reduced test case: It's not caused by reallocation, rather by array constructor? Test case without lhs realloc: program ala implicit none type :: array_of_foo real, dimension(:), allocatable :: p end type array_of_foo type(array_of_foo), dimension(:), allocatable :: tab integer :: i, nn do allocate(tab(1:2)) allocate(tab(1)%p(0)) allocate(tab(2)%p(1)) tab(2)%p(1) = 1.0 nn = size( [tab(1)%p, tab(2)%p] ) deallocate(tab(2)%p) deallocate(tab(1)%p) deallocate(tab) end do end program ala
[Bug driver/49178] [4.6/4.7 Regression] Space between linker option and library in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49178 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 15:34:00 UTC --- But the spaces in between -l and library name are solely on the Driving: line, which autoconf omits: # gfortran 4.3 outputs lines setting COLLECT_GCC_OPTIONS, COMPILER_PATH, # LIBRARY_PATH; skip all such settings. ac_[]_AC_LANG_ABBREV[]_v_output=`eval $ac_link AS_MESSAGE_LOG_FD1 21 | sed '/^Driving:/d; /^Configured with:/d; '/^[[_$as_cr_Letters]][[_$as_cr_alnum]]*=/d` AS_ECHO([$ac_[]_AC_LANG_ABBREV[]_v_output]) AS_MESSAGE_LOG_FD _AC_LANG_PREFIX[]FLAGS=$ac_save_[]_AC_LANG_PREFIX[]FLAGS so I don't see why it should make any difference. Even autoconf 2.59 did have something similar.
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-31 16:05:49 UTC --- The patch seems to work. I now get the ICE at output_die (already reported) but also new /abuild/jh/trunk-install/bin/g++ -flto=24 -fuse-linker-plugin -o dump_syms -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -fno-strict-aliasing -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -O3 -lpthread-Wl,-rpath-link,/abuild/jh/build-mozilla-new12/dist/bin -Wl,-rpath-link,/usr/local/lib -static host_dump_syms.o ../../../../../../../toolkit/crashreporter/google-breakpad/src/common/linux/libhost_breakpad_linux_common_s.a ../../../../../../../toolkit/crashreporter/google-breakpad/src/common/libhost_breakpad_common_s.a ../../../../../../../toolkit/crashreporter/google-breakpad/src/common/dwarf/libhost_breakpad_dwarf_s.a In file included from /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_tree.h:930:0, from :311: /abuild/jh/mozilla-central2/mozilla-central/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc: In function 'FindElfClassTextSection': /abuild/jh/mozilla-central2/mozilla-central/toolkit/crashreporter/google-breakpad/src/common/linux/file_id.cc:133:73: internal compiler error: in gen_typedef_die, at dwarf2out.c:21064 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [/tmp/ccaKinu0.ltrans21.ltrans.o] Error 1 Shall I try to get testcase?
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.31 16:16:36 AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dodji Seketeli dodji at gcc dot gnu.org 2011-05-31 16:16:56 UTC --- Fixed in trunk (4.7)
[Bug c/49243] New: attribute((returns_twice)) doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49243 Summary: attribute((returns_twice)) doesn't work Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se According to the documentation, attribute((returns_twice)) is supposed to allow people to call alternate implementations of setjmp-like functions. It doesn't work. In my test case, calling _setjmp (glibc's name) works and prevents inlining and other optimizations that are invalid in the presence of setjmp and longjmp, but calling my_setjmp (declared with returns_twice) doesn't prevent those invalid optimizations. This results in important side-effects disappearing if my longjmp replacement is called. The test case is a little long to inline here (114 lines) so I'll summarize. There's a decoder that reads and processes characters, and it's called in a loop to process strings of unknown length. In the real application it's possible for the input to be followed by an inaccessible page. This is handled by a wrapper function that calls setjmp() before calling the decoding loop, and having the read fault handler longjmp to the wrapper, which then returns a special value. The test case simulates the read fault by calling longjmp() on the second input character. In case of a read fault the toplevel needs to know the corresponding invalid input address. To do this it passes down the address of a local variable that initially points to the start of the input. The decoder loop increments this variable after each successful decoding step. After a read fault, the toplevel uses the updated variable to see how much was successfully decoded. The purpose of the intermediate wrapper function and passing down a pointer by reference is to limit the number of auto variables that become indeterminate after a longjmp, and to avoid having to mark auto variables as volatile, see the longjmp spec in C99 TC2 or C1X. The real application is sort-of embedded and uses it's own mini-libc, including setjmp/longjmp replacements written in assembly code. The test case simulates that by wrapping libc's setjmp behind new names, and declares the setjmp() replacement with __attribute__((returns_twice)) following gcc's documentation. The test case can also be compiled to use libc's setjmp as-is. First try with libc's setjmp as-is: gcc -O2 returns-twice-bug.c; ./a.out (No abort == success.) Now try with the setjmp replacement: gcc -O2 -DMYSETJMP returns-twice-bug.c ; ./a.out Abort What happened is that the read fault was detected but the toplevel variable that should have been updated to point to the invalid address wasn't. Repeating the above two gcc calls with -S and comparing the .s files one sees that the wrapper function with the setjmp call is eliminated and inlined into the toplevel, and the decoding loop no longer writes to the in-memory pointer variable. Now try again with the setjmp replacement but declare the wrapper function with __attribute__((noinline)): gcc -O2 -DMYSETJMP -DKLUDGE returns-twice-bug.c ; ./a.out (No abort == success.) Comparing the assembly code from the first and third steps we see that they are now essentially the same, differing only in the third step code having the setjmp/longjmp wrapper function definitions, the labels in subsequent code, and the name of the setjmp function called from the wrapper. So the important effect of calling libc's setjmp is that it prevents inlining of the calling function, but declaring a function of a different name but with returns_twice doesn't have that required effect. That's the bug. A quick check shows that glibc's setjmp() isn't declared with returns_twice, and gcc recognizes it from its name alone. Apparently the name-based checks cause more magic to happen than attribute((returns_twice)). This bug occurs on x86_64-linux and i686-linux with every gcc-4.x including current 4.7 trunk. With gcc-3.x it doesn't occur. I haven't checked non-x86 targets.
[Bug c/49243] attribute((returns_twice)) doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49243 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-05-31 16:22:43 UTC --- Created attachment 24404 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24404 test case
[Bug c++/44870] [4.7 regression] [C++0x] error when calling function with rvalue argument inside template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44870 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-05-31 18:06:42 UTC --- Author: jason Date: Tue May 31 18:06:39 2011 New Revision: 174499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174499 Log: PR c++/44870 * tree.c (lvalue_kind): Recurse on NON_DEPENDENT_EXPR. Handle ARROW_EXPR, TYPEID_EXPR, and arbitrary class-valued expressions. (build_min_non_dep): Preserve reference refs. (build_min_non_dep_call_vec): Likewise Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-template1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/44870] [4.7 regression] [C++0x] error when calling function with rvalue argument inside template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44870 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-05-31 18:07:16 UTC --- Fixed for 4.7.
[Bug c++/49198] GCC generates spurious has incomplete type errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49198 --- Comment #4 from Ollie Wild aaw at gcc dot gnu.org 2011-05-31 18:13:02 UTC --- Thanks for the clarification, Jason. I would not have figured that out on my own.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #54 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-31 18:25:54 UTC --- Author: burnus Date: Tue May 31 18:25:51 2011 New Revision: 174503 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174503 Log: 2011-05-31 Tobias Burnus bur...@net-b.de PR fortran/18918 * resolve.c (resolve_fl_variable): Handle static coarrays with non-constant cobounds. (resolve_symbol): Handle SAVE statement without arguments for coarrays. * trans-array.c (gfc_trans_array_cobounds): New function. (gfc_trans_array_bounds): Place code by call to it. * trans-array.h (gfc_trans_array_cobounds): New prototype. * trans-decl.c (gfc_get_symbol_decl, gfc_trans_deferred_vars): Handle static coarrays with nonconstant cobounds. 2011-05-31 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray/save_1.f90: New. * gfortran.dg/coarray_4.f90: Update dg-error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_4.f90
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #55 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-31 18:41:00 UTC --- Author: burnus Date: Tue May 31 18:40:55 2011 New Revision: 174504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174504 Log: 2011-05-31 Tobias Burnus bur...@net-b.de PR fortran/18918 * trans-array.c (gfc_trans_dummy_array_bias): Handle cobounds of assumed-shape arrays. 2011-05-31 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray/dummy_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/dummy_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48010] typedef redefinitions are allowed if the redefined type is a nested class type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48010 --- Comment #4 from fabien at gcc dot gnu.org 2011-05-31 19:02:22 UTC --- Author: fabien Date: Tue May 31 19:02:19 2011 New Revision: 174506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174506 Log: gcc/cp/ChangeLog 2010-05-31 Fabien Chene fab...@gcc.gnu.org PR c++/48010 * name-lookup.c (supplement_binding_1): If the old binding was a type name, also check that the DECL actually refers to the same type or is not a type. gcc/testsuite/ChangeLog 2010-05-31 Fabien Chene fab...@gcc.gnu.org PR c++/48010 * g++.dg/lookup/name-clash9.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/name-clash9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug target/48688] [x64]: shift/or instead of lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48688 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 19:12:28 UTC --- Author: jakub Date: Tue May 31 19:12:25 2011 New Revision: 174507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174507 Log: PR target/48688 * config/i386/i386.md (*lea_general_4): New define_insn_and_split. * gcc.target/i386/pr48688.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr48688.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/48688] [x64]: shift/or instead of lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48688 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-31 19:16:34 UTC --- Fixed.
[Bug c++/49245] New: Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245
Summary: Cannot compile
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@marc-richter.info
Created attachment 24405
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24405
This is the build log of the application
I am trying to compile gcc in Gentoo Linux. I already filed a bug there, but
since it couldn't be solved for more than 1,5 months now, I guess it is a
deeper gcc issue, noone there can solve.
You can find that record here: http://bugs.gentoo.org/show_bug.cgi?id=363675
It fails with the following output:
/var/tmp/portage/sys-devel/gcc-4.4.5/work/build/./prev-gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.4.5/work/build/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -c -DEFAULT_PIE_SSP -DEFAULT_RELRO
-DEFAULT_BIND_NOW -O2 -pipe -march=core2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I.
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/.
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/../include
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/../libcpp/include
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/../libdecnumber/bid
-I../libdecnumber
/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/gcc/cfgbuild.c -o
cfgbuild.o
{standard input}: Assembler messages:
{standard input}:73965: Warning: end of file not at
end of a line; newline inserted
{standard input}:73986: Error: no such instruction: `mo'
{standard input}:73986: Error: open CFI at the end of file; missing
.cfi_endproc directive
xgcc: Internal error: Killed (program cc1)
I'm no developer, but these environment facts might help here:
jb-gen2-0001 ~ # emerge --info
Portage 2.1.9.42 (hardened/linux/amd64, gcc-4.4.4, glibc-2.11.3-r0,
2.6.38.2-jb1 x86_64)
=
System uname:
Linux-2.6.38.2-jb1-x86_64-Intel-R-_Xeon-R-_CPU_L5630_@_2.13GHz-with-gentoo-1.12.14
Timestamp of tree: Fri, 15 Apr 2011 07:45:01 +
app-shells/bash: 4.1_p9
dev-lang/python: 2.6.6-r2, 2.7.1-r1, 3.1.3-r1
dev-util/cmake: 2.8.4
sys-apps/baselayout: 1.12.14-r1
sys-apps/sandbox:2.4
sys-devel/autoconf: 2.13, 2.65-r1
sys-devel/automake: 1.11.1
sys-devel/binutils: 2.20.1-r1
sys-devel/gcc: 4.4.4-r2
sys-devel/gcc-config: 1.4.1
sys-devel/libtool: 2.2.10
sys-devel/make: 3.81-r2
sys-kernel/linux-headers: 2.6.36.1
virtual/os-headers: 0
CBUILD=x86_64-pc-linux-gnu
CFLAGS=-O2 -pipe -march=core2
CHOST=x86_64-pc-linux-gnu
CXXFLAGS=-O2 -pipe -march=core2
LDFLAGS=-Wl,-O1 -Wl,--as-needed
MAKEOPTS=-j3
Also, please find attached a complete build lo.
[Bug other/49244] New: no intrinsics to emit 'lock bts' and 'lock btc'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
Summary: no intrinsics to emit 'lock bts' and 'lock btc'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: de...@desrt.ca
I want to be able to code this function:
bool
set_and_test (int *a,
int bit)
{
uint mask = (1u bit);
return (__sync_fetch_and_or (a, mask) mask) != 0;
}
and have GCC not emit a loop on amd64 and x86.
GCC presently emits a loop for __sync_fetch_and_or() in this case. That's
because asm lock or discards the previous value, so it can only be used in
cases that the result is ignored. Since we do a comparison with the value, GCC
has to do the loop.
This special case (set and test a single bit) corresponds quite directly to the
'lock bts' assembly instruction, though. GCC could emit that instead.
It would be nice if GCC could detect (by magic?) that I am only interested in
this single bit or (probably much easier) expose an intrinsic that lets me
access this functionality on platforms that it exists and falls back to using
__sync_fetch_and_or() otherwise.
[Bug c++/49245] Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245 --- Comment #1 from Marc Richter g...@marc-richter.info 2011-05-31 19:37:50 UTC --- PS: I can provide a root login for a server wherethis is reproduceable happening. You might try or destroy anything you like there, since I can easily make a snapshot of the system. Please just tell me if this is needed, since I do not like to publish the credentials in public here.
[Bug bootstrap/49246] New: bootstrap comparison failure with 174455 on OpenBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49246 Summary: bootstrap comparison failure with 174455 on OpenBSD Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@openbsd.org bootstrap fails with revision 174455 on OpenBSD/i386 -current. Compiled with a lightly patched GCC 4.2.1 This is a different list of object files to pr 49242 so opening a new pr. Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/build/genautomata.o differs gcc/cfgexpand.o differs gcc/dwarf2out.o differs gcc/ipa-prop.o differs gcc/matrix-reorg.o differs gcc/sel-sched.o differs gcc/tree-data-ref.o differs gcc/tree-into-ssa.o differs gcc/tree-predcom.o differs gcc/tree-ssa-math-opts.o differs gcc/tree-ssa-sccvn.o differs gcc/tree-vect-slp.o differs gcc/tree-vrp.o differs gmake[2]: *** [compare] Error 1 ./stage3-gcc/xgcc -v Using built-in specs. COLLECT_GCC=./stage3-gcc/xgcc Target: i386-unknown-openbsd4.9 Configured with: ../gcc/configure --prefix=/usr/gcc --program-transform-name='s,^,e,' --disable-nls --with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t --disable-checking --disable-lto --enable-languages=c,c++ --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.7.0 20110530 (experimental) (GCC) gcc -v Reading specs from /usr/lib/gcc-lib/i386-unknown-openbsd4.9/4.2.1/specs Target: i386-unknown-openbsd4.9 Configured with: OpenBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719 With a currently unsubmitted OpenBSD/amd64 target the problem is almost but not quite the same: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/build/genautomata.o differs gcc/cfgexpand.o differs gcc/dwarf2out.o differs gcc/ipa-prop.o differs gcc/sel-sched.o differs gcc/tree-into-ssa.o differs gcc/tree-predcom.o differs gcc/tree-ssa-math-opts.o differs gcc/tree-ssa-sccvn.o differs gcc/tree-vrp.o differs gcc/var-tracking.o differs gmake[2]: *** [compare] Error 1
[Bug c++/49245] Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-31 19:41:32 UTC --- looks like you ran out of memory and the OOM killer kicked in
[Bug bootstrap/49247] New: libiberty configure assumes newlib does not supply psignal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49247 Summary: libiberty configure assumes newlib does not supply psignal Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org A build of GCC mainline for arm-none-eabi using mainline newlib fails with: /scratch/janisjo/arm-eabi-fsf/src/gcc-mainline/libiberty/strsignal.c:554:1: error: conflicting types for 'psignal' /scratch/janisjo/arm-eabi-fsf/install/arm-none-eabi/include/signal.h:27:6: note: previous declaration of 'psignal' was here where the installed version comes from newlib. The libiberty version has an argument with char * and the newlib version uses const char * for that argument. The newlib version of psignal was added on 2011-05-04. The libiberty version of psignal is not compiled if HAVE_PSIGNAL is defined, but when building against newlib it is never defined. libiberty/configure.ac says: # If we are being configured for newlib, we know which functions # newlib provide and which ones we will be expected to provide. and # Of the functions in $checkfuncs, newlib only has strerror. This is no longer true, as the latest newlib now has psignal as well. It could also be the case that later versions of newlib will have other funtions in $checkfuncs.
[Bug bootstrap/49245] Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|c++ |bootstrap --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-31 19:42:35 UTC --- component should be bootstrap, this isn't a c++ issue
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #56 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-31 20:04:13 UTC --- Author: burnus Date: Tue May 31 20:04:09 2011 New Revision: 174510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174510 Log: 2011-05-31 Tobias Burnus bur...@net-b.de PR fortran/18918 * intrinsic.c (klass): Add CLASS_ATOMIC. (add_subroutines): Add atomic_ref/atomic_define. * intrinsic.texi (ATOMIC_REF, ATOMIC_DEFINE): Document. * intrinsic.h (gfc_check_atomic_def, gfc_check_atomic_ref, gfc_resolve_atomic_def, gfc_resolve_atomic_ref): New prototypes. * gfortran.h (gfc_isym_id): Add GFC_ISYM_ATOMIC_DEF and GFC_ISYM_ATOMIC_REF. (gfc_atomic_int_kind, gfc_atomic_logical_kind): New global vars. * iresolve.c (gfc_resolve_atomic_def, gfc_resolve_atomic_ref): * New functions. * check.c (gfc_check_atomic, gfc_check_atomic_def, gfc_check_atomic_ref): New functions. * iso-fortran-env.def (ISOFORTRANENV_FILE_ATOMIC_INT_KIND, ISOFORTRANENV_FILE_ATOMIC_LOGICAL_KIND): Change kind value. * trans-intrinsic.c (conv_intrinsic_atomic_def, conv_intrinsic_atomic_ref, gfc_conv_intrinsic_subroutine): New functions. (conv_intrinsic_move_alloc) Renamed from gfc_conv_intrinsic_move_alloc - and made static. * trans.h (gfc_conv_intrinsic_move_alloc): Remove. (gfc_conv_intrinsic_subroutine) Add prototype. * trans.c (trans_code): Call gfc_conv_intrinsic_subroutine. Added: trunk/gcc/testsuite/gfortran.dg/coarray/atomic_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_atomic_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/iso-fortran-env.def trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/49245] Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-31 20:13:10 UTC --- you could have tried searching the web for the last error: http://bugs.gentoo.org/256766
[Bug testsuite/49175] vect/pr48172.c execution failure for ARM GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49175 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.31 21:08:33 CC||ramana at gcc dot gnu.org Component|tree-optimization |testsuite Ever Confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-05-31 21:08:33 UTC --- This is more a testism rather than anything else and I think the correct option is to add a dg-require-effective-target vect_int . It's also the case in gcc 4.6 . cheers Ramana
[Bug fortran/45786] [4.5/4.6 Regression] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 --- Comment #12 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-05-31 21:37:04 UTC --- Author: tkoenig Date: Tue May 31 21:37:01 2011 New Revision: 174513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174513 Log: 2011-05-31 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/45786 * interface.c (gfc_equivalent_op): New function. (gfc_check_interface): Use gfc_equivalent_op instead of switch statement. * decl.c (access_attr_decl): Also set access to an equivalent operator. 2011-05-31 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/45786 * gfortran.dg/operator_7.f90: New test case. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/operator_7.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/decl.c branches/gcc-4_6-branch/gcc/fortran/gfortran.h branches/gcc-4_6-branch/gcc/fortran/interface.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/45786] [4.5 Regression] Relational operators .eq. and == are not recognized as equivalent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.1 |4.5.4 Summary|[4.5/4.6 Regression]|[4.5 Regression] Relational |Relational operators .eq. |operators .eq. and == are |and == are not recognized |not recognized as |as equivalent |equivalent
[Bug target/49094] ARM aligned(1) attribute is sometimes dropped
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49094
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.05.31 22:04:11
CC||ramana at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.6.0, 4.7.0
--- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-05-31
22:04:11 UTC ---
Confirmed and copyrename appears to generate this which is where things appear
to start going pear-shaped.
test_alignment (char * m)
{
unsigned int pkt_dst$s_addr;
int D.2017;
bb 2:
pkt_dst$s_addr_8 = MEM[(struct ip *)m_2(D) + 7B].s_addr;
if (pkt_dst$s_addr_8 == 0)
goto bb 4;
else
goto bb 3;
bb 3:
bb 4:
# D.2017_1 = PHI 1(2), 0(3)
return D.2017_1;
}
[Bug bootstrap/49245] Cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49245 Marc Richter g...@marc-richter.info changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Marc Richter g...@marc-richter.info 2011-05-31 22:20:24 UTC --- Absolutely great!!! As soon, as I remove -pipe from CFLAGS it works! Thank you very much Jonathan for your incredibly fast help on this! I used Google before, but I haven't found the right answer. Guess I used the wrong keywords .. Can't believe you solved an issue I'm waiting more than 1,5 months from the Gentoo people for in 3 minutes 42 seconds ... ;)
[Bug c/48783] ARM: kernel compiled at -O2 has a unused reference to __aeabi_uldivmod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.31 22:28:11 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-05-31 22:28:11 UTC --- IIUC the problem is because we externalize the label before the functions have been deleted. Based on a quick look at the sources, I *think* this comes from the fact that the default definition of ASM_OUTPUT_EXTERNAL_LIBCALL ends up generating a .globl symname and somehow don't think this is a port specific problem ( which I *think* comes from config/elfos.h ) cheers Ramana
[Bug debug/48203] ICE in dwarf2out.c while building eglibc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48203 --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-05-31 22:30:42 UTC --- (In reply to comment #13) Author: jakub Date: Mon Mar 28 23:53:46 2011 New Revision: 171640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171640 Log: PR debug/48203 * cfgexpand.c (expand_debug_expr) case SSA_NAME: Only create ENTRY_VALUE if incoming or address of incoming's MEM is a hard REG. * dwarf2out.c (mem_loc_descriptor): Don't emit DW_OP_GNU_entry_value of DW_OP_fbreg. * var-tracking.c (vt_add_function_parameter): Ensure cselib_lookup on ENTRY_VALUE is able to find the canonical parameter VALUE. * cselib.c (rtx_equal_for_cselib_1) case ENTRY_VALUE: Use rtx_equal_p instead of rtx_equal_for_cselib_1 to compare ENTRY_VALUE_EXPs. (cselib_hash_rtx) case ENTRY_VALUE: If ENTRY_VALUE_EXP is a REG_P or MEM_P with REG_P address, compute hash directly instead of calling cselib_hash_rtx on ENTRY_VALUE_EXP. (preserve_only_constants): Don't clear VALUES forwaring ENTRY_VALUE to some other VALUE. * gcc.dg/pr48203.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48203.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cselib.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c Jakub, Is this now fixed ? Ramana
[Bug testsuite/49175] vect/pr48172.c execution failure for ARM GNU/Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49175
--- Comment #3 from Janis Johnson janis at gcc dot gnu.org 2011-05-31
22:43:42 UTC ---
Usually the vect tests only require effective targets like vect_int if they are
checking that particular optimizations took place. There are no such checks in
this test.
The vector tests use neon options if check_effective_target_arm_neon_hw (from
lib/target-supports.exp) returns true. The test the proc executes is:
int
main (void)
{
long long a = 0, b = 1;
asm (vorr %P0, %P1, %P2
: =w (a)
: 0 (a), w (b));
return (a != 1);
}
compiled with neon options. That test apparently passes, but there's a neon
instruction generated for the test that fails. Should the test used for
arm_neon_hw be different?
[Bug c/49243] attribute((returns_twice)) doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49243
--- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-05-31
22:49:36 UTC ---
Comparing tree dumps from gcc-4.7 on a reduced compile-only test case shows
that the code that calls _setjmp (a) and the code that calls my_setjmp (b)
start to differ after 019t.inline_param1:
--- a/pr49243.c.019t.inline_param1 2011-05-31 23:29:47.0 +0200
+++ b/pr49243.c.019t.inline_param1 2011-05-31 23:30:10.0 +0200
@@ -4,7 +4,7 @@
Analyzing function body size: wrapper
-Inline summary for wrapper/0
+Inline summary for wrapper/0 inlinable
self time: 33
global time: 0
self size: 16
Adding -Winline one finds that the code that calls _setjmp is marked
non-inlinable because setjmp_call_p says so in inline_forbidden_p_stmt,
however it doesn't say so for the code that calls my_setjmp. setjmp_call_p
calls special_function_p, which only looks at the spelling of the function.
The closely related flags_from_decl_or_type does look at both attributes and
spelling; the following crude patch to make setjmp_call_p call the latter
instead fixes the reduced test case for me:
--- gcc-4.7-20110528/gcc/calls.c.~1~2011-05-25 13:00:14.0 +0200
+++ gcc-4.7-20110528/gcc/calls.c2011-06-01 00:02:13.0 +0200
@@ -554,7 +554,7 @@ special_function_p (const_tree fndecl, i
int
setjmp_call_p (const_tree fndecl)
{
- return special_function_p (fndecl, 0) ECF_RETURNS_TWICE;
+ return flags_from_decl_or_type (fndecl) ECF_RETURNS_TWICE;
}
(This is a tad expensive and can be optimized.)
The other calls to special_function_p () look safe though.
[Bug ada/49248] New: Cross compile ada failed at finding command gnatmake.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49248 Summary: Cross compile ada failed at finding command gnatmake. Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ray_l...@hotmail.com I am trying use i686-pc-mingw32 (GCC 4.6.0) to compile the target x86_64-w64-mingw32. in the 1st loop, I used the following command to compile binutils and GCC. bintuils: configure --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared --enable-static --prefix=/mingw32 --with-sysroot=/mingw32 --disable-nls --with-gcc --with-gnu-as --with-gnu-ld --with-stabs --enable-interwork --enable-multilib make make install GCC 4.6.0 ../gcc-4.6.0/configure --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --enable-multilib --enable-64bit --prefix=/mingw32 --with-sysroot=/mingw32 --disable-shared --enable-static --enable-version-specific-runtime-libs --with-dwarf2 --enable-fully-dynamic-string --enable-languages=c,ada --disable-libgomp --enable-libada --enable-gnattools --with-gcc --with-gnu-as --with-gnu-ld --with-stabs --enable-interwork --enable-multilib and I also compiled the MinGW64 Runtime with multi-lib. and I succeed got binaries start with x86_64-w64-mingw32 like x86_64-w64-mingw32-gnatmake under /mingw32/bin. in the 2nd loop, i tried to compile a pure 64bit binaries, so i run: binutils: configure --build=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-shared --enable-static --disable-nls --prefix=/tools --with-sysroot=/tools --host=x86_64-w64-mingw32 make -j 2 CFLAGS=-O3 -fomit-frame-pointer -pipe -m64 -m128bit-long-double -minline-stringops-dynamically LDFLAGS=-s -Wl,--as-needed I succeed at binutils and mingw64-runtime. but when I compiled GCC as following command: $ ../gcc-4.6.0/configure --build=x86_64-w64-mingw32 --enable-targets=all --enab le-multilib --enable-64bit --prefix=/tools --with-sysroot=/tools --disable-shar ed --enable-static --disable-nls --enable-version-specific-runtime-libs --disab le-win32-registry --with-dwarf2 --enable-fully-dynamic-string --enable-language s=c,c++,ada --disable-libgomp --enable-lto --disable-libssp --host=x86_64-w64- mingw32 make -j 2 I got failed at : x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns - nostdinc -I- -I. -Iada -I../../gcc-4.6.0/gcc/ada -I../../gcc-4.6.0/gcc/ada/gcc-i nterface ../../gcc-4.6.0/gcc/ada/debug.adb -o ada/debug.o cp -p ../../gcc-4.6.0/gcc/ada/sinfo.ads ../../gcc-4.6.0/gcc/ada/nmake.adt ../../ gcc-4.6.0/gcc/ada/xnmake.adb ../../gcc-4.6.0/gcc/ada/xutil.ads ../../gcc-4.6.0/g cc/ada/xutil.adb ada/bldtools/nmake_b x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns - nostdinc -I- -I. -Iada -I../../gcc-4.6.0/gcc/ada -I../../gcc-4.6.0/gcc/ada/gcc-i nterface ../../gcc-4.6.0/gcc/ada/elists.adb -o ada/elists.o x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns - nostdinc -I- -I. -Iada -I../../gcc-4.6.0/gcc/ada -I../../gcc-4.6.0/gcc/ada/gcc-i nterface ../../gcc-4.6.0/gcc/ada/err_vars.ads -o ada/err_vars.o (cd ada/bldtools/nmake_b; gnatmake -q xnmake ; ./xnmake -b ../../nmake.adb ) (cd ada/bldtools/snamest; gnatmake -q xsnamest ; ./xsnamest ) x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns - nostdinc -I- -I. -Iada -I../../gcc-4.6.0/gcc/ada -I../../gcc-4.6.0/gcc/ada/gcc-i nterface ../../gcc-4.6.0/gcc/ada/fmap.adb -o ada/fmap.o x86_64-w64-mingw32-gcc -c -g -O2 -D__USE_MINGW_ACCESS -gnatpg -gnata -gnatwns - nostdinc -I- -I. -Iada -I../../gcc-4.6.0/gcc/ada -I../../gcc-4.6.0/gcc/ada/gcc-i nterface ../../gcc-4.6.0/gcc/ada/fname-uf.adb -o ada/fname-uf.o /bin/sh: gnatmake: command not found /bin/sh: gnatmake: command not found /bin/sh: ./xnmake: No such file or directory /bin/sh: ./xsnamest: No such file or directory make[2]: *** [ada/nmake.adb] Error 127 make[2]: *** Waiting for unfinished jobs make[2]: *** [ada/stamp-snames] Error 127 make[2]: Leaving directory `/home/beta/gcc-build/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/beta/gcc-build' make: *** [all] Error 2 I am not sure why it failed, need your great support.
[Bug lto/49249] New: LTO streaming of builtins corrupts BLOCK lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49249
Summary: LTO streaming of builtins corrupts BLOCK lists
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org
Hi,
in the attached testcase (stolen from testsuite) there are two functions that
use implicit declaration of abort ().
Now C frontend behaves in a way that it produces two BLOCKS for each of local
scopes and declares abort there:
(gdb) p debug_tree (0x77692320)
block 0x77692320 used
vars function_decl 0x776a0400 abort
type function_type 0x777b5690 type void_type 0x7779fe70 void
QI
size integer_cst 0x7778cfa0 constant 8
unit size integer_cst 0x7778cfc0 constant 1
align 8 symtab 0 alias set -1 canonical type 0x777b5690
arg-types tree_list 0x777933e8 value void_type 0x7779fe70
void
addressable volatile used nothrow public external built-in decl_2
decl_5 decl_6 QI file built-in line 0 col 0
align 8 built-in BUILT_IN_NORMAL:BUILT_IN_ABORT context function_decl
0x776a0200 main attributes tree_list 0x77827d98
chain function_decl 0x776a0300 exit type function_type
0x777b7b28
addressable volatile used nothrow public external built-in decl_2
decl_5 decl_6 QI file built-in line 0 col 0
align 8 built-in BUILT_IN_NORMAL:BUILT_IN_EXIT context
function_decl 0x776a0200 main attributes tree_list 0x7782bcd0
supercontext function_decl 0x776a0200 main
type function_type 0x77685738 type integer_type 0x7779f498
int
QI size integer_cst 0x7778cfa0 8 unit size integer_cst
0x7778cfc0 1
align 8 symtab 0 alias set -1 canonical type 0x777b51f8
public static QI file a.c line 26 col 5 align 8 initial block
0x77692320
result result_decl 0x77797780 D.1598 type integer_type
0x7779f498 int
ignored SI file a.c line 26 col 5
size integer_cst 0x777a4160 constant 32
unit size integer_cst 0x7778cf00 constant 4
align 32
struct-function 0x7768f1c8
$22 = void
(gdb) p debug_tree (0x77692280)
block 0x77692280 used
vars function_decl 0x776a0100 abort
type function_type 0x777b5690 type void_type 0x7779fe70 void
QI
size integer_cst 0x7778cfa0 constant 8
unit size integer_cst 0x7778cfc0 constant 1
align 8 symtab 0 alias set -1 canonical type 0x777b5690
arg-types tree_list 0x777933e8 value void_type 0x7779fe70
void
addressable volatile used nothrow public external built-in decl_2
decl_5 decl_6 QI file built-in line 0 col 0
align 8 built-in BUILT_IN_NORMAL:BUILT_IN_ABORT context function_decl
0x776a f attributes tree_list 0x77827d98
supercontext block 0x776922d0 used
supercontext function_decl 0x776a f type function_type
0x777b69d8
addressable used public static decl_5 QI file a.c line 4 col 5
align 8 initial block 0x776922d0 arguments parm_decl 0x77795880 i
result result_decl 0x77797300 D.1587
(mem:QI (symbol_ref:DI (f) [flags 0x3] function_decl
0x776a f) [0 S1 A8])
struct-function 0x7768f130 subblocks block 0x77692280
Note that there are two declarations of abort() in two lists connected by
TREE_CHAIN. Now this gets completely messed up in LTO streaming. We identify
all builtin decls and consequentely we mess up the linked lists producing
completely nonsential BLOCK lists.
Honza
int f(int i) {
switch (i)
{
case -2:
return 33;
case -1:
return 0;
case 0:
return 7;
case 1:
return 4;
case 2:
return 3;
case 3:
return 15;
case 4:
return 9;
default:
abort ();
}
}
int main() {
if (f(-1))
abort ();
exit (0);
}
[Bug debug/49250] New: [4.7 Regression] ICE in set_slot_part, at var-tracking.c:6793
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49250 Summary: [4.7 Regression] ICE in set_slot_part, at var-tracking.c:6793 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu /bin/bash ../libtool --tag CXX --mode=compile /home/dave/gnu/gcc/objdir/./gcc/ xgcc -shared-libgcc -B/home/dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/home/dave/g nu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src -L/home/dave/gnu/gcc/objdir/hppa-l inux-gnu/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gn u/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/lib/ -isystem /home/dav e/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/g cc-4.7.0/hppa-linux-gnu/sys-include -I/home/dave/gnu/gcc/objdir/hppa-linux-g nu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gn u/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -fno-imp licit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-lo cation=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c -o ext -inst.lo ../../../../gcc/libstdc++-v3/src/ext-inst.cc In file included from /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/incl ude/bits/concept_check.h:55:0, from ../../../../gcc/libstdc++-v3/src/concept-inst.cc:32: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/boost_concept _check.h: In function ‘void __gnu_cxx::__aux_require_boolean_expr(const _Tp) [w ith _Tp = bool]’: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/bits/boost_concept _check.h:238:3: internal compiler error: in set_slot_part, at var-tracking.c:679 3 dave@mx3210:~/gnu/gcc/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa-linux-gnu Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --prefix=/home/dave/opt/gnu/gcc/gcc-4.7.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu --enable-java-gc=boehm --without-cloog --without-ppl --enable-languages=c,c++,objc,fortran,obj-c++,java,ada,lto Thread model: posix gcc version 4.7.0 20110531 (experimental) [trunk revision 174512] (GCC)
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Attachment #24399|0 |1 is obsolete|| --- Comment #18 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-06-01 05:09:12 UTC --- Created attachment 24406 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24406 New updated patch This updated patch takes care of Comment #16. Also, the test case, pr20755.f was originally intended to pass only with -std=legacy. This is to mimic g77 which does not ignore the scale factor. At least recently, gfortran passes this test case regardless of the -std=. I am tempted to delete the test case, since it looks like it goes against current standards. Any opinions about this?
[Bug debug/49250] [4.7 Regression] ICE in set_slot_part, at var-tracking.c:6793
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49250 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.01 05:56:03 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-01 05:56:03 UTC --- Please provide preprocessed testcase.
