[Bug c/53712] New: SEGV in generated code for _mm_cmpistri with unaligned operand when using -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53712 Bug #: 53712 Summary: SEGV in generated code for _mm_cmpistri with unaligned operand when using -O0 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jbem...@zonnet.nl Created attachment 27647 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27647 Test program triggering the bug - compile with "-O0 -msse4.2" Compile the attached program with "-msse4.2 -O0" The failing generated code looks like this (-S): test: .LFB575: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 movq%rdi, -40(%rbp) movq%rsi, -48(%rbp) movq-48(%rbp), %rax movq%rax, -24(%rbp) movq-24(%rbp), %rax movdqu (%rax), %xmm0 movdqa %xmm0, -16(%rbp) movq-40(%rbp), %rax SEGV => movdqa (%rax), %xmm1 movdqa -16(%rbp), %xmm0 pcmpistri $0, %xmm1, %xmm0 movl%ecx, %eax ? => pcmpistrm $0, %xmm1, %xmm0 popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc This code causes a SEGV at the indicated instruction, because %rax has a value of 0x4006d8 which is not aligned by 16 Compiling with -O1 (or higher) fixes the problem: test: .LFB643: .cfi_startproc movdqu (%rsi), %xmm0 pcmpistri $0, (%rdi), %xmm0 movl%ecx, %eax ret .cfi_endproc The root cause is that "pcmpistri" allows an unaligned memory operand, while gcc generates aligned loads for the operands when using -O0. A second issue is that gcc generates a redundant "pcmpistrm" instruction at -O0, unclear where this is coming from? $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.3/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC)
[Bug c++/53672] gcc/branches/cilkplus does not like C++ spawn (when optimized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53672 --- Comment #8 from bviyer at gcc dot gnu.org 2012-06-18 02:08:03 UTC --- Author: bviyer Date: Mon Jun 18 02:07:54 2012 New Revision: 188722 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188722 Log: This patch should fix the 2nd case of PR 53672. 2012-06-17 Balaji V. Iyer PR 53672 * dwarf2out.c (dwarf2out_abstract_function): Added a check for the spawn helper. (dwarf2out_function_decl): Added a check if CILK_FN_P is set when there is no function struct. * cilk.c (expand_builtin_cilk_metadata): Set the CILK_FN_P field to 1. * cilk-spawn.c (cg-hacks): Likewise. (gimplify_cilk_for_2): Likewise. (gimplify_cilk_for): Likewise. * tree.h (CILK_FN_P): Added new #define to access a base field of tree. Modified: branches/cilkplus/gcc/ChangeLog.cilk branches/cilkplus/gcc/cilk-spawn.c branches/cilkplus/gcc/cilk.c branches/cilkplus/gcc/cp/ChangeLog.cilk branches/cilkplus/gcc/cp/cilk.c branches/cilkplus/gcc/dwarf2out.c branches/cilkplus/gcc/tree.h
[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51867 --- Comment #5 from amker.cheng 2012-06-18 02:03:21 UTC --- Should be fixed.
[Bug libstdc++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #9 from Jonathan Wakely 2012-06-18 00:06:29 UTC --- I'm ambivalent.
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.8.0
[Bug c/53702] [4.8 Regression] ICE with -Wall and nested functions and unused typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2012-06-17 Ever Confirmed|0 |1 Summary|Segmentation fault with |[4.8 Regression] ICE with |-Wall |-Wall and nested functions ||and unused typedef Target Milestone|--- |4.8.0
[Bug bootstrap/53709] [4.7 Regregression] libada build failure when bootstrapping on Fedora 17 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53709 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.0, 4.7.2, 4.8.0 Keywords||build Resolution||FIXED Summary|libada build failure when |[4.7 Regregression] libada |bootstrapping on Fedora 17 |build failure when |x86_64 |bootstrapping on Fedora 17 ||x86_64 Target Milestone|--- |4.7.2 Known to fail||4.7.1 Severity|major |normal --- Comment #1 from Andrew Pinski 2012-06-17 22:25:55 UTC --- Fixed by: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00950.html It is broken only in 4.7.1 and arleady fixed in the 4.7 branch.
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 Ever Confirmed|0 |1 --- Comment #4 from janus at gcc dot gnu.org 2012-06-17 22:03:05 UTC --- Slightly compactified test case: module type_mod implicit none type field real :: var(1:3) contains procedure :: scalar_equals_field generic :: assignment (=) => scalar_equals_field procedure, nopass :: field_sqrt generic :: sqrt => field_sqrt end type contains elemental pure subroutine scalar_equals_field (A, b) class(field), intent(out) :: A real, intent(in) :: b A%var(:) = b end subroutine elemental pure function field_sqrt (A) result (B) class(field), intent(in) :: A type(field) :: B B%var(:) = sqrt (A%var(:)) end function end module program test use type_mod, only : field implicit none type(field) :: a a = 4.0 print *, sqrt(a) end program
[Bug rtl-optimization/53706] [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 --- Comment #5 from H.J. Lu 2012-06-17 22:00:43 UTC --- Created attachment 27646 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27646 A testcase for x86-64 valgrind ./cc1plus -fpreprocessed x.ii -quiet -dumpbase x.ii -march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -auxbase x -g -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fno-exceptions -fno-rtti -fno-common -o x.s ==15175== Memcheck, a memory error detector ==15175== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==15175== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==15175== Command: ./cc1plus -fpreprocessed x.ii -quiet -dumpbase x.ii -march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -auxbase x -g -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fno-exceptions -fno-rtti -fno-common -o x.s ==15175== GNU C++ (GCC) version 4.8.0 20120616 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20120604 (Red Hat 4.7.0-7), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.8.0 20120616 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20120604 (Red Hat 4.7.0-7), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 79196506890681890a6020f62ba12f85 ==15175== Invalid write of size 8 ==15175==at 0x1176677: variable_htab_free (var-tracking.c:1418) ==15175==by 0x15F75FC: htab_delete (hashtab.c:430) ==15175==by 0x118F11D: vt_emit_notes (var-tracking.c:9132) ==15175==by 0x119161D: variable_tracking_main_1 (var-tracking.c:9875) ==15175==by 0x1191653: variable_tracking_main (var-tracking.c:9889) ==15175==by 0xD51511: execute_one_pass (passes.c:2164) ==15175==by 0xD516F7: execute_pass_list (passes.c:2219) ==15175==by 0xD51718: execute_pass_list (passes.c:2220) ==15175==by 0xD51718: execute_pass_list (passes.c:2220) ==15175==by 0x9C0F9F: expand_function (cgraphunit.c:1615) ==15175==by 0x9C1686: expand_all_functions (cgraphunit.c:1720) ==15175==by 0x9C2205: compile (cgraphunit.c:2018) ==15175== Address 0xfcb2bf8 is 40 bytes inside a block of size 2,568 free'd ==15175==at 0x4C289AE: free (vg_replace_malloc.c:427) ==15175==by 0x9007EA: empty_alloc_pool (alloc-pool.c:210) ==15175==by 0x900867: free_alloc_pool (alloc-pool.c:230) ==15175==by 0x118F103: vt_emit_notes (var-tracking.c:9130) ==15175==by 0x119161D: variable_tracking_main_1 (var-tracking.c:9875) ==15175==by 0x1191653: variable_tracking_main (var-tracking.c:9889) ==15175==by 0xD51511: execute_one_pass (passes.c:2164) ==15175==by 0xD516F7: execute_pass_list (passes.c:2219) ==15175==by 0xD51718: execute_pass_list (passes.c:2220) ==15175==by 0xD51718: execute_pass_list (passes.c:2220) ==15175==by 0x9C0F9F: expand_function (cgraphunit.c:1615) ==15175==by 0x9C1686: expand_all_functions (cgraphunit.c:1720) ==15175==
[Bug rtl-optimization/53706] [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from H.J. Lu 2012-06-17 21:58:44 UTC --- *** Bug 53710 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53710] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from H.J. Lu 2012-06-17 21:58:44 UTC --- Dup *** This bug has been marked as a duplicate of bug 53706 ***
[Bug tree-optimization/53703] [4.8 Regression] verify_ssa: definition in block 105 does not dominate use in block 103
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53703 William J. Schmidt changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from William J. Schmidt 2012-06-17 21:47:38 UTC --- Mine. Investigating...
[Bug fortran/47710] [OOP] Improve ambiguity check for GENERIC TBP w/ PASS and NOPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47710 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-17 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from janus at gcc dot gnu.org 2012-06-17 21:28:32 UTC --- (In reply to comment #4) > Note: Comment 3 is fixed by the patch at > http://gcc.gnu.org/ml/fortran/2012-06/msg00111.html, but comment 0 is not. Updated patch fixes both: http://gcc.gnu.org/ml/fortran/2012-06/msg00118.html
[Bug bootstrap/53710] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 H.J. Lu changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from H.J. Lu 2012-06-17 21:18:59 UTC --- Adding -g0 or -mno-fma compiles tree-vect-loop.o fine.
[Bug bootstrap/53710] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 --- Comment #3 from H.J. Lu 2012-06-17 20:01:29 UTC --- (In reply to comment #2) > Are you sure about the revision? > > Probably dup of PR53706. They could be related since bootstrap passes when I turn off FMA on i386: diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c index 94f3819..a1fa2b7 100644 --- a/gcc/config/i386/driver-i386.c +++ b/gcc/config/i386/driver-i386.c @@ -445,7 +445,9 @@ const char *host_detect_local_cpu (int argc, const char **argv) has_popcnt = ecx & bit_POPCNT; has_aes = ecx & bit_AES; has_pclmul = ecx & bit_PCLMUL; +#if 0 has_fma = ecx & bit_FMA; +#endif has_f16c = ecx & bit_F16C; has_rdrnd = ecx & bit_RDRND; and IA64 has FMA.
[Bug c++/53650] [4.7/4.8 Regression] large array causes huge memory use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650 --- Comment #5 from David Stone 2012-06-17 19:54:52 UTC --- As a workaround for this bug, I was able to compile much faster (so that I can compile my program with optimizations turned on) by declaring the constructor for the class in the array as constexpr (which worked just fine for me because I only cared that a single member variable was 0, and the rest could have indeterminate values).
[Bug c++/53711] New: Wunused-function should warn for functions in the unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53711
Bug #: 53711
Summary: Wunused-function should warn for functions in the
unnamed namespace
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
Wunused-function currently only warns for functions that are declared as static
that are never used / defined. It should also warn about functions placed in
the unnamed namespace, such as:
namespace {
void f();
}
Such functions have similar mechanics to static functions. In particular, they
can only be referenced in the translation unit, so the compiler knows for
certain that if the function is not used in this translation unit, it is not
used.
[Bug bootstrap/53710] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 --- Comment #2 from Uros Bizjak 2012-06-17 19:35:48 UTC --- (In reply to comment #0) > *** glibc detected *** > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus: > corrupted double-linked list: 0x02408e20 *** > === Backtrace: = > /lib64/libc.so.6[0x339167befd] > /lib64/libc.so.6[0x339167c6a8] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(htab_delete+0x65)[0xf35fe5] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus[0xc4867b] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z22variable_tracking_mainv+0xbd)[0xc4a0bd] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z16execute_one_passP8opt_pass+0x115)[0x9a41e5] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x15)[0x9a45a5] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x27)[0x9a45b7] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x27)[0x9a45b7] > /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus[0x79a108] Are you sure about the revision? Probably dup of PR53706.
[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53647 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug tree-optimization/53703] [4.8 Regression] verify_ssa: definition in block 105 does not dominate use in block 103
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53703 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 CC||wschmidt at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2012-06-17 19:34:10 UTC --- It is caused by revision 188457: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00367.html
[Bug fortran/53685] surprising warns about transfer with explicit character range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685 --- Comment #4 from Tobias Burnus 2012-06-17 19:30:44 UTC --- Author: burnus Date: Sun Jun 17 19:30:29 2012 New Revision: 188708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188708 Log: 2012-06-17 Tobias Burnus PR fortran/53691 PR fortran/53685 * check.c (gfc_calculate_transfer_sizes): Return if SIZE= is not constant or source-size cannot be determined. 2012-06-17 Tobias Burnus PR fortran/53691 PR fortran/53685 * gfortran.dg/transfer_check_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_check_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/53691] [4.7/4.8 Regression] ICE with -Wsurprising in LAPACK 3.4.1 cgbrfsx.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53691 --- Comment #4 from Tobias Burnus 2012-06-17 19:30:46 UTC --- Author: burnus Date: Sun Jun 17 19:30:29 2012 New Revision: 188708 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188708 Log: 2012-06-17 Tobias Burnus PR fortran/53691 PR fortran/53685 * check.c (gfc_calculate_transfer_sizes): Return if SIZE= is not constant or source-size cannot be determined. 2012-06-17 Tobias Burnus PR fortran/53691 PR fortran/53685 * gfortran.dg/transfer_check_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_check_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus 2012-06-17 19:06:58 UTC --- (In reply to comment #1) > (In reply to comment #0) > > See also: > > https://groups.google.com/forum/#!msg/comp.lang.fortran/YDt3j0--1Do > Note: That link does not seem to work. Try: http://www.rhinocerus.net/forum/lang-fortran/708232-there-way-do-following.html
[Bug target/53698] [4.8 Regression] ICE: in plus_constant, at explow.c:88 with -O -mx32 -maddress-mode=long -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53698 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu 2012-06-17 18:48:00 UTC --- (In reply to comment #2) > Created attachment 27637 [details] > Suggested fix > > Please try the attached It works. Thanks.
[Bug bootstrap/53710] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 --- Comment #1 from H.J. Lu 2012-06-17 18:35:28 UTC --- There is no problem on processors where -march=native gives -march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase
[Bug bootstrap/53710] New: [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53710 Bug #: 53710 Summary: [4.8 Regression] Bootstrap failure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com, era...@google.com On Fedora 17/x86-64, revision 188675: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00585.html failed to bootstrap when configured with --with-arch=native --with-cpu=native which leads to -march=corei7-avx -mcx16 -msahf -mmovbe -maes -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase I got /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/g++ -B/export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/ -B/usr/gcc-4.8.0-x32-native/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -L/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/export/gnu/import/git/gcc/gcc -I/export/gnu/import/git/gcc/gcc/. -I/export/gnu/import/git/gcc/gcc/../include -I/export/gnu/import/git/gcc/gcc/../libcpp/include -I/export/gnu/import/git/gcc/gcc/../libdecnumber -I/export/gnu/import/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber /export/gnu/import/git/gcc/gcc/tree-vect-loop.c -o tree-vect-loop.o *** glibc detected *** /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus: corrupted double-linked list: 0x02408e20 *** === Backtrace: = /lib64/libc.so.6[0x339167befd] /lib64/libc.so.6[0x339167c6a8] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(htab_delete+0x65)[0xf35fe5] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus[0xc4867b] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z22variable_tracking_mainv+0xbd)[0xc4a0bd] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z16execute_one_passP8opt_pass+0x115)[0x9a41e5] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x15)[0x9a45a5] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x27)[0x9a45b7] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x27)[0x9a45b7] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus[0x79a108] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z7compilev+0x854)[0x79be24] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z25finalize_compilation_unitv+0x65)[0x79c3c5] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z28cp_write_global_declarationsv+0xc5b)[0x5d891b] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus(_Z11toplev_mainiPPc+0xa34)[0xa47a44] /lib64/libc.so.6(__libc_start_main+0xf5)[0x3391621735] /export/build/gnu/gcc-x32-native/build-x86_64-linux/./prev-gcc/cc1plus[0x4ff1b1] === Memory map: 0040-01321000 r-xp 08:11 6427104 /export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-gcc/cc1plus 0152-0152b000 rw-p 00f2 08:11 6427104 /export/build/gnu/gcc-x32-native/build-x86_64-linux/prev-gcc/cc1plus 0152b000-02458000 rw-p 00:00 0 [heap] 339120-3391221000 r-xp 08:07 933270 /usr/lib64/ld-2.15.so 339142-3391421000 r--p 0002 08:07 933270 /usr/lib64/ld-2.15.so 3391421000-3391422000 rw-p 00021000 08:07 933270 /usr/lib64/ld-2.15.so 3391422000-3391423000 rw-p 00:00 0 339160-33917ac000 r-xp 08:07 926387 /usr/lib64/libc-2.15.so 33917ac000-33919ac000 ---p 001ac000 08:07 926387 /usr/lib64/libc-2.15.so 3
[Bug fortran/47710] [OOP] Improve ambiguity check for GENERIC TBP w/ PASS and NOPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47710 --- Comment #4 from janus at gcc dot gnu.org 2012-06-17 17:46:55 UTC --- Note: Comment 3 is fixed by the patch at http://gcc.gnu.org/ml/fortran/2012-06/msg00111.html, but comment 0 is not.
[Bug rtl-optimization/53705] wrong code with custom flags - stores to memory are lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705 Andrew Pinski changed: What|Removed |Added Keywords||alias Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 Ever Confirmed|0 |1
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 --- Comment #2 from janus at gcc dot gnu.org 2012-06-17 17:19:57 UTC --- (In reply to comment #0) > It is not obvious from the standard that this holds, but it is analog to > ASSIGNMENT(=) and OPERATOR(...) which also act that way. [Which is supported > in > gfortran.] It is correct that gfortran supports this for ASSIGNMENTs and OPERATORs. However, there are problems, cf. PR 41951 comment 6 to 10. The two PRs might be fixable in one go.
[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47624 --- Comment #9 from Uros Bizjak 2012-06-17 17:01:42 UTC --- (In reply to comment #8) > Fixed on trunk. I'm going to look into backporting it. This patch caused PR53706.
[Bug rtl-optimization/53706] [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 CC||aoliva at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Uros Bizjak 2012-06-17 17:00:44 UTC --- r188530 fails. 2012-06-13 Alexandre Oliva PR debug/47624 * var-tracking.c (loc_exp_dep_pool): New. (vt_emit_notes): Create and release the pool. (compute_bb_dataflow): Use value-based locations in MO_VAL_SET. (emit_notes_in_bb): Likewise. (loc_exp_dep_insert): Deal with NOT_ONEPART vars. (notify_dependents_of_changed_value): Likewise. (notify_dependents_of_resolved_value): Check that NOT_ONEPART variables don't have a VAR_LOC_DEP_LST. (emit_note_insn_var_location): Expand NOT_ONEPART locs that are VALUEs or MEMs of VALUEs.
[Bug rtl-optimization/53706] [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 Uros Bizjak changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #2 from Uros Bizjak 2012-06-17 16:49:19 UTC --- r188529 works OK.
[Bug fortran/53328] [OOP] Ambiguous check for type-bound GENERIC shall ignore PASSed arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-17 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from janus at gcc dot gnu.org 2012-06-17 16:40:10 UTC --- Taking this one. Patch: http://gcc.gnu.org/ml/fortran/2012-06/msg00111.html
[Bug c/53702] Segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702 --- Comment #3 from Meador Inge 2012-06-17 16:15:51 UTC --- I will look into this one.
[Bug rtl-optimization/53705] wrong code with custom flags - stores to memory are lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705 --- Comment #2 from Michael Matz 2012-06-17 15:36:19 UTC --- Or alternatively cselib doesn't respect one invariant in constructing the locations of its VALUEs. As seen above it constructs two values for the same memory area, one referring to stack pointer, the other to (hard) frame pointer. But alias.c explains: 2. stack_pointer_rtx, frame_pointer_rtx, hard_frame_pointer_rtx (if distinct from frame_pointer_rtx) and arg_pointer_rtx. Each of these rtxes has a separate ADDRESS associated with it, each with a negative id. GCC is (and is required to be) precise in which register it chooses to access a particular region of stack. We can therefore assume that accesses based on one of these rtxes do not alias accesses based on another of these rtxes. Note the last paragraph. The RTL instructions themself respect this invariant (there are no accesses via [sp], only via [bp] or derived values). But the cselib values don't. I'd say value 5 (the one referring to sp and value 2) is the broken one. It should only refer to value 2.
[Bug rtl-optimization/53705] wrong code with custom flags - stores to memory are lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1 from Michael Matz 2012-06-17 15:21:10
UTC ---
Problem is somewhere in cselib. We test true_dependence of these two insns
(last write to q[] and the read of the last element):
(insn 13 299 22 2 (set (mem/f:DI (plus:DI (reg/v/f:DI 2 cx [orig:63 q ] [63])
(const_int 144 [0x90])) [2 *q_19+0 S8 A64])
(reg:DI 1 dx [73])) pr53705.c:9 62 {*movdi_internal_rex64}
(expr_list:REG_DEAD (reg/v/f:DI 2 cx [orig:63 q ] [63])
(nil)))
(insn 21 350 257 2 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/f/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -8 [0xfff8])) [2 q+152 S8 A64])
(reg:DI 1 dx [73]))) pr53705.c:19 7 {*cmpdi_1}
(expr_list:REG_DEAD (reg:DI 1 dx [73])
(nil)))
For that we check write_dependence of:
(mem/f:DI (plus:DI (reg/v/f:DI 2 cx [orig:63 q ] [63])
(const_int 144 [0x90])) [2 *q_19+0 S8 A64])
vs
(mem/f/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -8 [0xfff8])) [2 q+152 S8 A64])
(note that at this point cx == bp-152, hence this accesses the same memory.
true_dependence uses base_alias_check to test these two mems and wants
to disambiguate the bases. cselib is used for that and in valueized form
the two addresses look like so:
(plus:DI (value:DI 8:12039 @0x1b9ef68/0x1b55410) (const_int 144 [0x90]))
(plus:DI (value:DI 2:4059 @0x1b9eed8/0x1b552f0) (const_int -8))
>From cselib we have these details of the two involved VALUEs:
(value:DI 8:12039 @0x1b9ef68/0x1b55410)
locs:
from insn 43 (reg/v/f:DI 2 cx [orig:63 q ] [63])
from insn 43 (plus:DI (value:DI 5:7965 @0x1b9ef20/0x1b55380)
(const_int 8 [0x8]))
(value:DI 2:4059 @0x1b9eed8/0x1b552f0)
locs:
from insn 352 (reg/f:DI 6 bp)
from insn 351 (plus:DI (value:DI 1:1 @0x1b9eec0/0x1b552c0)
(const_int -8 [0xfff8]))
That is, value 2 is bp-based (or value 1) based, and value 8 is value 5 based,
which itself is:
(value:DI 5:7965 @0x1b9ef20/0x1b55380)
locs:
from insn 353 (reg/f:DI 7 sp)
from insn 353 (plus:DI (value:DI 2:4059 @0x1b9eed8/0x1b552f0)
(const_int -160 [0xff60]))
I.e. value 5 (and hence 8) is value 2 based (like the other mem), or sp based.
Now, find_base_term() for [bp-8] will return "(address:DI -4)", which comes
from
the REG_BASE_VALUE of the (reg/f:DI 6 bp).
find_base_term ([cx+144]) otoh will go via value 8 to value 5, from there
to REG_BASE_VALUE([sp]), which returns "(address:DI -1)". If find_base_term
would skip the first loc ("sp") and try to look into the second loc (val 2)
it would also return (address:DI -4).
Now, two ADDRESS rtxes that aren't pointer-equal aren't equivalent, and hence
the disambiguator thinks that the two mems cannot point into the same memory.
Obviously the problem is some confusion in setting up REG_BASE_VALUE for
sp and bp. When we have a frame pointer then both should have the same base,
not different ones.
[Bug bootstrap/53709] New: libada build failure when bootstrapping on Fedora 17 x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53709 Bug #: 53709 Summary: libada build failure when bootstrapping on Fedora 17 x86_64 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: andris.pave...@iki.fi Created attachment 27645 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27645 build output compressed with xz Noticed that 'make bootstrap" for gcc-4.7.1 release fails when building all-target-libada on Fedora 17 x86_64. Initially found with modified GCC sources, but reproduced also with original ones. Only C, C++ and Ada languages were enabled. Output ends with: -Wl,-soname,libgnat-4.7.so \ -lm /usr/bin/ld: adadecode.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC adadecode.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[5]: *** [gnatlib-shared-default] Error 1 make[5]: Leaving directory `/home/andris/2/build/gcc/ada' make[4]: *** [gnatlib-shared-dual] Error 2 make[4]: Leaving directory `/home/andris/2/build/gcc/ada' make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory `/home/andris/2/build/gcc/ada' make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory `/home/andris/2/build/x86_64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/home/andris/2/build' make: *** [bootstrap] Error 2 Full XZ packed build output attached (when building from original gcc-4.7.1 sources)
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 --- Comment #4 from Mikael Pettersson 2012-06-17 14:34:44 UTC --- This was fixed for gcc-4.7.0 by r177658: http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00672.html http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00353.html The patch applies cleanly to 4.6.3 and cures the ICE on this test case. I haven't tested the backport beyond that. For 4.6.3 you can also avoid the ICE by reducing the optimization level to -O2.
[Bug c/53702] Segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702 Markus Trippelsdorf changed: What|Removed |Added CC||meadori at gmail dot com --- Comment #2 from Markus Trippelsdorf 2012-06-17 14:16:27 UTC --- Started with revision 187979: commit e4a33abd20e349979e77e2881fcd29dac9825ed6 Author: jsm28 Date: Tue May 29 19:07:04 2012 + 2012-05-29 Meador Inge * c-decl.c (c_push_function_context): Always create a new language function. (c_pop_function_context): Clear the language function created in c_push_function_context. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@187979 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 Ever Confirmed|0 |1 --- Comment #1 from Iain Sandoe 2012-06-17 14:12:35 UTC --- it is because (some, if not all) the ObjC Meta-data alignment is being changed from 2 to 4. (presumably so that they become eligible for vector ops). However, the size/organization of the meta-data are fixed by the runtime, external to GCC - thus we cannot adjust in this manner. I think (but have yet to check) that the ObjC FE explicitly sets the alignment of the items. Presumably, the ME should honor that? If not, some suggestion about how to enforce what is needed would be helpful.
[Bug tree-optimization/53708] New: [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 Bug #: 53708 Summary: [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org, rgue...@gcc.gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* Between revisions 188187 (OK) and 188246 over one hundred tests failed with -m32 and -O3 -fnext-runtime on *-apple-darwin*: Running target unix/-m32 FAIL: objc/execute/exceptions/catchall-1.m compilation, -O3 -fomit-frame-pointer -fnext-runtime UNRESOLVED: objc/execute/exceptions/catchall-1.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/exceptions/catchall-1.m compilation, -O3 -g -fnext-runtime UNRESOLVED: objc/execute/exceptions/catchall-1.m execution, -O3 -g -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m compilation, -O3 -fomit-frame-pointer -fnext-runtime UNRESOLVED: objc/execute/exceptions/finally-1.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/exceptions/finally-1.m compilation, -O3 -g -fnext-runtime ... FAIL: objc.dg/torture/tls/thr-init-3.m -O3 -fomit-frame-pointer -fnext-runtime (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O3 -fomit-frame-pointer -fnext-runtime compilation failed to produce executable FAIL: objc.dg/torture/tls/thr-init-3.m -O3 -g -fnext-runtime (test for excess errors) WARNING: objc.dg/torture/tls/thr-init-3.m -O3 -g -fnext-runtime compilation failed to produce executable === objc Summary for unix/-m32 === # of expected passes5891 # of unexpected failures104 # of expected failures6 # of unresolved testcases92 # of unsupported tests85 On x86_64-apple-darwin10 I also see the following failures with -m64 Running target unix/-m64 FAIL: objc/execute/formal_protocol-4.m compilation, -O3 -fomit-frame-pointer -fnext-runtime UNRESOLVED: objc/execute/formal_protocol-4.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/formal_protocol-4.m compilation, -O3 -g -fnext-runtime UNRESOLVED: objc/execute/formal_protocol-4.m execution, -O3 -g -fnext-runtime FAIL: objc/execute/protocol-isEqual-2.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/protocol-isEqual-2.m execution, -O3 -g -fnext-runtime === objc Summary for unix/-m64 === # of expected passes6045 # of unexpected failures4 # of expected failures14 # of unresolved testcases2 # of unsupported tests91 while on powerpc-apple-darwin9 I only see the execution failures. The compilation failures are all of the kind ld: in /var/tmp//ccVsf9ME.o, S_LITERAL_POINTERS section __OBJC,__message_refs missing relocs collect2: error: ld returned 1 exit status They disappear if I compile the tests with '-O3 -fno-tree-vectorize', but reappear with '-O2 -ftree-vectorize'. According to Iain Sandoe, this is due to revisions 188235/188243.
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333 --- Comment #29 from Rafał Mużyło 2012-06-17 13:17:36 UTC --- gcc 4.7.1 still shows inconsistent behavior with attachment 25239.
[Bug c++/53707] compiler generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707 Rafał Mużyło changed: What|Removed |Added Attachment #27643|0 |1 is obsolete|| --- Comment #3 from Rafał Mużyło 2012-06-17 13:08:59 UTC --- Created attachment 27644 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27644 preprocessed sources triggering the bug (compressed)
[Bug c++/53707] compiler generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707 --- Comment #2 from Rafał Mużyło 2012-06-17 13:05:20 UTC --- Created attachment 27643 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27643 preprocessed sources triggering the bug
[Bug c++/53707] compiler generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707 --- Comment #1 from Rafał Mużyło 2012-06-17 13:03:27 UTC --- Created attachment 27642 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27642 -Wall warnings Attaching '-Wall' warnings for completeness. Note, that gcc 4.7.1 generates good code regardless of the presence of the added line.
[Bug c++/53707] New: compiler generates wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53707 Bug #: 53707 Summary: compiler generates wrong code Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: galtge...@o2.pl Using built-in specs. COLLECT_GCC=gcc-4.6.3 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/lto-wrapper Target: i686-pc-linux-gnu Configured with: /mnt/workbox/builds/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --with-arch=i686 --enable-objc-gc --enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.3, pie-0.5.1' --disable-libstdcxx-pch Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.1) g++-4.6.3 -std=gnu++0x -O3 -fomit-frame-pointer -march=native -c tools.cpp -o ui-tools.o (without preprocessor switches, as they won't matter for preprocessed sources) no warnings with the above line (though quite a few with -Wall, but not in the affected part of code, it would seem) The attached preprocessed sources produce *right* code, to get the *wrong* code, remove 'string test(n);' (which should be a no-op there) from the 'for(unsigned n = 0; n < Codes; n++)' around line 54977.
[Bug rtl-optimization/53706] [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 --- Comment #1 from Uros Bizjak 2012-06-17 12:42:32 UTC --- Created attachment 27641 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27641 Preprocessed source
[Bug rtl-optimization/53706] New: [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53706 Bug #: 53706 Summary: [4.8 Regression] [ia64]: Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ubiz...@gmail.com Recent 4.8 regression on ia64. The bootstrap fail with: *** glibc detected *** /home/uros/gcc-build/prev-gcc/cc1plus: corrupted double-linked list: 0x627ec0d0 *** === Backtrace: = /lib/libc.so.6.1(+0xd7800)[0x2021f800] /lib/libc.so.6.1(+0xd81f0)[0x202201f0] /lib/libc.so.6.1(+0xdb5e0)[0x202235e0] /lib/libc.so.6.1(cfree-0x1cfed0)[0x2022be10] /home/uros/gcc-build/prev-gcc/cc1plus(htab_delete+0x214501a0)[0x4184be90] /home/uros/gcc-build/prev-gcc/cc1plus[0x414063a0] /home/uros/gcc-build/prev-gcc/cc1plus(_Z22variable_tracking_mainv+0x21012b50)[0x4140c530] /home/uros/gcc-build/prev-gcc/cc1plus[0x4145f840] /home/uros/gcc-build/prev-gcc/cc1plus[0x40d72d10] /home/uros/gcc-build/prev-gcc/cc1plus(_Z16execute_one_passP8opt_pass+0x208a3860)[0x40c9f560] /home/uros/gcc-build/prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x208a4c90)[0x40ca0310] /home/uros/gcc-build/prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass+0x208a4ce0)[0x40ca0360] This corrupted double linked list problem can be exposed with a cross to ia64-unknown-linux-gnu under valgrind, with attached gimplify.ii: $ valgrind ~/gcc-build-ia64/gcc/cc1plus -O2 -g -fno-common -fno-exceptions -fno-rtti gimplify.ii ... ==2911== Invalid write of size 8 ==2911==at 0xBDC35E: variable_htab_free (var-tracking.c:1418) ==2911==by 0xDA819A: htab_delete (hashtab.c:430) ==2911==by 0xBE93EA: vt_emit_notes (var-tracking.c:9132) ==2911==by 0xBE9631: variable_tracking_main (var-tracking.c:9875) ==2911==by 0xC06995: ia64_reorg (ia64.c:9834) ==2911==by 0x9923F9: rest_of_handle_machine_reorg (reorg.c:4151) ==2911==by 0x945C26: execute_one_pass (passes.c:2164) ==2911==by 0x945FD4: execute_pass_list (passes.c:2219) ==2911==by 0x945FE6: execute_pass_list (passes.c:2220) ==2911==by 0x945FE6: execute_pass_list (passes.c:2220) ==2911==by 0x745047: expand_function (cgraphunit.c:1615) ==2911==by 0x746936: compile (cgraphunit.c:1720) ==2911== Address 0xf16ea18 is 40 bytes inside a block of size 2,568 free'd ==2911==at 0x4A079AE: free (vg_replace_malloc.c:427) ==2911==by 0x6DA9F7: empty_alloc_pool (alloc-pool.c:210) ==2911==by 0x6DAA68: free_alloc_pool (alloc-pool.c:230) ==2911==by 0xBE93D3: vt_emit_notes (var-tracking.c:9130) ==2911==by 0xBE9631: variable_tracking_main (var-tracking.c:9875) ==2911==by 0xC06995: ia64_reorg (ia64.c:9834) ==2911==by 0x9923F9: rest_of_handle_machine_reorg (reorg.c:4151) ==2911==by 0x945C26: execute_one_pass (passes.c:2164) ==2911==by 0x945FD4: execute_pass_list (passes.c:2219) ==2911==by 0x945FE6: execute_pass_list (passes.c:2220) ==2911==by 0x945FE6: execute_pass_list (passes.c:2220) ==2911==by 0x745047: expand_function (cgraphunit.c:1615)
[Bug rtl-optimization/53705] New: wrong code with custom flags - stores to memory are lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705 Bug #: 53705 Summary: wrong code with custom flags - stores to memory are lost Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 27640 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27640 reduced testcase (from testsuite/gcc.c-torture/execute/loop-2e.c) GCC 4.3-4.8 fails, while with GCC 4.2, the code is reduced just to return 0. I am not sure if this should be marked as a regression. Compiler output: $ gcc -O2 -fno-omit-frame-pointer -fpeel-loops -fsched2-use-superblocks -fno-tree-loop-optimize -fno-web --param=max-completely-peel-times=256 testcase.c $ ./a.out Aborted Looking at the assembly: ... subrsp, 320#, movrdx, QWORD PTR p[rip]# p.0, p learcx, [rbp-320]# q, ... movQWORD PTR [rcx+240], rdi# *q_19, tmp73 learax, [rdx+144]# tmp73, learsi, [rdx+148]# tmp73, leardi, [rdx+152]# tmp73, leardx, [rdx+156]# tmp73, cmpQWORD PTR [rbp-8], rdx# q, tmp73 movQWORD PTR [rcx+280], rax# *q_19, tmp73 movQWORD PTR [rcx+248], r8# *q_19, tmp73 movQWORD PTR [rcx+256], r9# *q_19, tmp73 movQWORD PTR [rcx+264], r10# *q_19, tmp73 movQWORD PTR [rcx+272], r11# *q_19, tmp73 movQWORD PTR [rcx+288], rsi# *q_19, tmp73 movQWORD PTR [rcx+296], rdi# *q_19, tmp73 movQWORD PTR [rcx+304], rdx# *q_19, tmp73 jne.L46#, ... It seems the dependency between storing to *q++ (esp. q[39]) in foo() and verifying it in main() is lost. Furthermore, it seems q[39] ([rcx+312]) is not stored to at all.
[Bug debug/53704] [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-17 Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-06-17 11:52:33 UTC --- > Running target unix/-m64 > FAIL: gfortran.dg/array_constructor_type_7.f03 -O3 -g (internal compiler > error) > FAIL: gfortran.dg/array_constructor_type_7.f03 -O3 -g (test for excess > errors) > > In both cases, the internal compiler error appears with optimization at -O1 or > above and -g and is > > [macbook] f90/bug% gfc -m32 -O1 -g minmax_char_1_red.f90 > minmax_char_1_red.f90: In function 'equal': > minmax_char_1_red.f90:28:0: internal compiler error: in based_loc_descr, at > dwarf2out.c:10027 But there is a kludge for this in function_possibly_abstracted_p, why doesn't it work on Darwin as well?
[Bug middle-end/53688] [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-17 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-06-17 11:41:54 UTC --- Mine.
[Bug debug/53704] New: [4.8 Regression] ICE: in based_loc_descr, at dwarf2out.c:10027 after revision 188621
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53704
Bug #: 53704
Summary: [4.8 Regression] ICE: in based_loc_descr, at
dwarf2out.c:10027 after revision 188621
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: bur...@net-b.de, ebotca...@gcc.gnu.org,
ia...@gcc.gnu.org
Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
Build: x86_64-apple-darwin10
On x86_64-apple-darwin10, revision 188621 causes/exposes the following
regressions:
Running target unix/-m32
FAIL: gfortran.dg/minmax_char_1.f90 -O3 -g (internal compiler error)
FAIL: gfortran.dg/minmax_char_1.f90 -O3 -g (test for excess errors)
...
Running target unix/-m64
FAIL: gfortran.dg/array_constructor_type_7.f03 -O3 -g (internal compiler
error)
FAIL: gfortran.dg/array_constructor_type_7.f03 -O3 -g (test for excess
errors)
In both cases, the internal compiler error appears with optimization at -O1 or
above and -g and is
[macbook] f90/bug% gfc -m32 -O1 -g minmax_char_1_red.f90
minmax_char_1_red.f90: In function 'equal':
minmax_char_1_red.f90:28:0: internal compiler error: in based_loc_descr, at
dwarf2out.c:10027
I have reduced minmax_char_1.f90 to
program test
character(len=3) :: s
character(len=6) :: t
s = "gee"
t = "crunch"
call foo("gee ","crunch",s,t)
contains
subroutine foo(res_max, res_min, a, b, c, d)
character(len=*) :: res_min, res_max
character(len=*), optional :: a, b, c, d
if (.not. equal(min(a,b,c,d), res_min)) call abort
if (.not. equal(max(a,b,c,d), res_max)) call abort
end subroutine foo
pure function equal(a,b)
character(len=*), intent(in) :: a, b
logical :: equal
equal = (len(a) == len(b)) .and. (a == b)
end function equal
end program test
The ICE goes away if I remove one of the IF in the subroutine foo. Note also
that minmax_char_1.f90 passes with -m64 and array_constructor_type_7.f03 with
-m32.
[Bug rtl-optimization/43616] Extra register move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43616
Uros Bizjak changed:
What|Removed |Added
Target|arm-eabi|arm-eabi, x86
Known to fail||
--- Comment #2 from Uros Bizjak 2012-06-17 11:03:47
UTC ---
The same problem happens on x86_64:
--cut here--
void foo (void);
float test (float a, float b)
{
foo ();
return b;
}
--cut here--
gcc -O2
test:
.LFB0:
subq$24, %rsp
movss %xmm1, (%rsp)
callfoo
A movss (%rsp), %xmm1
addq$24, %rsp
B movaps %xmm1, %xmm0
ret
We could move from stack directly to xmm0
[Bug c/53702] Segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf
2012-06-17 11:02:23 UTC ---
void fn1 ()
{
void fn2 ()
{
}
typedef int pt;
}
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson 2012-06-17 10:36:36 UTC --- ICEs gcc 4.6.3 and 4.4.7, compiles w/o error with 4.7.1, 4.5.3, 4.3.6, and 4.2.4 (all crosses to ia64-linux hosted on i686-linux).
[Bug rtl-optimization/53700] [4.7 regression] ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53700 --- Comment #4 from Kacper Kowalik 2012-06-17 10:07:04 UTC --- (In reply to comment #1) > It was fixed in trunk by following changeset: > > http://gcc.gnu.org/viewcvs?view=revision&revision=185971 > > Please backport For the completness, the regression was introduced by: http://gcc.gnu.org/viewcvs?view=revision&revision=182015 (gdb) bt #0 fancy_abort (file=0xcb4975 "/dev/shm/gcc/gcc/postreload.c", line=403, function=0xcb4e90 "reload_cse_simplify_operands") at /dev/shm/gcc/gcc/diagnostic.c:898 #1 0x00737f75 in _fatal_insn (msgid=, insn=0x755f0318, file=0xcb4975 "/dev/shm/gcc/gcc/postreload.c", line=403, function=0xcb4e90 "reload_cse_simplify_operands") at /dev/shm/gcc/gcc/rtl-error.c:110 #2 0x00737fa0 in _fatal_insn_not_found (insn=, file=, line=, function=) at /dev/shm/gcc/gcc/rtl-error.c:120 #3 0x006f4e01 in reload_cse_simplify_operands (insn=0x755f0318, testreg=0x755fe0c0) at /dev/shm/gcc/gcc/postreload.c:403 #4 0x006f519d in reload_cse_simplify (testreg=0x755fe0c0, insn=0x755f0318) at /dev/shm/gcc/gcc/postreload.c:181 #5 reload_cse_regs_1 (first=) at /dev/shm/gcc/gcc/postreload.c:214 #6 0x006f65a9 in reload_cse_regs (first=0x75929480) at /dev/shm/gcc/gcc/postreload.c:71 #7 0x006f6f7c in rest_of_handle_postreload () at /dev/shm/gcc/gcc/postreload.c:2277 #8 rest_of_handle_postreload () at /dev/shm/gcc/gcc/postreload.c:2271 #9 0x006efc2a in execute_one_pass (pass=0x11b0140) at /dev/shm/gcc/gcc/passes.c:2074 #10 0x006eff45 in execute_pass_list (pass=0x11b0140) at /dev/shm/gcc/gcc/passes.c:2129 #11 0x006eff57 in execute_pass_list (pass=0x11afec0) at /dev/shm/gcc/gcc/passes.c:2130 #12 0x006eff57 in execute_pass_list (pass=0x11aff20) at /dev/shm/gcc/gcc/passes.c:2130 #13 0x007c7a53 in tree_rest_of_compilation (fndecl=0x758d8500) at /dev/shm/gcc/gcc/tree-optimize.c:421 #14 0x0057a40a in cgraph_expand_function (node=) at /dev/shm/gcc/gcc/cgraphunit.c:1818 #15 0x0057baba in cgraph_expand_all_functions () at /dev/shm/gcc/gcc/cgraphunit.c:1885 #16 cgraph_optimize () at /dev/shm/gcc/gcc/cgraphunit.c:2198 #17 0x0057c07a in cgraph_finalize_compilation_unit () at /dev/shm/gcc/gcc/cgraphunit.c:1327 #18 0x004c09a0 in c_write_global_declarations () at /dev/shm/gcc/gcc/c-decl.c:10026 #19 0x00782978 in compile_file () at /dev/shm/gcc/gcc/toplev.c:573 #20 do_compile () at /dev/shm/gcc/gcc/toplev.c:1928 #21 toplev_main (argc=5, argv=0x7fffe118) at /dev/shm/gcc/gcc/toplev.c:2004 #22 0x767156e5 in __libc_start_main () from /lib64/libc.so.6 #23 0x004afc19 in _start ()
[Bug c/53703] New: verify_ssa: definition in block 105 does not dominate use in block 103
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53703 Bug #: 53703 Summary: verify_ssa: definition in block 105 does not dominate use in block 103 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 27639 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27639 C source code I just tried to compile the package gnet2-2.0.8-6 on gcc-4.8 trunk dated 20120617 on an AMD x86_64 box. The compiler said usagi_ifaddrs.c:428:1: error: definition in block 105 does not dominate use in block 103 usagi_getifaddrs (struct ifaddrs **ifap) ^ for SSA_NAME: .MEM_375 in statement: # VUSE <.MEM_375> D.5483_238 = ifamap.address_len; usagi_ifaddrs.c:428:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 Cyril Brulebois changed: What|Removed |Added CC||kibi at debian dot org --- Comment #2 from Cyril Brulebois 2012-06-17 09:47:22 UTC --- FWIW, it builds fine with: gcc-4.7 (Debian 4.7.1-1) 4.7.0
[Bug c/53702] New: Segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53702 Bug #: 53702 Summary: Segmentation fault with -Wall Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 27638 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27638 C source code I just tried to compile the package gstreamer-plugins-espeak-0.3.5-2 on gcc-4.8 trunk dated 20120617 on an AMD x86_64 box. The compiler said espeak.c:245:5: internal compiler error: Segmentation fault g_atomic_int_set (&spin->state, PLAY); ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Preprocessed source code attached. Flag -Wall required.
[Bug rtl-optimization/48542] unchanged variables in code which calls setjmp may be clobbered (including the return-address)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48542 Eric Botcazou changed: What|Removed |Added CC||martin at netbsd dot org --- Comment #19 from Eric Botcazou 2012-06-17 09:18:29 UTC --- *** Bug 53219 has been marked as a duplicate of this bug. ***
[Bug target/53219] inlined function erroneously clobbers %i0 register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #9 from Eric Botcazou 2012-06-17 09:18:29 UTC --- First anniversary today. :-) Upgrade your compiler or backport the fix. *** This bug has been marked as a duplicate of bug 48542 ***
[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53694 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2012-06-17 08:52:44 UTC --- (In reply to comment #0) > See also: https://groups.google.com/forum/#!msg/comp.lang.fortran/YDt3j0--1Do Note: That link does not seem to work.
[Bug target/53698] [4.8 Regression] ICE: in plus_constant, at explow.c:88 with -O -mx32 -maddress-mode=long -fno-tree-dominator-opts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53698 --- Comment #2 from rsandifo at gcc dot gnu.org 2012-06-17 08:29:38 UTC --- Created attachment 27637 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27637 Suggested fix Please try the attached
[Bug ada/53686] gnatchop -r raises STORAGE_ERROR on all inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53686 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-17 CC||ebotcazou at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-06-17 08:07:37 UTC --- Indeed, since 06/12 according to my logs.
[Bug ada/53684] Cannot raise custom exceptions in configurable runtime mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53684 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||INVALID --- Comment #1 from Eric Botcazou 2012-06-17 08:03:13 UTC --- > According to the HIE docs, > (http://docs.adacore.com/gnat-hie-docs/html/gnathie_ug_3.html#SEC8) it states > when using a configurable runtime, exceptions declarations are valid. Note that this documentation isn't for the FSF compiler, so there is no point in mentioning it here. > In an attempt to build a hello world kernel for i386 using FS GNAT 4.6 on > Debian testing, it fails to build. > > Compile the test with: > > gnatmake -gnat2005 -g -a -x -gnatg -gnatec=./gnat.adc test.adb --RTS=. -cargs > -m32 -march=i386 > > Results are: > > test.adb:5:04: construct not allowed in configurable run-time mode > test.adb:5:04: file a-except.ads not found > test.adb:5:04: entity "Ada.Exceptions.Raise_Exception" not available > gnatmake: "test.adb" compilation error > > Expected results: > > What is expected is that a-except is not looked for and the exception is > caught using the local handler or redirected to last_chance_handler. No, you need to provide a specialized version of the package.
[Bug ada/53677] GNAT build didn't stop after a fatal error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53677 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-17 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-06-17 07:50:35 UTC --- Feel free to submit a patch if you want this changed. The interesting lines are 2564-2595 in ada/gcc-interface/Makefile.in. Otherwise, I'm afraid nobody will care enough to do it.
