[Bug rtl-optimization/57479] [ARM][NEON] internal compiler error: Segmentation fault in add_dependence_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57479 --- Comment #3 from bccheng at android dot com --- Here is my configuration: --target=arm-linux-androideabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu Please let me know if you need additional information. Thanks!
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #6 from asmwarrior asmwarrior at gmail dot com ---
Hi, all, I create a simple c++ program to reproduce this bug:
#include set
#include map
typedef std::setint IntSet;
typedef std::mapint, IntSet IntToSetMap;
int main()
{
IntToSetMap m;
IntSet s;
s.insert(5);
m[3] = s;
IntSet refSet = m[3];
refSet.insert(6);
return 0;
}
Now, you can set a BP in the line refSet.insert(6);, and run the command p
refSet, you will get the error message.
Python Exception type 'exceptions.IndexError' list index out of range:
$1 = std::set with 1 elements
If you run n, and then type p refSet again, you get:
Python Exception type 'exceptions.IndexError' list index out of range:
$2 = std::set with 2 elements
It looks like the elements number(from 1 to 2) is correct.
Thanks
Yuanhui Zhang
[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #7 from asmwarrior asmwarrior at gmail dot com ---
Ok, I found another issue on the line return 0, see the GDB log:
[debug] p m
[debug]$2 = std::map with 1 elements = {[3] = std::set with 2 elements = {[0] =
5, [1] = 6}}
[debug]cb_gdb:
[debug] p m[3]
[debug]Attempt to take address of value not located in memory.
[debug]cb_gdb:
p m shows the correct value, but I'm not sure why p m[3] failed? Is it a
GDB bug?
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #26 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to David Abdurachmanov from comment #25) I downloaded GCC 4.8.1 (final) and binutils 2.23.1 (default ld.gold). The problem is that boost and a lot other C/C++ packages are not compiled w/ ASan. One way would be to guarantee every single C/C++ RPM package correctly compiling w/ ASan (quite some effort). This will be indeed quite some effort. But I still want this to happen! I prefer to instrument the main software (+ some critical C/C++ packages in future) for now. I assume I cannot use -static-libasan for shared objects (-shared) as PREINIT_ARRAY section would be a duplicate. Then -static-libasan should be only used for the final executable binary? I tried something like that: c++ -fsanitize=address -shared -Wl,-E -Wl,-z,defs -Wl,-v ./test.o -o libtest.so -static-libasan I see it doesn't pass to linker: long_path/lib64/libasan_preinit.o -Bstatic --whole-archive -lasan --no-whole-archive -Bdynamic And linker dies w/ undefined references of ASan. The linker complains because you have -Wl,-z,defs Just remove it. Do I need to make sure that **only** executable binaries gets ASan linked statically (-static-libasan)? (Thus they always have PREINIT_ARRAY section initializing ASan). david
[Bug target/12081] Gcc can't be compiled with -mregparm=3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081 --- Comment #22 from Mikael Pettersson mikpe at it dot uu.se --- FWIW, the updated patch for gcc 4.9 bootstraps and regtests cleanly on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k).
[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #4) Seems to have been fixed with the Symtab cleanups 2/17 - merge alias code fix (r199577) or possibly with the same fix as for PR57467 (r199582). Fixed on arm-none-eabi it seems. Dominique, can you confirm that x86_64-apple-darwin10 is fixed as well?
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #16 from Mikael Pettersson mikpe at it dot uu.se --- FWIW, I've bootstrapped and regtested gcc 4.9 with r192676 reapplied and the dse.c and cselib.c hunks of r193802 reverted on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k) without regressions.
[Bug tree-optimization/57488] [4.9 regression] loop terminates early at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look later this week unless somebody beats me here.
[Bug bootstrap/57486] bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-03 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Err... In file included from ../../gcc/dbgcnt.h:28:0, from ../../gcc/graphite.c:57: ../../gcc/dbgcnt.def:149:1: error: \u2018clone\u2019 redeclared as different kind of symbol this is weird - dbgcnt.def does not include a 'clone' debug-counter, line 149 reads DEBUG_COUNTER (dce) for me. Please provide preprocessed source with -dD for graphite.c.
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug middle-end/57500] [4.9 Regression] Segfault in ipa_record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57500 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/57499] [4.7/4.8/4.9 Regression] ICE when noreturn destructor returns after throw with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57499 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.4.7 Keywords||ice-on-invalid-code Last reconfirmed||2013-06-03 Component|c++ |middle-end Ever confirmed|0 |1 Summary|ICE when noreturn |[4.7/4.8/4.9 Regression] |destructor returns after|ICE when noreturn |throw with -O |destructor returns after ||throw with -O Target Milestone|--- |4.7.4 Known to fail||4.5.4, 4.6.4, 4.7.2, 4.8.1, ||4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. 0xd197c5 crash_signal /space/rguenther/src/svn/trunk/gcc/toplev.c:333 0xd745a5 infinite_empty_loop_p /space/rguenther/src/svn/trunk/gcc/tree-eh.c:4187 0xd74908 cleanup_empty_eh /space/rguenther/src/svn/trunk/gcc/tree-eh.c:4263 0xd74d7e cleanup_all_empty_eh /space/rguenther/src/svn/trunk/gcc/tree-eh.c:4376 0xd74e0a execute_cleanup_eh_1 /space/rguenther/src/svn/trunk/gcc/tree-eh.c:4405 0xd74e5b execute_cleanup_eh /space/rguenther/src/svn/trunk/gcc/tree-eh.c:4430
[Bug rtl-optimization/57497] [4.9 Regression] ICE in lra_create_new_reg_with_unique_value, at lra.c:155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57497 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 Known to work||4.8.1 Target Milestone|--- |4.9.0 Summary|ICE in |[4.9 Regression] ICE in |lra_create_new_reg_with_uni |lra_create_new_reg_with_uni |que_value, at lra.c:155|que_value, at lra.c:155 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug bootstrap/57494] [4.9 regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- patch was reverted.
[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014 --- Comment #1 from Johannes Goller jogojapan at gmail dot com --- I've just confirmed that the problem also exists in GCC 4.9 20130602 snapshot.
[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014 --- Comment #2 from Johannes Goller jogojapan at gmail dot com --- It also exists in 4.8.1.
[Bug sanitizer/57507] New: gcc 4.8: thread sanitizer: std::thread false(?) positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
Bug ID: 57507
Summary: gcc 4.8: thread sanitizer: std::thread false(?)
positive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: alxchk at alxchk dot me
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
$ cat test.cpp
#include thread
int main(int argc, char *argv[])
{
std::thread t([](){});
t.join();
return 0;
}
$ LC_ALL=C g++ --version
g++ (Gentoo Hardened 4.8.0 p1.2, pie-0.5.5) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.
$ g++ -o test test.cpp --std=gnu++11 -pthread -fsanitize=thread -ggdb3 -O0
$ ./test
==
WARNING: ThreadSanitizer: data race (pid=14129)
Write of size 8 at 0x7d08bfc8 by thread T1:
#0 null null:0 (libtsan.so.0+0x00020dc0)
#1 deallocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/new_allocator.h:110
(exe+0x2b42)
#2 deallocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/alloc_traits.h:377
(exe+0x2972)
#3 _M_destroy
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:417
(exe+0x3336)
#4 null null:0 (libstdc++.so.6+0x000c8cea)
Previous atomic write of size 4 at 0x7d08bfc8 by main thread:
#0 null null:0 (libtsan.so.0+0xdfc5)
#1 __exchange_and_add
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/atomicity.h:47
(exe+0x1898)
#2 __exchange_and_add_dispatch
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/atomicity.h:80
(exe+0x1995)
#3 std::_Sp_counted_base(__gnu_cxx::_Lock_policy)2::_M_release()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:141
(exe+0x3c86)
#4 std::__shared_count(__gnu_cxx::_Lock_policy)2::~__shared_count()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:553
(exe+0x3c2d)
#5 std::__shared_ptrstd::thread::_Impl_base,
(__gnu_cxx::_Lock_policy)2::~__shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:810
(exe+0x3aae)
#6 std::shared_ptrstd::thread::_Impl_base::~shared_ptr()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:93
(exe+0x3afc)
#7 threadmain(int, char**)::__lambda0
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:135
(exe+0x1c10)
#8 main /tmp/test.cpp:5 (exe+0x1a3e)
Location is heap block of size 56 at 0x7d08bfc0 allocated by main thread:
#0 null null:0 (libtsan.so.0+0x00020ad2)
#1 allocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/ext/new_allocator.h:104
(exe+0x2a5b)
#2 allocate
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/alloc_traits.h:351
(exe+0x2881)
#3 __shared_countstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() , std::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:519
(exe+0x26e5)
#4
__shared_ptrstd::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() , std::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr_base.h:986
(exe+0x25a1)
#5 shared_ptrstd::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() , std::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:316
(exe+0x2511)
#6 allocate_sharedstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() , std::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:598
(exe+0x2422)
#7 make_sharedstd::thread::_Implstd::_Bind_simplemain(int,
char**)::__lambda0() , std::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/bits/shared_ptr.h:614
(exe+0x225a)
#8 _M_make_routinestd::_Bind_simplemain(int, char**)::__lambda0()
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:193
(exe+0x1fa2)
#9 threadmain(int, char**)::__lambda0
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/thread:135
(exe+0x1bde)
#10 main /tmp/test.cpp:5 (exe+0x1a3e)
Thread T1 (tid=14130, running) created by main thread at:
#0 null null:0 (libtsan.so.0+0x00022cdb)
#1 null null:0 (libstdc++.so.6+0x000c8ef6)
#2 main /tmp/test.cpp:5
[Bug sanitizer/57507] gcc 4.8: thread sanitizer: std::thread false(?) positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507 --- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org --- FTR: we don't yet officially support C++11 treads, so this is quite expected. Patches and tests (to the upstream repo) are welcome
[Bug fortran/57508] New: [OOP] Intrinsic assignment+defined-assignment for comps: ROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 Bug ID: 57508 Summary: [OOP] Intrinsic assignment+defined-assignment for comps: ROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org The following code fails with the error message: end module 1 Error: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute at (1) That's due to the support of calling defined assignment for the components in an intrinsic assignment, which was added in GCC 4.8. The _F.DA0 variable is generated in resolve.c's get_temp_from_expr. module ForTrilinos_ref_counter type ref_counter contains procedure :: assign generic :: assignment(=) = assign end type contains subroutine assign (lhs, rhs) class (ref_counter), intent(inout) :: lhs class (ref_counter), intent(in) :: rhs end subroutine end module module FEpetra_BlockMap use ForTrilinos_ref_counter, only : ref_counter type :: Epetra_BlockMap type(ref_counter) :: counter end type contains function from_struct() result(new_Epetra_BlockMap) type(Epetra_BlockMap) :: new_Epetra_BlockMap end function type(Epetra_BlockMap) function create_arbitrary() create_arbitrary = from_struct() end function end module
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- Works fine on i386-pc-solaris2.10 with Sun as. Thanks. Rainer
[Bug c++/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Just to clarify that this is neither a library neither a C++ front-end issue: limits just uses the various __builtin_nans*
[Bug fortran/57496] I/O: WRITE(*,*) HUGE(0_16) [REAL(10)+REAL(16)]: Gives SIGFPE with -ffpe-trap=overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57496 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon Jun 3 09:20:46 2013 New Revision: 199598 URL: http://gcc.gnu.org/viewcvs?rev=199598root=gccview=rev Log: 2013-06-01 Tobias Burnus bur...@net-b.de PR fortran/57496 * io/write_float.def (ISFINITE2Q, ISFINITE2, ISFINITE2L, * ISFINITE, SIGNBIT2Q, SIGNBIT2, SIGNBIT2L, SIGNBIT, ISNAN2Q, ISNAN2, ISNAN2L, ISNAN): New macros. (output_float_FMT_G_,WRITE_FLOAT): Use them. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug fortran/57496] I/O: WRITE(*,*) HUGE(0._10) gives SIGFPE with -ffpe-trap=overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57496 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Summary|I/O: WRITE(*,*) HUGE(0_16) |I/O: WRITE(*,*) HUGE(0._10) |[REAL(10)+REAL(16)]: Gives |gives SIGFPE with |SIGFPE with |-ffpe-trap=overflow |-ffpe-trap=overflow | --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- The commit in comment 3 solved the problem for REAL(16). For REAL(10) (= long double), there is still a problem: print *, HUGE(0.0_10) end gives a SIGFPE with -ffpe-trap=overflow. See comment 2 for details.
[Bug target/57329] ICE with -O2 and -mthumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57329
Terry Guo terry.guo at arm dot com changed:
What|Removed |Added
CC||terry.guo at arm dot com
--- Comment #2 from Terry Guo terry.guo at arm dot com ---
The case has operations on vector for Thumb-1 targets. Thus subreg is generated
for example:
(insn 65 64 66 2 (set (subreg:SI (reg:TI 137 [ D.4126 ]) 4)
(reg:SI 211)) 187 {*thumb1_movsi_insn}
(nil))
The subreg:SI is supposed to be turned into normal reg:SI in subreg1 pass.
However current 4.8 branch incorrectly calculates the rtx cost of such
transformation.
Speed costs
===
SI move: from zero cost 4, from reg cost 4
DI move: original cost 4, split cost 4 * 2
TI move: original cost 4, split cost 4 * 4
EI move: original cost 4, split cost 4 * 6
The subreg will be kept until IRA stage and causes ICE there.
With Bin's patch at http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00784.html, we
will get correct rtx cost:
Speed costs
===
SI move: from zero cost 4, from reg cost 4
DI move: original cost 8, split cost 4 * 2
TI move: original cost 16, split cost 4 * 4
EI move: original cost 24, split cost 4 * 6
Then the split happens, we will get:
(insn 65 64 66 2 (set (reg:SI 393 [ D.4126+4 ])
(reg:SI 211)) 187 {*thumb1_movsi_insn}
(nil))
and then everything works well.
I believe this is the cause of the issue and am doing back port to 4.8 branch.
[Bug sanitizer/57507] gcc 4.8: thread sanitizer: std::thread false(?) positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Would supporting std::shared_ptr solve the problem? The problem seems to be due to not understanding that the atomic ops used by shared_ptr are atomic.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Simplified testcase that fails with 'gfortran -c -g -O2 -ffast-math bug.f90' cat bug.f90 SUBROUTINE xb88_lr_adiabatic_lda_calc(npoints,e,g,sx) IMPLICIT REAL*8 (t) INTEGER, PARAMETER :: dp=8 REAL(kind=dp) :: e(npoints) DO ii=1,npoints t804 = 0.19e2_dp * t7 * t766 + 0.60e1_dp * t405 * t2873 * t237 t3026 = 0.162000e3_dp * t1143 * t474 * t2169 + 0.108000e3_dp * t1143 * t3030 * t237 - 0.60e1_dp * t478 * t27 * t379 * t14 - 0.24e2_dp * t478 * t123 * t2843 - 0.12e2_dp * t473 * t1157 * t2368 t3070 = t3026 + t3069 t3093 = (3 * t496 * t865 * t65) + (t187 * t2285 * t65) + (t3070 * t65) - 0.36e0_dp * t1137 * t1134 t3268 = 0.16e1_dp * t2937 * t446 * t2843 + (t3093 + t3141 + t3181 + t3232) * 0.312500e0_dp * t3262 * t45 * t166 * t3264 t3288 = -0.11e1_dp * t165 * t2636 * t237 - (t2724 + t2783 + t2935 + t3268) - 0.833340e-1_dp * t906 * t384 * t2160 t3291 = -0.11e1_dp * t2147 * t84 * t754 - t8 * (t2635 + t3288) IF( g= 3 .OR. g== -3 ) THEN e(ii) = e(ii) + t3291 * sx END IF END DO END SUBROUTINE xb88_lr_adiabatic_lda_calc
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 CC||janus at gcc dot gnu.org Summary|[OOP] Intrinsic |[4.8/4.9 Regression] [OOP] |assignment+defined-assignme |Intrinsic |nt for comps: ROCEDURE |assignment+defined-assignme |attribute of '_F.DA0' |nt for comps: PROCEDURE |conflicts with VARIABLE |attribute of '_F.DA0' |attribute |conflicts with VARIABLE ||attribute Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- 4.7 shows no error, 4.8 gives an additional ICE (in gfc_enforce_clean_symbol_state) which might be PR 57364
[Bug c++/57509] New: Segmentation fault when using __builtin_shuffle in templated class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57509
Bug ID: 57509
Summary: Segmentation fault when using __builtin_shuffle in
templated class.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beholder0x100 at gmail dot com
Ubuntu 12.10 64-bit
GCC 4.8.1 which I built from source:
COLLECT_GCC=/opt/custom/gcc-4.8.1/bin/gcc
COLLECT_LTO_WRAPPER=/opt/custom/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --prefix=/opt/custom/gcc-4.8.1
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.1 (GCC)
/opt/custom/gcc-4.8.1/bin/gcc test.cpp
test.cpp: In static member function ‘static int_v4Tp::Tpv
int_v4Tp::shuffle(const int_v4Tp, const int_v4Tp, const int_v4Tp)’:
test.cpp:8:49: internal compiler error: Segmentation fault
return __builtin_shuffle(u1.v, u2.v, s.v);
^
0x8d7dff crash_signal
../../gcc-4.8.1/gcc/toplev.c:332
0x632761 c_build_vec_perm_expr(unsigned int, tree_node*, tree_node*,
tree_node*)
../../gcc-4.8.1/gcc/c-family/c-common.c:2280
0x5965f3 cp_parser_postfix_expression
../../gcc-4.8.1/gcc/cp/parser.c:5558
0x5983bd cp_parser_unary_expression
../../gcc-4.8.1/gcc/cp/parser.c:6729
0x598eef cp_parser_binary_expression
../../gcc-4.8.1/gcc/cp/parser.c:7421
0x59939f cp_parser_assignment_expression
../../gcc-4.8.1/gcc/cp/parser.c:7657
0x59af93 cp_parser_expression
../../gcc-4.8.1/gcc/cp/parser.c:7819
0x5932ce cp_parser_expression
../../gcc-4.8.1/gcc/cp/parser.c:7858
0x5932ce cp_parser_jump_statement
../../gcc-4.8.1/gcc/cp/parser.c:10144
0x5932ce cp_parser_statement
../../gcc-4.8.1/gcc/cp/parser.c:8874
0x593a8e cp_parser_statement_seq_opt
../../gcc-4.8.1/gcc/cp/parser.c:9238
0x593bae cp_parser_compound_statement
../../gcc-4.8.1/gcc/cp/parser.c:9192
0x5a1d28 cp_parser_function_body
../../gcc-4.8.1/gcc/cp/parser.c:17827
0x5a1d28 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-4.8.1/gcc/cp/parser.c:17863
0x5a2a5f cp_parser_function_definition_after_declarator
../../gcc-4.8.1/gcc/cp/parser.c:21843
0x58de44 cp_parser_late_parsing_for_member
../../gcc-4.8.1/gcc/cp/parser.c:22484
0x58de44 cp_parser_class_specifier_1
../../gcc-4.8.1/gcc/cp/parser.c:18586
0x58de44 cp_parser_class_specifier
../../gcc-4.8.1/gcc/cp/parser.c:18610
0x58de44 cp_parser_type_specifier
../../gcc-4.8.1/gcc/cp/parser.c:13677
0x5a0711 cp_parser_decl_specifier_seq
../../gcc-4.8.1/gcc/cp/parser.c:11003
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
- test.cpp -
template typename Tp
class int_v4
{
typedef Tp Tpv __attribute__((vector_size(4 * sizeof(Tp;
Tpv v;
static Tpv shuffle(const int_v4 u1, const int_v4 u2, const int_v4 s) {
return __builtin_shuffle(u1.v, u2.v, s.v); //segfault
}
Tpv shuffle2(const int_v4 u1, const int_v4 u2, const int_v4 s) {
return __builtin_shuffle(v, v, v); //error if shuffle() is removed
}
};
int main()
{
int_v4int iv4;
int_v4unsigned int uv4;
return 0;
}
---
If:
typedef int Tp;
is added at the top and the lines with template stuff are removed then it
compiles just fine but with the use of templates there is a segfault in
shuffle() and if shuffle() is removed then there is:
error: __builtin_shuffle last argument must be an integer vector
in shuffle2(). When compiling with GCC 4.7.2 (which is shipping with Ubuntu
12.10) then everything compiles, even if the line:
int_v4float fv4;
is added to main() (meaning that it was possible to pass non-integer vector as
the last argument of __builtin_shuffle in GCC 4.7.2).
I'm guessing that the bug is somehow related to the presence/addition of error
handling code. It looks like (I am not a GCC developer) GCC is trying to
determine the type of the last argument before any variables using the template
are even defined (they can be removed and the error message will still be
there).
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- I believe that it is not a true regression. In GCC 4.7, the intrinsic assignment create_arbitrary = from_struct() did also an intrinsic assignment of the counter component. Since Paul's GCC 4.8 patch for PR 46897 (r194016), one now invokes subroutine assign for the counter component. - That patch introduced the '@DA0' temporary, which I changed GCC 4.9's r199215 to be _F.DA0 to avoid assembler errors.
[Bug c++/57510] New: initializer_list memory leak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510
Bug ID: 57510
Summary: initializer_list memory leak
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at ookypooky dot com
Created attachment 30247
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30247action=edit
Code demonstrating the problem
It looks as though initializer_list can suffer from memory leaks - if during
construction of the initializer_list members an exception is thrown then the
previously allocated members are not correctly destroyed. Unfortunately I do
not have access to a newer g++ version than 4.7.2, however I could not see any
mention of this issue in the closed bugs.
Code (also attached):
--
#include memory
#include random
struct X
{
X () : m_n (std::unique_ptrint (new int)) { if (random () 1) throw 1; }
std::unique_ptrint m_n;
};
void foo (std::initializer_listX)
{
}
int main ()
{
for (int i = 0; i 10; ++i)
{
try
{
foo ({ X{}, X{} });
}
catch (...) {}
}
}
--
$ g++ -v
Using built-in specs.
COLLECT_GCC=/software/thirdparty/gcc/4.7.2-0.el6_64/bin/g++
COLLECT_LTO_WRAPPER=/software/thirdparty/gcc/4.7.2-0.el6_64/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/software/thirdparty/gcc/4.7.2-0.el6_64
--with-system-zlib --enable-shared --enable-threads=posix --enable-laguages=all
Thread model: posix
gcc version 4.7.2 (GCC)
$ g++ -std=c++11 memory_leak.cpp
$ valgrind ./a.out
==13775== Memcheck, a memory error detector
==13775== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13775== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13775== Command: ./a.out
==13775==
==13775==
==13775== HEAP SUMMARY:
==13775== in use at exit: 12 bytes in 3 blocks
==13775== total heap usage: 23 allocs, 20 frees, 1,244 bytes allocated
==13775==
==13775== LEAK SUMMARY:
==13775==definitely lost: 12 bytes in 3 blocks
==13775==indirectly lost: 0 bytes in 0 blocks
==13775== possibly lost: 0 bytes in 0 blocks
==13775==still reachable: 0 bytes in 0 blocks
==13775== suppressed: 0 bytes in 0 blocks
==13775== Rerun with --leak-check=full to see details of leaked memory
==13775==
==13775== For counts of detected and suppressed errors, rerun with: -v
==13775== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|arm-none-eabi |arm-none-eabi |x86_64-apple-darwin10 |x86_64-apple-darwin10 |cris-elf|cris-elf *-*-solaris2.9 CC||ro at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- Also fails on Solaris 9 with Sun as, will check if current mainline works again. Rainer
[Bug rtl-optimization/57497] [4.9 Regression] ICE in lra_create_new_reg_with_unique_value, at lra.c:155
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57497 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with http://gcc.gnu.org/r199298
[Bug tree-optimization/57511] New: [4.8/4.9 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511
Bug ID: 57511
Summary: [4.8/4.9 Regression] Missing SCEV final value
replacement
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
The following simple loop is no longer optimized out with 4.8 and 4.9:
int main(int argc, char* argv[])
{
int i, a = 0;
for (i=0; i 1; i++)
a += i + 0xff00ff;
return a;
}
$ gcc-4.7.2 -O2 -S main.c -o-
main:
.LFB0:
.cfi_startproc
movl$-334379544, %eax
ret
$ gcc-4.8.0 -O2 -S main.c -o-
main:
.LFB0:
.cfi_startproc
movl$16711935, %edx
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L3:
addl%edx, %eax
addl$1, %edx
cmpl$16721935, %edx
jne.L3
rep ret
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30248 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30248action=edit another example of the alignment faults Hello Sandra, good that you continue to work on that bug again. I agree that there may be two completely different aspects of this bug. Attached you'll find a new test program that came in my mind when I looked at PR 41809, the structure s is aligned 2 and packed. If you make it an array of size 10, each second call of f is given an odd pointer. But the compiler should know that because of the aligned(2) attribute. What is the difference to PR 41809 is this: 1. PR 41809 is not a correct C-program at all, and has never been. While this attached new test program is correct C program. previous GCC versions did compile that correctly, current GCC does not even emit a warning. 2. PR 41809 is not about volatile at all. However if you remove the volatile in the test program(s), the code is correct and does no longer use unaligned addresses. On the other hand, volatile might mean that the compiler should try not to optimize the read instructions, for instance in loops. But of course not to an extent that the generated code is no longer valid.
[Bug c++/57510] initializer_list memory leak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-03
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Testcase without memory and random and not requiring valgrind:
#include initializer_list
struct counter
{
static int n;
counter() { ++n; }
counter(const counter) { ++n; }
~counter() { --n; }
};
int counter::n = 0;
struct X
{
X () { if (counter::n 1) throw 1; }
counter c;
};
int main ()
{
try
{
auto x = { X{}, X{} };
}
catch (...)
{
if ( counter::n != 0 )
throw;
}
}
[Bug sanitizer/57507] gcc 4.8: thread sanitizer: std::thread false(?) positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
Dmitry Vyukov dvyukov at google dot com changed:
What|Removed |Added
CC||dvyukov at google dot com
--- Comment #3 from Dmitry Vyukov dvyukov at google dot com ---
The problem is that libstdc++ is not instrumented. It makes atomic accesses to
the shared_ptr that tsan does not see.
Here are the only events related to address that tsan sees (the first number is
thread id):
#0: alloc(48) = 0x7d0cefd0
#0: MemoryAccess: @0x7f5094bb5021 0x7d0cefd0 size=8 is_write=0
shadow_mem=0x0433bf40 {402418, 0, 0, 0}
#0: __tsan_atomic32_fetch_add(0x7d0cefd8, 4)
#0: MemoryAccess: @0x7f5094bcd8d4 0x7d0cefd8 size=4 is_write=1
shadow_mem=0x0433bf60 {402418, 0, 0, 0}
#1: free(0x7d0cefd0)
#1: MemoryAccessRange: @0x7f5094bb6c27 0x7d0cefd0 size=48 is_write=1
Write of size 8 at 0x7d0cefd8 by thread T1:
Previous atomic write of size 4 at 0x7d0cefd8 by main thread:
Location is heap block of size 48 at 0x7d0cefd0 allocated by main thread:
And here the stack where we detect the race:
#0 __tsan::ReportRace (thr=0x7f8a1c35e800) at tsan_rtl_report.cc:596
#1 0x7f8a1c520565 in __tsan::__tsan_report_race () at tsan_rtl.cc:351
#2 0x7f8a1c5205b8 in __tsan::HandleRace (thr=0x7f8a1c35e800,
shadow_mem=0x433bf60, cur=..., old=...) at tsan_rtl.cc:378
#3 0x7f8a1c5381a3 in __tsan::MemoryAccessImpl (thr=0x7f8a1c35e800,
addr=137490493140952, kAccessSizeLog=3, kAccessIsWrite=true, kIsAtomic=false,
shadow_mem=0x433bf60, cur=...)
at tsan_rtl.cc:462
#4 0x7f8a1c5438ca in __tsan::MemoryAccessRange (thr=0x7f8a1c35e800,
pc=140231157189671, addr=137490493140952, size=40, is_write=true) at
tsan_rtl_thread.cc:363
#5 0x7f8a1c522952 in __tsan::MemoryRangeFreed (thr=0x7f8a1c35e800,
pc=140231157189671, addr=137490493140944, size=48) at tsan_rtl.cc:607
#6 0x7f8a1c5187e6 in __tsan::user_free (thr=0x7f8a1c35e800,
pc=140231157189671, p=0x7d0cefd0) at tsan_mman.cc:138
#7 0x7f8a1c4f8c4b in operator delete (ptr=0x7d0cefd0) at
tsan_interceptors.cc:519
#8 0x7f8a1c4f61ee in
__gnu_cxx::new_allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u
::deallocate(__gnu_cxx::new_allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u ::pointer,
__gnu_cxx::new_allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u ::size_type)
(this=0x7f8a1c35de4f, __p=0x7d0cefd0) at
gccinstall/include/c++/4.9.0/ext/new_allocator.h:110
#9 0x7f8a1c4f60dd in
std::allocator_traitsstd::allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u
::deallocate(std::allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u ,
std::allocator_traitsstd::allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u ::pointer,
std::allocator_traitsstd::allocatorstd::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u ::size_type)
(__a=..., __p=0x7d0cefd0, __n=1)
at gccinstall/include/c++/4.9.0/bits/alloc_traits.h:377
#10 0x7f8a1c4f6855 in
std::_Sp_counted_ptr_inplacestd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() ,
std::allocatorstd::thread::_Implstd::_Bind_simplemain(int,
char**)::lambda()() , (__gnu_cxx::_Lock_policy)2u::_M_destroy(void)
(this=0x7d0cefd0) at
gccinstall/include/c++/4.9.0/bits/shared_ptr_base.h:454
#11 0x7f8a1bc56e7b in _M_release (this=0x7d0cefd0) at
gccbuild/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:163
#12 ~__shared_count (this=synthetic pointer, __in_chrg=optimized out)
at
gccbuild/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:589
#13 ~__shared_ptr (this=synthetic pointer, __in_chrg=optimized out)
at
gccbuild/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:846
#14 ~shared_ptr
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #41 from Dmitry Vyukov dvyukov at google dot com --- Similar problem with libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57507
[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511 --- Comment #1 from Alexander Monakov amonakov at gcc dot gnu.org --- The loop invokes signed integer overflow, but changing 1 to 10 still keeps the missed optimization there.
[Bug tree-optimization/57512] New: Vectorizer: cannot handle accumulation loop of signed char type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57512
Bug ID: 57512
Summary: Vectorizer: cannot handle accumulation loop of signed
char type
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bmei at broadcom dot com
Created attachment 30249
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30249action=edit
Unvectorized with signed char type.
GCC (I used 4.7.2 x86-64 target) cannot vectorize this accumulation loop.
gcc tst.c -O2 -S -ftree-vectorize -fdump-tree-vect-details
signed short mac_char (signed char * __restrict__ in1, signed char *
__restrict__ in2)
{
unsigned i;
signed short sum = 0;
for (i = 0; i 256; i++)
{
signed char d1 = in1[i];
signed char d2 = in2[i];
sum += ((signed short)d1 * (signed short)d2);
}
return sum;
}
If I change signed char to unsigned char, vectorization does work.
unsigned short mac_uchar (unsigned char * __restrict__ in1, unsigned char *
__restrict__ in2)
{
unsigned i;
unsigned short sum = 0;
for (i = 0; i 256; i++)
{
unsigned char d1 = in1[i];
unsigned char d2 = in2[i];
sum += ((unsigned short)d1 * d2);
}
return sum;
}
Looking into .vect file, I think the problem is with handling following gimple
stmts. GCC converts short additions to unsigned short additions and then
converts result back to short because of integer promotion. This confuses
vectorizer so it cannot find correct vector reduction patterns.
D.3015_14 = (short unsigned int) D.3014_13;
sum.0_15 = (short unsigned int) sum_25;
D.3017_16 = D.3015_14 + sum.0_15;
sum_17 = (short int) D.3017_16;
[Bug tree-optimization/57512] Vectorizer: cannot handle accumulation loop of signed char type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57512 --- Comment #1 from Bingfeng Mei bmei at broadcom dot com --- Created attachment 30250 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30250action=edit Vectorized assembly code with unsigned char type
[Bug libstdc++/57513] New: std::regex_token_iterator fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 Bug ID: 57513 Summary: std::regex_token_iterator fails to link Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: andy at aligature dot com Created attachment 30251 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30251action=edit test code file Any code using std::regex_token_iterator fails to link with gcc-4.8.1. See the attached code sample. ./gcc-4.8.1/bin/g++ -std=c++11 -Wl,-rpath ./gcc-4.8.1/lib64 regex.cpp -o regex /tmp/ccmknhZw.o: In function `main': regex.cpp:(.text+0x10): undefined reference to `std::regex_token_iterator__gnu_cxx::__normal_iteratorchar const*, std::string, char, std::regex_traitschar ::regex_token_iterator()' collect2: error: ld returned 1 exit status
[Bug c++/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #6 from Charles L. Wilcox zxClhzAApX1EdJwQANqrjLERmFeURQVy at cynd dot net --- (In reply to Paolo Carlini from comment #5) Just to clarify that this is neither a library neither a C++ front-end issue: limits just uses the various __builtin_nans* Paolo, I guessed this was the case from what I could tell using the debugger, but I wanted some confirmation that I was correct. Should the Component be changed from C++ to something else?
[Bug c++/57510] initializer_list memory leak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 CC||jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Thus I would say wrong code and P2.
[Bug c++/52377] C++11 non-static initializers in unions are not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52377 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks!
[Bug libstdc++/57513] std::regex_token_iterator fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Even if it linked it probably wouldn't work because most of regex is unimplemented. *** This bug has been marked as a duplicate of bug 53631 ***
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||andy at aligature dot com --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 57513 has been marked as a duplicate of this bug. ***
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #3 from Martin Liška marxin.liska at gmail dot com --- I had a problem with linker, looks like chrome build system uses both linkers. I hacked build system to use just ld.bfd. gcc revision: 197652. I know it's about 2 months old, same error is given by gcc from about 15th May 2013. Latest gcc suffers from a different failure that will be added in following comment. ld --version: GNU ld (GNU Binutils) 2.23.52.20130526 Failure: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1 -Wl,--as-needed -flto -fno-fat-lto-objects -o mksnapshot.x64 -Wl,--start-group obj/v8/src/mksnapshot.x64.mksnapshot.o obj/v8/tools/gyp/libv8_nosnapshot.x64.a obj/v8/tools/gyp/libv8_base.x64.a -Wl,--end-group -fdump-ipa-all --save-temps lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:267 0x709296 inline_call(cgraph_edge*, bool, veccgraph_edge*, va_heap, vl_ptr*, int*, bool) ../../gcc/ipa-inline-transform.c:263 0x6fb118 inline_small_functions ../../gcc/ipa-inline.c:1613 0x6fb118 ipa_inline ../../gcc/ipa-inline.c:1794 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++ returned 1 exit status [Leaving LTRANS mksnapshot.x64.ltrans.out] [Leaving LTRANS /tmp/ccIviE1Z.args] /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Dump: https://docs.google.com/file/d/0B0pisUJ80pO1ck5sUmF5Q0k1Mmc/edit?usp=sharing Thanks, Martin
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503
--- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Created attachment 30252
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30252action=edit
.165r.expand: dump file with -Os -mmcu=atmega168 -fno-expensive-optimizations
The tree-ssa part for widening_mul can be disabled by
-fno-expensive-optimizations, but the code is still wrong. Cf. the attached
.expand dump of
long
func1 (unsigned char a, unsigned char b, int c)
{
unsigned ab = a * b;
return (long) ab * c;
}
ab is computed in insn 10 with zero-extended inputs:
(insn 8 5 9 2 (set (reg:HI 53 [ D.1447 ])
(zero_extend:HI (reg/v:QI 49 [ a ]))) cecky.c:4 -1
(nil))
(insn 9 8 10 2 (set (reg:HI 54 [ D.1447 ])
(zero_extend:HI (reg/v:QI 50 [ b ]))) cecky.c:4 -1
(nil))
(insn 10 9 11 2 (set (reg:HI 55 [ D.1447 ])
(mult:HI (reg:HI 53 [ D.1447 ])
(reg:HI 54 [ D.1447 ]))) cecky.c:4 -1
This is correct, but then in insn 11 ab gets sign-extended even though it is
unsigned:
(insn 11 10 12 2 (set (reg:SI 56 [ D.1448 ])
(sign_extend:SI (reg:HI 55 [ D.1447 ]))) cecky.c:5 -1
(nil))
Insn combine combines this wrong extension into a widening multiplication.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #4 from Martin Liška marxin.liska at gmail dot com --- gcc --version: HEAD (June 3rd, 2013) Failure: g++ -Wl,-z,now -Wl,-z,relro -pthread -Wl,-z,noexecstack -fPIC -Wl,-O1 -Wl,--as-needed -flto -fno-fat-lto-objects -o protoc -Wl,--start-group obj/third_party/protobuf/src/google/protobuf/compiler/protoc.code_generator.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.command_line_interface.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.plugin.pb.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.subprocess.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.zip_writer.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_enum_field.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_extension.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_field.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_file.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_generator.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_helpers.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_message_field.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_primitive_field.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_service.o obj/third_party/protobuf/src/google/protobuf/compiler/cpp/protoc.cpp_string_field.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_enum_field.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_extension.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_field.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_file.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_generator.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_helpers.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_message_field.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_primitive_field.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_service.o obj/third_party/protobuf/src/google/protobuf/compiler/java/protoc.java_string_field.o obj/third_party/protobuf/src/google/protobuf/compiler/python/protoc.python_generator.o obj/third_party/protobuf/src/google/protobuf/compiler/protoc.main.o obj/third_party/protobuf/libprotobuf_full_do_not_use.a -Wl,--end-group lto1: internal compiler error: in get_alias_symbol, at lto-cgraph.c:921 0x77d283 get_alias_symbol ../../gcc/lto-cgraph.c:921 0x77ff45 input_node ../../gcc/lto-cgraph.c:1012 0x77ff45 input_cgraph_1 ../../gcc/lto-cgraph.c:1176 0x77ff45 input_symtab() ../../gcc/lto-cgraph.c:1449 0x507cda read_cgraph_and_symbols ../../gcc/lto/lto.c:2967 0x507cda lto_main() ../../gcc/lto/lto.c:3327 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++ returned 1 exit status /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Dump: https://docs.google.com/file/d/0B0pisUJ80pO1MWZRMU5MZ3BYWE0/edit?usp=sharing Thank you, Martin
[Bug middle-end/57484] 'std::numeric_limits T ::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|c++ |middle-end --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- middle-end seems more appropriate. Richard, can you help me triaging this? Thanks in advance.
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #5 from thutt at vmware dot com --- (In reply to Andrew Pinski from comment #3) (In reply to thutt from comment #2) Can you please explain why it's invalid to return a double if SSE is disabled? SSE is an x86-specific hardware implementation and has nothing to do with language validity from my standpoint. On x86_64 the ABI says doubles are returned (and passed) via the SSE registers. Compiling the same program with gcc-4.8 -m64 -mno-sse -c -o /tmp/gungla.o /tmp/gungla.c does not exhibit the issue. Is there simple explanation for the difference in behavior?
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to thutt from comment #5) Is there simple explanation for the difference in behavior? Is the preprocessed source the same? I bet glibc enables some inline function at -O1.
[Bug middle-end/57500] [4.9 Regression] Segfault in ipa_record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57500 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine. Seems alias target got lost somehow.
[Bug c++/57514] New: -fno-align-functions doesn't work on member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57514
Bug ID: 57514
Summary: -fno-align-functions doesn't work on member functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
[hjl@gnu-6 tmp]$ cat a.cc
class Foo
{
public:
void yyy ();
};
void
Foo::yyy ()
{
}
[hjl@gnu-6 tmp]$ gcc -S a.cc -fno-align-functions -O3
[hjl@gnu-6 tmp]$ cat a.s
.filea.cc
.text
.align 2
.globl_ZN3Foo3yyyEv
.type_ZN3Foo3yyyEv, @function
_ZN3Foo3yyyEv:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.size_ZN3Foo3yyyEv, .-_ZN3Foo3yyyEv
[hjl@gnu-6 tmp]$ gcc -S a.cc -O3
[hjl@gnu-6 tmp]$ cat a.s
.filea.cc
.text
.align 2
.p2align 4,,15
.globl_ZN3Foo3yyyEv
.type_ZN3Foo3yyyEv, @function
_ZN3Foo3yyyEv:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE0:
.size_ZN3Foo3yyyEv, .-_ZN3Foo3yyyEv
C++ front end has
/* If pointers to member functions use the least significant bit to
indicate whether a function is virtual, ensure a pointer
to this function will have that bit clear. */
if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn
TREE_CODE (type) == METHOD_TYPE
DECL_ALIGN (decl) 2 * BITS_PER_UNIT)
DECL_ALIGN (decl) = 2 * BITS_PER_UNIT;
But the function alignment is controlled by -falign-functions and
backends. All member functions may be aligned to 16 byte on x86.
How does C++ run-tim use the least significant bit to indicate
whether a member function is virtual?
[Bug libstdc++/57515] New: implement begin() and end() for fixed size arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515
Bug ID: 57515
Summary: implement begin() and end() for fixed size arrays
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jos at vandenoever dot info
Currently this code does not compile:
int total = 0;
std::for_each(begin(some_list), end(some_list), [total](int x) {
total += x;
});
because begin() and end() are not defined for simple arrays. Implementing this
functionality is simple:
template class T
constexpr inline T* begin(T t[]) {
return t;
}
template class T, size_t N
constexpr inline T* end(T (t)[N]) {
return t + sizeof(t) / sizeof(T);
}
[Bug libstdc++/57515] implement begin() and end() for fixed size arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515
--- Comment #1 from jos at vandenoever dot info ---
The first line of the code snippet was missing:
int some_list[]={ 1, 2, 3, 4, 5 };
int total = 0;
std::for_each(begin(some_list), end(some_list), [total](int x) {
total += x;
});
[Bug c++/57514] -fno-align-functions doesn't work on member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57514 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- How does C++ run-tim use the least significant bit to indicate whether a member function is virtual? Why not read the ABI? Basically pointer to member function need to indicate if they are either a virtual function (then an indirect call via the vtable) or a direct call (just use the pointer to member function ptr).
[Bug c++/57514] -fno-align-functions doesn't work on member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57514 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-06-03 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Andrew Pinski from comment #1) How does C++ run-tim use the least significant bit to indicate whether a member function is virtual? Why not read the ABI? Basically pointer to member function need to indicate if they are either a virtual function (then an indirect call via the vtable) or a direct call (just use the pointer to member function ptr). Why does alignment of pointer to member function have anything to do with function alignment?
[Bug target/57516] New: [avr] Incorrect fixed-point rounding result in the overflow case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57516 Bug ID: 57516 Summary: [avr] Incorrect fixed-point rounding result in the overflow case Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org CC: eric.weddington at atmel dot com Target: avr ISO/IEC TR 18037 writes on the roundfx rounding functions: 2.1.7.2 The fixed-point rounding functions [...] The rounding applied is to-nearest, with unspecified rounding direction in the halfway case. Fractional bits beyond the rounding point are set to zero in the result. If the exact result value cannot be represented, the saturated result value is returned. Currently, bits beyond the rounding point are always cleared, no matter whether or not the intermediate result is representable or not.
[Bug target/57516] [avr] Incorrect fixed-point rounding result in the overflow case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57516 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 Target Milestone|--- |4.8.2 Ever confirmed|0 |1
[Bug c++/57514] -fno-align-functions doesn't work on member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57514 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to H.J. Lu from comment #2) Why does alignment of pointer to member function have anything to do with function alignment? Simple a pointer to a member function is a pointer to a function in the non virtual case. In the virtual case with the lower bit set, it is some offset for the vtable.
[Bug libstdc++/57515] implement begin() and end() for fixed size arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- The code doesn't compile because it isn't valid, you need to use std::begin and std::end, and please don't file bug reports that contain only a snippet of code without includes etc. the bug reporting guidelines clearly say we do not want: * A source file that #includes header files that are left out of the bug report (see above) * A code snippet that won't cause the compiler to produce the exact output mentioned in the bug report (e.g., a snippet with just a few lines around the one that apparently triggers the bug, with some pieces replaced with ellipses or comments for extra obfuscation :-)
[Bug middle-end/57500] [4.9 Regression] Segfault in ipa_record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57500 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, the problem here is that the symbol is not created yet, but decl exists. Why it happens with -g only is bit strange. The following should fix it however Index: cgraphunit.c === --- cgraphunit.c(revision 199591) +++ cgraphunit.c(working copy) @@ -656,8 +656,11 @@ cgraph_process_same_body_aliases (void) symtab_node node; FOR_EACH_SYMBOL (node) if (node-symbol.cpp_implicit_alias !node-symbol.analyzed) - symtab_resolve_alias (node, - symtab_get_node (node-symbol.alias_target)); + symtab_resolve_alias +(node, + TREE_CODE (node-symbol.alias_target) == VAR_DECL + ? (symtab_node)varpool_node_for_decl (node-symbol.alias_target) + : (symtab_node)cgraph_get_create_node (node-symbol.alias_target)); cpp_implicit_aliases_done = true; }
[Bug tree-optimization/57517] New: internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517 Bug ID: 57517 Summary: internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: decker at envsci dot rutgers.edu The following code compiles at O2, but not O3. ~/test gfortran481 -O3 -c module_diffusion_em.f90 module_diffusion_em.f90: In function ‘cal_helicity’: module_diffusion_em.f90:1:0: internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913 SUBROUTINE cal_helicity (uh, ph, phb, ht, ims, ime, jms, jme, kms, kme, ^ 0xc81b7a eliminate_temp_copies ../../gcc-4.8.1/gcc/tree-predcom.c:1913 0xc81b7a tree_predictive_commoning_loop ../../gcc-4.8.1/gcc/tree-predcom.c:2519 0xc82277 tree_predictive_commoning() ../../gcc-4.8.1/gcc/tree-predcom.c:2554 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ~/test cat module_diffusion_em.f90 SUBROUTINE cal_helicity (uh, ph, phb, ht, ims, ime, jms, jme, kms, kme, its, ite, jts, jte, kts, kte) INTEGER, INTENT( IN ) :: ims, ime, jms, jme, kms, kme, its, ite, jts, jte, kts, kte REAL, DIMENSION( ims:ime , jms:jme ), INTENT( IN ) :: ht REAL, DIMENSION( ims:ime, kms:kme, jms:jme ), INTENT( IN ) :: ph, phb REAL, DIMENSION( ims:ime, jms:jme ), INTENT( INOUT ) :: uh INTEGER :: i, j, k, ktf, i_start, i_end, j_start, j_end REAL :: zl, zu REAL, DIMENSION( its-2:ite+2, kts:kte, jts-2:jte+2 ) :: wavg, rvort real, parameter :: g = 9.81 DO j = j_start, j_end DO k = kts, ktf DO i = i_start, i_end zu = (( ph(i ,k+1,j ) + phb(i ,k+1,j ) ) / g - ht(i ,j ) ) + (( ph(i-1,k+1,j ) + phb(i-1,k+1,j ) ) / g - ht(i-1,j ) ) + (( ph(i ,k+1,j-1) + phb(i ,k+1,j-1) ) / g - ht(i ,j-1) ) IF ( zl .GE. 2000. .AND. zu .LE. 5000. ) THEN IF ( wavg(i,k,j) .GT. 0. .AND. wavg(i,k+1,j) .GT. 0. ) THEN uh(i,j) = uh(i,j) + ( wavg(i,k,j) * rvort(i,k,j) + wavg(i,k+1,j) * rvort(i,k+1,j) ) * ( zu - zl ) ENDIF ENDIF END DO END DO END DO END SUBROUTINE cal_helicity ~/test gfortran481 -v Using built-in specs. COLLECT_GCC=/home/decker/local/gcc481/bin/gfortran481 COLLECT_LTO_WRAPPER=/home/decker/local/gcc481/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.1/configure --prefix=/home/decker/local/gcc481 --program-suffix=481 --enable-languages=c,c++,fortran --with-gmp=/home/decker/local --with-mpfr=/home/decker/local --with-mpc=/home/decker/local --with-isl=/home/decker/local --with-cloog=/home/decker/local Thread model: posix gcc version 4.8.1 (GCC)
[Bug libstdc++/57515] implement begin() and end() for fixed size arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57515
jos at vandenoever dot info changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
--- Comment #3 from jos at vandenoever dot info ---
I've expanded the comment with #include and std::. It *does* compile now, so
the bug was invalid.
#include algorithm
#include iostream
int
main() {
int some_list[]={ 1, 2, 3, 4, 5 };
int total = 0;
std::for_each(std::begin(some_list), std::end(some_list), [total](int x) {
total += x;
});
std::cout total std::endl;
return 0;
}
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Dara Hazeghi dhazeghi at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Dara Hazeghi dhazeghi at yahoo dot com --- I think I've managed to wrap my head around the discussion of DR 236, and I agree that the code submitted is indeed undefined. Thanks for the discussion and explanations.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #16 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Yes please. If you can run: dwarfdump --eh-frame --verify file.o on all the .o files and see if there are any more lurking in there. Any that fail verification will need to be fixed, one way, or another.
[Bug target/47333] [4.8/4.9 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #35 from Jan Hubicka hubicka at gcc dot gnu.org --- I am having problem to reproduce it on a cross compiler. I assume you have non-plugin-enable LD setup, right?
[Bug target/47333] [4.8/4.9 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #36 from Jan Hubicka hubicka at gcc dot gnu.org --- I am having problem to reproduce it on a cross compiler. I assume you have non-plugin-enable LD setup, right? There is problem with chained weakrefs that ought to be fixed by the following change: Index: cgraphunit.c === --- cgraphunit.c(revision 199591) +++ cgraphunit.c(working copy) @@ -656,8 +656,11 @@ cgraph_process_same_body_aliases (void) @@ -2018,7 +2021,7 @@ compile (void) (DECL_ASSEMBLER_NAME (node-symbol.decl)) = 1; TREE_CHAIN (DECL_ASSEMBLER_NAME (node-symbol.decl)) = (node-symbol.alias_target ? node-symbol.alias_target - : DECL_ASSEMBLER_NAME (symtab_alias_target (node)-symbol.decl)); + : DECL_ASSEMBLER_NAME (symtab_alias_ultimate_target (node)-symbol.decl)); } #endif I however do not see any chained weakrefs in the preprocessed file attached, so I am not quite convinced this can change anything. Can you, please, run it in debugger and take a look what is the assembler name ultimate_target is called for and what is its CHAIN_DECL?
[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug rtl-optimization/57518] New: Redundent insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
Bug ID: 57518
Summary: Redundent insn generated in LRA
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
Testcase:
char ip[10];
int total, total1;
void foo() {
int t;
t = ip[2];
total = t 0x3;
}
Target: x86_64-linux-gnu
gcc version 4.9.0 20130529 (experimental) (GCC)
~/workarea/gcc-r199418/build/install/bin/gcc -O2 -S 1.c
.cfi_startproc
movzbl ip+2(%rip), %eax
movb%al, -16(%rsp) == redundent
movl-16(%rsp), %eax== redundent
andl$3, %eax
movl%eax, total(%rip)
ret
.cfi_endproc
Target: x86_64-linux-gnu
gcc version 4.8.0 20120613 (experimental) (GCC)
gcc -O2 -S 1.c
.cfi_startproc
movzblip+2(%rip), %eax
andl$3, %eax
movl%eax, total(%rip)
ret
.cfi_endproc
IR before LRA:
(insn 12 7 8 2 (set (reg:QI 64 [ ip+2 ])
(mem/j/c:QI (const:DI (plus:DI (symbol_ref:DI (ip) var_decl
0x761da260 ip)
(const_int 2 [0x2]))) [0 ip+2 S1 A8])) 1.c:9 87
{*movqi_internal}
(expr_list:REG_EQUIV (mem/j/c:QI (const:DI (plus:DI (symbol_ref:DI (ip)
var_decl 0x761da260 ip)
(const_int 2 [0x2]))) [0 ip+2 S1 A8])
(nil)))
(insn 8 12 9 2 (parallel [
(set (reg:SI 65 [ D.1731 ])
(and:SI (subreg:SI (reg:QI 64 [ ip+2 ]) 0)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) 1.c:9 387 {*andsi_1}
(expr_list:REG_DEAD (reg:QI 64 [ ip+2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI (total) var_decl
0x761da2f8 total) [2 total+0 S4 A32])
(nil)
IR after LRA:
(insn 12 7 14 2 (set (reg:QI 0 ax [orig:64 ip+2 ] [64])
(mem/j/c:QI (const:DI (plus:DI (symbol_ref:DI (ip) var_decl
0x761da260 ip)
(const_int 2 [0x2]))) [0 ip+2 S1 A8])) 1.c:9 87
{*movqi_internal}
(expr_list:REG_EQUIV (mem/j/c:QI (const:DI (plus:DI (symbol_ref:DI (ip)
var_decl 0x761da260 ip)
(const_int 2 [0x2]))) [0 ip+2 S1 A8])
(nil)))
(insn 14 12 15 2 (set (mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [3 %sfp+-16 S1 A64])
(reg:QI 0 ax [orig:64 ip+2 ] [64])) 1.c:9 87 {*movqi_internal}
(expr_list:REG_DEAD (reg:QI 0 ax [orig:64 ip+2 ] [64])
(nil)))
(insn 15 14 8 2 (set (reg:SI 0 ax [orig:65 D.1731 ] [65])
(mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [3 %sfp+-16 S4 A64]))
1.c:9 85 {*movsi_internal}
(nil))
(insn 8 15 16 2 (parallel [
(set (reg:SI 0 ax [orig:65 D.1731 ] [65])
(and:SI (reg:SI 0 ax [orig:65 D.1731 ] [65])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) 1.c:9 387 {*andsi_1}
(expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI (total) var_decl
0x761da2f8 total) [2 total+0 S4 A32])
(nil)))
IRA Trace:
Pass 0 for finding pseudo/allocno costs
a0 (r65,l0) best GENERAL_REGS, allocno GENERAL_REGS
a1 (r64,l0) best NO_REGS, allocno NO_REGS
a1's rclass are all NO_REGS because it has REG_EQUIV note (equivalent to mem
ip+2)
Because reg 64 is marked as equivalent to mem ip+2, insn 12 is expected to be
deleted and reg 64 in insn 8 replaced by mem ip+2. In LRA constraints, insn 12
is not deleted because the subreg op in insn 8 (see lra-constraints.c:3662
r199418). In addition, reg 64's rclass is NO_REGS, so redundent spills are
inserted.
The mode size check (lra-constraints.c:3662 r199418) needs to be considered in
update_equiv_regs in IRA, in order not to mark the reg 64 equivalent with mem
ip + 2 in this case.
[Bug fortran/57508] [4.8/4.9 Regression] [OOP] Intrinsic assignment+defined-assignment for comps: PROCEDURE attribute of '_F.DA0' conflicts with VARIABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57508 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Patch, pending review: http://gcc.gnu.org/ml/fortran/2013-06/msg00027.html
[Bug debug/57519] New: DW_TAG_imported_declaration put in wrong class (base class instead of derived class)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57519
Bug ID: 57519
Summary: DW_TAG_imported_declaration put in wrong class (base
class instead of derived class)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at google dot com
Created attachment 30253
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30253action=edit
assembler output
[with svn head as of today]
class base
{
public:
int foo (int x) { return x; }
};
class derived : base
{
public:
using base::foo;
double foo (double x) { return x; }
};
int
main ()
{
derived *d = new derived;
return d-foo (0);
}
bash$ g++ -m64 -c -o using-method.o64 using-method.cc -g -save-temps -dA
-fverbose-asm
I see this in the debug info for base (instead of derived):
.uleb128 0x6# (DIE (0x58) DW_TAG_imported_declaration)
.byte 0x1 # DW_AT_decl_file (using-method.cc)
.byte 0x8 # DW_AT_decl_line
.long 0x35# DW_AT_import
I would have expected this to be in the debug info for derived.
[full output attached]
[Bug rtl-optimization/57462] ira-costs considers only a single register at a time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57462 --- Comment #2 from Joshua Conner josh.m.conner at gmail dot com --- No problem - I appreciate you taking the time to respond. This has a noticeable impact on codegen for ARM because of the redundancy in the CPU/FPU functionality and cost of transferring data between integer/FP registers, so I thought it would be worth mentioning in case it wasn't recognized already. Thanks.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #17 from Dara Hazeghi dhazeghi at yahoo dot com --- (In reply to m...@gcc.gnu.org from comment #16) Yes please. If you can run: dwarfdump --eh-frame --verify file.o on all the .o files and see if there are any more lurking in there. Any that fail verification will need to be fixed, one way, or another. From gcc/ I see the following: 1 errors found in EH frame for dfp.o (x86_64). 1 errors found in EH frame for gengtype-state.o (x86_64). 1 errors found in EH frame for hooks.o (x86_64). 3 errors found in EH frame for i386.o (x86_64). 3 errors found in EH frame for insn-output.o (x86_64). 2 errors found in EH frame for langhooks.o (x86_64). 1 errors found in EH frame for sched-deps.o (x86_64). 9 errors found in EH frame for targhooks.o (x86_64). 1 errors found in EH frame for tree-profile.o (x86_64). 1 errors found in EH frame for tree-ssa-loop-im.o (x86_64). 2 errors found in EH frame for tree.o (x86_64). 1 errors found in EH frame for var-tracking.o (x86_64). Shall I upload the object code or the assembly code?
[Bug c++/57520] New: alias template substitution/deduction failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57520
Bug ID: 57520
Summary: alias template substitution/deduction failure
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stephen.pope at predict dot com
gcc 4.8.1 (as well as 4.8.0 and 4.7.2) appears to fail to correctly substitute
the alias's template-id for an alias template instantiation when reference or
by pointer types are involved.
I was able to whittle a messy real-world problem down to a minor variation on
the non-normative example provided in the C++ 11 standard section temp.alias
(14.5.7/2):
#include vector
using namespace std;
template class T
using Vec = vectorT, allocatorT;
template template class class TT
void f1(TTint v);
template template class class TT
void f2(TTint v);
template template class class TT
void f3(TTint* v);
template template class, class class TT
void g1(TTint, allocatorint v);
template template class, class class TT
void g2(TTint, allocatorint v);
template template class, class class TT
void g3(TTint, allocatorint* v);
void foo()
{
Vecint v;
f1(v);// gcc and clang both correctly yield no matching function error
g1(v);
f2(v);// clang yields a no matching function error
g2(v);// gcc yields a no matching function error
f3(v);// clang yields a no matching function error
g3(v);// gcc yields a no matching function error
}
(compile with -std=c++11)
As noted above, clang 3.3 (recent pull from svn) and gcc (4.7.2, 4.8.0, and
4.8.1) agree on the handling of f1/g1 in conformance with the standard, but
differ on the handling of f2/g2 and f3/g3 (to be clear, all tested versions of
gcc incorrectly accept the call to f2() and f3() and error on the call to g2()
and g3()).
All indications, both in this example and in my real problem, are that gcc is
not correctly converting the type of the instantiation of the alias template
(e.g. Vecint) to the aliased type (e.g. vectorint, allocatorint) prior to
trying to deduce the template parameter for the instantiations of f2, f3, g2,
and g3.
Here is the full error output of gcc-4.8.1:
% gcc-4.8.1/bin/g++ -Wall -Wextra -std=c++11 temp.cpp
temp.cpp: In function 'void foo()':
temp.cpp:30:8: error: no matching function for call to 'f1(Vecint)'
f1(v);// gcc and clang both correctly yield no matching function error
^
temp.cpp:30:8: note: candidate is:
temp.cpp:9:6: note: templatetemplateclass class TT void f1(TTint)
void f1(TTint v);
^
temp.cpp:9:6: note: template argument deduction/substitution failed:
temp.cpp:30:8: error: wrong number of template arguments (2, should be 1)
f1(v);// gcc and clang both correctly yield no matching function error
^
temp.cpp:8:34: error: provided for 'templateclass class TT'
template template class class TT
^
temp.cpp:34:8: error: no matching function for call to 'g2(Vecint)'
g2(v);// gcc yields a no matching function error
^
temp.cpp:34:8: note: candidate is:
temp.cpp:21:6: note: templatetemplateclass, class class TT void g2(TTint,
std::allocatorint )
void g2(TTint, allocatorint v);
^
temp.cpp:21:6: note: template argument deduction/substitution failed:
temp.cpp:34:8: error: wrong number of template arguments (1, should be 2)
g2(v);// gcc yields a no matching function error
^
temp.cpp:20:41: error: provided for 'templateclass, class class TT'
template template class, class class TT
^
temp.cpp:37:9: error: no matching function for call to 'g3(Vecint*)'
g3(v);// gcc yields a no matching function error
^
temp.cpp:37:9: note: candidate is:
temp.cpp:24:6: note: templatetemplateclass, class class TT void g3(TTint,
std::allocatorint *)
void g3(TTint, allocatorint* v);
^
temp.cpp:24:6: note: template argument deduction/substitution failed:
temp.cpp:37:9: error: wrong number of template arguments (1, should be 2)
g3(v);// gcc yields a no matching function error
^
temp.cpp:23:41: error: provided for 'templateclass, class class TT'
template template class, class class TT
^
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #17 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Mikael Pettersson from comment #16) FWIW, I've bootstrapped and regtested gcc 4.9 with r192676 reapplied and the dse.c and cselib.c hunks of r193802 reverted on several hosts (x86_64, sparc64, powerpc64, armv5tel, m68k) without regressions. Wow, thanks. So, what's needed is to just spell out the exact patch (a description as above doesn't suffice unfortunately), send it to gcc-patches and CC Eric who I think would ok it at a glance. Here's me hoping someone will beat me to it, but it just might happen *this* month...
[Bug c++/57471] [4.9 Regression] Bizarre error for template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57471 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 Summary|[C++11] Bizarre error for |[4.9 Regression] Bizarre |template parameter pack |error for template ||parameter pack Ever confirmed|0 |1
[Bug c++/57443] Captured variable hide the parameter if they have the same name in Lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57443 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 Blocks||54367 Ever confirmed|0 |1 Severity|major |normal
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu --- Do we have any idea why this problem is latent with --checking=release and --checking=yes but is triggered by --disable-checking?
[Bug c++/57444] ICE in instantiate_type for invalid use of member with using-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57444 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-03 Ever confirmed|0 |1
[Bug c++/57471] [4.9 Regression] Bizarre error for template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57471 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Regressed withe the fix for PR c++/56679.
[Bug tree-optimization/57521] New: wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521
Bug ID: 57521
Summary: wrong code for expressions in loop at -O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dhazeghi at yahoo dot com
The following code is miscompiled with current gcc trunk at -O3 optimization on
x86_64-linux. I've tried to reduce it somewhat from the original form. Note
that 'e' is only touched in one place. This also fails on 4.7 and 4.8 and is a
regression from gcc 4.6.
$ gcc-trunk -v
gcc version 4.9.0 20130603 (experimental) [trunk revision 199601] (GCC)
$ gcc-trunk -O2 wrong.c
$ ./a.out
1
$ gcc-4.6 -O3 wrong.c
$ ./a.out
1
$ gcc-trunk -O3 wrong.c
$ ./a.out
0
$
--
int printf (const char *, ...);
int a, b, c, d, o = 1, p;
short e;
int
fn1 (int * p1)
{
int f, g, h, j = 0, k = 0, l = 0;
unsigned int i;
int *m[1] = { l };
for (; b = 0; b--)
{
if (*p1)
if (j = 0)
{
int n = 1;
e = 1;
h = a ? a : 1 % n;
g = h 0 ? 0 : h + 1;
k = c + g;
}
else
continue;
else
{
f = d 0 ? 0 : d + 1;
i = f;
j = 1 + i;
}
l++;
}
return k;
}
int
main ()
{
for (;; p++)
{
fn1 (o);
break;
}
printf (%d\n, e);
return 0;
}
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #19 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- I'll build my own tree, thanks. I was hoping that it was a singular issue and we'd be done with it.
[Bug middle-end/57500] [4.9 Regression] Segfault in ipa_record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57500 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from David Edelsohn dje at gcc dot gnu.org --- The proposed patch fixes the regression. I commmitted it with permission.
[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 --- Comment #5 from David Krauss potswa at mac dot com --- Does this also fix #57429?
[Bug c++/57429] Dependent function call with one visible declaration, deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57429 --- Comment #1 from David Krauss potswa at mac dot com --- To clarify the example, it's failing at definition time. There are two separate failures illustrated, a function template and a class template.
[Bug tree-optimization/57521] [4.7/4.8/4.9 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-04 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|wrong code for expressions |[4.7/4.8/4.9 Regression] |in loop at -O3 |wrong code for expressions ||in loop at -O3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r175704 aka PR46787.
