[Bug libstdc++/56613] [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Known to work||4.7.2 Target Milestone|--- |4.8.0
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-14 09:13:45 UTC --- Author: jakub Date: Thu Mar 14 09:13:36 2013 New Revision: 196650 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196650 Log: PR tree-optimization/53265 * common.opt (Waggressive-loop-optimizations): New option. * tree-ssa-loop-niter.c: Include tree-pass.h. (do_warn_aggressive_loop_optimizations): New function. (record_estimate): Call it. Don't add !is_exit bounds to loop-bounds if number_of_latch_executions returned constant. (estimate_numbers_of_iterations_loop): Call number_of_latch_executions early. If number_of_latch_executions returned constant, set nb_iterations_upper_bound back to it. * cfgloop.h (struct loop): Add warned_aggressive_loop_optimizations field. * Makefile.in (tree-ssa-loop-niter.o): Depend on $(TREE_PASS_H). * doc/invoke.texi (-Wno-aggressive-loop-optimizations): Document. * gcc.dg/pr53265.c: New test. * gcc.dg/torture/pr49518.c: Add -Wno-aggressive-loop-optimizations to dg-options. * g++.dg/opt/longbranch2.C (EBCOTLut): Double sizes of a2 and a3 arrays. * gcc.dg/tree-ssa/cunroll-10.c (main): Rename to foo. Add argument n, use it as high bound instead of 4. * unwind-dw2.c (execute_cfa_program): Avoid -Waggressive-array-optimizations warnings for DW_CFA_GNU_window_save on targets with DWARF_FRAME_REGISTERS 32. * testsuite/libmudflap.c/fail37-frag.c: Add optimization barrier. Added: trunk/gcc/testsuite/gcc.dg/pr53265.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cfgloop.h trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/longbranch2.C trunk/gcc/testsuite/gcc.dg/torture/pr49518.c trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-10.c trunk/gcc/tree-ssa-loop-niter.c trunk/libgcc/ChangeLog trunk/libgcc/unwind-dw2.c trunk/libmudflap/ChangeLog trunk/libmudflap/testsuite/libmudflap.c/fail37-frag.c
[Bug target/56592] [SH] Add vector ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56592 Manu Evans turkeyman at gmail dot com changed: What|Removed |Added CC||turkeyman at gmail dot com --- Comment #1 from Manu Evans turkeyman at gmail dot com 2013-03-14 09:48:17 UTC --- I watch with keen anticipation! :)
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-14 10:21:05 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=184199 aka PR39055. If the testcase is valid, perhaps we need to special case the std::initializer_list temporaries, or allow DECL_ARTIFICIAL except for this?
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-14 10:54:45 UTC --- Author: jakub Date: Thu Mar 14 10:54:38 2013 New Revision: 196655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196655 Log: PR tree-optimization/53265 * gcc.dg/graphite/scop-3.c (toto): Increase array size to avoid undefined behavior. * gcc.dg/graphite/id-6.c (test): Likewise. * gcc.dg/graphite/pr35356-2.c: Adjust regexp patterns to only look for MIN_EXPR and MAX_EXPR in GIMPLE stmts. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/id-6.c trunk/gcc/testsuite/gcc.dg/graphite/pr35356-2.c trunk/gcc/testsuite/gcc.dg/graphite/scop-3.c
[Bug fortran/56615] New: [4.4/4.5/4.6/4.7 Regression] Wrong code for passing arrays of character
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56615 Bug #: 56615 Summary: [4.4/4.5/4.6/4.7 Regression] Wrong code for passing arrays of character Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: anl...@gmx.de Hi, the code bwloe works with gfortran 4.1.2 and 4.3.4, but fails at least with 4.4.0, 4.5 and 4.7. Correct output: # Forward: a=abcdefgh s=abcdefgh c=abcdefgh ok stride = +2: u=aceg c=aceg ok # Backward: b=hgfedcba t=hgfedcba c=hgfedcba ok stride = -1: c=hgfedcba ok Wrong output: # Forward: a=abcdefgh s=abcdefgh c=abcdefgh ok stride = +2: u=aceg c=abcdBUG! # Backward: b=hgfedcba t=hgfedcba c=hgfedcba ok stride = -1: c=hBUG! --- program gfcbug implicit none integer, parameter :: n = 8 integer:: i character(len=1), dimension(n) :: a, b character(len=n) :: s, t character(len=n/2) :: u do i = 1, n a(i) = achar (i-1 + iachar(a)) end do print *, # Forward: print *, a=, a s = transfer (a, s) print *, s=, s call cmp (a, s) print *, stride = +2: do i = 1, n/2 u(i:i) = a(2*i-1) end do print *, u=, u call cmp (a(1:n:2), u) print * print *, # Backward: b = a(n:1:-1) print *, b=, b t = transfer (b, t) print *, t=, t call cmp (b, t) print *, stride = -1: call cmp (a(n:1:-1), t) contains subroutine cmp (b, s) character(len=1), dimension(:), intent(in) :: b character(len=*), intent(in) :: s character(len=size(b)) :: c c = transfer (b, c) print *, c=, c, , merge ( ok,BUG!, c == s) end subroutine cmp end program gfcbug
[Bug ada/56616] New: gnatmake builds SAL incorrectly if library_kind is static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56616 Bug #: 56616 Summary: gnatmake builds SAL incorrectly if library_kind is static Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org Created attachment 29665 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29665 Reproducer Gnatmake will accept a GPR which calls for a stand-alone static library. The library that is created will not work if the library implementation requires linking or elaboration that is not already implied by the user program or the library interface units: for example, if the library implementation uses tasking but the user program does not, either libgnarl won't be included in the link or tasking won't be initialized (so only the first entry in the environment task's TCB's Entry_Calls is initialized). I beg you not to respond by disabling static SALs: the ability to populate the Library_Src_Dir with the library's interface source is valuable. Using the attached demonstrator (static-sal-bug.tar.gz) results in $ gnatmake -p -P build_library.gpr object directory /Users/simon/tmp/static-sal-bug/.build-lib created for project build_library library directory /Users/simon/tmp/static-sal-bug/lib created for project build_library library source copy directory /Users/simon/tmp/static-sal-bug/include created for project build_library gcc -c -g -I- -gnatA /Users/simon/tmp/static-sal-bug/src/library.adb gcc -c -g -I- -gnatA /Users/simon/tmp/static-sal-bug/src/library_impl.adb gnatbind -n -o b~ibrary.adb -Library -a ... gcc -c -gnatws b~ibrary.adb -fPIC -g ... building static library for project build_library ar cr /Users/simon/tmp/static-sal-bug/lib/libibrary.a /Users/simon/tmp/static-sal-bug/.build-lib/b~ibrary.o ... ranlib /Users/simon/tmp/static-sal-bug/lib/libibrary.a $ gnatmake -p -P locking.gpr object directory /Users/simon/tmp/static-sal-bug/.build created for project locking gcc -c -g -I- -gnatA /Users/simon/tmp/static-sal-bug/locking.adb gnatbind -E -x /Users/simon/tmp/static-sal-bug/.build/locking.ali gnatlink /Users/simon/tmp/static-sal-bug/.build/locking.ali -g /Users/simon/tmp/static-sal-bug/lib/libibrary.a -Wl,-rpath,/opt/gcc-4.8-196573/lib/gcc/x86_64-apple-darwin12/4.8.0/adalib/ -o /Users/simon/tmp/static-sal-bug/locking Undefined symbols for architecture x86_64: _system__tasking__protected_objects__entries__finalize__2, referenced from: _library_impl__poTVDF in libibrary.a(library_impl.o) _library_impl__poTVIP__F12b.3417 in libibrary.a(library_impl.o) _system__tasking__protected_objects__entries__initialize_protection_entries, referenced from: _library_impl__poTVIP in libibrary.a(library_impl.o) _system__tasking__protected_objects__entries__lock_entries, referenced from: _library_impl__po__releaseP in libibrary.a(library_impl.o) _system__tasking__protected_objects__entries__protection_entriesIP, referenced from: _library_impl__poTVIP in libibrary.a(library_impl.o) _system__tasking__protected_objects__operations__communication_blockIP, referenced from: _library_impl__seize in libibrary.a(library_impl.o) _system__tasking__protected_objects__operations__complete_entry_body, referenced from: _library_impl__po__seize_E3b in libibrary.a(library_impl.o) _system__tasking__protected_objects__operations__exceptional_complete_entry_body, referenced from: _library_impl__po__seize_E3b in libibrary.a(library_impl.o) _system__tasking__protected_objects__operations__protected_entry_call, referenced from: _library_impl__seize in libibrary.a(library_impl.o) _system__tasking__protected_objects__operations__service_entries, referenced from: _library_impl__po__releaseP___finalizer.3471 in libibrary.a(library_impl.o) ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status gnatlink: error when calling /opt/gcc-4.8-196573/bin/gcc gnatmake: *** link failed.
[Bug c++/56617] New: c++ compiler error when trying to build SuperCollider with nova-simd extension on arm ubuntu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56617 Bug #: 56617 Summary: c++ compiler error when trying to build SuperCollider with nova-simd extension on arm ubuntu Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: videoo...@yahoo.com Created attachment 29666 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29666 files relevant to the bug report When I try to build SuperCollider with nova-simd extension on my UG802 Arm Cortex A9 box running Ubuntu, the g++ compiler quits with an internal compiler error. When I disable nova-simd support in cmake SuperCollider builds successfully. I've attached a zip containing the preprocessed file where the error occurs, the output of gcc -v and the command line call with the compiler error.
[Bug ada/56616] gnatmake builds SAL incorrectly if library_kind is static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56616 --- Comment #1 from simon at pushface dot org 2013-03-14 12:30:33 UTC --- Created attachment 29667 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29667 Proposed patch
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 13:08:42 UTC --- Author: jason Date: Thu Mar 14 13:08:36 2013 New Revision: 196657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196657 Log: PR c++/56346 * decl.c (register_dtor_fn): Pass null to __cxa_thread_atexit dso_handle parm on targets without __cxa_atexit. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 13:09:20 UTC --- Author: jason Date: Thu Mar 14 13:09:11 2013 New Revision: 196658 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196658 Log: PR c++/56614 * decl.c (local_variable_p_walkfn): Check DECL_ARTIFICIAL again. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-defarg1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug tree-optimization/56618] New: inline assembler with too many lines causes ICE in account_size_time, at ipa-inline-analysis.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56618
Bug #: 56618
Summary: inline assembler with too many lines causes ICE in
account_size_time, at ipa-inline-analysis.c
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
A 6.4 mio lines inline assembler statement (happened in some auto generated
real code) causes an overflow in the inliner cost estimation per cpu, resulting
in a ICE.
Reproducer
#!/usr/bin/python
print int foo(void) {
print asm(
for i in range(640):
print r'\n'
print );
print }
./longasm.py l.c
gcc l.c
Observed back to 4.7 at least, but much older compilers should be ok. So it's a
regression
Patch has been posted at
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg50027.html
There was some discussion, but no approval
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #11 from Adam Seering aseering at vertica dot com 2013-03-14 13:15:02 UTC --- I'm not familiar with gcc's backport process; is there anything I can do to help that along? Is it already in-queue?
[Bug target/56619] New: i386 hle atomic intrinsics flags are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619 Bug #: 56619 Summary: i386 hle atomic intrinsics flags are undocumented Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: andi-...@firstfloor.org Patch has been posted here http://patchwork.ozlabs.org/patch/198096/ but so far not reviewed/approved
[Bug target/56619] i386 hle atomic intrinsics flags are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619 --- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2013-03-14 13:18:32 UTC --- This is a more complete version of the documentation (also including RTM intrinsics), again not approved: http://patchwork.ozlabs.org/patch/211504/
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||patch CC||manu at gcc dot gnu.org --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-14 15:43:28 UTC --- (In reply to comment #11) I'm not familiar with gcc's backport process; is there anything I can do to help that along? Is it already in-queue? I guess Jakub is extremely busy with the imminent release of GCC 4.8.0. To backport, someone would need to apply the patch here: http://gcc.gnu.org/r196260 to the GCC 4.7 branch here: http://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch/ then bootstrap + regression test and check if there are any new failures. Then submit the patch with an appropriate changelog to gcc-patches. Since the patch is already written, I don't think you need a copyright assignment to do any of this.
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 16:11:56 UTC --- Author: jason Date: Thu Mar 14 16:11:37 2013 New Revision: 196660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196660 Log: PR c++/56403 * init.c (build_zero_init_1): Use RECORD_OR_UNION_CODE_P instead of CLASS_TYPE_P. * g++.dg/torture/pr56403.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr56403.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/init.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 16:12:58 UTC --- Author: jason Date: Thu Mar 14 16:12:37 2013 New Revision: 196661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196661 Log: PR c++/56403 * init.c (build_zero_init_1): Use RECORD_OR_UNION_CODE_P instead of CLASS_TYPE_P. * g++.dg/torture/pr56403.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/torture/pr56403.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/init.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/56618] inline assembler with too many lines causes ICE in account_size_time, at ipa-inline-analysis.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56618 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-14 16:24:23 UTC --- In a mean time, it was already filed by someone else. *** This bug has been marked as a duplicate of bug 56580 ***
[Bug tree-optimization/56580] Internal compiler error when trying to compile a sequence of NOPs inside a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56580 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-14 16:24:23 UTC --- *** Bug 56618 has been marked as a duplicate of this bug. ***
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 16:28:10 UTC --- Fixed in 4.6 and 4.7 as well.
[Bug c++/56403] [4.6/4.7 Regression] internal compiler error: in build_zero_init_1, at cp/init.c:279
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56403 --- Comment #16 from Adam Seering aseering at vertica dot com 2013-03-14 16:41:57 UTC --- Thanks!
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 17:35:03 UTC --- Author: jason Date: Thu Mar 14 17:34:55 2013 New Revision: 196662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196662 Log: PR c++/56614 * decl.c (local_variable_p_walkfn): Check DECL_ARTIFICIAL again. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-defarg1.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/decl.c
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 17:35:53 UTC --- Fixed.
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-14 17:45:58 UTC --- Thanks, Jason
[Bug fortran/56615] [4.6/4.7/4.8 Regression] Wrong code with TRANSFER of arrays of character with stride -1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56615 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.1.2, 4.3.4 Keywords||wrong-code Last reconfirmed||2013-03-14 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|[4.4/4.5/4.6/4.7|[4.6/4.7/4.8 Regression] |Regression] Wrong code for |Wrong code with TRANSFER of |passing arrays of character |arrays of character with ||stride -1 Target Milestone|--- |4.6.4 Known to fail||4.4.0, 4.5.3, 4.6.3, 4.7.2, ||4.8.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-14 18:01:06 UTC --- The problem seems to be the TRANSFER in: call cmp (a(n:1:-1), t) ... subroutine cmp (b, s) character(len=1), dimension(:), intent(in) :: b c = TRANSFER (b, c) In the dump, I see code like: __builtin_memcpy (transfer.5, parm.4.data, MAX_EXPR MIN_EXPRD.1912,D.1904,0); However, that assumes that parm.4.data is contiguous and walked forwardly. In 4.4, one has the same - but additionally the calls: D.929 = _gfortran_internal_pack (parm.4); ... _gfortran_internal_unpack (parm.4, D.929);
[Bug c/56620] New: Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620
Bug #: 56620
Summary: Memcpy optimization may lead to unaligned access on
ARM Thumb
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eleven...@gmail.com
Created attachment 29668
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29668
Sample source file
Whereas #53016 resolved to an alignment problem with the underlying structures,
this is a case where the builtin memcpy optimization emits instructions that
may access words on a non-word boundary.
The target is an ARM Cortex-M4. The compiler was generated by the summon-gcc
project in order to gain access to the hard-float feature of GCC 4.7.2. The
problem didn't appear until I implemented faults on unaligned access per the
ARM recommendations.
The example was compiled with both -O2 and -Os. In both instances the compiler
emitted unaligned ldr instructions. Below is pasted the disassembled code at
fault.
// Here we load the base address of the data array of bytes.
a: 4e0cldr r6, [pc, #48] ; (3c copy_unaligned+0x3c)
c: f44f 74ff mov.w r4, #510; 0x1fe
10: 19a3addsr3, r4, r6
// r3 has 510 - 16*i, an word unaligned offset assuming the data array aligned.
12: 466dmov r5, sp
14: f103 0710 add.w r7, r3, #16
// This next instruction faults.
18: 6818ldr r0, [r3, #0]
1a: 6859ldr r1, [r3, #4]
1c: 462amov r2, r5
1e: c203stmia r2!, {r0, r1}
20: 3308addsr3, #8
22: 42bbcmp r3, r7
24: 4615mov r5, r2
26: d1f7bne.n 18 copy_unaligned+0x18
3c: .word 0x
I recall that a few versions back, GCC started putting stack allocated arrays
of bytes on odd or non-word address boundaries. If this is the case, I don't
see how memcpy could every legally emit the code above, even if it knew that
the array offset was word aligned.
While producing the sample, I noticed that it was necessary to have both the
unaligned offset like 510 and the indexed offset i*16 to trigger the errant
code.
Cheers
[Bug c/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #1 from eleventen at gmail dot com 2013-03-14 18:13:03 UTC --- Created attachment 29669 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29669 Sample source object
[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|ARM Thumb Cortex-M4 | Host|x86 | --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-14 18:20:03 UTC --- Can you mention the exact configure option which was used to build GCC (gcc -v should give that)? Can you also say what option you passed to GCC?
[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #3 from Marc Singer eleventen at gmail dot com 2013-03-14 18:26:02 UTC --- The compiler was built as follows: elf@cerise ~/memcpy-bug /opt/gcc/arm-none-eabi/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/gcc/arm-none-eabi/bin/gcc Target: arm-none-eabi Configured with: ../gcc-4.7.2/configure --target=arm-none-eabi --prefix=/opt/gcc --enable-multilib --enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib --disable-newlib-supplied-syscalls Thread model: single gcc version 4.7.2 (GCC) The invoking command line, available at the top of the sample source file, is reproduced here for clarity. arm-none-eabi-gcc -std=c99 -g -Os -c -mcpu=cortex-m3 -mthumb memcpy-test.c -o memcpy-test.o
[Bug inline-asm/56621] New: Misaligned stack with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621
Bug #: 56621
Summary: Misaligned stack with inline assembly
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: au...@yahoo.com
The following minimal program (compiled merely by gcc test.c -o test) is
intended to write test to standard output using the write system call, and
then exit:
int main() {
int tmp;
char message[8] = test\n;
int message_size = 5;
// Comment out this loop and it suddenly works correctly.
for (tmp = 0; tmp 1; ++tmp) { }
__asm__ __volatile__
(
movq $1, %%rax; // System call 1 (write)
movq $1, %%rdi; // File descriptor 1 (stdout)
movq %0, %%rsi; // %0 is message
movq %1, %%rdx; // %1 is message_size
syscall
:
: q(message), g(message_size)
: %rax, %rdi, %rsi, %rdx, %rcx, %r11
);
return(0);
}
This version produces no output, and exits immediately. If the marked for
loop is commented out, the program *does* produce the expected output.
(Obviously, the original version where I discovered this problem had a loop
that did actual work).
Examining the binary via objdump (or the intermediate test.s file when
preserving temporary files), I find that it uses an instruction of movq
-8(%rbp), %rdx in the non-working version, as compared to movq -4(%rbp,
%rdx) in the working version. Similarly, the initial assignment is done by an
offset of -8 or -4 in the stack, respectively. If I directly edit the binary
file to change the instruction to the correct offset, the non-working version
then starts working as expected.
This problem is present in the default Debian wheezy gcc version 4.7.2
(output of gcc -v below); it is also present in the latest development version
as of the time of this bug report, which I downloaded and compiled in order to
test the problem. The bug is *not* present in the Debian squeeze version
4.4.5 of gcc, so I can only conclude that this became an issue somewhere in an
intervening version.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
[Bug target/56351] ARM Big-Endian: storing local double to packed variable causes corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-14 18:52:26 UTC --- Author: ebotcazou Date: Thu Mar 14 18:52:18 2013 New Revision: 196664 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196664 Log: PR target/56351 Backport from mainline 2012-10-22 Julian Brown jul...@codesourcery.com * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Avoid subreg'ing VFP D registers in big-endian mode. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/arm/arm.h
[Bug plugins/56622] New: -fopenmp with -fplugin conflicts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56622 Bug #: 56622 Summary: -fopenmp with -fplugin conflicts Classification: Unclassified Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: hayder.alkhali...@googlemail.com Dear all, I am trying to extending the compiler gcc-4.5.0 by using plug-in. When I tried using -fpluging with -fopenmp, I got this error as bellow: *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event| Plugins PLUGIN_PRE_GENERICIZE| libplugin-pointer-types PLUGIN_FINISH| libplugin-pointer-types PLUGIN_ATTRIBUTES| libplugin-pointer-types pointer-types-target.c: In function ‘main’: pointer-types-target.c:46:2: internal compiler error: in join_on_bb_function_call, at aop-pc-fun-call.c:246 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. BTY: I didn't have more experience in extending gcc. I have already attached the *.i file as well.
[Bug plugins/56622] -fopenmp with -fplugin conflicts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56622 --- Comment #1 from hayder.alkhalissi at googlemail dot com 2013-03-14 18:55:13 UTC --- Created attachment 29670 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29670 preprocessed file
[Bug target/56351] ARM Big-Endian: storing local double to packed variable causes corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56351 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-14 18:57:44 UTC --- Thanks for reporting the problem.
[Bug inline-asm/56621] Misaligned stack with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-14 18:58:12 UTC --- No, that is just bogus inline asm, for multiple reasons. message_size is 32-bit, so using movq on it means you can end up with arbitrary garbage in the high 32-bits. E.g. I see: write(1, test\n\0\0\0\5\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0005\27\202\351?\0\0\0..., 4294967301) = -1 EFAULT (Bad address) where 4294967301 is 0x10005. You'd want movl instead, which will zero the upper 32 bits. Also, nothing tells the compiler that the clobbered registers are clobbered before consuming the inputs, the compiler could assign one of the two inputs to the clobbered registers. Better just use long dummy; int dummy2; ... =S (dummy), =d (dummy2) ... : 0 (message), 1 (message_size) ... then you don't need to do any of the bogus moves first, the compiler will arrange all of that. Or why aren't you just using syscall function, or write?
[Bug inline-asm/56621] Misaligned stack with inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621 --- Comment #2 from auc42 at yahoo dot com 2013-03-14 20:00:56 UTC --- Ah, I had forgotten to change tmp back to a long in the code snippet provided. I was experimenting to see variations of the generated assembly while using different types. The failure is present with both the 8-byte long and 4-byte int, in this case. I accept your explanation about the clobbered registers, though. I apparently misunderstood how clobber declarations worked (and in re-reading the manual, either I'm still missing something or the text isn't very clear). Placing the variables directly in the S and d registers and skipping the movX instructions eliminates the problem. I suppose that the sequence only worked by happenstance in earlier versions of gcc. (As for the reason of doing it this way: the original code was avoiding use of the C standard library and/or any include files, as a personal learning exercise toward a later program.)
[Bug c++/56606] GCC refuses to emit long calls for operator new/delete on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56606 --- Comment #1 from Michael Mrozek gcc at mrozekma dot com 2013-03-14 20:20:22 UTC --- I found that including any of the standard C++ headers (string, list, map, etc.) works around this, as does forward-declaring the operator: void* operator new(std::size_t);
[Bug plugins/56622] -fopenmp with -fplugin conflicts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56622 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-14 20:30:13 UTC --- join_on_bb_function_call, at aop-pc-fun-call.c:246 This is a bug in your plugin code and not in GCC. Please report it to the place where you got the plugin.
[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-14 20:33:27 UTC --- I think you are required to use -mno-unaligned-access for armv7 targets where you doing bare metal work without the page table setup.
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 20:38:02 UTC --- Fixed.
[Bug fortran/56615] [4.6/4.7/4.8 Regression] Wrong code with TRANSFER of arrays of character with stride -1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56615
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-14
21:04:44 UTC ---
trans-intrinsic.c gfc_conv_intrinsic_transfer's has:
/* Repack the source if not a full variable array. */
if (arg-expr-expr_type == EXPR_VARIABLE
arg-expr-ref-u.ar.type != AR_FULL)
{
However, I do not see any relation between being a full array and the need to
repack. A more useful check would be whether the expression is simply
contiguous or not.
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -5436,7 +5436,6 @@ gfc_conv_intrinsic_transfer (gfc_se * se, gfc_expr *
expr)
source_type = gfc_get_element_type (TREE_TYPE (argse.expr));
- /* Repack the source if not a full variable array. */
- if (arg-expr-expr_type == EXPR_VARIABLE
- arg-expr-ref-u.ar.type != AR_FULL)
+ /* Repack the source if not simply contiguous. */
+ if (!gfc_is_simply_contiguous (arg-expr, false))
{
tmp = gfc_build_addr_expr (NULL_TREE, argse.expr);
[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 Marc Singer eleventen at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Marc Singer eleventen at gmail dot com 2013-03-14 21:05:42 UTC --- Indeed the compiler documentation states that the ARMv6M and older default to no unaligned accesses, but that changed in v7. Thanks.
[Bug c++/45917] inaccessible types allowed as template argument in nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug target/56620] Memcpy optimization may lead to unaligned access on ARM Thumb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56620 --- Comment #6 from Marc Singer eleventen at gmail dot com 2013-03-14 21:35:54 UTC --- For the sake of posterity, the Cortex-M3 and M4 do handle unaligned accesses properly in hardware though with the expected performance penalty. It is the fact that I enforced alignment by making configuration changes to the MCU that caused the issue. And I did so on the recommendation of ARM which isn't universally justified in the Cortex TRM: To ensure a smooth transition, ARM recommends that code designed to operate on other Cortex-M profile processor architectures obey the following rules and configure the Configuration and Control Register (CCR) appropriately: • • • use word transfers only to access registers in the NVIC and System Control Space (SCS). treat all unused SCS registers and register fields on the processor as Do-Not-Modify. configure the following fields in the CCR: — STKALIGN bit to 1 — UNALIGN_TRP bit to 1 — Leave all other bits in the CCR register as their original value.
[Bug c++/45917] inaccessible types allowed as template argument in nested-name-specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-14 21:40:38 UTC --- Created attachment 29671 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29671 patch Simple fix, waiting for 4.8 to branch.
[Bug libstdc++/56613] [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-14 23:28:18 UTC --- Author: redi Date: Thu Mar 14 23:28:11 2013 New Revision: 19 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19 Log: PR libstdc++/56613 * include/bits/stl_tree.h (_Rb_tree::_M_create_node): Use allocator_traits instead of calling construct directly. * testsuite/23_containers/map/56613.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/map/56613.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h
[Bug libstdc++/56613] [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-14 23:30:53 UTC --- fixed
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 --- Comment #15 from John David Anglin danglin at gcc dot gnu.org 2013-03-14 23:46:18 UTC --- Adding -fvar-tracking -fvar-tracking-assignments results in the following warning on hppa2.0w-hp-hpux11.11: spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c -fno-diagnostics-show-caret -O2 -g -fdump-tree-esra -fvar-tracking -fvar-tracking-assignments -S -o pr55579.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c:1:0: warning: variable tracking requested, but not supported by this debug format [enabled by default]
[Bug bootstrap/56623] New: Can't build GCC due to tar: ./ssl: Cannot utime: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56623
Bug #: 56623
Summary: Can't build GCC due to tar: ./ssl: Cannot utime: No
such file or directory
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: 4tmue...@informatik.uni-hamburg.de
make[3]: Entering directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/gcc'
rm -rf include-fixed; mkdir include-fixed
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc \
make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
set -e; for ml in `cat fixinc_list`; do \
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed${multi_dir}; \
if ! false test ! -d `echo /usr/include | sed -e :a -e
's,[^/]*/\.\.\/,,' -e ta`; then \
echo The directory that should contain system headers does not exist: 2
; \
echo `echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` 2
; \
tooldir_sysinc=`echo
/tmp/WebKit/WebKitBuild/Dependencies/Root/lib64/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../x86_64-unknown-linux-gnu/sys-include
| sed -e :a -e s,[^/]*/\.\.\/,, -e ta`; \
if test x`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` =
x${tooldir_sysinc}; \
then sleep 1; else exit 1; fi; \
fi; \
/bin/sh ../.././gcc/../mkinstalldirs ${fix_dir}; \
chmod a+rx ${fix_dir} || true; \
(TARGET_MACHINE='x86_64-unknown-linux-gnu'; srcdir=`cd ../.././gcc;
${PWDCMD-pwd}`; \
SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
gcc_dir=`${PWDCMD-pwd}` ; \
export TARGET_MACHINE srcdir SHELL MACRO_LIST \
cd ../../build-x86_64-unknown-linux-gnu/fixincludes \
/bin/sh ./fixinc.sh ${gcc_dir}/${fix_dir} \
`echo /usr/include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` ); \
rm -f ${fix_dir}/syslimits.h; \
if [ -f ${fix_dir}/limits.h ]; then \
mv ${fix_dir}/limits.h ${fix_dir}/syslimits.h; \
else \
cp ../.././gcc/gsyslimits.h ${fix_dir}/syslimits.h; \
fi; \
chmod a+r ${fix_dir}/syslimits.h; \
done; \
fi
make[4]: Entering directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc'
(cd `${PWDCMD-pwd}`/include-fixed ; \
tar -cf - .; exit 0) | (cd
/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc/../gcc/./include-fixed;
tar xpf - )
tar: ./ssl: Cannot utime: No such file or directory
tar: Exiting with failure status due to previous errors
make[4]: *** [real-install-headers-tar] Error 2
make[4]: Leaving directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc'
make[3]: *** [stmp-fixinc] Error 2
make[3]: Leaving directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory
`/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2'
make: *** [all] Error 2
*** Error during phase build of gcc: ## Error running make -j 32 ***
[1/1
$ head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.64. Invocation command line was
$ ./configure --prefix /tmp/WebKit/WebKitBuild/Dependencies/Root --libdir
/tmp/WebKit/WebKitBuild/Dependencies/Root/lib64 --disable-static
--disable-gtk-doc
4tmuelle@ccblade9:/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc$
ls -l include-fixed/
total 44
-rw-r--r-- 1 4tmuelle j2004 5447 15. Mär 00:41 limits.h
drwxr-xr-x 1 4tmuelle j2004 4096 15. Mär 01:42 linux
drwxr-xr-x 1 4tmuelle j2004 4096 15. Mär 01:42 net-snmp
drwxr-xr-x 1 4tmuelle j2004 4096 15. Mär 01:42 openssl
-rw-r--r-- 1 4tmuelle j2004 750 15. Mär 01:43 README
lrwxrwxrwx 1 4tmuelle j20047 15. Mär 01:42 ssl - openssl
-rw-r--r-- 1 4tmuelle j2004 330 15. Mär 01:43 syslimits.h
drwxr-xr-x 1 4tmuelle j2004 4096 15. Mär 01:42 X11
-rw-r--r-- 1 4tmuelle j2004 7384 15. Mär 01:42 zutil.h
4tmuelle@ccblade9:/tmp/WebKit/WebKitBuild/Dependencies/Source/gcc-4.7.2/host-x86_64-unknown-linux-gnu/prev-gcc$
tar --version
tar (GNU tar) 1.26
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by John Gilmore and Jay Fenlason.
[Bug target/56619] i386 hle atomic intrinsics flags are undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619 --- Comment #2 from ak at gcc dot gnu.org 2013-03-15 04:31:53 UTC --- Author: ak Date: Fri Mar 15 04:31:43 2013 New Revision: 196671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196671 Log: Document HLE / RTM intrinsics The TSX HLE/RTM intrinsics were missing documentation. Add this to the manual. gcc/: 2013-03-14 Andi Kleen a...@linux.intel.com PR target/56619 * doc/extend.texi: Document __ATOMIC_HLE_ACQUIRE, __ATOMIC_HLE_RELEASE. Document __builtin_ia32 TSX intrincs. Document _x* TSX intrinsics. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
