[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #7 from cnstar9988 at gmail dot com 2009-02-03 08:43 --- 4.3.3 on Linux has the same problem. Target Milestone: 4.3.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #5 from pault at gcc dot gnu dot org 2009-02-03 08:55 --- (In reply to comment #4) I would have said that the value of the integer component after the first assignment is, at best, ill-defined. If L_TO_T assigns a value to it, gfortran gives the same result as any other compiler. For what it's worth, the test case compiles successfully with a different compiler. The larger program compiles with several other compilers. And it compiles with gfortran too ;). Indeed, all this is so. Regardless of the legality of the testcase, this highlights that gfortran is being too conservative in its dependency analysis and is using a temporary in the WHERE assignements unnecessarily. There is an error of logic in gfc_dep_resolver that I haven't quite caught yet. It has all the hooks needed to detect that implicit and explicit full arrays are the same but it is not working (remove the rhs array reference from the first assignment and gfortran gets the right result). Cheers Paul PS I might as well take it! -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-01-18 20:40:05 |2009-02-03 08:55:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug tree-optimization/38964] TBAA side-effects of C++ new still missing
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-03 09:08 --- The testcase lays the way to proof that whatever PTA ends up putting in the ESCAPED solution (which includes all globals) TBAA disambiguation on these is invalid. This basically means that TBAA is nearly useless, as if PTA has more precise information we can as well use that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38964
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-03 09:17 ---
Yes, but as the store to y is via *x and x points to { ANYTHING } (via the
non-pointer (int ***)q) only (as x already includes ANYTHING we do not add
a for the second constraint), so for *x = i we fail to add a to y.
For reference, here are the constraints:
a = y
p_4 = ANYTHING
p_1 = p_4
p_1 = a
x_6 = *p_1
derefaddrtmp.9 = i
*x_6 = derefaddrtmp.9
y.0_7 = y
and the solutions:
a = { y }
y = same as y.0_7
p_4 = { ANYTHING }
p_1 = { ANYTHING a }
x_6 = { ANYTHING }
i = { }
derefaddrtmp.9 = { i }
y.0_7 = { }
while correct would be if everything would point to at least i (through
the effective *ANYTHING = i constraint)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:45 --- How is it now? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #10 from bonzini at gnu dot org 2009-02-03 09:47 --- Can you try the patch of PR38824? -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug middle-end/19988] [4.2/4.3/4.4 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #14 from bonzini at gnu dot org 2009-02-03 09:49 --- What about canonicalizing to a *positive* number? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug inline-asm/39059] [4.3/4.4 regression] ICE with fixed-point type in inline-asm
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-03 10:06 ---
Similarly
__typeof (0r)
foo (void)
{
return 0r;
}
ICEs on x86-64 and so does
_Fract foo (void)
{
return 0r;
}
(the last one just as error-recovery ICE). I'd say for
!targetm.fixed_point_supported_p () we should remove the loop hole that
fixed-point constants introduce fixed point types without any error, similarly
for C++ we should reject FIXED_CSTs, and to improve error-recovery, we
shouldn't used fixed point types after we've diagnosed we don't support them.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-02-03 10:06:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
[Bug rtl-optimization/39077] [4.3/4.4 Regression] GCSE-optimization causes enormous binary size increase (~20 times !)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-03 09:55 --- Created an attachment (id=17230) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17230action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
[Bug target/29207] gij bus errors on hppa-linux-gnu and alpha-linux-gnu
--- Comment #2 from ubizjak at gmail dot com 2009-02-03 10:52 --- libjava testsuite works OK on 4.3.4 branch for hppa-linux-gnu [1] and alpha [2]. The remaining java failures on alpha are due to testsuite problem (dg ?/ expect ?/tcl ?), described in PR 33263. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00244.html [2] http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00046.html Confirmed fixed on 4.3.4+, wontfix for 4.2. -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.3.4 Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29207
[Bug ada/36025] cpu_set_t not declared in OS_Interface compilation problem on alpha
--- Comment #6 from ubizjak at gmail dot com 2009-02-03 11:04 --- (In reply to comment #2) Note: ada on alpha bootstrap fine on trunk. And on 4.3 branch [1]: [1] http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00280.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|4.4.0 |4.4.0 4.3.3 Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36025
[Bug c++/36897] [4.2/4.3/4.4 Regression] ICE with function pointer template parameter
--- Comment #5 from bonzini at gnu dot org 2009-02-03 11:11 --- caused by r90059 (convert_nontype_argument rewrite). Giovanni, do you have time to see if the patch I made makes sense? -- bonzini at gnu dot org changed: What|Removed |Added CC||giovannibajo at gcc dot gnu ||dot org, bonzini at gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #12 from bonzini at gnu dot org 2009-02-03 11:17 --- What if we forbid altogether memory operands and we *synthesize* them with a peephole2? Anyway, it seems safe to me to declare this a dup of PR38824? -- bonzini at gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2009-02-03 10:36:46 |2009-02-03 11:17:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug libmudflap/28077] [4.2/4.3 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #6 from ubizjak at gmail dot com 2009-02-03 11:18 --- Can someone check if this still fails on latest 4.3 branch? 4.4 works OK. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #7 from ubizjak at gmail dot com 2009-02-03 11:10 --- Not a GCC bug. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Comment #8 from ubizjak at gmail dot com 2009-02-03 12:24 --- Current trunk produces: f: .frame $30,0,$26,0 .prologue 0 and $16,4,$3 lda $6,64($31) bis $31,$31,$2 cmpult $31,$3,$3 beq $3,$L3 stl $31,0($16) lda $6,63($31) lda $2,1($31) $L3: lda $8,64($31) subq $8,$3,$8 zapnot $8,15,$8 srl $8,1,$5 addl $5,$5,$7 beq $7,$L4 s4addq $3,$16,$3 zapnot $5,15,$5 bis $31,$31,$1 .align 4 $L5: addl $1,1,$1 stq $31,0($3) lda $3,8($3) zapnot $1,15,$4 cmpult $4,$5,$4 bne $4,$L5 zapnot $7,15,$1 addl $2,$7,$2 subl $6,$7,$6 cmpeq $8,$1,$8 bne $8,$L9 $L4: lda $4,-1($6) s4addq $2,$16,$2 bis $31,$31,$1 zapnot $4,15,$4 s4addq $4,4,$4 .align 4 $L7: lda $1,4($1) stl $31,0($2) lda $2,4($2) cmpeq $1,$4,$3 beq $3,$L7 $L9: ret $31,($26),1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Comment #9 from ubizjak at gmail dot com 2009-02-03 12:25 --- Together with the patch for PR 8603: f: .frame $30,0,$26,0 .prologue 0 and $16,4,$4 lda $1,64($31) bis $31,$31,$2 cmpult $31,$4,$4 beq $4,$L3 stl $31,0($16) lda $1,63($31) lda $2,1($31) $L3: lda $8,64($31) subl $8,$4,$8 zapnot $8,15,$8 srl $8,1,$6 addl $6,$6,$7 beq $7,$L4 s4addq $4,$16,$4 zapnot $6,15,$6 bis $31,$31,$3 .align 4 $L5: addl $3,1,$3 stq $31,0($4) lda $4,8($4) zapnot $3,15,$5 cmpult $5,$6,$5 bne $5,$L5 zapnot $7,15,$3 addl $2,$7,$2 subl $1,$7,$1 cmpeq $8,$3,$8 bne $8,$L9 $L4: s4addq $2,$16,$2 .align 4 $L7: stl $31,0($2) subl $1,1,$1 lda $2,4($2) bne $1,$L7 $L9: ret $31,($26),1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha
--- Comment #10 from ubizjak at gmail dot com 2009-02-03 12:31 ---
By changing the test to:
--cut here--
unsigned int p[64];
int f(void) {
for (int i = 0; i 64; ++i)
p[i] = 0;
}
--cut here--
gcc -O2 -ftree-vectorize -mcpu=ev67 -std=c99
f:
.frame $30,0,$26,0
ldgp $29,0($27) # 63 *prologue_ldgp_1[length = 4]
$f..ng:
.prologue 1
lda $1,p # 37 *movdi_fix/4[length = 4]
lda $3,256($1) # 38 *adddi_internal/2 [length = 4]
.align 4
$L2:
stq $31,0($1)# 40 *movv2si_fix/4 [length = 4]
lda $1,8($1) # 41 *adddi_internal/2 [length = 4]
cmpeq $1,$3,$2 # 43 *setcc_internal [length = 4]
beq $2,$L2 # 44 *bcc_normal [length = 4]
ret $31,($26),1 # 67 *return_internal[length = 4]
.end f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #18 from paolo dot carlini at oracle dot com 2009-02-03 13:16 --- (In reply to comment #17) + if (TREE_CODE (t1) == TYPENAME_TYPE) +t1 = resolve_typename_type (t2, /*only_current_p=*/true); But I suppose you want consistently t1 here ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #11 from ubizjak at gmail dot com 2009-02-03 10:36 --- (In reply to comment #10) Can you try the patch of PR38824? I have tried with a similar peephole2 recognizer. The problem is, that there is no spare x register to allocate as a temporary, so peephole2 is ineffective in this particular case. -- ubizjak at gmail dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2009-02-03 10:36:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/38991] [4.3/4.4 Regression] SH: ICE in extract_insn at recog.c:1990
--- Comment #2 from kkojima at gcc dot gnu dot org 2009-02-03 13:31 --- It seems that the move insn in problem is generated when reloading but has no insn definition matched. The patch --- ORIG/trunk/gcc/config/sh/predicates.md 2008-04-05 09:19:14.0 +0900 +++ INTEST/trunk/gcc/config/sh/predicates.md2009-02-03 14:40:07.0 +0900 @@ -392,12 +392,6 @@ return 0; } - if ((mode == QImode || mode == HImode) - (GET_CODE (op) == SUBREG - GET_CODE (XEXP (op, 0)) == REG - system_reg_operand (XEXP (op, 0), mode))) -return 0; - if (TARGET_SHMEDIA (GET_CODE (op) == PARALLEL || GET_CODE (op) == CONST_VECTOR) sh_rep_vec (op, mode)) will workaround this issue, though it may be slightly invasive and a thorough test will be needed. BTW, the asm statement in the test case looks a bit worse than __asm__( swap.b %1, %0; : =r (__reg) : r ((unsigned short) t)); which give a chance for compiler to allocate better registers in general. The above asm can avoid this PR too. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.3.3 4.4.0 Known to work||4.2.4 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-02-03 13:31:38 date|| Summary|ICE in extract_insn at |[4.3/4.4 Regression] SH: ICE |recog.c:1990|in extract_insn at ||recog.c:1990 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38991
[Bug tree-optimization/38049] points-to results imprecise
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-03 10:20 --- Subject: Bug 38049 Author: rguenth Date: Tue Feb 3 10:20:20 2009 New Revision: 143890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143890 Log: 2009-02-03 Richard Guenther rguent...@suse.de PR tree-optimization/38049 * tree-ssa-structalias.c (struct constraint_expr): Make offset signed. (UNKNOWN_OFFSET): Define special value. (dump_constraint): Dump UNKNOWN_OFFSET as UNKNOWN. (solution_set_expand): New helper function split out from ... (do_sd_constraint): ... here. (solution_set_add): Handle UNKNOWN_OFFSET. Handle negative offsets. (do_ds_constraint): Likewise. (do_sd_constraint): Likewise. Do not special-case ESCAPED = *ESCAPED and CALLUSED = *CALLUSED. (set_union_with_increment): Make inc argument signed. (type_safe): Remove. (get_constraint_for_ptr_offset): Handle unknown and negative constant offsets. (first_vi_for_offset): Handle offsets before start. Bail out early for offsets beyond the variable extent. (first_or_preceding_vi_for_offset): New function. (init_base_vars): Add ESCAPED = ESCAPED + UNKNOWN_OFFSET constraint. Together with ESCAPED = *ESCAPED this properly computes reachability. * gcc.dg/torture/pta-ptrarith-3.c: New testcase. * gcc.dg/tree-ssa/pta-ptrarith-1.c: Likewise. * gcc.dg/tree-ssa/pta-ptrarith-2.c: Likewise. * gcc.dg/vect/no-vfa-vect-43.c: Adjust. Added: branches/alias-improvements/gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-1.c branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pta-ptrarith-2.c Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/testsuite/gcc.dg/vect/no-vfa-vect-43.c branches/alias-improvements/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38049
[Bug target/37437] [4.4 regression] speed regression
--- Comment #6 from bonzini at gnu dot org 2009-02-03 13:58 --- News? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
[Bug rtl-optimization/38373] 32-bit Vortex degradation on PPC due to bad RTL aliasing
--- Comment #2 from bonzini at gnu dot org 2009-02-03 14:00 --- Is this a regression? I don't see anything in the patches or in their description that would prevent a backport to 4.4. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38373
[Bug middle-end/20548] [4.3/4.4 regression] ACATS c52103x c52104x c52104y segfault
--- Comment #34 from bonzini at gnu dot org 2009-02-03 14:02 --- Is this still a 4.4 regression? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20548
[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for struct assignment
--- Comment #13 from bonzini at gnu dot org 2009-02-03 14:23 --- Adjusting subject, the testcase from comment #2 still produces suboptimal code. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Last reconfirmed|2008-08-15 21:26:55 |2009-02-03 14:23:13 date|| Summary|[4.3/4.4 Regression] code |[4.3/4.4 Regression] code |size increase for bit-fields|size increase for struct |assignment |assignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37135
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #6 from rguenther at suse dot de 2009-02-03 14:24 --- Subject: Re: PTA constraint processing for *x = y is wrong On Tue, 3 Feb 2009, dberlin at dberlin dot org wrote: Subject: Re: PTA constraint processing for *x = y is wrong There used to be a *ANYTHING = ANYTHING constraint + ANYTHING containing all the variables pointing to ANYTHING that would have taken care of this. You certainly don't want to dynamically add all variables at solving time yourself, since that can't be optimized. This is the reason it works for ESCAPED, there we have an *ESCAPED = ESCAPED constraint. It doesn't work for CALLUSED though, I have a simple fix (CALLUSED is not big usually, so just not using it as a placeholder fixes the issue here). For the ANYTHING problem I have just dealt with it in do_ds_constraint (I'll post an updated patch soon after testing finished). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug middle-end/37135] [4.3/4.4 Regression] code size increase for struct assignment
--- Comment #14 from bonzini at gnu dot org 2009-02-03 14:30 --- what remains is a dup of 22141. *** This bug has been marked as a duplicate of 22141 *** -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37135
[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures
--- Comment #16 from bonzini at gnu dot org 2009-02-03 14:30 --- *** Bug 37135 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||etienne_lorrain at yahoo dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition
-- bonzini at gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084
[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark
--- Comment #11 from vmakarov at redhat dot com 2009-02-03 14:48 --- I have a patch (a new spill heuristic) which makes facerec even faster with IRA on power6. The patch is in http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00368.html Unfortunately the new spill heuristic results in worse SPECINT2000 scores for x86, x86_64. So I did not committed the patch. Facerec has one very hot (80%) function localmove::graphRoutines.f90 and there is only one hot loop in the function. Although the loop is pretty big because of inlining TopCostFct. The loop contains a few if-statements and several big switch-statements. But only a small part of the loop body is hot. Static branch prediction makes very inaccurate results in this case and the old RA accidentally generates a better code than IRA. This is classical example of heuristic approach drawback. You never get best code using one heuristic for all programs. Sometimes the old RA will generate better code especially when the static branch probability prediction is bad. What are goal should be is to achieve better or not worse code in average, i.e. for some credible benchmark like SPECFP2000 and IRA is successful in this. I am still working on some better spill heuristics. Classical graph coloring spill heuristics are bad and IMHO they should be based on register pressure not on number of allocnos conflicting with allocno being spilled. I don't think the problem will be solved for gcc4.4 but it might be solved for gcc 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark
--- Comment #12 from bonzini at gnu dot org 2009-02-03 14:56 --- Maybe we can approach the problem from the other side, for example marking I/O functions as cold, or marking I/O functions as cold so that PRED_FLAG_FIRST_MATCH hits in predict.def? -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2009-02-03 14:56:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug rtl-optimization/37534] [4.4 Regression] IRA causes 17% degradation in 187.facerec benchmark
-- bonzini at gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|2009-02-03 14:56:47 |2009-02-03 14:57:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37534
[Bug c/39085] New: Floating point errors on Arm9 processor
On an Arm9 processor running Debian the following program gives the results
indicated...
#include stdio.h
#include stdlib.h
#include math.h
int main()
{
double in, out;
in = 2.0;
out = sqrt(in);
printf(%f\n, out); // 2.
printf(%f\n, sqrt(in)); // 1.414214
printf(%f\n, sqrt(2.0)); // 1.414214
return 0;
}
It works for most values but some obvious ones, all of which seem to be powers
of two, fail though not all powers of two.
This also seems to affect other floating point operations.
--
Summary: Floating point errors on Arm9 processor
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mp2 at ladybridge dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39085
[Bug target/37437] [4.4 regression] speed regression
--- Comment #7 from vmakarov at redhat dot com 2009-02-03 15:06 --- I don't see anymore code difference (only a bit different hard registers are used) on mentioned functions for code generated with the old RA and IRA. Probably it was fixed with a fix in regmove which was submitted as a part of patch removing the old RA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
[Bug debug/39086] New: Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
When compiling test 27_io/basic_istream/requirements/explicit_instantiation.cc from the libstc++ testsuite and adding the -fno-tree-sra flag, I get the following error: -- u...@host:~/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/testsuite$ $HOME/gcc/svn/obj/./gcc/g++ -shared-libgcc -B$HOME/gcc/svn/obj/./gcc -nostdinc++ -L$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/src -L$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B$HOME/gcc/inst/svn//i686-pc-linux-gnu/bin/ -B$HOME/gcc/inst/svn//i686-pc-linux-gnu/lib/ -isystem $HOME/gcc/inst/svn//i686-pc-linux-gnu/include -isystem $HOME/gcc/inst/svn//i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -g -O2 -D_GNU_SOURCE -DLOCALEDIR=. -nostdinc++ -I$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I$HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include -I$HOME/gcc/svn/libstdc++-v3/libsupc++ -I$HOME/gcc/svn/libstdc++-v3/include/backward -I$HOME/gcc/svn/libstdc++-v3/testsuite/util $HOME/gcc/svn/libstdc++-v3/testsuite/27_io/basic_istream/requirements/explicit_instantiation.cc -include bits/stdc++.h -S -o explicit_instantiation.s -fno-tree-sra In file included from $HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/istream:833, from $HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/sstream:44, from $HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/complex:52, from $HOME/gcc/svn/libstdc++-v3/include/precompiled/stdc++.h:69: $HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/istream.tcc: In member function 'typename std::basic_istream_CharT, _Traits::int_type std::basic_istream_CharT, _Traits::get() [with _CharT = __gnu_cxx::characterunsigned char, __gnu_test::pod_int, __gnu_test::pod_state, _Traits = std::char_traits__gnu_cxx::characterunsigned char, __gnu_test::pod_int, __gnu_test::pod_state ]': $HOME/gcc/svn/obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/istream.tcc:222: internal compiler error: in decl_ultimate_origin, at dwarf2out.c:5770 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- This is with trunk revision 143890, compiled on i686-pc-linux without bootstrap. I will attach preprocessed source shortly. -- Summary: Failing assert in dwarf2out.c:5770 when compiling with - fno-tree-sra Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamborm at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug debug/39086] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-02-03 15:09 --- Created an attachment (id=17232) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17232action=view) Preprocessed source Enough to compile with -O2 -g -fno-tree-sra explicit_instantiation.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug target/37437] [4.4 regression] speed regression
--- Comment #8 from bonzini at gnu dot org 2009-02-03 15:09 --- Great. -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37437
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #11 from bonzini at gnu dot org 2009-02-03 15:15 --- No, the patch does not fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #12 from bonzini at gnu dot org 2009-02-03 15:19 --- But at least it gets cc1 to call rtx_addr_can_trap_p_1. Mine -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|hp at gcc dot gnu dot org |bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug debug/39086] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-03 15:30 --- Not too useful, that preprocessed source includes PCHs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39084
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #3 from tony_eckert at umsl dot edu 2009-02-03 15:38 --- Created an attachment (id=17233) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17233action=view) autoconf log of failed stage 3 build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug fortran/39087] New: Performance using COMPLEX data type
I have noticed that in some cases - especially calculating Mandelbrot Fractals there is a severe performance penalty if the COMPLEX data type is used instead of plain variables. It's nothing wrong with the calculation, but it shall be noted that it can mean a severe performance penalty if the COMPLEX data type is used. Result of test cases I have created: --- [r...@cvs2 frac]# time ./m6 real0m5.806s user0m1.705s sys 0m0.032s [r...@cvs2 frac]# time ./m7 real0m18.598s user0m12.469s sys 0m0.036s --- -- Summary: Performance using COMPLEX data type Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m4341 at abc dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
Re: [Bug c++/36607] [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers
Sent from my iPhone On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from bonzini at gnu dot org 2009-02-03 13:56 --- ping? The patch was just approved last night and I will be applying it when I get into work today. -- bonzini at gnu dot org changed: What|Removed |Added --- --- -- CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
[Bug c++/36607] [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers
--- Comment #8 from pinskia at gmail dot com 2009-02-03 15:44 --- Subject: Re: [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers Sent from my iPhone On Feb 3, 2009, at 5:56 AM, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from bonzini at gnu dot org 2009-02-03 13:56 --- ping? The patch was just approved last night and I will be applying it when I get into work today. -- bonzini at gnu dot org changed: What|Removed |Added --- --- -- CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #13 from bonzini at gnu dot org 2009-02-03 15:48 --- Created an attachment (id=17235) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17235action=view) patch to be tested The patch fixes the bug. As a follow up (see PR38921 audit trail) MTP_AFTER_MOVE and MTP_UNALIGNED_MEMS could be folded, but I'm not going to do that right now. If anyone can test it for me, I'd be grateful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #2 from m4341 at abc dot se 2009-02-03 15:50 --- Notice that the test cases have been executed on a Pentium III computer with dual 866MHz processors. The 'depth' variable in the example code has been set to produce comfortable execution times for the forementioned computer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug c/39088] New: Warning about potential use of uninitialized variable
Following emits a warning about potential use of uninitialized variable,
even though the variable initialization and it's use are guarded by the
same predicate.
int f (void);
int g (int a)
{
int b;
if (a) b = f ();
asm volatile (#);
if (a) return b;
return 1;
}
$ gcc -O -Wuninitialized -c repro.c
repro.c: In function 'g':
repro.c:5: warning: 'b' may be used uninitialized in this function
This happens with gcc 4.3.0 and 4.3.1
--
Summary: Warning about potential use of uninitialized variable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: av1474 at comtv dot ru
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39088
[Bug c++/36897] [4.2/4.3/4.4 Regression] ICE with function pointer template parameter
--- Comment #6 from bonzini at gnu dot org 2009-02-03 15:56 --- Subject: Bug 36897 Author: bonzini Date: Tue Feb 3 15:56:05 2009 New Revision: 143896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143896 Log: gcc/cp: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * pt.c (convert_nontype_argument_function): Expect expr to be an ADDR_EXPR. PR c++/37314 * typeck.c (merge_types): Call resolve_typename_type if only one type is a typename. gcc/testsuite: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * g++.dg/template/func2.C: New test. PR c++/37314 * g++.dg/template/typename15.C: New. * g++.dg/template/typename16.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/func2.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename15.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename16.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/cp/typeck.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #20 from bonzini at gnu dot org 2009-02-03 15:56 --- Subject: Bug 37314 Author: bonzini Date: Tue Feb 3 15:56:05 2009 New Revision: 143896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143896 Log: gcc/cp: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * pt.c (convert_nontype_argument_function): Expect expr to be an ADDR_EXPR. PR c++/37314 * typeck.c (merge_types): Call resolve_typename_type if only one type is a typename. gcc/testsuite: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * g++.dg/template/func2.C: New test. PR c++/37314 * g++.dg/template/typename15.C: New. * g++.dg/template/typename16.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/func2.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename15.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename16.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/cp/typeck.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug target/39076] internal compiler error when cross-compiling flac
--- Comment #3 from s dot neumann at phase-zero dot de 2009-02-03 16:14 --- The code in flac that triggered the problem does also make gcc crash with -O3 -funroll-loops. I've also tested -O1 and -O2, same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-03 16:15 --- Use -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug target/23322] [4.2/4.3/4.4 regression] performance regression
--- Comment #32 from bonzini at gnu dot org 2009-02-03 16:16 --- The patch for partial memory writes was committed. How are we doing on this benchmark now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug target/23322] [4.2/4.3/4.4 regression] performance regression
-- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug c++/36897] [4.2 Regression] ICE with function pointer template parameter
--- Comment #7 from bonzini at gnu dot org 2009-02-03 16:20 --- fixed on 4.3/4.4, still needs backporting to 4.2 -- bonzini at gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.1 4.3.0 4.1.2 |4.0.4 4.1.2 4.3.3 Known to work|3.4.6 |3.4.6 4.3.4 4.4.0 Summary|[4.2/4.3/4.4 Regression] ICE|[4.2 Regression] ICE with |with function pointer |function pointer template |template parameter |parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #21 from bonzini at gnu dot org 2009-02-03 16:21 --- fixed on 4.3/4.4, still needs backporting to 4.2 -- bonzini at gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.0 4.2.4 4.3.2 |4.1.2 4.2.0 4.2.4 4.3.3 |4.4.0 | Known to work|4.0.4 4.1.1 |4.0.4 4.1.1 4.3.4 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug c++/36897] [4.2 Regression] ICE with function pointer template parameter
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-03 16:22 --- Did you really commit it to mainline? I don't see it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug c++/37314] [4.2 Regression] seg violation
--- Comment #22 from paolo dot carlini at oracle dot com 2009-02-03 16:22 --- Likewise... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug target/27440] [4.2/4.3/4.4 regression] code quality regression due to ivopts
--- Comment #12 from bonzini at gnu dot org 2009-02-03 16:25 --- When generating 64-bit code we produce good induction variables either with or without ivopts, but with an extra mov. For 32-bit code the situation is the same as reported originally. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Last reconfirmed|2007-11-20 07:36:56 |2009-02-03 16:25:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27440
[Bug c++/36897] [4.2 Regression] ICE with function pointer template parameter
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 --- Subject: Re: [4.2 Regression] ICE with function pointer template parameter Did you really commit it to mainline? I don't see it. I was doing it. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug c++/36897] [4.2 Regression] ICE with function pointer template parameter
--- Comment #9 from bonzini at gnu dot org 2009-02-03 16:26 --- Subject: Re: [4.2 Regression] ICE with function pointer template parameter Did you really commit it to mainline? I don't see it. I was doing it. :-) --- Comment #10 from bonzini at gnu dot org 2009-02-03 16:26 --- Subject: Bug 36897 Author: bonzini Date: Tue Feb 3 16:26:28 2009 New Revision: 143898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143898 Log: gcc/cp: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * pt.c (convert_nontype_argument_function): Expect expr to be an ADDR_EXPR. PR c++/37314 * typeck.c (merge_types): Call resolve_typename_type if only one type is a typename. gcc/testsuite: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * g++.dg/template/func2.C: New test. PR c++/37314 * g++.dg/template/typename15.C: New. * g++.dg/template/typename16.C: New. Added: trunk/gcc/testsuite/g++.dg/template/func2.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/func2.C trunk/gcc/testsuite/g++.dg/template/typename15.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename15.C trunk/gcc/testsuite/g++.dg/template/typename16.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36897
[Bug c++/37314] [4.2 Regression] seg violation
--- Comment #23 from bonzini at gnu dot org 2009-02-03 16:26 --- Subject: Bug 37314 Author: bonzini Date: Tue Feb 3 16:26:28 2009 New Revision: 143898 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143898 Log: gcc/cp: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * pt.c (convert_nontype_argument_function): Expect expr to be an ADDR_EXPR. PR c++/37314 * typeck.c (merge_types): Call resolve_typename_type if only one type is a typename. gcc/testsuite: 2009-02-03 Paolo Bonzini bonz...@gnu.org PR c++/36897 * g++.dg/template/func2.C: New test. PR c++/37314 * g++.dg/template/typename15.C: New. * g++.dg/template/typename16.C: New. Added: trunk/gcc/testsuite/g++.dg/template/func2.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/func2.C trunk/gcc/testsuite/g++.dg/template/typename15.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename15.C trunk/gcc/testsuite/g++.dg/template/typename16.C - copied unchanged from r143896, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/typename16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug tree-optimization/37709] [4.4 Regression] inlining causes explosion in debug info
--- Comment #8 from bonzini at gnu dot org 2009-02-03 16:28 --- changing summary, inlining _is_ the right thing to do. -- bonzini at gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] inliner|[4.4 Regression] inlining |gone crazy |causes explosion in debug ||info http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug libstdc++/25191] exception_defines.h #defines try/catch
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #1 from m4341 at abc dot se 2009-02-03 15:46 --- Created an attachment (id=17234) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17234action=view) Test cases for demonstrating performance impact. The attached file contains code that is in it's current state requiring Xwindows, but it's completely optional for the test case and is only used to display the result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug tree-optimization/32044] [4.3 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #68 from bonzini at gnu dot org 2009-02-03 16:32 --- This was fixed on trunk (see comment #65). Open another bug for long-term solutions, this is cluttering the 4.4 regressions. :-) -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Summary|[4.3/4.4 Regression] final |[4.3 Regression] final value |value replacement too |replacement too aggressive |aggressive for e.g. targets |for e.g. targets with no |with no native div/mod insns|native div/mod insns http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #14 from hp at gcc dot gnu dot org 2009-02-03 16:34 --- (In reply to comment #11) No, the patch does not fix it. Yes, I found that out too ;) but haven't had time to follow up. FWIW, I have an overlapping patch for PR38921 that does fold the code as suggested. It doesn't do much for this PR, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures
--- Comment #17 from etienne_lorrain at yahoo dot fr 2009-02-03 16:38
---
(In reply to comment #15)
The advantage of such a RTL pass (or just adding such optimization to another
RTL pass) would be that it would handle also say: ...
Why only limit that pass to constants, and only to writes:
etie...@cygne:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
etie...@cygne:~$ cat tmp.c
struct S
{
char a;
char b;
char c;
char d;
} u, v;
void fct (void) {
u.a = v.a;
u.b = v.b;
u.c = v.c;
u.d = v.d;
}
etie...@cygne:~$ gcc -Os -S tmp.c -o tmp.s
etie...@cygne:~$ cat tmp.s
.file tmp.c
.text
.globl fct
.type fct, @function
fct:
movbv, %al
pushl %ebp
movl%esp, %ebp
popl%ebp
movb%al, u
movbv+1, %al
movb%al, u+1
movbv+2, %al
movb%al, u+2
movbv+3, %al
movb%al, u+3
ret
.size fct, .-fct
.comm u,4,4
.comm v,4,4
.ident GCC: (Debian 4.3.3-3) 4.3.3
.section.note.GNU-stack,,@progbits
etie...@cygne:~$
A single 32 bits read, and a single 32 bits write should be sufficient,
when none of the fields of the structure is declared volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #15 from bonzini at gnu dot org 2009-02-03 16:40 --- Subject: Re: [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm. Yes, I found that out too ;) but haven't had time to follow up. FWIW, I have an overlapping patch for PR38921 that does fold the code as suggested. It doesn't do much for this PR, however. If you submit it, I'll happily take care of the conflicts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug c++/35652] [4.2/4.3/4.4 Regression] offset warning should be given in the front-end
--- Comment #13 from bonzini at gnu dot org 2009-02-03 16:40 --- I agree that the patch is correct *without* the -1, so... ping :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug fortran/39087] Performance using COMPLEX data type
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:52 --- more precisely, without -ffast-math gcc is not able to change abs(z) 2 to r*r+i*i 4 and computes a square root on every iteration. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39087
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #4 from bonzini at gnu dot org 2009-02-03 16:56 --- no he's not. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug debug/39086] Failing assert in dwarf2out.c:5770 when compiling with -fno-tree-sra
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-02-03 16:56 --- Created an attachment (id=17236) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17236action=view) Preprocessed source OK, this one is hopefully without any precompiled headers. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Attachment #17232|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
[Bug target/36861] [4.3/4.4 Regression] boost's compressed avl confuses GCC
--- Comment #28 from bonzini at gnu dot org 2009-02-03 09:54 --- Am I right that the bug is just at -O, not at -O2? 4.4 -O2 is worse than 4.4 -O2 -fno-strict-aliasing, but are they better than 4.3 -O2 or worse? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #77 from bonzini at gnu dot org 2009-02-03 17:10 --- Can't the library just #undef try/catch at the end of each file that includes exception_defines.h? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #78 from paolo dot carlini at oracle dot com 2009-02-03 17:14 --- Nope, we never do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37060] [4.3/4.4 regression] Bogus __builtin___memcpy_chk overflow warning
--- Comment #6 from bonzini at gnu dot org 2009-02-03 17:15 --- Only fails on 64-bit targets. -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37060
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #79 from bonzini at gnu dot org 2009-02-03 17:15 --- Yeah, but it seems better than uglifying __try/__catch all over the place... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #80 from paolo dot carlini at oracle dot com 2009-02-03 17:20 --- Many solutions are better, in principle, but really this issue is too old. After all we are uglifying also in other cases. Let's do that and be done with it. Unless there are objections (or, better, constructive proposals, aka patches) that the library solutions is an improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug middle-end/37060] [4.3/4.4 regression] Bogus __builtin___memcpy_chk overflow warning
--- Comment #7 from bonzini at gnu dot org 2009-02-03 17:21 --- Interesting: we actually propagate *more* on 64-bit targets, and end up with __builtin___memcpy_chk (buf, valbuf_7(D), 16, 8); while on 32-bit we get __builtin___memcpy_chk (buf, valbuf_7(D), D.1293_2, 8); -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2008-08-08 15:43:24 |2009-02-03 17:21:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37060
[Bug c++/39056] [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-03 17:23 --- Subject: Bug 39056 Author: jakub Date: Tue Feb 3 17:23:11 2009 New Revision: 143899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143899 Log: PR c++/39056 * typeck2.c (digest_init_r): Don't call process_init_constructor for COMPLEX_TYPE. * g++.dg/cpp0x/initlist13.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug inline-asm/39059] [4.3/4.4 regression] ICE with fixed-point type in inline-asm
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-03 17:26 --- Subject: Bug 39059 Author: jakub Date: Tue Feb 3 17:26:28 2009 New Revision: 143900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143900 Log: PR inline-asm/39059 * c-parser.c (c_parser_postfix_expression): If fixed point is not supported, don't accept FIXED_CSTs. * c-decl.c (finish_declspecs): Error if fixed point is not supported and _Sat is used without _Fract/_Accum. Set specs-type to integer_type_node for cts_fract/cts_accum if fixed point is not supported. * parser.c (cp_parser_primary_expression): Reject FIXED_CSTs. * gcc.dg/nofixed-point-2.c: New test. * g++.dg/ext/fixed1.C: Adjust expected diagnostics. * g++.dg/ext/fixed2.C: Likewise. * g++.dg/other/error25.C: Likewise. * g++.dg/lookup/crash7.C: Likewise. * g++.dg/cpp0x/decltype-38655.C: Likewise. Added: trunk/gcc/testsuite/gcc.dg/nofixed-point-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype-38655.C trunk/gcc/testsuite/g++.dg/ext/fixed1.C trunk/gcc/testsuite/g++.dg/ext/fixed2.C trunk/gcc/testsuite/g++.dg/lookup/crash7.C trunk/gcc/testsuite/g++.dg/other/error25.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
[Bug target/35318] [4.3/4.4 regression] ICE with inline asm in reload
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-03 17:28 --- Subject: Bug 35318 Author: jakub Date: Tue Feb 3 17:27:45 2009 New Revision: 143901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143901 Log: PR target/35318 * function.c (match_asm_constraints_1): Skip over initial optional % in the constraint. * gcc.c-torture/compile/pr35318.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr35318.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
[Bug c/35433] [4.2/4.3/4.4 regression] ICE with typeof and ternary operator
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-03 17:38 --- Working on a patch. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-15 01:30:20 |2009-02-03 17:38:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35433
[Bug rtl-optimization/38921] [4.3 Regression] NULL access in delay-slot
--- Comment #9 from hp at gcc dot gnu dot org 2009-02-03 17:46 --- Created an attachment (id=17237) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17237action=view) Proposed fix Also folds may_trap_after_code_motion_p into may_trap_or_fault_p, as being the original semantics. -- hp at gcc dot gnu dot org changed: What|Removed |Added Attachment #17156|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #16 from hp at gcc dot gnu dot org 2009-02-03 17:54 --- (In reply to comment #15) If you submit it, I'll happily take care of the conflicts. I've put it in the PR, though it's not a proper submit yet. Also, only regtested for cris-elf on the 4.3 branch and x86_64-unknown-linux-gnu on trunk. Thanks for dealing with this PR, your patch looks correct. (The overlap seems to be minimal, just your last chunk.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug fortran/39072] I/O READing logical value beyond end of string
--- Comment #4 from burnus at gcc dot gnu dot org 2009-02-03 10:02 --- I believe gfortran is correct as far as giving an error. The last logical value does not begin with a T(t) or F(f). That was my impression in comment 0 (maybe wontfix), which was confirmed by the standard (comment 2); when I filled I was unsure since so many compilers support it. (I encountered it in Fleur (www.flapw.de) and it took me a while to figure out what was wrong.) The only thing remaining here to me is are we attempting to read past the end of record with the error case and so should we really be giving an EOR. Hmm, I wonder whether it should be EOR. NAG f95 and g95 also give an error for an invalid logical and not an EOR. (No value found in LOGICAL input field, Bad value on logical read) Testing for iostat= using IS_IOSTAT_EOR(I),IS_IOSTAT_END(I), gives with all three compilers a F(alse). Thus, I would suggest WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #13 from ubizjak at gmail dot com 2009-02-03 11:34 --- (In reply to comment #12) What if we forbid altogether memory operands and we *synthesize* them with a peephole2? Anyway, it seems safe to me to declare this a dup of PR38824? I think that we will hit PR 19398 then... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug middle-end/19988] [4.2/4.3/4.4 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #15 from jakub at gcc dot gnu dot org 2009-02-03 09:56 --- I really think either GCSE should be trying to decrease the number of floating point constants used by a function by getting rid of constants for which negated constants is also used and it can be negated at no cost (by swapping an addition with subtraction etc.). Or if not GCSE, some late tree pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug c++/39089] New: -Wconversion is buggy with bitwise operators
g++ 4.3.3 emits warnings for every statement in the following function when the
code is built this way:
/gcc43/bin/g++ -c -Wall -Wconversion test.cpp
void func(unsigned char a, unsigned char b, unsigned char *out)
{
*out = a | b;
*out = out[0] 0x20;
out[0] = 0x20;
}
I'd expect bitwise operators to see/preserve argument widths...
--
Summary: -Wconversion is buggy with bitwise operators
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oleg dot smolsky at riverbed dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
[Bug rtl-optimization/37889] [4.3/4.4 Regression] SEGV, conditional execution proactively executed the false arm.
--- Comment #17 from bonzini at gnu dot org 2009-02-03 17:57 --- Thanks, I'll merge it with mine, bootstrap/regtest i686-pc-linux-gnu and submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37889
[Bug target/39090] New: MIPS: wrong-code with 64-bit values and register asm constraints with o32 ABI.
With GCC: (GNU) 4.4.0 20090116 (experimental) [trunk revision 143437]
Consider this program (bug1900.c):
---8---
unsigned long long bar()
{
unsigned long long rv;
asm volatile (rdhwr %0, $30 : =d (rv));
return rv;
}
---8---
$ mips64-linux-gcc -march=mips32r2 -mabi=32 -O2 -c bug1900.c
$ cat bug1900.s
.file 1 bug1900.c
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.abicalls
.text
.align 2
.globl bar
.setnomips16
.entbar
.type bar, @function
bar:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
#APP
# 7 bug1900.c 1
rdhwr $4, $30
# 0 2
#NO_APP
move$2,$4
.setnoreorder
.setnomacro
j $31
move$3,$5
.setmacro
.setreorder
.endbar
.size bar, .-bar
.ident GCC: (GNU) 4.4.0 20090116 (experimental) [trunk revision
143437]
Register $3 (v1) returns with uninitialized garbage. This is the high part of
the 64 bit return value.
I am not sure what should happen here. Really the d asm constraint should
not match a 64 bit variable for the o32 ABI.
--
Summary: MIPS: wrong-code with 64-bit values and register asm
constraints with o32 ABI.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
GCC build triplet: mips64-unknown-linux-gnu
GCC host triplet: mips64-unknown-linux-gnu
GCC target triplet: mips64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39090
[Bug c++/39089] -Wconversion is buggy with bitwise operators
--- Comment #1 from oleg dot smolsky at riverbed dot com 2009-02-03 17:58 --- Created an attachment (id=17238) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17238action=view) The test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39089
[Bug tree-optimization/39074] PTA constraint processing for *x = y is wrong
--- Comment #5 from dberlin at gcc dot gnu dot org 2009-02-03 14:16 ---
Subject: Re: PTA constraint processing for *x =
y is wrong
There used to be a *ANYTHING = ANYTHING constraint + ANYTHING
containing all the variables pointing to ANYTHING that would have
taken care of this.
You certainly don't want to dynamically add all variables at solving
time yourself, since that can't be optimized.
On Tue, Feb 3, 2009 at 4:17 AM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-03 09:17
---
Yes, but as the store to y is via *x and x points to { ANYTHING } (via the
non-pointer (int ***)q) only (as x already includes ANYTHING we do not add
a for the second constraint), so for *x = i we fail to add a to y.
For reference, here are the constraints:
a = y
p_4 = ANYTHING
p_1 = p_4
p_1 = a
x_6 = *p_1
derefaddrtmp.9 = i
*x_6 = derefaddrtmp.9
y.0_7 = y
and the solutions:
a = { y }
y = same as y.0_7
p_4 = { ANYTHING }
p_1 = { ANYTHING a }
x_6 = { ANYTHING }
i = { }
derefaddrtmp.9 = { i }
y.0_7 = { }
while correct would be if everything would point to at least i (through
the effective *ANYTHING = i constraint)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #5 from mikael dot morin at tele2 dot fr 2009-02-03 18:00 --- /export/home/eckerta/Desktop/objdir/./gcc/gfortran -B/export/home/eckerta/Desktop/objdir/./gcc/ -B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/bin/ -B/usr/local/gcc-4.3.3/i686-pc-linux-gnu/lib/ -isystem /usr/local/gcc-4.3.3/i686-pc-linux-gnu/include -isystem /usr/local/gcc-4.3.3/i686-pc-linux-gnu/sys-include -c conftest.F 5 /export/home/eckerta/Desktop/objdir/./gcc/f951: symbol lookup error: /usr/local/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions I guess it's a problem with gmp. Do you have it installed? Which versions of mpfr and gmp do you have? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug libfortran/39083] stage 3 libgfortran build fails
--- Comment #6 from mikael dot morin at tele2 dot fr 2009-02-03 18:01 --- (In reply to comment #1) Only departure from defaults is --prefix No, -prefix ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
--- Comment #17 from bonzini at gnu dot org 2009-02-03 12:51 --- The failure happens because structural_comptypes calls resolve_typename_type, while merge_types does not. Maybe it should as in this patch? Index: ../../peak-gcc-src/gcc/cp/typeck.c === --- ../../peak-gcc-src/gcc/cp/typeck.c (revision 143676) +++ ../../peak-gcc-src/gcc/cp/typeck.c (working copy) @@ -606,6 +606,11 @@ merge_types (tree t1, tree t2) if (TYPE_PTRMEMFUNC_P (t2)) t2 = TYPE_PTRMEMFUNC_FN_TYPE (t2); + if (TREE_CODE (t1) == TYPENAME_TYPE) +t1 = resolve_typename_type (t2, /*only_current_p=*/true); + if (TREE_CODE (t2) == TYPENAME_TYPE) +t2 = resolve_typename_type (t2, /*only_current_p=*/true); + code1 = TREE_CODE (t1); code2 = TREE_CODE (t2); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
GCC bug: Inappropriate implicit invocation of copy constructor when reference parameter is a temporary
I believe this is a genuine GCC compiler bug (in both GCC 4.1.1 and GCC
4.2.4). I hope this report is of value, and certainly hope it can be
corrected.
Forgive me for not logging a bug via http://gcc.gnu.org/bugzilla/ - I don't
want to mess around with your system due to unfamiliarity with Bugzilla.
Please email me directly if you wish.
Manfred
==
Description of presumed bug:
When a temporary is passed as a reference parameter, the copy constructor of
the source object type is apparently invoked without reason. This is
evidenced by a no matching function error message if there is no valid
copy constructor. If the actual parameter is not a temporary, this does not
occur.
My take:
It should be possible to pass a reference of a temporary to a function even
when the class has no copy semantics, and there is no call for invoking a
copy constructor in this context.
Additional observations:
If the function expects a reference to a base class, the message refers to
the class of the temporary, to the expected reference type. This, if X is
publicly derived from B and f expects a reference to B, the message still
refers to 'X::X(X)' and not to B.
If the copy constructor is public and implicitly callable, the message no
longer appears.
This is not to be confused with the same message being generated when the
copy constructor must be available for returning an object from a function
(e.g. http://gcc.gnu.org/ml/gcc/2005-05/msg00916.html).
Example of code (test.cpp) that triggers the bug:
class X {
private: explicit X (X const ); // suppress copy constructor
public: X () { }
};
void f (X const ) { }
void g () {
f(X()); // error reported: no matching function for call to
'X::X(X)'
}
Compiler details:
$ gcc -v -save-temps test.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -fpch-preprocess -o test.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.4/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -auxbase test -version -fstack-protector
-fstack-protector -o test.s
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: cca9b7b48c023363b938f208576b99cc
test.cpp: In function \u2018void g()\u2019:
test.cpp:9: error: no matching function for call to \u2018X::X(X)\u2019
$
Output files:
test.s:
.file test.cpp
test.ii:
# 1 test.cpp
# 1 built-in
# 1 command-line
# 1 test.cpp
class X {
private: explicit X (X const );
public: X () { }
};
void f (X const ) { }
void g () {
f(X());
}
Alternative compiler details (same problem):
gcc -v
Using built-in specs.
Target: arm-unknown-elf
Configured with: ../gcc-2006q3/configure --target=arm-unknown-elf
--build=i686-pc-mingw32 --host=i686-pc-mingw32
--prefix=/c/gcc-build-2006q3-26/install
Thread model: single
gcc version 4.1.1
[Bug testsuite/35114] 731 unexpected libgomp testsuite failures due setup of test environment
--- Comment #2 from gerald at pfeifer dot com 2009-02-03 10:03 --- Latest testruns confirm this as fixed: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00249.html Only four failures remain, and these are different from what has been reported here: === libgomp tests === Running target unix FAIL: libgomp.fortran/condinc2.f -O (test for excess errors) WARNING: libgomp.fortran/condinc2.f -O compilation failed to produce executable FAIL: libgomp.fortran/condinc4.f90 -O (test for excess errors) WARNING: libgomp.fortran/condinc4.f90 -O compilation failed to produce executable FAIL: libgomp.fortran/omp_cond2.f -O (test for excess errors) WARNING: libgomp.fortran/omp_cond2.f -O compilation failed to produce executable FAIL: libgomp.fortran/omp_cond4.F90 -O (test for excess errors) WARNING: libgomp.fortran/omp_cond4.F90 -O compilation failed to produce executable === libgomp Summary === # of expected passes2333 # of unexpected failures4 # of unsupported tests 2 -- gerald at pfeifer dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35114
