[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target Severity|major |normal
[Bug fortran/48279] [4.6/4.7 Regression] segfault in gfc_check_vardef_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48279 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-29 06:26:50 UTC --- (In reply to comment #7) call set1 (get (h)) subroutine set1 (a) integer, intent(inout) :: a If one changes the (invalid) INOUT to IN, it compiles. * * * Additionally, for the modified program, I think NAG is correct with the following error - gfortran just compiles it: Error: GET1 in generic GET is an internal procedure From F2008, 12.4.3.4.1 Generic identifiers: The PROCEDURE statement lists procedure pointers, external procedures, dummy procedures, or module procedures that have this generic interface. (However, g95, pgf95 and crayftn also compile it, thus, I might misread F2008.)
[Bug bootstrap/48327] New: [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 Summary: [4.7 Regression] Bootstrap comparison failure with ada since r171622 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: l...@gcc.gnu.org Target: x86_64-linux ../configure --enable-languages=all,obj-c++,ada,lto,go --enable-checking=yes,rtl configured gcc results in .bad_compare: gcc/ada/exp_dist.o differs r171621 works, r171622 fails. Most likely stage2 tree-ssa-forwprop.o is miscompiled, doesn't seem to be VTA related, as even when I compile exp_dist.adb with -g0 by both stage1-gcc/gnat1 and prev-gcc/gnat1, it differs. r171621 compiled exp_dist.s is identical to what stage1-gcc/gnat1 in r171622 produces, differences start in forwprop1 pass.
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-03-29 07:04:08 UTC --- (In reply to comment #5) The patch in comment #3 fixes the ICE, but the test still fails: FAIL: gcc.dg/vect/pr38529.c scan-tree-dump-times vect OUTER LOOP VECTORIZED 1 This is expected, because the patch only prevents vectorization of unexpected phis. As Richard wrote, copyprop will have to be fixed to propagate the zero. After that the loop will get vectorized again.
[Bug target/48252] ARM neon: problem with consecutive vzip, vuzp and vtrn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48252 --- Comment #1 from Johan Kristell johan.kristell at axis dot com 2011-03-29 07:18:37 UTC --- Some additional info about the gcc version tested. URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch Revision: 171340
[Bug target/48325] ICE in reload_cse_simplify_operands, at postreload.c:403 with neon optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48325 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-03-29 07:43:35 UTC --- That's a heavily modified compiler by CodeSourcery. Please reproduce with a vanilla FSF GCC, or report the problem to CodeSourcery as their compiler clearly directs you to do (see the --with-bugurl= setting).
[Bug bootstrap/48327] [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-linux|x86_64-linux x86-linux Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.29 07:49:51 CC||ebotcazou at gcc dot ||gnu.org Version|4.6.0 |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-29 07:49:51 UTC --- Confirmed. Same error on x86.
[Bug target/48328] New: GCC failed to generate 16bit relative jump table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48328
Summary: GCC failed to generate 16bit relative jump table
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Host: linux
Target: arm-eabi
Build: linux
Created attachment 23796
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23796
testcase
As mentioned in pr47373, sometimes gcc generates absolute address in jump
table, double the size of the table. Now I extract the test case. Compile it
with trunk gcc and options -march=armv7-a -mthumb -Os, I can get
...
ldrr3, [fp, #0]
subsr3, r3, #11
.L14:
cmpr3, #18
bhi.L14
adrr0, .L21
ldrpc, [r0, r3, lsl #2]
.align2
.L21:
.word.L15+1
.word.L14+1
.word.L16+1
.word.L14+1
.word.L14+1
.word.L17+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L18+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L14+1
.word.L19+1
.word.L76+1
.L15:
...
This is the first problem, the relative address now becomes absolute address,
of course 32bit entries.
The corresponding insns from infback.c.220r.nothrow is actually addr_diff_vec,
I couldn't find how the absolute addresses are outputted.
(jump_insn:TI 85 83 86 7 (parallel [
(set (pc)
(if_then_else (leu (reg:SI 3 r3 [551])
(const_int 18 [0x12]))
(mem:SI (plus:SI (mult:SI (reg:SI 3 r3 [551])
(const_int 4 [0x4]))
(label_ref 86)) [0 S4 A32])
(label_ref:SI 82)))
(clobber (reg:CC 24 cc))
(clobber (reg:SI 0 r0))
(use (label_ref 86))
]) src/zlib/infback.c:281 717 {thumb2_casesi_internal}
(expr_list:REG_UNUSED (reg:CC 24 cc)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(insn_list:REG_LABEL_TARGET 82 (nil
- 86)
(code_label 86 85 87 21 [2 uses])
(jump_insn 87 86 88 (addr_diff_vec:SI (label_ref:SI 86)
[
(label_ref:SI 89)
(label_ref:SI 82)
(label_ref:SI 180)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 232)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 484)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 82)
(label_ref:SI 700)
(label_ref:SI 762)
]
(label_ref:SI 82)
(label_ref:SI 762)) src/zlib/infback.c:281 -1
(nil))
When I add -fpic to command line, gcc generates following
subsr3, r3, #11
.L14:
cmpr3, #18
bhi.L14
adrr0, .L21
ldrr1, [r0, r3, lsl #2]
addr0, r0, r1
bxr0
.align2
.L21:
.word.L15+1-.L21
.word.L14+1-.L21
.word.L16+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L17+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L18+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L14+1-.L21
.word.L19+1-.L21
.word.L76+1-.L21
.L15:
Now we get relative address table, but the table entries are 4 bytes, not the
optimal 2 bytes form. This is the second problem.
The related source should be in arm.h
#define CASE_VECTOR_SHORTEN_MODE(min, max, body)\
(TARGET_THUMB1\
? (min = 0 max 512\
? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, QImode)\
: min = -256 max 256\
? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, QImode)\
: min = 0 max 8192\
? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 1, HImode)\
: min = -4096 max 4096\
? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, HImode)\
: SImode)\
: ((min 0 || max = 0x2000 || !TARGET_THUMB2) ? SImode\
: (max = 0x200) ? HImode\
: QImode))
Problems:
a) Is (max = 0x2000) correct? Why not (max = 0x2)? The maximum unsigned
short is 0x.
b) Alghough tbb/tbh needs forward jump (min = 0), but tbb/tbh isn't must be
used. In this case (min 0), we can use separate instructions to load the
offset and add it to pc. It is
[Bug middle-end/48329] New: Program takes twice as long *without* -fopenmp than with 1 OpenMP thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329 Summary: Program takes twice as long *without* -fopenmp than with 1 OpenMP thread Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization, openmp Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Program taken from http://openmp.org/forum/viewtopic.php?f=3t=1123 System: Intel Xeon X5570 @ 2.93GHz, SUSE SLES 11 (x86_64) [glibc-2.11.1] No OpenMP: gfortran -O3 -ffast-math test2.f90 time ./a.out - 14.44user 0.00system 0:14.46elapsed 99%CPU With OpenMP and OMP_NUM_THREADS=1 gfortran -fopenmp -O3 -ffast-math test2.f90 time ./a.out - 7.22user 0.00system 0:07.23elapsed 99%CPU Using gfortran 4.3.4, I get the 7s result also without -fopenmp; ditto with ifort 11.1. With OpenMP the run time of GCC 4.6 and ifort is exactly the same [modulo noise] for 1 and 2 threads. program calcpi USE omp_lib implicit none double precision:: h,x,sum,pi integer:: n,i double precision:: f f(x) = 4.0/(1.0+x**2) n = 21 h= 1.0 / dble(n) sum = 0.0 !$OMP PARALLEL DO DEFAULT(NONE) !$OMP SHARED(n,h) PRIVATE(x) !$OMP REDUCTION(+:sum) DO i=1, n x = h * (dble(i)-0.5) sum = sum + f(x) END DO !$OMP END PARALLEL DO pi = h * sum write(*,*) 'Pi=',pi end program calcpi
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de 2011-03-29 09:22:15 UTC --- On Mon, 28 Mar 2011, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-28 18:26:52 UTC --- The patch in comment #3 fixes the ICE, but the test still fails: FAIL: gcc.dg/vect/pr38529.c scan-tree-dump-times vect OUTER LOOP VECTORIZED 1 Compiling with -Ofast -ftree-vectorizer-verbose=2 I get /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:11: note: not vectorized: unsupported data-type /opt/gcc/_clean/gcc/testsuite/gcc.dg/vect/pr38529.c:6: note: vectorized 0 loops in function. That's expected. I suppose the testcase is no longer testing what it was supposed to test (even before, as LIM was applying store-sinking to the store).
[Bug fortran/48095] [OOP] Invalid assignment to procedure pointer component not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48095 --- Comment #4 from janus at gcc dot gnu.org 2011-03-29 09:39:13 UTC --- Author: janus Date: Tue Mar 29 09:39:10 2011 New Revision: 171654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171654 Log: 2011-03-29 Janus Weil ja...@gcc.gnu.org PR fortran/48095 * decl.c (match_procedure_decl,match_ppc_decl): Set flavor of interface. * module.c (MOD_VERSION): Bump. (mio_typespec): Read/write 'interface' field. * primary.c (match_string_constant,match_logical_constant): Remove unneeded code. (match_complex_constant): Make sure to clear the typespec. 2011-03-29 Janus Weil ja...@gcc.gnu.org PR fortran/48095 * gfortran.dg/module_md5_1.f90: Modified MD5 sum. * gfortran.dg/proc_ptr_comp_32.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_32.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/module_md5_1.f90
[Bug other/48318] Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.03.29 10:01:59 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-29 10:01:59 UTC --- Please provide backtraces with gdb and/or valgrind.
[Bug c++/48319] [4.6/4.7 Regression] [C++0x] Segmentation fault in instantiation of std::is_constructibleint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48319 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.1
[Bug fortran/48095] [OOP] Invalid assignment to procedure pointer component not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48095 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-29 10:10:40 UTC --- Remains to be done: The test case of comment 0. Seemingly, for an initialization, the check is not done - while for a normal pointer assignment it is (in expr.c's gfc_check_pointer_assign). I would assume that one needs a similar check in resolve_structure_cons. There are already checks for pointer initialization - one probably needs needs to add a similar check to the one in gfc_check_pointer_assign.
[Bug driver/48306] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-29 10:15:45 UTC --- Ok, I can reproduce it with ~ env -i PATH=/tmp:/space/rguenther/install/gcc-4.6.0/bin gcc t.c gcc: error trying to exec 'cc1': execvp: No such file or directory but not with ~ env -i PATH=/tmp:$PATH gcc-4.6 t.c t.c: In function 'main': t.c:10:3: warning: 'used' attribute ignored [-Wattributes] weird ;) Note that we try to search for the GCC install dir, it is not statically compiled in (so that install with DESTDIR works).
[Bug driver/48306] [4.3/4.4/4.5/4.6/4.7 Regression] presence of gcc subdir with . in PATH causes breakdown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48306 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.2.4 Target Milestone|--- |4.3.6 Summary|presence of gcc subdir with |[4.3/4.4/4.5/4.6/4.7 |. in PATH causes breakdown |Regression] presence of gcc ||subdir with . in PATH ||causes breakdown Known to fail||4.3.0 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-29 10:17:46 UTC --- Fails since 4.3.0, works with 4.2.4.
[Bug fortran/48095] [OOP] Invalid assignment to procedure pointer component not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48095 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-29 10:19:02 UTC --- (In reply to comment #5) I would assume that one needs a similar check in resolve_structure_cons. That should then also take care of: rect = rectangle (1.0, 2.0, get_my_area) which had the same issue, except that it is currently rejected with: Error: Function 'get_my_area' requires an argument list at (1) However, if I read the standard correctly (F2008, 4.5.10 Construction of derived-type values), it should be valid: R456 component-spec is [ keyword = ] component-data-source R457 component-data-source is expr or data-target or proc-target R740 proc-target is expr or procedure-name or proc-component-ref C497 (R457) A data-target shall correspond to a data pointer component; a proc-target shall correspond to a procedure pointer component.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.29 10:23:10 Ever Confirmed|0 |1 Known to fail||4.4.4, 4.5.2, 4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-29 10:23:10 UTC --- Confirmed.
[Bug bootstrap/48327] [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/48330] New: [4.7 Regression] ICE: in optimize_inline_calls, at tree-inline.c:4201 with -fmudflap -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48330 Summary: [4.7 Regression] ICE: in optimize_inline_calls, at tree-inline.c:4201 with -fmudflap -fno-early-inlining Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: jamb...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu It seems any input file is enough to trigger the assertion. Compiler output: $ echo '' testcase.c $ gcc -O -fmudflap -fno-early-inlining testcase.c testcase.c: In function '_GLOBAL__sub_I_00099_0_testcase.c': testcase.c:1:0: internal compiler error: in optimize_inline_calls, at tree-inline.c:4201 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. That assert was added in http://gcc.gnu.org/viewcvs?view=revisionrevision=171602
[Bug tree-optimization/48290] FAIL: gcc.dg/vect/pr38529.c, ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1072
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48290 --- Comment #8 from irar at gcc dot gnu.org 2011-03-29 10:26:30 UTC --- Author: irar Date: Tue Mar 29 10:26:25 2011 New Revision: 171657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171657 Log: PR tree-optimization/48290 * tree-vect-loop.c (vect_analyze_loop_operations): In outer loop vectorization, check that relevant phis in the basic block after the inner loop are really inner loop's exit phis. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/48329] Missed vectorization of reduction due to PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|openmp | Last reconfirmed||2011.03.29 10:31:56 Component|middle-end |tree-optimization CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Program takes twice as long |Missed vectorization of |*without* -fopenmp than |reduction due to PRE |with 1 OpenMP thread| --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-29 10:31:56 UTC --- We vectorize the reduction if the function is outlined. I suppose sth confuses the vectorizer in the non-OMP path. Yep, it's PRE, so try -fno-tree-pre: bb 3: # i_1 = PHI 1(2), i_22(4) # sum_2 = PHI 0.0(2), sum_20(4) # prephitmp.9_50 = PHI 5.66893424036281234980410020432668056299176519904892395524e-20(2), D.1586_48(4) # ivtmp.12_10 = PHI 21(2), ivtmp.12_11(4) D.1574_17 = prephitmp.9_50 + 1.0e+0; D.1575_18 = ((D.1574_17)); D.1576_19 = 4.0e+0 / D.1575_18; sum_20 = D.1576_19 + sum_2; ivtmp.12_11 = ivtmp.12_10 - 1; if (ivtmp.12_11 == 0) goto bb 5; else goto bb 4; bb 4: i_22 = i_1 + 1; pretmp.8_44 = (real(kind=8)) i_22; pretmp.8_45 = pretmp.8_44 - 5.0e-1; pretmp.8_46 = ((pretmp.8_45)); pretmp.8_47 = pretmp.8_46 * 4.76190476190476200439314681013558416822206709184683859348e-10; D.1586_48 = __builtin_pow (pretmp.8_47, 2.0e+0); goto bb 3; is not detected as reduction. Probably not only because, but at least also because of the latch block not being empty.
[Bug bootstrap/48327] [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-29 10:56:50 UTC --- Binary search revealed it is actually gimple.o that got miscompiled by stage1-gcc/cc1. Ignoring .L number differences, only is_gimple_val and canonicalize_cond_expr_cond functions are different.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-29 11:21:53 UTC --- At revision 171632 the test also failed on x86_64-apple-darwin10.7.0: ... Executing on host: ../libtool --silent --tag=CC --mode=link /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/boehm-gc/testsuite/boehm- gc.c/thread_leak_test.c /opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/libgcjgc.la -O2 -I/opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-g c/include -I/opt/gcc/work/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lm -m64 -o ./thread_leak_test(timeout = 300) PASS: boehm-gc.c/thread_leak_test.c -O2 (test for excess errors) Setting LD_LIBRARY_PATH to .:/opt/gcc/build_w/gcc:/opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/.libs:.libs:.:/opt/gcc/build_w/gcc:/opt/gcc/bu ild_w/x86_64-apple-darwin10.7.0/./boehm-gc/.libs:.libs Leaked composite object at 0x1000c0fe0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at 0x1000c0ec0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at 0x1000c0f20 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:12, sz=4, NORMAL) Leaked composite object at start: 0x1000c0f00, appr. length: 48 WARNING: program timed out. FAIL: boehm-gc.c/thread_leak_test.c -O2 execution testExecuting on host: ../libtool --mode=clean rm -f thread_leak_test(timeout = 300) libtool: clean: rm -f thread_leak_test .libs/thread_leak_test .libs/thread_leak_testS.o^M libtool: clean: rmdir .libs /dev/null 21 ... while it passed at revision 171578. Manual runs give [macbook] boehm-gc/testsuite% ../libtool --silent --tag=CC --mode=link /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c /opt/gcc/build_w/x86_64-apple-darwin10.7.0/i386/boehm-gc/libgcjgc.la -O2 -I/opt/gcc/build_w/x86_64-apple-darwin10.7.0/i386/boehm-gc/include -I/opt/gcc/work/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lm -m32 -o ./leak_test [macbook] boehm-gc/testsuite% time ./leak_test Leaked composite object at 0x92fd0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c:16, sz=4, NORMAL) 0.012u 0.021s 0:00.06 50.0%0+0k 0+1io 0pf+0w [macbook] boehm-gc/testsuite% ../libtool --silent --tag=CC --mode=link /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c /opt/gcc/build_w/x86_64-apple-darwin10.7.0/i386/boehm-gc/libgcjgc.la -O2 -I/opt/gcc/build_w/x86_64-apple-darwin10.7.0/i386/boehm-gc/include -I/opt/gcc/work/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lm -m32 -o ./thread_leak_test [macbook] boehm-gc/testsuite% time ./thread_leak_test Leaked composite object at 0x92fd0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c:16, sz=4, NORMAL) 0.012u 0.022s 0:00.04 75.0%0+0k 0+0io 0pf+0w [macbook] boehm-gc/testsuite% ../libtool --silent --tag=CC --mode=link /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c /opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/libgcjgc.la -O2 -I/opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/include -I/opt/gcc/work/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lm -m64 -o ./leak_test [macbook] boehm-gc/testsuite% time ./leak_test Leaked composite object at 0x1000beef0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/leak_test.c:16, sz=8, NORMAL) 0.013u 0.024s 0:00.06 50.0%0+0k 0+2io 0pf+0w [macbook] boehm-gc/testsuite% ../libtool --silent --tag=CC --mode=link /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ /opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c /opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/libgcjgc.la -O2 -I/opt/gcc/build_w/x86_64-apple-darwin10.7.0/./boehm-gc/include -I/opt/gcc/work/boehm-gc/testsuite/../include -Wc,-shared-libgcc -lpthread -lm -m64 -o ./thread_leak_test [macbook] boehm-gc/testsuite% time ./thread_leak_testLeaked composite object at 0x1000c0fe0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:11, sz=4, NORMAL) Leaked composite object at 0x1000c0f80 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:11, sz=4, NORMAL) Leaked composite object at 0x1000c0ef0 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:11, sz=4, NORMAL) Leaked composite object at 0x1000c0d10 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:11, sz=4, NORMAL) Leaked composite object at 0x1000c0e30 (/opt/gcc/work/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c:11, sz=4, NORMAL) 0.013u
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-29 11:30:31 UTC --- --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-29 11:21:53 UTC --- At revision 171632 the test also failed on x86_64-apple-darwin10.7.0: [...] while it passed at revision 171578. Manual runs give Those are both after the dg-based testsuite went in. This either suggests a different change being responsible or a timing issue. Some of those tests can be quite sensitive to load. Could you try to rerun the testcase manually several times and see if the outcome is consistent or differs? Thanks. Rainer
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-29 11:39:58 UTC --- This either suggests a different change being responsible or a timing issue. Some of those tests can be quite sensitive to load. Could you try to rerun the testcase manually several times and see if the outcome is consistent or differs? The failing test occured on a quiet state: i.e., terminal, safari, and xchat opened but not used. The tests run in a fraction of a second far away of the 300s timeout. BTW I did not find a way to run only the boehm test suite: if I make check in x86_64-apple-darwin10.7.0/boehm-gc, I get WARNING: could not find `runtest'
[Bug rtl-optimization/48331] New: [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331 Summary: [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 23797 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23797 reduced testcase Output: $ gcc -O -fira-algorithm=priority -fPIC testcase.c $ valgrind -q ./a.out ==1889== Use of uninitialised value of size 8 ==1889==at 0x400599: sub2 (testcase.c:6) ==1889==by 0x4E4EB6C: (below main) (in /lib64/libc-2.11.3.so) ==1889== ==1889== Jump to the invalid address stated on the next line ==1889==at 0x0: ??? ==1889==by 0x4E4EB6C: (below main) (in /lib64/libc-2.11.3.so) ==1889== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==1889== ==1889== ==1889== Process terminating with default action of signal 11 (SIGSEGV) ==1889== Bad permissions for mapped region at address 0x0 ==1889==at 0x0: ??? ==1889==by 0x4E4EB6C: (below main) (in /lib64/libc-2.11.3.so) Segmentation fault Tested revisions: r171653 - fail r171626 - OK
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-29 11:46:29 UTC --- The failing test occured on a quiet state: i.e., terminal, safari, and xchat opened but not used. The tests run in a fraction of a second far away of the 300s timeout. That's not what I meant: there are tests that fail only once in a while. Rerun it 50 times and you observe failures only during a fraction of those runs. You'd see timeouts in the testsuite logs if they occured. BTW I did not find a way to run only the boehm test suite: if I make check in x86_64-apple-darwin10.7.0/boehm-gc, I get WARNING: could not find `runtest' Run make check in boehm-gc/testsuite instead. Better yet, just build the failing test once and manually rerun it in a loop with LD_LIBRARY_PATH or equivalent set. Rainer
[Bug tree-optimization/48195] ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48195 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-29 11:55:36 UTC --- Proposed patch posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01982.html
[Bug rtl-optimization/48331] [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-03-29 12:10:38 UTC --- The while (1) part of the testcase is not actually needed. The problem seems to be there (at the assembly level): ... movrax, QWORD PTR buf@GOTPCREL[rip]#, movrax, QWORD PTR 8[rax]#, movQWORD PTR -8[rbp], rax# %sfp, # stores value movrax, QWORD PTR buf@GOTPCREL[rip]#, movrbp, QWORD PTR [rax]#, # rbp changes movrsp, QWORD PTR 16[rax]#, jmp[QWORD PTR -8[rbp]]# %sfp # uses new value or rbp ... Maybe this was just uncovered by recent changes - comparing asm output from r171626 and r171653 shows the priority allocator now gives much worse results. In r171626, the generated code is the same as with CB's allocator, but in r171653 there is much higher stack usage, causing this problem to show up.
[Bug bootstrap/48332] New: optabs changes (PR48263 fix) broke m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332 Summary: optabs changes (PR48263 fix) broke m68k-linux bootstrap Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Current gcc-4.7 fails to build for m68k-linux due to an ICE while stage1 gcc builds libgcc: /tmp/gcc-4.7-r171418/libgcc/../gcc/libgcc2.c: In function '__mulvsi3': /tmp/gcc-4.7-r171418/libgcc/../gcc/libgcc2.c:157:18: internal compiler error: in maybe_legitimize_operand, at optabs.c:7034 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_mulvsi3.o] Error 1 make[2]: Leaving directory `/tmp/objdir2/m68k-unknown-linux/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/objdir2' make: *** [all] Error 2 Bisection identified r171418 as the cause of the ICE: Author: rsandifo Date: Thu Mar 24 17:23:18 2011 New Revision: 171418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171418 Log: gcc/ PR rtl-optimization/48263 * optabs.c (expand_binop_directly): Reinstate convert_modes code and original commutative_p handling. Use maybe_gen_insn. Configuration: /tmp/gcc-4.7-r171418/configure --target=m68k-unknown-linux --prefix=/home/mikpe/pkgs/linux-x86/cross-m68k --with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix --enable-checking=release --enable-languages=c
[Bug bootstrap/48332] optabs changes (PR48263 fix) broke m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-29 12:47:23 UTC --- Please attach a preprocessed file.
[Bug debug/48333] New: -fcompare-debug failure (length) - memmove x __builtin_memmove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48333 Summary: -fcompare-debug failure (length) - memmove x __builtin_memmove Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23798 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23798 partially reduced testcase Compiler output: $ gcc -O -fkeep-inline-functions -fcompare-debug testcase.ii testcase.ii: In function ‘std::_Resetiosflags std::resetiosflags(std::ios_base::fmtflags)’: testcase.ii:20948:5: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] testcase.ii: In function ‘std::_Setiosflags std::setiosflags(std::ios_base::fmtflags)’: testcase.ii:20966:5: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] testcase.ii: In function ‘std::_Setbase std::setbase(int)’: testcase.ii:20984:5: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] testcase.ii: In function ‘std::_Setfill_CharT std::setfill(_CharT)’: testcase.ii:21010:7: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] testcase.ii: In function ‘std::_Setprecision std::setprecision(int)’: testcase.ii:21028:5: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] testcase.ii: In function ‘std::_Setw std::setw(int)’: testcase.ii:21046:5: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default] gcc: error: testcase.ii: -fcompare-debug failure (length) $ diff testcase.*gkd 24071c24071 (call (mem:QI (symbol_ref:DI (memmove) [flags 0x41] function_decl # memmove) [ memmove S1 A8]) --- (call (mem:QI (symbol_ref:DI (memmove) [flags 0x41] function_decl # memmove) [ __builtin_memmove S1 A8]) Reducing the testcase is very slow. I met this problem several times, but never with a small testcase.
[Bug tree-optimization/48330] [4.7 Regression] ICE: in optimize_inline_calls, at tree-inline.c:4201 with -fmudflap -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48330 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-29 12:54:50 UTC --- It's mudflap adding call graph nodes from outside the pass manager again: (gdb) bt #0 fancy_abort (file=0x89fd0b8 /home/mjambor/gcc/icln/src/gcc/tree-inline.c, line=4201, function=0x89fe0a3 optimize_inline_calls) at /home/mjambor/gcc/icln/src/gcc/diagnostic.c:893 #1 0x086c4642 in optimize_inline_calls (fn=0xb7649100) at /home/mjambor/gcc/icln/src/gcc/tree-inline.c:4201 #2 0x08699622 in cgraph_early_inlining () at /home/mjambor/gcc/icln/src/gcc/ipa-inline.c:1757 #3 0x083b43f9 in execute_one_pass (pass=0x8b1f300) at /home/mjambor/gcc/icln/src/gcc/passes.c:1555 #4 0x083b46ad in execute_pass_list (pass=0x8b1f300) at /home/mjambor/gcc/icln/src/gcc/passes.c:1610 #5 0x084be2f5 in tree_lowering_passes (fn=0xb7649100) at /home/mjambor/gcc/icln/src/gcc/tree-optimize.c:375 #6 0x08688514 in cgraph_lower_function (node=0xb75c63fc) at /home/mjambor/gcc/icln/src/gcc/cgraphunit.c:334 #7 0x0868a6c4 in cgraph_analyze_function (node=0xb75c63fc) at /home/mjambor/gcc/icln/src/gcc/cgraphunit.c:799 #8 0x086854f7 in cgraph_add_new_function (fndecl=0xb7649100, lowered=0 '\000') at /home/mjambor/gcc/icln/src/gcc/cgraph.c:2501 #9 0x086ad21e in cgraph_build_static_cdtor_1 (which=73 'I', body=0xb762d4b0, priority=99, final=0 '\000') at /home/mjambor/gcc/icln/src/gcc/ipa.c:1593 #10 0x08119465 in mudflap_finish_file () at /home/mjambor/gcc/icln/src/gcc/tree-mudflap.c:1366 #11 0x0845c559 in compile_file () at /home/mjambor/gcc/icln/src/gcc/toplev.c:601 #12 do_compile () at /home/mjambor/gcc/icln/src/gcc/toplev.c:1900 #13 toplev_main (argc=20, argv=0xbfffef34) at /home/mjambor/gcc/icln/src/gcc/toplev.c:1963 #14 0x0816cedb in main (argc=20, argv=0xbfffef34) at /home/mjambor/gcc/icln/src/gcc/main.c:36
[Bug bootstrap/48332] optabs changes (PR48263 fix) broke m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48332 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-03-29 13:01:13 UTC --- Created attachment 23799 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23799 preprocessed and reduced test case
[Bug other/48318] Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 --- Comment #3 from Markus Elfring Markus.Elfring at web dot de 2011-03-29 13:10:41 UTC --- (In reply to comment #2) I can not generate a backtrace myself by the tool GNU debugger on my system at the moment because of the issue GDB or dependency python not properly configured?. https://bugzilla.novell.com/show_bug.cgi?id=677225#c1 I have tried the build again. Now I get a result that is different from yesterday. dmesg: ... [10656.313658] genmddeps[9790]: segfault at 607bb0 ip 00607bb0 sp 7fff77ba4d38 error 15 in genmddeps[607000+1000] [11339.164308] conftest[20445]: segfault at 600ae0 ip 00600ae0 sp 7fff009794e8 error 15 in conftest[60+1000] [11500.528057] genmodes[29951]: segfault at 608320 ip 00608320 sp 7fff10bfc488 error 15 in genmodes[608000+1000] elfring@Sonne:~/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl1/gcc valgrind --verbose --trace-children=yes --log-file=vg_log48318_%p.txt build/genmddeps /home/elfring/Projekte/GNU/GCC/Quellen/4.6.0/gcc/config/i386/i386.md tmp-mddeps Speicherzugriffsfehler ... ==394== Process terminating with default action of signal 11 (SIGSEGV) ==394== Bad permissions for mapped region at address 0x607BB0 ==394==at 0x607BB0: ??? (in /home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl1/gcc/build/genmddeps) ==394==by 0x4036D2: read_md_files (read-md.c:1125) ==394==by 0x4012B2: main (genmddeps.c:50) ... elfring@Sonne:~/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl2/gcc valgrind --verbose --trace-children=yes --log-file=vg_log48318_%p.txt build/genmodes -h tmp-modes.h Speicherzugriffsfehler ... ==31666== Process terminating with default action of signal 11 (SIGSEGV) ==31666== Bad permissions for mapped region at address 0x608320 ==31666==at 0x608320: ??? (in /home/elfring/Projekte/GNU/GCC/erzeugt/4.6.0/Auswahl2/gcc/build/genmodes) ==31666==by 0x4E4BBFC: (below main) (in /lib64/libc-2.11.3.so) ... It seems that some files which names will be generated with the prefix tmp- have got a high probability for unexpected behaviour in the corresponding programs here.
[Bug tree-optimization/48330] [4.7 Regression] ICE: in optimize_inline_calls, at tree-inline.c:4201 with -fmudflap -fno-early-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48330 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.29 13:13:29 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-29 13:13:29 UTC --- The following (untested) patch fixes the issue. It seems OK to me as the lowering passes probably should know that the current function is analyzed but I guess we should ask Honza whether it is really correct: Index: src/gcc/cgraphunit.c === --- src.orig/gcc/cgraphunit.c +++ src/gcc/cgraphunit.c @@ -796,8 +796,8 @@ cgraph_analyze_function (struct cgraph_n gimplify_function_tree (decl); dump_function (TDI_generic, decl); - cgraph_lower_function (node); node-analyzed = true; + cgraph_lower_function (node); pop_cfun (); current_function_decl = save;
[Bug other/48318] Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 --- Comment #4 from Markus Elfring Markus.Elfring at web dot de 2011-03-29 13:13:52 UTC --- Created attachment 23800 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23800 valgrind log
[Bug other/48318] Memory access error by build/genhooks?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48318 --- Comment #5 from Markus Elfring Markus.Elfring at web dot de 2011-03-29 13:15:04 UTC --- Created attachment 23801 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23801 valgrind log
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 13:27:31 UTC --- Author: jason Date: Tue Mar 29 13:27:25 2011 New Revision: 171661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171661 Log: PR c++/48296 * decl.c (cp_finish_decl): Defer validation of constexpr member functions. * class.c (finalize_literal_type_property): Validate them here. * semantics.c (is_valid_constexpr_fn): Don't check completeness. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/42687] The prevention of ADL with the help of parentheses doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42687 Florian Sowade f.sowade-gcc at r9e dot de changed: What|Removed |Added CC||f.sowade-gcc at r9e dot de --- Comment #2 from Florian Sowade f.sowade-gcc at r9e dot de 2011-03-29 13:27:51 UTC --- The change in http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#705 only changed the wording to make this behavior clearer. But the behavior itself is, like clearly argumented there, implied by the old version of 3.4.2. This is still not fixed in trunk. Neither in c++0x mode with the explicit wording in the standard, nor in c++03 mode with the more subtle wording in the standard.
gcc-win-x-ppc/powerpc-wrs-vxworks/mrtp/libgcc Makefile error
Hi Nex here, I try to compile a Canadian Cross Compiler Configure for Candian Cross : ../../source/gcc-4.5.2/configure --build=i686-linux --host=mingw32 --target=powerpc-wrs-vxworks --with-gnu-ld --with-gnu-as --disable-nls --disable-shared --enable-languages=c,c++ --prefix=/usr/share/tools/gcc-win-x-ppc --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-version-specific-runtime-libs --disable-symvers --disable-hosted-libstdcxx --disable-libgomp It is the last step, i allready got linux - win32 compiler and linux - ppc-vxworks compiler But if i try to make,compile this configured gcc there is an makefile, configure error in mrtp/libgcc folder: /build/gcc-win-x-ppc/powerpc-wrs-vxworks/mrtp/libgcc powerpc-wrs-vxworks-gcc -g -O2 -mrtp -O2 -nostdinc -I `case /mrtp in */mrtp*) echo /usr/share/tools/gcc-powerpc/usr//h ;; *) echo /usr/share/tools/gcc-powerpc/target/h ;; esac` -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../source/gcc-4.5.2/libgcc -I../../../../../source/gcc-4.5.2/libgcc/. -I../../../../../source/gcc-4.5.2/libgcc/../gcc -I../../../../../source/gcc-4.5.2/libgcc/../include -DHAVE_CC_TLS -o vxlib.o -MT vxlib.o -MD -MP -MF vxlib.dep -fexceptions -c ../../../../../source/gcc-4.5.2/libgcc/../gcc/config/vxlib.c I `case /mrtp in */mrtp*) echo /usr/share/tools/gcc-powerpc/usr//h ;; *) echo /usr/share/tools/gcc-powerpc/target/h ;; esac` should be -I/usr/share/tools/gcc-powerpc/usr/h -I/usr/share/tools/gcc-powerpc/target/h Im not good in fixing makescripts :( Does anyone got an idea how to fix that ? Thanks in advance Nex -- View this message in context: http://old.nabble.com/gcc-win-x-ppc-powerpc-wrs-vxworks-mrtp-libgcc-Makefile-error-tp31267661p31267661.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/42687] The prevention of ADL with the help of parentheses doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42687 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.29 13:46:50 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 13:46:50 UTC --- (In reply to comment #2) This is still not fixed in trunk. Yup, that's why the bug report is still open. It can be confimed though.
[Bug c++/42687] [4.4/4.5/4.6/4.7 Regression] The prevention of ADL with the help of parentheses doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42687 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.1.2 Summary|The prevention of ADL with |[4.4/4.5/4.6/4.7 |the help of parentheses |Regression] The prevention |doesn't work|of ADL with the help of ||parentheses doesn't work --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 13:49:22 UTC --- This is actually a regression, as 4.1 compiled the example
[Bug rtl-optimization/48334] New: [4.7 Regression] gcc.target/i386/pr39445.c FAILs with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48334
Summary: [4.7 Regression] gcc.target/i386/pr39445.c FAILs with
-fira-algorithm=priority
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 23802
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23802
reduced testcase
Output:
$ gcc -O -fira-algorithm=priority testcase.c
$ ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x00400537 in foo (a1=value optimized out, a2=..., a3=..., a4=...,
a5=..., a6=..., a7=..., a8=..., b1=1, b2=2, b3=3, b4=4, b5=5,
b6=6, b7=-1, y=...) at testcase.c:8
8 {
(gdb) disassemble
Dump of assembler code for function foo:
0x00400534 +0: xorps %xmm0,%xmm0
= 0x00400537 +3: movaps %xmm0,0x10(%rsp)
0x0040053c +8: movlps 0x10(%rsp),%xmm0
0x00400541 +13:movlps %xmm0,0x10(%rsp)
0x00400546 +18:movlps 0x18(%rsp),%xmm0
0x0040054b +23:movlps %xmm0,0x18(%rsp)
0x00400550 +28:movaps 0x10(%rsp),%xmm0
0x00400555 +33:retq
End of assembler dump.
(gdb) i r rsp
rsp0x7fffde28 0x7fffde28
The problem is unaligned access.
As in PR48331, the code generated by priority allocator is much worse than with
CB's one. The code with both allocators was the same in r171626.
[Bug ada/48335] New: [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335
Summary: [4.6/4.7 Regression] ICE in convert_move
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
/* { dg-do compile } */
/* { dg-options -O2 -fno-tree-sra -msse2 } */
#include emmintrin.h
struct S
{
_Complex double d __attribute__((aligned (16)));
};
void bar (struct S);
void
foo (__m128d x, struct S y)
{
struct S s;
_mm_store_pd ((double *) s.d, x);
__real__ s.d *= 7.0;
bar (s);
}
ICEs in convert_move, starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=161655
[Bug ada/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.5.2 Target Milestone|--- |4.6.1 Known to fail||4.6.0, 4.7.0
[Bug c++/47570] one() = 0 isn't constexpr for unsigned int, yet == and is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47570 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:24:15 UTC --- Author: jason Date: Tue Mar 29 14:24:09 2011 New Revision: 171663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171663 Log: PR c++/47570 * semantics.c (cxx_eval_constant_expression) [COMPOUND_EXPR]: Don't use the generic binary expression handling. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-47570.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/47504] some constexpr calculations erroneously overflow when using negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47504 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:24:24 UTC --- Author: jason Date: Tue Mar 29 14:24:19 2011 New Revision: 171664 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171664 Log: PR c++/47504 * semantics.c (cxx_eval_constant_expression) [NOP_EXPR]: Don't let the conversion set TREE_OVERFLOW. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-data2.C
[Bug c++/48313] [C++0x] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:25:34 UTC --- Author: jason Date: Tue Mar 29 14:25:22 2011 New Revision: 171669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171669 Log: PR c++/48313 * pt.c (maybe_adjust_types_for_deduction): Handle T deduction from overloaded function. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/rv-deduce2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/pt.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/47999] [C++0x] auto type deduction works incorrectly in a function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47999 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:25:49 UTC --- Author: jason Date: Tue Mar 29 14:25:37 2011 New Revision: 171670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171670 Log: PR c++/47999 * semantics.c (finish_call_expr): Preserve reference semantics in templates. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/auto22.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:26:43 UTC --- Author: jason Date: Tue Mar 29 14:26:33 2011 New Revision: 171675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171675 Log: PR c++/48296 * decl.c (cp_finish_decl): Defer validation of constexpr member functions. * class.c (finalize_literal_type_property): Validate them here. * semantics.c (is_valid_constexpr_fn): Don't check completeness. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-memfn1.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/class.c branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48296] [C++0x] constexpr member function cannot use the class type it belongs as parameter type or return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48296 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:29:24 UTC --- Fixed for 4.6.1.
[Bug target/48336] New: Error in generation of ARM ldrd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48336 Summary: Error in generation of ARM ldrd instruction Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: revital.e...@linaro.org Host: arm-linux-gnueabi Target: arm-linux-gnueabi I get the follwoing error while building GCC trunk -r171652 on arm-linux-gnueabi the configuration is: ../gcc/configure --enable-checking --enable-languages=c,c++,lto,fortran --disable-bootstrap --with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpc=/opt/cfarm/mpc-0.8 --with-arch=armv7-a Entering directory `/home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/libiberty' ~/mainline/build/armv7l-unknown-linux-gnueabi/libiberty$ /home/revitale/mainline/build/./gcc/xgcc -B/home/revitale/mainline/build/./gcc/ -B/home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/bin/ -B/home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/lib/ -isystem /home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/include -isystem /home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/simple-object-elf.c -o simple-object-elf.o /tmp/ccQwihSs.s: Assembler messages: /tmp/ccQwihSs.s:945: Error: first destination register must be even -- `ldrd fp,[r6,#16]'
[Bug c++/48313] [C++0x] std::bind with template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48313 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:30:17 UTC --- Fixed for 4.6.1.
[Bug rtl-optimization/48334] [4.7 Regression] gcc.target/i386/pr39445.c FAILs with -fira-algorithm=priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48334 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2011-03-29 14:32:47 UTC --- It started with http://gcc.gnu.org/viewcvs?view=revisionrevision=171649
[Bug c++/48029] [4.5 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48029 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:33:06 UTC --- Fixed for 4.5.3.
[Bug rtl-optimization/48331] [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-03-29 14:35:34 UTC --- It started with http://gcc.gnu.org/viewcvs?view=revisionrevision=171649 I don't know what's the status of this allocator (how near is its end), nor if there are any targets that have to use it as CB's allocator doesn't work for them.
[Bug c++/48289] [4.5/4.6/4.7 regression] -pedantic breaks std::move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48289 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.5.3 |4.6.1 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:35:50 UTC --- Fixed for 4.6.1. This patch alone wasn't enough to fix the bug in 4.5, so I'm not going to try to fix it there.
[Bug bootstrap/48337] New: [4.7 regression] options.c doesn't compile on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48337 Summary: [4.7 regression] options.c doesn't compile on SPARC Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ebotca...@gcc.gnu.org, js...@gcc.gnu.org Host: sparc-sun-solaris2.* Target: sparc-sun-solaris2.* Build: sparc-sun-solaris2.* As already reported by Art Haas on the gcc list, SPARC bootstrap is broken since Joseph's recent sparc option patch: options.c:753:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:753:3: error: (near initialization for 'global_options_init.x_sparc_cpu_and_features') [-Werror=c++-compat] options.c:755:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:755:3: error: (near initialization for 'global_options_init.x_sparc_cpu') [-Werror=c++-compat] The lines in question are: 0, /* sparc_cpu_and_features */ 0, /* sparc_std_struct_return */ 0, /* sparc_cpu */ Since I could make no sense of the options machinery, I've added options.o-warn = -Wno-error to gcc/Makefile.in as a workaround.
[Bug c++/47504] some constexpr calculations erroneously overflow when using negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47504 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:37:13 UTC --- Fixed for 4.6.1.
[Bug c++/47570] one() = 0 isn't constexpr for unsigned int, yet == and is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47570 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:37:44 UTC --- Fixed for 4.6.1.
[Bug target/48338] New: [4.7 Regression] Glibc miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48338 Summary: [4.7 Regression] Glibc miscompiled Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, GCC 4.7.0 revision 171601 miscompiled glibc trunk. I got [hjl@gnu-6 glibc-32bit]$ GCONV_PATH=/export/build/gnu/glibc-32bit/build-i686-linux/iconvdata LC_ALL=C /export/build/gnu/glibc-32bit/build-i686-linux/elf/ld-linux.so.2 --library-path /export/build/gnu/glibc-32bit/build-i686-linux:/export/build/gnu/glibc-32bit/build-i686-linux/math:/export/build/gnu/glibc-32bit/build-i686-linux/elf:/export/build/gnu/glibc-32bit/build-i686-linux/dlfcn:/export/build/gnu/glibc-32bit/build-i686-linux/nss:/export/build/gnu/glibc-32bit/build-i686-linux/nis:/export/build/gnu/glibc-32bit/build-i686-linux/rt:/export/build/gnu/glibc-32bit/build-i686-linux/resolv:/export/build/gnu/glibc-32bit/build-i686-linux/crypt:/export/build/gnu/glibc-32bit/build-i686-linux/nptl /export/build/gnu/glibc-32bit/build-i686-linux/nptl/tst-cancel17 --direct going to cancel tf in-time Segmentation fault [hjl@gnu-6 glibc-32bit]$ GCONV_PATH=/export/build/gnu/glibc-32bit/build-i686-linux/iconvdata LC_ALL=C /export/build/gnu/glibc-32bit/build-i686-linux/elf/ld-linux.so.2 --library-path /export/build/gnu/glibc-32bit/build-i686-linux:/export/build/gnu/glibc-32bit/build-i686-linux/math:/export/build/gnu/glibc-32bit/build-i686-linux/elf:/export/build/gnu/glibc-32bit/build-i686-linux/dlfcn:/export/build/gnu/glibc-32bit/build-i686-linux/nss:/export/build/gnu/glibc-32bit/build-i686-linux/nis:/export/build/gnu/glibc-32bit/build-i686-linux/rt:/export/build/gnu/glibc-32bit/build-i686-linux/resolv:/export/build/gnu/glibc-32bit/build-i686-linux/crypt:/export/build/gnu/glibc-32bit/build-i686-linux/nptl /export/build/gnu/glibc-32bit/build-i686-linux/nptl/tst-cancelx17 --direct going to cancel tf in-time Segmentation fault [hjl@gnu-6 glibc-32bit]$
[Bug c++/47999] [C++0x] auto type deduction works incorrectly in a function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47999 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.1 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 14:38:30 UTC --- Fixed for 4.6.1.
[Bug bootstrap/48337] [4.7 regression] options.c doesn't compile on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48337 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-03-29 14:51:01 UTC --- On Tue, 29 Mar 2011, ro at gcc dot gnu.org wrote: options.c:753:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:753:3: error: (near initialization for 'global_options_init.x_sparc_cpu_and_features') [-Werror=c++-compat] options.c:755:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:755:3: error: (near initialization for 'global_options_init.x_sparc_cpu') [-Werror=c++-compat] Try adding Init(PROCESSOR_V7) to the lines in sparc.opt defining sparc_cpu and sparc_cpu_and_features. It appears an explicit initializer of 0 for these enums isn't being accepted even where an implicit 0 from the lack of initializer (when a variable rather than a field was used) was accepted.
[Bug ada/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-29
14:55:51 UTC ---
And:
/* { dg-do compile } */
/* { dg-options -O2 -fno-tree-sra } */
typedef __float128 T __attribute__((__may_alias__));
struct S
{
_Complex double d __attribute__((aligned (16)));
};
void bar (struct S);
void
foo (T x)
{
struct S s;
*(T *) s.d = x;
__real__ s.d *= 7.0;
bar (s);
}
seems to be quietly miscompiled (instead of storing the 128 bit __float128 over
both real and imaginary parts (it is __may_alias__, so it should be fine
aliasing-wise) it converts the __float128 to double and stores just over real
part. In 4.5 s.d was present and s was addressable, but ADDR_EXPR in MEM_EXPR
is ignored and thus in 4.6 we happily put s into (concat:DC (reg:DF ...)
(reg:DF ...)).
[Bug ada/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-29
14:59:50 UTC ---
Yet another testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fno-tree-sra } */
typedef long long T __attribute__((__may_alias__));
struct S
{
_Complex float d __attribute__((aligned (8)));
};
void bar (struct S);
void
foo (T x)
{
struct S s;
*(T *) s.d = x;
__real__ s.d *= 7.0;
bar (s);
}
which ICEs too. BTW, in the original testcase from
https://bugzilla.redhat.com/show_bug.cgi?id=691133 -fno-tree-sra wasn't used,
just delta did a poor job on it even after many hours (got it to 32KB), so I've
decided to try to write a testcase myself and for that I needed -fno-tree-sra.
[Bug rtl-optimization/48331] [4.7 Regression] gcc.c-torture/execute/built-in-setjmp.c FAILs with -O -fira-algorithm=priority -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48331 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2011-03-29 15:07:46 UTC --- (In reply to comment #2) It started with http://gcc.gnu.org/viewcvs?view=revisionrevision=171649 I don't know what's the status of this allocator (how near is its end), nor if there are any targets that have to use it as CB's allocator doesn't work for them. Thanks for reporting. The patch is to permit to use CB allocator for ports which had to use the priority allocator. The performance result of the modified CB allocator is expected to be better than the usage of priority one for the ports. In perspective, priority coloring will be removed. I'd recommend maintainers of the ports using priority coloring to check CB coloring and plan to switch to it by default. The changes in IRA are big and complex and probably will result some port problems for some time because RA is the most machine-dependent part of the compiler. Therefore the patch was committed to the trunk on the beginning of stage1 to have more time to fix all the problems. Meanwhile, I am going to work and try to fix this PR.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-29 15:12:00 UTC --- Run make check in boehm-gc/testsuite instead. Better yet, just build the failing test once and manually rerun it in a loop with LD_LIBRARY_PATH or equivalent set. I have run the following script #!/bin/sh i=0 thread_leak_test while [ $? == 0 ] do i=`expr $i + 1` echo $i thread_leak_test done and saw it fail for i between 8 and 153. The symptom is always Leaked composite object at start: 0x1000c0f?0, appr. length: 48 and the test starts to consume 100% of the cpu untill I stop it. Sampling the test gives Sampling process 85239 for 3 seconds with 1 millisecond of run time between samples Sampling completed, processing symbols... Analysis of sampling thread_leak_test (pid 85239) every 1 millisecond Process: thread_leak_test [85239] Path: /opt/gcc/build_w/x86_64-apple-darwin10.7.0/boehm-gc/testsuite/.libs/thread_leak_test Load Address:0x1 Identifier: thread_leak_test Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [191] Date/Time: 2011-03-29 16:31:27.577 +0200 OS Version: Mac OS X 10.6.7 (10J869) Report Version: 6 Call graph: 2682 Thread_17437964 DispatchQueue_1: com.apple.main-thread (serial) 2682 GC_obj_kinds 2682 GC_try_to_collect_inner 2682 GC_finish_collection 2682 GC_set_fl_marks Total number in stack (recursive counted multiple, when =5): Sort by top of stack, same collapsed (when = 5): GC_set_fl_marks2682 Binary Images: 0x1 -0x10ff7 +thread_leak_test ??? (???) C97DEDBE-04FF-EFEE-1C1B-68710038E8C2 /opt/gcc/build_w/x86_64-apple-darwin10.7.0/boehm-gc/testsuite/.libs/thread_leak_test 0x13000 -0x10001dff7 +libgcjgc.1.dylib 2.2.0 (compatibility 2.0.0) 7CAAF920-9603-D889-1D10-4250288EE1C8 /opt/gcc/build_w/x86_64-apple-darwin10.7.0/boehm-gc/.libs/libgcjgc.1.dylib 0x10004b000 -0x10005ffe7 +libgcc_s.1.dylib ??? (???) 559F9DAA-51E8-95F3-B24B-9DDA7CCC1341 /opt/gcc/gcc4.7w/lib/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc3bdef dyld 132.1 (???) B536F2F1-9DF1-3B6C-1C2C-9075EA219A06 /usr/lib/dyld 0x7fff80415000 - 0x7fff80419ff7 libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) 95718673-FEEE-B6ED-B127-BCDBDB60D4E5 /usr/lib/system/libmathCommon.A.dylib 0x7fff80fc4000 - 0x7fff81185fff libSystem.B.dylib 125.2.10 (compatibility 1.0.0) 9BAEB2F2-B485-6349-E1AB-637FE12EE770 /usr/lib/libSystem.B.dylib 0x7fe0 - 0x7fe01fff libSystem.B.dylib ??? (???) 9BAEB2F2-B485-6349-E1AB-637FE12EE770 /usr/lib/libSystem.B.dylib Sample analysis of process 85239 written to file /dev/stdout Note that I have applied the patch in http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01903.html without any change.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.29 15:23:12
CC||ibolton at gcc dot gnu.org
Known to work||4.4.5, 4.5.2
Ever Confirmed|0 |1
Known to fail||4.6.0, 4.7.0
--- Comment #6 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-29 15:23:12
UTC ---
Using trunk, r171422, I have compiled the reduced test case as follows:
arm-none-linux-gnueabi-gcc -fPIC -Os -c pr48308.c -mcpu=arm9tdmi -marm
pr48308.s: Assembler messages:
pr48308.s:97: Error: can't resolve `.LC4' {.rodata.str1.1 section} - `.LPIC4'
{*UND* section}
With --save-temps, you can see the missing .LPIC4 in the .s.
This is therefore confirmed in trunk as well.
FYI: the problem doesn't happen with -mthumb.
[Bug debug/47471] [4.6/4.7 Regression] stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
--- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2011-03-29
15:24:07 UTC ---
I believe the issue is that for that source code, GCC emits two
identical .loc asm directives for line 3. In theory I don't thing
doing that would be wrong.
But in practise the second .loc directive triggers a special opcode in
the generated line program that increments the line with an increment
of zero; it also increments the current program address with a
increment of zero. And that happens before the first line that
doesn't belong to the prologue.
That seems to break GDB's heuristic, and is also a bit of bloat.
The patch below avoids emitting two identical consecutive line number
debug information and seems to fix the issue for me. I am currently
regression-testing it.
From eb1450a263a4e50b43132ef9b914f49a971c8e9d Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Tue, 29 Mar 2011 16:56:20 +0200
Subject: [PATCH] PR debug/47471
gcc/
* dwarf2out.c (dwarf2out_source_line): Avoid emitting two
identical contiguous .loc asm directive.
gcc/testsuite/
* gcc.dg/debug/dwarf2/line-prog-1.c: New test.
---
gcc/dwarf2out.c | 33 +++---
gcc/testsuite/gcc.dg/debug/dwarf2/line-prog-1.c | 25 +
2 files changed, 47 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/line-prog-1.c
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 7803ab7..b350f43 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -22068,6 +22068,8 @@ dwarf2out_source_line (unsigned int line, const char
*filename,
line != 0)
{
int file_num = maybe_emit_file (lookup_filename (filename));
+ static int prev_file_num;
+ static unsigned int prev_line;
switch_to_section (current_function_section ());
@@ -22078,19 +22080,28 @@ dwarf2out_source_line (unsigned int line, const char
*filename,
if (DWARF2_ASM_LINE_DEBUG_INFO)
{
- /* Emit the .loc directive understood by GNU as. */
- fprintf (asm_out_file, \t.loc %d %d 0, file_num, line);
- if (is_stmt != last_is_stmt)
+ static int prev_file_num;
+ static unsigned int prev_line;
+ if (prev_file_num != file_num
+ || prev_line != line)
{
- fprintf (asm_out_file, is_stmt %d, is_stmt ? 1 : 0);
- last_is_stmt = is_stmt;
-}
- if (SUPPORTS_DISCRIMINATOR discriminator != 0)
-fprintf (asm_out_file, discriminator %d, discriminator);
- fputc ('\n', asm_out_file);
+ /* Emit the .loc directive understood by GNU as. */
+ fprintf (asm_out_file, \t.loc %d %d 0, file_num, line);
+ if (is_stmt != last_is_stmt)
+{
+ fprintf (asm_out_file, is_stmt %d, is_stmt ? 1 : 0);
+ last_is_stmt = is_stmt;
+}
+ if (SUPPORTS_DISCRIMINATOR discriminator != 0)
+fprintf (asm_out_file, discriminator %d, discriminator);
+ fputc ('\n', asm_out_file);
+
+ /* Indicate that line number info exists. */
+ line_info_table_in_use++;
- /* Indicate that line number info exists. */
- line_info_table_in_use++;
+ prev_file_num = file_num;
+ prev_line = line;
+}
}
else if (function_section (current_function_decl) != text_section)
{
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/line-prog-1.c
b/gcc/testsuite/gcc.dg/debug/dwarf2/line-prog-1.c
new file mode 100644
index 000..63637dc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/line-prog-1.c
@@ -0,0 +1,25 @@
+/*
+ Origin: PR debug/47471
+ { dg-options -g -dA }
+ */
+
+int v;
+void f (int i, ...)
+{
+ v++;
+}
+
+int
+main (void)
+{
+ f (1);
+ return 0;
+}
+
+/* We want to have only one .loc directive that points to the opening
+ curly bracket of the definition of function f, at line 8. */
+
+/*
+ { dg-final { scan-assembler-times \.loc 1 8 0 1 } }
+
+ */
--
1.7.3.4
[Bug bootstrap/48337] [4.7 regression] options.c doesn't compile on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48337 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-29 15:43:39 UTC --- Try adding Init(PROCESSOR_V7) to the lines in sparc.opt defining sparc_cpu and sparc_cpu_and_features. It appears an explicit initializer of 0 for these enums isn't being accepted even where an implicit 0 from the lack of initializer (when a variable rather than a field was used) was accepted. That did the trick, together with a similar change in sparc.c. I'll submit the patch shortly. Thanks. Rainer
[Bug target/48336] Error in generation of ARM ldrd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48336 --- Comment #1 from revital.eres at linaro dot org 2011-03-29 15:43:41 UTC --- Created attachment 23803 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23803 A testcase based on simple-object-elf.c Here is the command line for running: /home/revitale/mainline/build/./gcc/xgcc -B/home/revitale/mainline/build/./gcc/ -B/home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/bin/ -B/home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/lib/ -isystem /home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/include -isystem /home/revitale/mainline/build/armv7l-unknown-linux-gnueabi/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic new_bad.c
[Bug bootstrap/48337] [4.7 regression] options.c doesn't compile on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48337 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.29 15:47:51 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-03-29 15:47:51 UTC --- Patch submitted.
[Bug middle-end/48335] [4.6/4.7 Regression] ICE in convert_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48335 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.29 15:50:00 Component|ada |middle-end AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/48327] [4.7 Regression] Bootstrap comparison failure with ada since r171622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48327 --- Comment #3 from Jeffrey A. Law law at redhat dot com 2011-03-29 15:59:11 UTC --- It's a problem with updating the SSA graph in a relatively uncommon case. We're failing to update a PHI argument correctly. I'm still thinking about how best to address the problem.
[Bug c++/48166] [4.6/4.7 Regression] ICE on static member function with invalid type qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48166 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 16:07:20 UTC --- Author: jason Date: Tue Mar 29 16:07:15 2011 New Revision: 171679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171679 Log: PR c++/48166 * decl.c (revert_static_member_fn): Strip function-cv-quals. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/parse/memfnquals1.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/48166] [4.6/4.7 Regression] ICE on static member function with invalid type qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48166 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 16:08:33 UTC --- Fixed for 4.6.1.
[Bug c++/48319] [4.6/4.7 Regression] [C++0x] Segmentation fault in instantiation of std::is_constructibleint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48319 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.03.29 16:09:36 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-03-29 16:09:36 UTC --- Mine.
[Bug target/48325] ICE in reload_cse_simplify_operands, at postreload.c:403 with neon optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48325
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.29 16:23:26
CC||ibolton at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.5.3, 4.7.0
--- Comment #2 from Ian Bolton ibolton at gcc dot gnu.org 2011-03-29 16:23:26
UTC ---
I get the same thing when I use r171282 of FSF 4.5 branch.
arm-none-linux-gnueabi-gcc pr48325.c -mfloat-abi=softfp -mfpu=neon -O1
pr48325.c: In function 'test':
pr48325.c:19:1: error: insn does not satisfy its constraints:
(insn 40 38 26 2
/work/ianbol01/cross-build/gcc45-r171282-thumb/arm-none-linux-gnueabi/tools/lib/gcc/arm-none-linux-gnueabi/4.5.3/include/arm_neon.h:10277
(set (reg:OI 95 d16 [orig:152 __b ] [152])
(mem/s/c:OI (pre_dec:SI (reg/f:SI 3 r3 [151])) [0 __b+0 S32 A64])) 731
{*neon_movoi} (expr_list:REG_INC (reg/f:SI 3 r3 [151])
(nil)))
pr48325.c:19:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Here is the command-line just for cc1:
cc1 -quiet pr48325.c -mfloat-abi=softfp -mfpu=neon -marm -mcpu=cortex-a9 -O1
Doesn't work for thumb either.
It also fails on trunk.
There are two other bugs in flight that manifest in
reload_cse_simplify_operands: PR48250 (broke on trunk for EABI, works on 4.5
for EABI) and PR42949 (works on EABI for trunk and gcc4.5, broke for OABI).
I do not know if they are duplicates of each other, or if there are two or more
separate bugs causing this.
[Bug web/48339] New: Current release series version is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48339 Summary: Current release series version is incorrect Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: fl...@flast.jp Current release series version should be GCC 4.6.0. But it shows GCC 4.6.1 in top page.
[Bug c++/42322] 'foo is not a template function' error message should include signature of function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42322 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:36:49 UTC --- closing due to lack of response if you reopen it please provide code demonstrating the problem
[Bug c++/43114] GCC 4.4.1 problems with include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43114 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:37:30 UTC --- closing due to lack of response if you reopen it please provide the code demonstrating the problem
[Bug c++/46069] [C++0x] ill-formed use of decltype causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46069 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:37:55 UTC --- closing due to lack of response if you reopen it please provide the code demonstrating the problem
[Bug c++/47734] no comparisons like X=Y=Z do not have their mathematical meaning warning in c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47734 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:38:32 UTC --- fixed in current releases
[Bug libstdc++/47859] Makefile: Input/output error. Stop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47859 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:38:51 UTC --- closing due to lack of feedback
Build glibc 2.13 errno.c:34:3: internal compiler error: in do_assemble_alias, at varasm.c:5438
# binutils 2.21 # kernel headers 2.6.38.2 # libc headers 2.13 # gcc stage1 (c-only) 4.6.0 # libc libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes gmp 5.0.1 mpfr 3.0.0 mpc 0.9 i686-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=i686-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/tools/usr/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6.0/configure --srcdir=/tools/gcc-4.6.0 --prefix=/usr --target=i686-pc-linux-gnu --disable-multilib --disable-bootstrap --disable-shared --disable-threads --enable-tls=no --disable-libssp --disable-libquadmath --disable-libgomp --disable-libmudflap --disable-decimal-float --enable-languages=c --without-ppl --without-cloog --with-build-sysroot=/tools --with-sysroot=/tools --with-build-time-tools=/tools/usr/bin --with-gmp=/tools/usr --with-mpfr=/tools/usr --with-mpc=/tools/usr --with-system-zlib LDFLAGS='-L/tools/lib -L/tools/usr/lib' AR=/tools/usr/i686-pc-linux-gnu/bin/ar AS=/tools/usr/i686-pc-linux-gnu/bin/as LD=/tools/usr/i686-pc-linux-gnu/bin/ld NM=/tools/usr/i686-pc-linux-gnu/bin/nm RANLIB=/tools/usr/i686-pc-linux-gnu/bin/ranlib STRIP=/tools/usr/i686-pc-linux-gnu/bin/strip OBJCOPY=/tools/usr/i686-pc-linux-gnu/bin/objcopy OBJDUMP=/tools/usr/i686-pc-linux-gnu/bin/objdump Thread model: single gcc version 4.6.0 (GCC) GNU assembler version 2.21 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.21 glibc/csu/errno.o errno.c:34:3: internal compiler error: in do_assemble_alias, at varasm.c:5438 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/45460] Regression ICE when compiling Scribus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45460 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:44:53 UTC --- (In reply to comment #2) Please provide a testcase. closing due to lack of response if you reopen it please provide the code demonstrating the problem
[Bug c++/47964] logical || returns false result, optimization level 02 or 03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47964 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:51:47 UTC --- Is this still present on the 4.5 branch, or later releases? (In reply to comment #4) (In reply to comment #1) You need to provide self-contained testcase, this is not self-contained. Thank you for running your simple experiment. Unfortunately, all my attempts to create a simple self-contained test have failed. It doesn't necessarily have to be simple (although that's preferable) but without a testcase of some kind this will not get looked at.
[Bug c++/47996] Bug in atomicity.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47996 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 16:53:04 UTC --- closing due to lack of response if you reopen please provide the information requested
[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546 --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-29 16:57:17 UTC --- AFAICT this pr seems fixed by revision 171654 (pr48095).
[Bug c++/42022] takes segmentation fault at proxy file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42022 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 17:00:47 UTC --- (In reply to comment #2) This is focal to what development? I can't get any compiler to get it on a 64 bit Intel/AMD how would Linux compile a variant when it can't do a fairly stable release? If the code seg faults anywhere in code execution why blame the compiler with a code dump? How can I upgrade if the compiler was broke? I don't understand your questions, but if you can't test a current release of GCC then please report the bug to Mandriva. In any case, noone can look at the problem without a testcase and the other information listed at http://gcc.gnu.org/bugs/ so I'm closing this report. If you reopen this report please provide the required information.
[Bug debug/48315] ICE in mem_loc_descriptor, at dwarf2out.c:13899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-03-29 17:12:27 UTC --- Might be related to PR48203. Could you post a pre-processed file here ?
[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546 --- Comment #26 from janus at gcc dot gnu.org 2011-03-29 17:12:54 UTC --- (In reply to comment #25) AFAICT this pr seems fixed by revision 171654 (pr48095). Oh, wow. That's kind of unexpected. But nice :)
[Bug c++/36694] g++-4.2 rejects code, that other versions of gcc accept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36694 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 17:17:57 UTC --- GCC 4.2 is no longer maintained, please reopen if you can reproduce this with a current release (4.3 or later)
[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45918 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 17:23:48 UTC --- works for me, just use -Wtype-limits or -Wextra
[Bug c++/45509] program abort after compiled with gcc-4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45509 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-29 17:24:29 UTC --- Please provide the information requested at http://gcc.gnu.org/bugs/
[Bug libstdc++/48340] New: Several wchar_t tests FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48340
Summary: Several wchar_t tests FAIL on IRIX 6.5
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
Of the remaining libstdc++ failures on IRIX 6.5, most are related to wchar_t
tests, as can be seen at
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg02830.html
An example is
FAIL: 21_strings/basic_string/inserters_extractors/wchar_t/1.cc execution test
Assertion failed: EX, file
/vol/gcc/src/hg/gcc-4.6-branch/local/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/1.cc,
line 52
#6 0x1000308c in test01 () at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/21_strings/basic_string/inserters_extractors/wchar_t/1.cc:52
Running the testcase under gdb, I find:
(gdb) p str10
$1 = {static npos = 4294967295, _M_dataplus = {std::allocatorwchar_t =
{__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields},
_M_p = 0x1000e2f4
L\000\000\000s\000\000\000a\000\000\000i\000\000\000l\000\000\000i\000\000\000n\000\000\000g\000\000\000
\000\000\000g\000\000\000r\000\000\000a\000\000\000n\000\000\000d\000\000\000
\000\000\000t\000\000\000r\000\000\000a\000\000\000v\000\000\000e\000\000\000r\000\000\000s\000\000\000e\000\000\000
\000\000\000b\000\000\000a\000\000\000y\000\000\000\n\000\000\000\t\000\000\000\t\000\000\000\t\000\000\000
\000\000\000 \000\000\000 \000\000\000
\000\000\000f\000\000\000r\000\000\000o\000\000\000m\000\000\000
\000\000\000E\000\000\000l\000\000\000k\000\000\000
\000\000\000R\000\000\000a\000\000\000p\000\000\000i\000\000\000d\000\000\000s\000\000\000
...}}
(gdb) p str02
$2 = {static npos = 4294967295, _M_dataplus = {std::allocatorwchar_t =
{__gnu_cxx::new_allocatorwchar_t = {No data fields}, No data fields},
_M_p = 0x1000e0f4
L\000\000\000s\000\000\000a\000\000\000i\000\000\000l\000\000\000i\000\000\000n\000\000\000g}}
I'll need guidance where to look further for the root cause of this.
[Bug debug/48315] ICE in mem_loc_descriptor, at dwarf2out.c:13899
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48315 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca 2011-03-29 17:26:17 UTC --- On Tue, 29 Mar 2011, ramana at gcc dot gnu.org wrote: Could you post a pre-processed file here ? Attached.
[Bug fortran/47546] [OOP] Internal error - free_pi_tree(): Unresolved fixup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47546 --- Comment #27 from janus at gcc dot gnu.org 2011-03-29 17:28:43 UTC --- (In reply to comment #25) AFAICT this pr seems fixed by revision 171654 (pr48095). I can confirm that comment #8 works with current trunk on x86_64-unknown-linux-gnu. However, I do not see how or why it is fixed. The only explanation I have is that it was a bug in module I/O, and the modified module format somehow fixes (or just hides) it. Rich, can you confirm that all test cases in this PR now work for you? Also, since PR 47601 may be related, can someone check if this is fixed too (on Darwin)?
