[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-11 06:12 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-11 06:12:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-11 06:25 --- Subject: Bug 31823 Author: brooks Date: Wed Jul 11 06:25:47 2007 New Revision: 126538 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126538 Log: Backport from trunk: PR fortran/31823 * intrinsic.texi (CMPLX): Document result kind. (COMPLEX): Add documentation. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-11 06:34 --- Fixed, as per the above commit. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-11 06:38 --- Working: 2007-07-09-r126478 Failing: 2007-07-10-r126510 I believe it is due to the patch r126509 | pault | 2007-07-10 07:11:00 +0200 (Di, 10 Jul 2007) | 28 lines PR 32634 [...] * module.c (write_generic): Write the local name of the interface. but I might be wrong and it is one of: r126486 | dfranke | 2007-07-09 16:56:49 +0200 (Mon, 09 Jul 2007) | 14 lines r126493 | kargl | 2007-07-09 21:41:37 +0200 (Mon, 09 Jul 2007) | 6 lines r126496 | fxcoudert | 2007-07-10 00:00:52 +0200 (Tue, 10 Jul 2007) | 6 lines The error message is: USE util,ONLY: sort 1 Error: Symbol 'sort' referenced at (1) not found in module 'util' Reduced test case: MODULE kinds INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 ) END MODULE kinds MODULE util USE kinds, ONLY: dp INTERFACE sort MODULE PROCEDURE sort2 END INTERFACE CONTAINS SUBROUTINE sort2 ( ) END SUBROUTINE sort2 END MODULE util MODULE graphcon USE util,ONLY: sort END MODULE graphcon -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug bootstrap/32726] ICE when compiling emit-rtl.c
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-11 06:43 --- (In reply to comment #0) r126521 on ppc64-linux bootstrap fails with r126512 passed bootstrap on powerpc64, so I guess the problem was introduced somewhere in between -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
[Bug bootstrap/32726] ICE when compiling emit-rtl.c
--- Comment #2 from eres at il dot ibm dot com 2007-07-11 06:51 --- The problem seems to be fixed. See - http://gcc.gnu.org/ml/gcc/2007-07/msg00352.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
[Bug c++/32687] Invalid code generation for reading signed negative bitfield value (g++ optimization)
--- Comment #2 from siarhei dot siamashka at gmail dot com 2007-07-11 07:06 --- Tried this test with gcc 4.2.0, it also works correctly. So looks like the problem only shows up in gcc 4.1.x -- siarhei dot siamashka at gmail dot com changed: What|Removed |Added Known to work|3.4.6 4.3.0 |3.4.6 4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32687
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #7 from rguenther at suse dot de 2007-07-11 08:32 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On Tue, 10 Jul 2007, dberlin at dberlin dot org wrote: On 10 Jul 2007 15:32:51 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: --- Comment #5 from rguenther at suse dot de 2007-07-10 15:32 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote: --- Comment #4 from ramana dot radhakrishnan at celunite dot com 2007-07-10 15:14 --- (In reply to comment #3) Fixed with take3.diff. Did you forget to attach take3.diff ? No, that was a hint to Danny ;) You never told me whether omnetpp/xalanbmc were still failing with it or not :) Doh! Yes, they did. You never got around sending me the variant with more asserts either ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-11 08:33 --- No error up to and including r126496. That leaves only Paul's patch ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #14 from rguenther at suse dot de 2007-07-11 08:36 --- Subject: Re: wrong types in character array/scalar binop On Wed, 10 Jul 2007, pinskia at gcc dot gnu dot org wrote: --- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-10 23:36 --- I think this was fixed with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01471.html aka PR32140. No, it's still there. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #4 from rguenther at suse dot de 2007-07-11 08:45 ---
Subject: Re: CCP removes volatile qualifiers.
On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote:
(In reply to comment #2)
As the decl is volatile as well this is clearly a bogus optimization.
Putting a breakpoint on evaluate_stmt in tree-ssa-ccp.c shows that stmt_ann of
the stmt does not have has_volatile_ops set to true.
(gdb) p stmt
(gdb) pt
gimple_modify_stmt 0xb7d4fee0 side-effects
arg 0 ssa_name 0xb7d4aed4
type pointer_type 0xb7d44bd0 type integer_type 0xb7d44b64 int
sizes-gimplified unsigned SI
size integer_cst 0xb7caa460 constant invariant 32
unit size integer_cst 0xb7caa24c constant invariant 4
align 32 symtab 0 alias set -1 canonical type 0xb7d44bd0
visited var var_decl 0xb7d5005c spinlock0 def_stmt
gimple_modify_stmt 0xb7d4fee0
version 1
arg 1 addr_expr 0xb7d481c0 type pointer_type 0xb7d44bd0
constant invariant
arg 0 array_ref 0xb7cb5084 type integer_type 0xb7d44b64 int
arg 0 var_decl 0xb7d5 spinlock
arg 1 integer_cst 0xb7d4fec4 constant invariant 0
try.c:5
(gdb) (gdb) p *(stmt-base-ann)
$17 = {common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, vdecl = {
common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0},
out_of_ssa_tag = 0, base_var_processed = 0, used = 0,
need_phi_state = NEED_PHI_STATE_NO, in_vuse_list = 1, in_vdef_list = 0,
is_heapvar = 0, call_clobbered = 1, noalias_state = NO_ALIAS_GLOBAL,
mpt = 0xb7cb6804, symbol_mem_tag = 0x0, partition = 0, base_index = 0,
current_def = 0x0, subvars = 0x0, escape_mask = 3084210192}, fdecl = {
common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0},
reference_vars_info = 0xb7eed528}, stmt = {common = {type = STMT_ANN,
aux = 0x0, value_handle = 0x0}, bb = 0xb7eed528, operands = {
def_ops = 0xb7cb6804, use_ops = 0x0, vdef_ops = 0x0, vuse_ops = 0x0,
stores = 0x0, loads = 0x0}, addresses_taken = 0xb7d55010, uid = 0,
references_memory = 0, modified = 0, has_volatile_ops = 0,
makes_clobbering_call = 0}}
Shouldn't has_volatile_ops get set to true in this case because the stmt
essentially has one volatile operand here ?
No, this assignment just assigns pointers (the pointers are not volatile,
just the thing they point to is). Basically volatile ops is set only
on statements reading/writing memory.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug fortran/32627] [ISO Bind C] Accept c_f_pointer for TYPE
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-11 08:46 --- Also http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/index.html fails with the same error. (One needs to change g95) into g95|gfortran) in configure.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32627
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-11 08:52 --- FYI, testcase is standard conforming code AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug middle-end/32725] Unnecessary reg-reg moves
--- Comment #1 from rask at sygehus dot dk 2007-07-11 08:53 --- I think (1) and (2) is just the register allocator being stupid. This sort of thing can happen when the %rax at (1) was a different pseudo register than the %rax at (2). The register allocator is supposed to be able to tie such pseudo registers, but it does not take a lot to mess that up. You should use -dp when posting asm output intended for human readers (although in this case, I don't think you need to repost the asm output just to include the -dp output). movq%rax, %rbx # 95*movdi_1_rex64/2[length = 6] andq%r8, %rbx # 25*anddi_1_rex64/2[length = 3] movq%rbx, %rax # 96*movdi_1_rex64/2[length = 6] Notice that the movq insns have much higher insn uids than the andq insn. I.e. they were most likely emitted in a later pass. (And those movq insn lenghts are wrong, they should be 3 instead of 6.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-11 09:18 --- Subject: Bug 32560 Author: paolo Date: Wed Jul 11 09:18:39 2007 New Revision: 126542 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126542 Log: /cp 2007-07-11 Paolo Carlini [EMAIL PROTECTED] PR c++/32560 * parser.c (cp_parser_make_indirect_declarator): When the the code argument is ERROR_MARK return cp_error_declarator. /testsuite 2007-07-11 Paolo Carlini [EMAIL PROTECTED] PR c++/32560 * g++.dg/template/decl3.C: New. Added: trunk/gcc/testsuite/g++.dg/template/decl3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560
[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template
--- Comment #3 from pcarlini at suse dot de 2007-07-11 09:19 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560
[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-07-11 09:43 --- Subject: Bug 32589 Author: ebotcazou Date: Wed Jul 11 09:43:25 2007 New Revision: 126545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126545 Log: PR tree-optimization/32589 * doc/tree-ssa.texi (Rough GIMPLE Grammar): Add missing rule. * tree-gimple.c (is_gimple_min_invariant): Clarify head comment. * tree-ssa-propagate.c (valid_gimple_expression_p): New predicate, extracted from... (set_rhs): ...here. Call it for the expression on entry. * tree-ssa-propagate.h (valid_gimple_expression_p): Declare. * tree-ssa-sccvn.c: Include tree-ssa-propagate.h. (simplify_binary_expression): Use valid_gimple_expression_p to validate the simplification. * Makefile.in (tree-ssa-sccvn.o): Depends on tree-ssa-propagate.h. Added: trunk/gcc/testsuite/gnat.dg/invariant_index.adb trunk/gcc/testsuite/gnat.dg/invariant_index.ads Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/tree-ssa.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-gimple.c trunk/gcc/tree-ssa-propagate.c trunk/gcc/tree-ssa-propagate.h trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-07-11 09:46 --- The compiler now bootstraps, but the library still doesn't build. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-11 09:55 --- Trying to reduce the testcase, the following ICEs: contains Character (len=20) Function Up (string) Character(len=*) string Up = transfer(merge(transfer(string,x,len(string)), string, .true.), x) return end function Up end ./f951 -quiet achar_4.f90 achar_4.f90: In function 'up': achar_4.f90:9: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:4525 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-11 10:00
---
Reduced testcase:
contains
Character (len=20) Function Up (string)
Character(len=*) string
Up = transfer(achar(iachar(transfer(string,x,1))), x)
return
end function Up
end
char.3 = (*(char[0:][1:1] *) atmp.0.data)[S.2][1]{lb: 1 sz: 1};
(*(char[0:][1:1] *) atmp.1.data)[S.2] = char.3;
the first line is correct, the second is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-07-11 10:13 --- Built from #0 build4_stat (code=ARRAY_REF, tt=0x2b468e0df750, arg0=0x2b468e0e4880, arg1=0x2b468e0e7000, arg2=0x0, arg3=0x0) at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3170 #1 0x00497ae4 in gfc_build_array_ref (base=0x2b468e0e4880, offset=0x2b468e0e7000) at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans.c:317 #2 0x0049eab7 in gfc_conv_scalarized_array_ref (se=0x7fff1d4d8400, ar=0x0) at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:2227 #3 0x004a5b0c in gfc_conv_expr_descriptor (se=0x7fff1d4d8860, expr=0x1395c70, ss=0x1397540) at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:4583 #4 0x004a703e in gfc_conv_array_parameter (se=0x7fff1d4d8860, expr=0x1395c70, ss=0x1397540, g77=1) at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:4887 #5 0x004d0cd2 in gfc_conv_intrinsic_transfer (se=0x7fff1d4d8be0, expr=0x1395a10) at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-intrinsic.c:3195 but I'm lost where to fix this up. Fortran FE functions are poorly documented. It's unclear whether the descriptors are wrong or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #4 from pixel at mandriva dot com 2007-07-11 10:23 --- i forgot to say it doesn't occur without -O, and occurs with -O, -O2 /usr/lib/gcc/i586-mandriva-linux-gnu/4.2.1/cc1 -O fail.c _create Analyzing compilation unitPerforming interprocedural optimizations Assembling functions: _create Execution times (seconds) callgraph construction: 0.14 ( 1%) usr 0.01 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.07 ( 0%) usr 0.02 ( 0%) sys 0.10 ( 0%) wall 428 kB ( 1%) ggc preprocessing : 0.27 ( 1%) usr 0.23 ( 2%) sys 0.68 ( 2%) wall 8293 kB (25%) ggc lexical analysis : 0.13 ( 1%) usr 0.60 ( 4%) sys 0.84 ( 3%) wall 0 kB ( 0%) ggc parser: 0.64 ( 3%) usr 0.43 ( 3%) sys 0.84 ( 3%) wall 18586 kB (57%) ggc tree find ref. vars : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1905 kB ( 6%) ggc tree PTA : 15.92 (86%) usr 10.73 (72%) sys 26.67 (80%) wall 5 kB ( 0%) ggc tree alias analysis : 0.91 ( 5%) usr 2.77 (19%) sys 3.65 (11%) wall 0 kB ( 0%) ggc tree SSA incremental : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc expand: 0.10 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 7 kB ( 0%) ggc varconst : 0.05 ( 0%) usr 0.02 ( 0%) sys 0.01 ( 0%) wall 643 kB ( 2%) ggc global alloc : 0.00 ( 0%) usr 0.01 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc symout: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 18.5714.8433.41 32596 kB ps: the verbose output is a little garbled, this trivial patch on branches/gcc-4_2-branch fixes it: --- gcc/cgraphunit.c(revision 126511) +++ gcc/cgraphunit.c(working copy) @@ -1544,7 +1544,7 @@ timevar_push (TV_CGRAPHOPT); if (!quiet_flag) -fprintf (stderr, Performing interprocedural optimizations\n); +fprintf (stderr, \nPerforming interprocedural optimizations\n); cgraph_function_and_variable_visibility (); if (cgraph_dump_file) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug middle-end/30482] complex division by 0
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-11 10:24 --- Subject: Bug 30482 Author: paolo Date: Wed Jul 11 10:23:56 2007 New Revision: 126546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126546 Log: 2007-07-11 Paolo Carlini [EMAIL PROTECTED] PR middle-end/30482 * c-opts.c (c_common_post_options): Do not change flag_complex_method conditional to flag_isoc99. (c_common_init_options): Do it here, unconditionally. Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482
[Bug middle-end/30482] complex division by 0
--- Comment #3 from pcarlini at suse dot de 2007-07-11 10:24 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482
[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-07-11 10:29 --- Subject: Bug 32713 Author: ebotcazou Date: Wed Jul 11 10:29:17 2007 New Revision: 126547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126547 Log: PR tree-optimization/32713 * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle REAL_CST. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-11 10:31 --- The Ada compiler is alive again everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-11 10:25 --- (In reply to comment #16) Trying to reduce the testcase, the following ICEs: PR 31610 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug tree-optimization/32477] ice for legal code with -O2 -ftree-vectorize
--- Comment #5 from irar at il dot ibm dot com 2007-07-11 10:49 --- Fixed. -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32477
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #8 from tbm at cyrius dot com 2007-07-11 12:02 --- Created an attachment (id=13884) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13884action=view) -fdump-tree-original, no flag -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #9 from tbm at cyrius dot com 2007-07-11 12:02 --- Created an attachment (id=13885) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13885action=view) -fdump-tree-original, -fdefault-integer-8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #10 from tbm at cyrius dot com 2007-07-11 12:03 --- Could you (or some other interested party) compile t.f90 with -fdump-tree-original, both with and without -fdefault-integer-8, and post the t.f90.003t.original file produced in each case? This would help us understand where the problem is, without having access to a powerpc machine. Done, on a MIPS (big-endian) box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-07-11 12:29 --- The call to MVBITS is translated as a function call: _gfortran_mvbits_i8 (C.913, C.914, C.915, i, C.916); where all C.* (and i) variables are int8, while the library prototype for the function is: _gfortran_mvbits_i8 (const GFC_INTEGER_8 *from, const GFC_INTEGER_4 *frompos, const GFC_INTEGER_4 *len, GFC_INTEGER_8 *to, const GFC_INTEGER_4 *topos) We need to make a choice between these two, and decided whether all arguments have the same type (my preferred choice) or if some have a fixed type. In all cases, uses of MVBITS with different mixed kinds should be audited, for there might be a few other inconsistencies lurking here. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-15 19:19:03 |2007-07-11 12:29:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-11 13:14 --- Created an attachment (id=13886) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13886action=view) reduced testcase I suppose it needs some minimal DECL_UID, this is as small as I can get it (automated). Fails in verify_ssa compiling with -O2 -fno-tree-store-copy-prop --param ggc-min-expand=0 --param ggc-min-heapsize=0. tree-ssa-structalias.3.min.i:1098: error: definition in block 5 follows the use for SSA_NAME: D.4370_29 in statement: D.4369_26 = D.4370_29; tree-ssa-structalias.3.min.i:1098: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug fortran/32380] misaligned stores don't get vectorized
--- Comment #2 from irar at il dot ibm dot com 2007-07-11 14:50 --- I don't get any dependence test failures on current mainline. I think they were solved by Zdenek's rewrite of data-refs' analysis, since I can still see those failures on autovect-branch (with old data-refs' analysis): unal.f:222: note: not vectorized: can't determine dependence between csfsavloc.savfrc[D.2175_919] and csfsavloc.savfrc[D.2388_922] unal.f:159: note: not vectorized: can't determine dependence between aux01loc.fm11[D.2175_330] and aux01loc.fm11[D.2175_330] unal.f:172: note: not vectorized: can't determine dependence between aux01loc.ft11[D.2175_439] and aux01loc.ft11[D.2175_439] On the mainline unal.f:222 gets vectorized now, and unal.f:159 and unal.f:172 are not vectorized because unsupported unaligned stores: unal.f:222: note: LOOP VECTORIZED.(get_loop_exit_condition unal.f:198: note: LOOP VECTORIZED. unal.f:209: note: not vectorized: unsupported unaligned store. unal.f:159: note: not vectorized: unsupported unaligned store. unal.f:172: note: not vectorized: unsupported unaligned store. unal.f:138: note: not vectorized: unsupported unaligned store. unal.f:127: note: not vectorized: unsupported unaligned store. With loop distribution we could vectorize these loops using peeling to handle misaligned stores (multiple stores make peeling for alignment insufficient here). Misaligned stores support is on the top of our TODO list in Wiki (see http://gcc.gnu.org/wiki/VectorizationTasks)... I am adding missed-optimization keyword and changing the summary. Thanks, Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-07-11 14:50:36 date|| Summary|reports unaligned store |misaligned stores don't get |and can't determine |vectorized |dependence | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug c++/29297] Segmentation fault on invalid use of `::'
--- Comment #2 from pcarlini at suse dot de 2007-07-11 15:02 --- Can't reproduce with current mainline / 4_2-branch / 4_1-branch, on x86_64-linux. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #2 from scovich at gmail dot com 2007-07-11 15:03 --- (In reply to comment #1) Confirmed, not a regression. Also affects 4.3. Changing target -- scovich at gmail dot com changed: What|Removed |Added Version|4.1.2 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #3 from scovich at gmail dot com 2007-07-11 15:10 ---
This bug also causes _mm_cvtsi128_si64x() (which calls
__builtin_ia32_vec_ext_v2di) to emit suboptimal code.
// g++-4.3-070710 -mtune=core2 -O3 -S -dp
#include emmintrin.h
long vector2long(__m128i* src) { return _mm_cvtsi128_si64x(*src); }
Becomes
_Z11vector2longPU8__vectorx:
.LFB529:
movdqa (%rdi), %xmm0 # 6 *movv2di_internal/2 [length = 3]
movd%xmm0, %rax # 25*movdi_1_rex64/14 [length = 4]
ret # 28return_internal [length = 1]
This might be related to bug 32708 (and therefore have a similar fix?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug c++/23472] [hammer] __attribute__((constructor)) called twice with -funit-at-a-time
--- Comment #4 from matz at gcc dot gnu dot org 2007-07-11 15:37 --- Nope. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23472
[Bug c/32728] g++: Internal error: Terminated (program cc1plus)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32728
[Bug c/32728] New: g++: Internal error: Terminated (program cc1plus)
g++: Internal error: Terminated (program cc1plus) Please submit a full bug report. make[4]: *** [sql_yacc.o] Error 1 make[4]: Leaving directory `/usr/src/mysql-5.0.41/sql' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/usr/src/mysql-5.0.41/sql' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/src/mysql-5.0.41/sql' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/mysql-5.0.41' make: *** [install] Error 2 -- Summary: g++: Internal error: Terminated (program cc1plus) Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sn4jc at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32728
[Bug middle-end/32729] New: Loop unrolling not performed with large constant loop bound
Consider the following functions:
// g++ -mtune=core2 -O3 -S -dp
void loop(int* dest, int* src, int count) {
for(int i=0; i count; i++)
dest[i] = src[i];
}
void loop_few(int* dest, int* src) { loop(dest, src, 8); }
void loop_many(int* dest, int* src) { loop(dest, src, 64); }
loop() unrolls 8x, as expected. loop_few() peels completely, as expected.
However, loop_many() neither peels nor unrolls.
_Z9loop_manyPiS_:
xorl%edx, %edx # 34*movdi_xor_rex64[length = 2]
.L47:
movl(%rsi,%rdx,4), %eax # 11*movsi_1/1 [length = 3]
movl%eax, (%rdi,%rdx,4) # 12*movsi_1/2 [length = 3]
incq%rdx# 13*adddi_1_rex64/1[length = 3]
cmpq$64, %rdx # 15cmpdi_1_insn_rex64/1[length = 4]
jne .L47# 16*jcc_1 [length = 2]
rep ; ret # 35return_internal_long[length = 1]
Ideally the optimizer would unroll 8x, then notice that (count%8==0) and
eliminate the partial unroll code. However, even a stock unroll would be better
than nothing.
--
Summary: Loop unrolling not performed with large constant loop
bound
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729
[Bug middle-end/32729] Loop unrolling not performed with large constant loop bound
--- Comment #1 from scovich at gmail dot com 2007-07-11 16:36 ---
(In reply to comment #0)
// g++ -mtune=core2 -O3 -S -dp
Oops... that doesn't actually unroll loop() all, though it still peels
loop_few().
Adding -funroll-loops (supposedly enabled by -O3?) unrolls loop()
Adding -funroll-all-loops does nothing
Nested loops also have issues:
void nested_loop(int* dest, int* src) {
for(int i=0; i 2; i++)
for(int j=0; j 2; j++)
dest[4*i+j] = src[4*j+i];
}
becomes
_Z11nested_loopPiS_:
.LFB533:
xorl%edx, %edx # 39*movdi_xor_rex64[length = 2]
.L47:
movl(%rsi), %ecx# 13*movsi_1/1 [length = 2]
movl%ecx, (%rdi,%rdx,4) # 14*movsi_1/2 [length = 3]
movl16(%rsi), %eax # 15*movsi_1/1 [length = 3]
addq$4, %rsi# 17*adddi_1_rex64/1[length = 4]
movl%eax, 4(%rdi,%rdx,4)# 16*movsi_1/2 [length = 4]
addq$4, %rdx# 18*adddi_1_rex64/1[length = 4]
cmpq$8, %rdx# 20cmpdi_1_insn_rex64/1[length = 4]
jne .L47# 21*jcc_1 [length = 2]
rep ; ret # 40return_internal_long[length = 1]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729
[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound
--- Comment #2 from scovich at gmail dot com 2007-07-11 16:37 --- Regression: gcc-4.1.2 outputs the expected code for all test cases -- scovich at gmail dot com changed: What|Removed |Added Summary|Loop unrolling not performed|Regression: Loop unrolling |with large constant loop|not performed with large |bound |constant loop bound http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #12 from kargl at gcc dot gnu dot org 2007-07-11 17:01 --- (In reply to comment #11) We need to make a choice between these two, and decided whether all arguments have the same type (my preferred choice) or if some have a fixed type. In all cases, uses of MVBITS with different mixed kinds should be audited, for there might be a few other inconsistencies lurking here. FROM and TO are integer and these must have the same kind type parameter. The other arguments are simply specified to be of type integer. However, these are restricted by BITSIZE(FROM). INTEGER*4 is clearly large enough. So, we could walk the argument in iresolve.c(gfc_resolve_mvbits) and forcefully convert the remaining args to INTEGER*4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug tree-optimization/32720] No coalesce ssa_names
--- Comment #8 from rosana07a at gmail dot com 2007-07-11 17:32 --- Works with 4.2.1 ' making this a regression Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2.1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-nls --disable-checking --disable-werror --disable-multilib --disable-libunwind-exceptions --disable-decimal-float --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-libgcc-math --enable-languages=c,c++,fortran --with-cpu=pentium3 --with-system-zlib --enable-clocale=gnu Thread model: posix gcc version 4.2.1 20070704 (prerelease) /usr/libexec/gcc/i686-pc-linux-gnu/4.2.1/f951 lexlin.f90 -quiet -dumpbase lexlin.f90 -mtune=pentium3 -auxbase lexlin -O2 -version -I /usr/lib/gcc/i686-pc-linux-gnu/4.2.1/finclude -o lexlin.s GNU F95 version 4.2.1 20070704 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 4.2.1 20070704 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /usr/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o lexlin.o lexlin.s GNU assembler version 2.17.50.0.16 (i686-pc-linux-gnu) using BFD version (Linux/GNU Binutils) 2.17.50.0.16.20070511 -- rosana07a at gmail dot com changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug c++/32108] [4.2/4.3 regression] ICE with __label__ outside of block scope
--- Comment #2 from pcarlini at suse dot de 2007-07-11 18:00 --- Yes, seems doable. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32108
[Bug c++/32730] New: std::string.find(x, std::string::npos) searchs from begining of string
string.find returns results when it should not:
x=4294967295 Found:a test
x=4294967294 Found:a test
x=4294967293 Found:a test
x=4294967292 Not found
x=4294967291 Not found
x=4294967290 Not found
x=4294967289 Not found
x=4294967288 Not found
x=4294967287 Not found
x=4294967286 Not found
Also happens on gcc4.1.2 FreeBSD gcc2.95.2 Unixware 7.1 and gcc4.1.1 Linux 64
[~]$ g++ -v --save-temps -Wall -ansi -pedantic str3.cpp
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
str3.cpp -mtune=generic -ansi -Wall -pedantic -fpch-preprocess -o str3.ii
ignoring nonexistent directory
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/i386-redhat-linux
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.1.1/include
/usr/include
End of search list.
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -fpreprocessed str3.ii -quiet
-dumpbase str3.cpp -mtune=generic -ansi -auxbase str3 -Wall -pedantic -ansi
-version -o str3.s
GNU C++ version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa6f91b930c2d3bef702d56afc079b20
as -V -Qy -o str3.o str3.s
GNU assembler version 2.17.50.0.6-2.el5 (i386-redhat-linux) using BFD version
2.17.50.0.6-2.el5 20061020
/usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1
-L/usr/lib/gcc/i386-redhat-linux/4.1.1/../../.. str3.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crtn.o
#include iostream
#include string
#include climits
int main(int argc, char *argv[])
{
std::string a(this is a test);
std::string b(a t);
for(unsigned long x=ULONG_MAX; xULONG_MAX-10; --x)
{
std::string::size_type y=a.find(b, x);
if(y==std::string::npos)
{
std::cout x= x Not found\n;
}
else
{
std::cout x= x Found: a.substr(y) std::endl;
}
}
return 0;
}
--
Summary: std::string.find(x, std::string::npos) searchs from
begining of string
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #1 from gnu at bluedreamer dot com 2007-07-11 18:10 --- Created an attachment (id=13887) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13887action=view) Source file Example source that causes bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #2 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13888) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13888action=view) From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #3 from gnu at bluedreamer dot com 2007-07-11 18:11 --- Created an attachment (id=13889) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13889action=view) From --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug libstdc++/31401] string find behaves strange when searching from npos
--- Comment #7 from pcarlini at suse dot de 2007-07-11 18:20 --- *** Bug 32730 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||gnu at bluedreamer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string
--- Comment #4 from pcarlini at suse dot de 2007-07-11 18:20 --- *** This bug has been marked as a duplicate of 31401 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
[Bug libfortran/32731] New: pack/unpack with kind=1 or kind=2 mask
$ cat pack.f90 program main real, dimension(2,2) :: a a = 0 print *,pack(a,logical(a0,kind=1)) end program main $ gfortran pack.f90 ./a.out Fortran runtime error: Funny sized logical array $ cat unpack.f90 program main logical(kind=1),dimension(2,2) :: mask mask = .true. print *,unpack((/1,2,3,4/),mask,0) end program main $ gfortran unpack.f90 ./a.out Fortran runtime error: Funny sized logical array -- Summary: pack/unpack with kind=1 or kind=2 mask Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731
[Bug libfortran/32731] pack/unpack with kind=1 or kind=2 mask
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-11 18:38:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #4 from uros at gcc dot gnu dot org 2007-07-11 18:43 --- Subject: Bug 32661 Author: uros Date: Wed Jul 11 18:42:44 2007 New Revision: 126557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126557 Log: PR target/32661 * config/i386/sse.md (*sse2_storeq_rex64): Handle 64bit mem-reg moves. (*vec_extractv2di_1_sse2): Disable for TARGET_64BIT. (*vec_extractv2di_1_rex64): New insn pattern. testsuite/ChangeLog: PR target/32661 * gcc.target/i386/pr32661-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr32661-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #5 from ubizjak at gmail dot com 2007-07-11 18:47 --- (In reply to comment #3) This might be related to bug 32708 (and therefore have a similar fix?) Yes, DImode moves are implemented/fixed by the patch above. Your example now compiles to: movq(%rdi), %rax ret Other examples are shown in http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01077.html. SImode moves will be a bit harder, because shufps insn pattern is involved in the vector expansion. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||07/msg01077.html Status|NEW |ASSIGNED Last reconfirmed|2007-07-07 09:25:01 |2007-07-11 18:47:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug rtl-optimization/32725] Unnecessary reg-reg moves
--- Comment #2 from ubizjak at gmail dot com 2007-07-11 19:12 ---
This is due to reload. It is trying to solve following pattern
(insn:HI 25 24 28 2 pr32725.c:14 (parallel [
(set (reg:DI 75)
(and:DI (reg:DI 71)
(reg:DI 74)))
(clobber (reg:CC 17 flags))
]) 299 {*anddi_1_rex64} (expr_list:REG_DEAD (reg:DI 74)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
to following register constraints:
(define_insn *adddi_1_rex64
[(set (match_operand:DI 0 nonimmediate_operand =r,rm,r)
(plus:DI (match_operand:DI 1 nonimmediate_operand %0,0,r)
(match_operand:DI 2 x86_64_general_operand rme,re,le)))
(clobber (reg:CC FLAGS_REG))]
But it produces following mess:
(insn 95 24 25 2 pr32725.c:14 (set (reg:DI 3 bx [75])
(reg:DI 0 ax [74])) 82 {*movdi_1_rex64} (nil))
(insn:HI 25 95 96 2 pr32725.c:14 (parallel [
(set (reg:DI 3 bx [75])
(and:DI (reg:DI 3 bx [75])
(reg:DI 37 r8 [71])))
(clobber (reg:CC 17 flags))
]) 299 {*anddi_1_rex64} (nil))
(insn 96 25 33 2 pr32725.c:14 (set (reg:DI 0 ax)
(reg:DI 3 bx [75])) 82 {*movdi_1_rex64} (nil))
Ideally, output reg should be matched to dead reg 74 (due to % modifier) and
this would fix the whole sequence.
Perhaps a reload expert will be interested in this PR ;)
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||bonzini at gnu dot org
Status|UNCONFIRMED |NEW
Component|middle-end |rtl-optimization
Ever Confirmed|0 |1
Keywords||ra
Last reconfirmed|-00-00 00:00:00 |2007-07-11 19:12:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug rtl-optimization/21202] Extra register moves generated with long long
--- Comment #5 from ubizjak at gmail dot com 2007-07-11 19:20 --- Fixed in 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21202
[Bug rtl-optimization/32725] Unnecessary reg-reg moves
--- Comment #3 from bonzini at gnu dot org 2007-07-11 19:49 --- First, I'm not a reload expert. :-) But it does not look like a reload bug (or at least it is easily worked around in the machine description, methinks). regmove should have changed that but it does not probably because the final constraint does not have a duplicate operand. Actually, I think you want to look at anddi_1_rex64, not adddi_1_rex64: [(set (match_operand:DI 0 nonimmediate_operand =r,rm,r,r) (and:DI (match_operand:DI 1 nonimmediate_operand %0,0,0,qm) (match_operand:DI 2 x86_64_szext_general_operand Z,re,rm,L))) (clobber (reg:CC FLAGS_REG))] The final constraint is for when and is used to create a zero-extending moves (L matches constants 0xFF and 0x). I would say that you have to 1) define a predicate which has the same behavior as L and 2) split that alternative out of the three anddi patterns that use it (grep for '\L\') into a separate insn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-07-11 20:10 --- Can someone paste the output of debug_generic_stmt (to) and debug_tree(to) at the point of failure? (gdb) p debug_tree(to) var_decl 0x557f7114 vn_top.181 type void_type 0x55716804 void sizes-gimplified visited VOID align 8 symtab 0 alias set 36 canonical type 0x55716804 pointer_to_this pointer_type 0x55716870 used ignored VOID file ../c87b26b.adb line 4 align 8 $4 = void (gdb) p debug_generic_stmt(to) vn_top.181 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args
--- Comment #6 from scovich at gmail dot com 2007-07-11 20:27 --- (In reply to comment #5) SImode moves will be a bit harder, because shufps insn pattern is involved in the vector expansion. IIRC, shufps takes 3 cycles on Core2 (http://www.agner.org/optimize/instruction_tables.pdf), even without the operand type mismatch (does that still exist?). That's =4 cycles. Storing the vector to stack and load the desired entry would take =4 cycles, even without Intel's store-load optimizations, and I imagine the optimizer would be able to deal with it better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661
[Bug rtl-optimization/32725] Unnecessary reg-reg moves
--- Comment #4 from rask at sygehus dot dk 2007-07-11 20:45 --- In reply to comment #2: Reload is unable to use a register with a REG_DEAD note for an output reload. Look at the functions find_reload_regs(), order_regs_for_reload() and find_reg() and pay attention to how they use chain-dead_or_set and bad_spill_regs. Several years ago, the reg sets chain-live_throughout and chain-dead_or_set were instead chain-live_before and chain-live_after and it would have been easy to fix something like this. I think. But IMHO, this is something which local-alloc or global-alloc should get right and not leave to reload. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-07-11 20:47 --- Something c++ specific, when compiled by gcc, the loop is unrolled just fine. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-11 20:47:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729
[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-07-11 20:56 ---
The following patch fixes the problem; I am not quite sure why this check is
there.
Index: cfghooks.c
===
*** cfghooks.c (revision 126547)
--- cfghooks.c (working copy)
*** tidy_fallthru_edges (void)
*** 838,845
bool
can_duplicate_block_p (basic_block bb)
{
- edge e;
-
if (!cfg_hooks-can_duplicate_block_p)
internal_error (%s does not support can_duplicate_block_p,
cfg_hooks-name);
--- 838,843
*** can_duplicate_block_p (basic_block bb)
*** 847,858
if (bb == EXIT_BLOCK_PTR || bb == ENTRY_BLOCK_PTR)
return false;
- /* Duplicating fallthru block to exit would require adding a jump
- and splitting the real last BB. */
- e = find_edge (bb, EXIT_BLOCK_PTR);
- if (e (e-flags EDGE_FALLTHRU))
- return false;
-
return cfg_hooks-can_duplicate_block_p (bb);
}
--- 845,850
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729
[Bug fortran/32732] New: [Bind C] Character scalars are passed as arrays
| subroutine foo(a) bind(c)
|character(len=1,kind=c_char), value :: a
Has a single, scalar argument a; in C notation:
| void foo(char a)
gfortran, however, uses
| void foo(char a[])
with length one.
This causes problems on IA-64 HP-UX, see thread starting at
http://gcc.gnu.org/ml/fortran/2007-07/msg00210.html
(If a is a scalar, one needs to audit also all character uses to make sure
that one does use it as such (and does not compile Fortran if(a /= 5) into C
if(*a != 5) as a is not a pointer.)
Additionally, If the function is called, the length is additionally passed to
the function:
| call foo(a)
produces:
| foo(a, 1) // 'a' array, not zero terminated
instead of
| foo('a')
As the length arguments come always last and are not used, this seems to be
harmless, but there might be platforms or scenarios where they may cause
problems.
--
Summary: [Bind C] Character scalars are passed as arrays
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #4 from jaydub66 at gmail dot com 2007-07-11 21:39 --- Paul, I tested your patch, and indeed it does fix the problem for me. I also checked it for regressions, and it doesn't seem to break anthing. Cheers, Janus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug libfortran/32731] pack/unpack with kind=1 or kind=2 mask
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-11 21:41 --- Created an attachment (id=13890) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13890action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-11 21:42 --- The proposed patch (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01098.html) breaks library compatibility. Is this intentional? -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug ada/32733] New: g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12
Ada (revision 126547) fails bootstrap on i386-unknown-netbsdelf3.1: /gcctmp/agcc070711/build/./gcc/xgcc -B/gcctmp/agcc070711/build/./gcc/ -B/usr/local/i386-unknown-netbsdelf3.1/bin/ -B/usr/local/i386-unknown-netbsdelf3.1/lib/ -isystem /usr/local/i386-unknown-netbsdelf3.1/include -isystem /usr/local/i386-unknown-netbsdelf3.1/sys-include -c -g -O2 -W -Wall -gnatpg g-spipat.adb -o g-spipat.o g-spipat.adb: In function 'GNAT.SPITBOL.PATTERNS.XMATCHD': g-spipat.adb:1302: warning: 'anonymous' may be used uninitialized in this function g-spipat.adb:1302: note: 'anonymous' was declared here g-spipat.adb:5221: warning: 'S' may be used uninitialized in this function g-spipat.adb:5221: warning: 'GNAT.SPITBOL.PATTERNS.XMATCHD.L_70.T2464B' may be used uninitialized in this function g-spipat.adb:5002: warning: 'ASSIGN_ONM' may be used uninitialized in this function g-spipat.adb:4959: warning: 'LENGTH' may be used uninitialized in this function g-spipat.adb:4955: warning: 'NODE' may be used uninitialized in this function g-spipat.adb:1306: warning: 'STOP' may be used uninitialized in this function g-spipat.adb:1306: note: 'STOP' was declared here g-spipat.adb:1305: warning: 'START' may be used uninitialized in this function g-spipat.adb:1305: note: 'START' was declared here g-spipat.adb: In function 'GNAT.SPITBOL.PATTERNS.ALTERNATE': g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12 for SSA_NAME: NMT.17854_68 in statement: NMT.17854_209 = PHI NMT.17854_150(7), NMT.17854_68(8), NMT.17854_68(11), NMT.17854_68(12) PHI argument NMT.17854_68 for PHI node NMT.17854_209 = PHI NMT.17854_150(7), NMT.17854_68(8), NMT.17854_68(11), NMT.17854_68(12) +===GNAT BUG DETECTED==+ | 4.3.0 20070711 (experimental) (i386-unknown-netbsdelf3.1) GCC error: | | verify_ssa failed| | Error detected around g-spipat.adb:1597 | [...] ./xgcc -B./ -v Reading specs from ./specs Target: i386-unknown-netbsdelf3.1 Configured with: ../gcc/configure --enable-languages=c,ada Thread model: posix gcc version 4.3.0 20070711 (experimental) The source tree has the following patch applied to fix an unrelated bootstrap problem on NetBSD: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02159.html -- Summary: g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cato at df dot lth dot se GCC build triplet: i386-unknown-netbsdelf3.1 GCC host triplet: i386-unknown-netbsdelf3.1 GCC target triplet: i386-unknown-netbsdelf3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #7 from paolo at gcc dot gnu dot org 2007-07-11 21:52 --- Subject: Bug 31027 Author: paolo Date: Wed Jul 11 21:52:04 2007 New Revision: 126558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126558 Log: 2007-07-11 Paolo Carlini [EMAIL PROTECTED] PR c++/31027 * g++.dg/inherit/virtual4.C: New. Added: trunk/gcc/testsuite/g++.dg/inherit/virtual4.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug fortran/32035] 'anonymous' may be used uninitialized in this function
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-11 21:54 --- I think it was decided that until 4.3 is released, we don't care about libgfortran ABI stability (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00927.html) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #8 from paolo at gcc dot gnu dot org 2007-07-11 21:54 --- Subject: Bug 31027 Author: paolo Date: Wed Jul 11 21:54:36 2007 New Revision: 126559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126559 Log: 2007-07-11 Paolo Carlini [EMAIL PROTECTED] PR c++/31027 * g++.dg/inherit/virtual4.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/virtual4.C Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug c++/31027] [4.1 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #9 from pcarlini at suse dot de 2007-07-11 21:56 --- Doesn't fail anymore in mainline and 4_2-branch. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression]|[4.1 regression] Compiler |Compiler segfaults in simple|segfaults in simple virtual |virtual inheritance |inheritance situation |situation | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
Re: [Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
The only way i can see this happening is if you have a truly uninitialized variable, or there is something we have missed. Does this function have cfun-static_chain_decl being used, and we have a copy of that here? It is theoretically safe to call set_ssa_to_val with to == vn_top, but it's probably a bug somewhere, and i'd rather eliminate the bug cases before turning it off. On 11 Jul 2007 20:10:10 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-07-11 20:10 --- Can someone paste the output of debug_generic_stmt (to) and debug_tree(to) at the point of failure? (gdb) p debug_tree(to) var_decl 0x557f7114 vn_top.181 type void_type 0x55716804 void sizes-gimplified visited VOID align 8 symtab 0 alias set 36 canonical type 0x55716804 pointer_to_this pointer_type 0x55716870 used ignored VOID file ../c87b26b.adb line 4 align 8 $4 = void (gdb) p debug_generic_stmt(to) vn_top.181 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-11 22:20 --- Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022 The only way i can see this happening is if you have a truly uninitialized variable, or there is something we have missed. Does this function have cfun-static_chain_decl being used, and we have a copy of that here? It is theoretically safe to call set_ssa_to_val with to == vn_top, but it's probably a bug somewhere, and i'd rather eliminate the bug cases before turning it off. On 11 Jul 2007 20:10:10 -, ebotcazou at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-07-11 20:10 --- Can someone paste the output of debug_generic_stmt (to) and debug_tree(to) at the point of failure? (gdb) p debug_tree(to) var_decl 0x557f7114 vn_top.181 type void_type 0x55716804 void sizes-gimplified visited VOID align 8 symtab 0 alias set 36 canonical type 0x55716804 pointer_to_this pointer_type 0x55716870 used ignored VOID file ../c87b26b.adb line 4 align 8 $4 = void (gdb) p debug_generic_stmt(to) vn_top.181 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-07-11 22:21 --- Just for the record: The bug disappeared between 2007-06-23 and 2007-07-02. I'd guess this was fixed by 2007-07-01 Ollie Wild [EMAIL PROTECTED] * name-lookup.c (ambiguous_decl): Fix case when new-value is hidden. (select_decl): Remove function. (unqualified_namespace_lookup): Populate binding by calling ambiguous_decl. Remove select_decl call. (lookup_qualified_name): Remove select_decl call. * decl.c (lookup_and_check_tag): Check for ambiguous references. * parser.c (cp_parser_elaborated_type_specifier): Skip redundant error generation when name lookup is ambiguous. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106
[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-07-11 22:28 --- Btw, the bug disappeared on mainline between 2007-05-13 and 2007-05-26. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace
--- Comment #3 from pcarlini at suse dot de 2007-07-11 22:37 --- Thanks Volker. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106
[Bug c++/32232] [4.1 Regression] ICE in resolve_overloaded_unification
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-07-11 23:04
---
Mark, I don't think the fix for this PR is complete, because the following
simplified testcase (which previously ICE'd) should compile IMHO:
=
templatetypename struct A
{
A operator(void (*)(A));
};
templatetypename T AT operator(AT, const AT);
templatetypename T void foo(AT);
void bar()
{
Aint() (1, fooint);
}
=
But it is rejected with the following error message:
bug.cc: In function 'void bar()':
bug.cc:12: error: no match for 'operator' in 'Aint() (0, fooint)'
bug.cc:3: note: candidates are: A template-parameter-1-1 A
template-parameter-1-1 ::operator(void (*)(A template-parameter-1-1
)) [with template-parameter-1-1 = int]
An even smaller testcase for this problem is the following:
=
struct A
{
A operator(void (*)(A));
};
templatetypename void foo(A);
void bar()
{
A() (1, fooint);
}
=
bug.cc: In function 'void bar()':
bug.cc:10: error: no match for 'operator' in 'A() (0, fooint)'
bug.cc:3: note: candidates are: A A::operator(void (*)(A))
The code compiles fine, if I remove the 0,.
Btw, there's another glitch in the error message:
The code contains (1, fooint), which is printed as (0, fooint)
in the error message.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #4 from dougkwan at google dot com 2007-07-11 23:15 --- Created an attachment (id=13891) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13891action=view) Patch for fixing byte swap optimization. I have tested this patch on i486-linux-gnu (C/C++ test suite only, full bootstrap to be done). The problem was reported on m68k initially but I checked that it also appeared on i486. The patched have been tested to work on i486-linux-gnu and powerpc64-unknown-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index
--- Comment #12 from rob1weld at aol dot com 2007-07-12 00:55 --- I am building on target i686-pc-linux-gnu and have not noticed this problem with this target. It does NOT occur for a 'regular' make, only seems to happen with this last make profiledbootstrap that I did: We have a problem of 'doubling up the directories'. This _always_ occurs for platform i686-pc-cygwin as described here (with a FIX): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341 That means I have these directories when the build crashed: /opt/gcc-4_3-build/stage1-gcc/stage1-gcc/ /opt/gcc-4_3-build/stage1-i686-pc-linux-gnu/stage1-i686-pc-linux-gnu/ /opt/gcc-4_3-build/stage1-intl/stage1-intl/ /opt/gcc-4_3-build/stage1-libcpp/stage1-libcpp/ /opt/gcc-4_3-build/stage1-libdecnumber/stage1-libdecnumber/ /opt/gcc-4_3-build/stage1-libiberty/stage1-libiberty/ /opt/gcc-4_3-build/stage1-zlib/stage1-zlib/ That wastes a huge amount of space if the makefiles are double building everything and not deleting (or merging) unused directories as it goes. This is likely causing the BCF, the *.gcda not found, execution counts estimated problem, and other related errors. You say compiler now bootstraps, I hope that means the 'doubling' is fixed since it could knock out builds on smaller (or nearly full) HDs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #33 from kkojima at gcc dot gnu dot org 2007-07-12 01:11 --- It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c and the patch 126487 breaks gcc.c-torture/compile/2804-1.c on 4.2 for SH. Both failures happen only with -O0. It looks ia64 testresults show similar errors: http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00309.html http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00446.html on 4.2. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug c++/32734] New: bogus template with C linkage from erroneous #line directives
While attempting to compile Xerces 2.7 on MacOS, I discovered what I think is a bug in gcc, which I'm using for all phases of build. The c++ preprocessor is emitting line number statements which have an inconsistent number of arguments after the file name, e.g.: # 1 /usr/include/xercesc/util/XMLEnumerator.hpp 1 3 4 vs. # 25 /usr/include/xercesc/util/XMLEnumerator.hpp 3 4 and, in the former case (with the extra number), it seems to introduce some compiler behavior where a subsequent template class definition will be rejected with the misguiding error message template with C linkage. I have whittled the problem down to a single preprocessed source file that exhibits this problem - will try to attach it once I can figure out Bugzilla's UI. Thanks for your help and advice! Alan -- Summary: bogus template with C linkage from erroneous #line directives Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pitaman at austin dot rr dot com GCC host triplet: Mac OS 10.4 GCC target triplet: native http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
[Bug c++/32734] bogus template with C linkage from erroneous #line directives
--- Comment #1 from pitaman at austin dot rr dot com 2007-07-12 01:13 --- Created an attachment (id=13892) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13892action=view) simple C++ input file that shows the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
[Bug c++/32734] bogus template with C linkage from erroneous #line directives
--- Comment #2 from pitaman at austin dot rr dot com 2007-07-12 01:14 --- Created an attachment (id=13893) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13893action=view) minor tweaking of c++ preprocessor output which fixes the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
[Bug c++/32734] bogus template with C linkage from erroneous #line directives
--- Comment #3 from pitaman at austin dot rr dot com 2007-07-12 01:14 --- zeus:~/projects/xerces-c-src_2_7_0 pitaman$ gcc fails.cpp /usr/include/xercesc/util/XMLEnumerator.hpp:2: error: template with C linkage zeus:~/projects/xerces-c-src_2_7_0 pitaman$ gcc succeeds.cpp /usr/bin/ld: Undefined symbols: _main collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
[Bug c++/32734] bogus template with C linkage from erroneous #line directives
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-12 01:25 --- How did /usr/include/xercesc come to exist? Was it there before compiling Xerces or did it use that as the default path for install? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
[Bug c++/32735] New: i686 sse2 generates more movdqa than necessary
Test program attached. Command line: [EMAIL PROTECTED]:~/exp-sum-delta$ /home/mec/gcc-4.3-20070707/install/bin/g++ -v -S -O2 -msse2 sum-delta.cc Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/mec/gcc-4.3-20070707/src/configure --build=i686-pc-linux- gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/home/mec/gcc-4 .3-20070707/install --enable-languages=c,c++,objc,obj-c++,treelang --with-gmp=/h ome/mec/gmp-4.2.1/install --with-mpfr=/home/mec/mpfr-2.2.1/install Thread model: posix gcc version 4.3.0 20070707 (experimental) /home/mec/gcc-4.3-20070707/install/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1plus -quiet -v -D_GNU_SOURCE sum-delta.cc -quiet -dumpbase sum-delta.cc -msse2 -mtune =generic -auxbase sum-delta -O2 -version -o sum-delta.s ignoring nonexistent directory /home/mec/gcc-4.3-20070707/install/lib/gcc/i686- pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../ include/c++/4.3.0 /home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../ include/c++/4.3.0/i686-pc-linux-gnu /home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../ include/c++/4.3.0/backward /usr/local/include /home/mec/gcc-4.3-20070707/install/include /home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/include /home/mec/gcc-4.3-20070707/install/lib/gcc/i686-pc-linux-gnu/4.3.0/include-fixe d /usr/include End of search list. GNU C++ version 4.3.0 20070707 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070707 (experimental), GMP version 4.2 .1, MPFR version 2.2.1. warning: GMP header version 4.2.1 differs from library version 4.1.4. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 1338ea4083517ffee92283f96caf8872 === The loop for CallSumDeltas2 compiles to: .L7: movdqa %xmm1, %xmm0 pslldq $4, %xmm0 addl$1, %eax paddd %xmm1, %xmm0 cmpl$1, %eax movdqa %xmm0, %xmm1 pslldq $8, %xmm1 paddd %xmm1, %xmm0 movdqa %xmm0, %xmm1 movdqa %xmm0, foo1 jne .L7 === This is two more movdqa then the hand-written code in CallSumDeltas3. -- Summary: i686 sse2 generates more movdqa than necessary Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mec at google dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #1 from mec at google dot com 2007-07-12 01:30 --- Created an attachment (id=13894) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13894action=view) Test program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #2 from mec at google dot com 2007-07-12 01:31 --- Created an attachment (id=13895) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13895action=view) Generated code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #3 from mec at google dot com 2007-07-12 01:33 --- Created an attachment (id=13896) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13896action=view) Assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug c++/32735] i686 sse2 generates more movdqa than necessary
--- Comment #4 from mec at google dot com 2007-07-12 01:33 --- Created an attachment (id=13897) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13897action=view) Assembly code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
[Bug tree-optimization/32663] [4.3 regression]: revision 126369 went into an infinite loop
--- Comment #12 from dberlin at gcc dot gnu dot org 2007-07-12 02:20 --- Subject: Bug 32663 Author: dberlin Date: Thu Jul 12 02:20:04 2007 New Revision: 126568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126568 Log: 2007-07-11 Daniel Berlin [EMAIL PROTECTED] PR tree-optimization/32663 * tree.h (VALUE_HANDLE_VUSES): Remove. (struct tree_value_handle): Remove vuses. * tree-vn.c (create_value_handle_for_expr): Don't set VALUE_HANDLE_VUSES. * tree-ssa-pre.c (expression_vuses): New. (alloc_expression_id): Set up expression_vuses. (get_expression_vuses): New. (set_expression_vuses): Ditto. (clear_expression_ids): Modify for expression_vuses. (phi_translate_1): Ditto. (phi_translate_set): Ditto. (value_dies_in_block_x): Ditto (valid_in_sets): Ditto. (add_to_sets): Ditto. (find_existing_value_expr): Ditto. (create_value_handle_for_expr): Ditto. (make_values_for_stmt): Ditto. (vuse_equiv): Remove. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr32663.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21559.c trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vn.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-12 04:58 --- (In reply to comment #4) No error up to and including r126496. That leaves only Paul's patch ... Daniel, Could you please revert r126496 and re-open the PR? - I can do nothing about it for 10 days or more. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
