[Bug fortran/33338] ERROR MSG FOR "READ (11,FMT='(Q,A)'..." POINTS AT END-OF-LINE RATHER THAN AT Q.

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-09-08 07:16 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
  Known to fail||4.2.1 4.3.0
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 07:16:34
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

[Bug fortran/33343] ICE (segfault) on invalid code with wrongly shaped arguments to elemental procedures

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-09-08 07:19 ---
Confirmed.

Traceback:

#0  integer_onep (expr=0x0) at ../../../gcc/trunk/gcc/tree.c:1337
#1  0x080d0513 in gfc_conv_loop_setup (loop=0xbff16814)
at ../../../gcc/trunk/gcc/fortran/trans-array.c:3250
#2  0x080e653a in gfc_trans_assignment_1 (expr1=0x8928798, expr2=0x8929758, 
init_flag=0 '\0') at ../../../gcc/trunk/gcc/fortran/trans-expr.c:3972
#3  0x080e6a55 in gfc_trans_assignment (expr1=0x8928798, expr2=0x8929758, 
init_flag=20 '\024') at ../../../gcc/trunk/gcc/fortran/trans-expr.c:4152
#4  0x080e77b1 in gfc_trans_assign (code=0x8928948)
at ../../../gcc/trunk/gcc/fortran/trans-expr.c:4164
#5  0x080c7512 in gfc_trans_code (code=0x8928948)
at ../../../gcc/trunk/gcc/fortran/trans.c:970
#6  0x080de492 in gfc_generate_function_code (ns=0x8927ff8)
at ../../../gcc/trunk/gcc/fortran/trans-decl.c:3258
#7  0x080c498a in gfc_generate_module_code (ns=0x8926380)
at ../../../gcc/trunk/gcc/fortran/trans.c:1190
#8  0x080991c6 in gfc_parse_file ()
at ../../../gcc/trunk/gcc/fortran/parse.c:3316
#9  0x080c023d in gfc_be_parse_file (set_yydebug=0)
at ../../../gcc/trunk/gcc/fortran/f95-lang.c:300
#10 0x08344908 in toplev_main (argc=2, argv=0xbff16d74)
at ../../../gcc/trunk/gcc/toplev.c:1045
#11 0x08108ccf in main (argc=-1212603072, argv=0x0)
at ../../../gcc/trunk/gcc/main.c:35


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 07:19:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33343

[Bug fortran/33334] User-defined type as function result: use-assocciated not accepted

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-09-08 08:09 ---
This probably needs the same technique as PR31229 / PR31154.

The following program is valid, but rejected by gfortran (also if one does not
rename the symbol):

  func%i = 5
 1
Error: Derived type 'z' at (1) is being used before it is defined
a.f90:7.21:

type(z) function func()
1
Error: The derived type 'func' at (1) is of type 'z', which has not been
defined


module x
 type t
   integer :: i
 end type t
end module x

type(z) function func()
  use x, only: z=>t
  func%i = 5
end function func


This program is accepted by NAG f95, g95, ifort, openf95 and sunf95.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||32834
  nThis||
   Keywords||rejects-valid
Summary|User-defined type as|User-defined type as
   |function result in an   |function result: use-
   |interface: Accepts invalid  |assocciated not accepted


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4

[Bug c++/33350] copy constructor error

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-09-08 09:15 ---
Yes the copy constructor is going to be called implicately here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350

[Bug middle-end/33351] segfault in assembler function

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-09-08 09:16 ---
Can you provide the output of "/home/marcus/projects/gcc/BIN/bin/gcc -v"?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351

[Bug tree-optimization/33301] wrong vectorization factor due to an invariant type-promotion in the loop

[dorit at gcc dot gnu dot org]

--- Comment #1 from dorit at gcc dot gnu dot org  2007-09-08 09:19 ---
Subject: Bug 33301

Author: dorit
Date: Sat Sep  8 09:19:39 2007
New Revision: 128265

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128265
Log:
PR tree-optimization/33301
* tree-vect-analyze (analyze_operations): Look at the type of the rhs
when relevant.


Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr33301.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-analyze.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33301

[Bug tree-optimization/33301] wrong vectorization factor due to an invariant type-promotion in the loop

[dorit at gcc dot gnu dot org]

--- Comment #2 from dorit at gcc dot gnu dot org  2007-09-08 09:23 ---
fix committed


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33301

[Bug tree-optimization/33299] [4.3 Regression] miscompilation with gfortran -O2 -ffast-math -ftree-vectorize

[dorit at gcc dot gnu dot org]

--- Comment #6 from dorit at gcc dot gnu dot org  2007-09-08 09:24 ---
fix committed


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299

[Bug bootstrap/33352] New: invalid rtl sharing -- bootstrap failure compiling libgomp/team.c on i386

[gerald at pfeifer dot com]

I have a hunch this only happens on i386, not i586, which is why nobody 
else has seen this so far:

/sw/test/GCC/trunk/libgomp/team.c: In function 'gomp_thread_start':
/sw/test/GCC/trunk/libgomp/team.c:131: error: invalid rtl sharing found in the
insn
(insn 22 21 23 2 /sw/test/GCC/trunk/libgomp/team.c:89 (parallel [
(set (reg:SI 74)
(plus:SI (reg:SI 70)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags
0x22] )
] 5)
(const_int 8 [0x8])
(clobber (reg:CC 17 flags))
]) 170 {*addsi_1} (nil))
/sw/test/GCC/trunk/libgomp/team.c:131: error: shared rtx
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0x22] )
] 5)
(const_int 8 [0x8])))
/sw/test/GCC/trunk/libgomp/team.c:131: internal compiler error: internal
consistency failure


-- 
   Summary: invalid rtl sharing -- bootstrap failure compiling
libgomp/team.c on i386
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
  GCC host triplet: i386-unknown-freebsd5.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33352

[Bug tree-optimization/33320] ICE with vectorization in the testsuite during dataref analysis

[dorit at gcc dot gnu dot org]

--- Comment #2 from dorit at gcc dot gnu dot org  2007-09-08 09:42 ---
(In reply to comment #1)
> (In reply to comment #0)
> > When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with 
> > vectorization it
> > ICes when the dataref analysis called from vectorizer:
> I can't get the compiler (current mainline) to segfault with the compile flags
> form the description on x86_64-pc-linux-gnu or i686-pc-linux-gnu (with and
> without -msse2).

I can't reproduce it anymore either... I actually opened this PR at least a
week after I saw this failure, so maybe it got fixed in the meantime? I guess
I'll close it then.


-- 

dorit at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33320

[Bug c++/33342] [4.3 Regression] ICE in dependent_type_p, at cp/pt.c:15081

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2007-09-08 11:14 ---
Thanks. The patch passes regtesting.

Maybe Andrew can help us for a reduced testcase?


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33342

[Bug fortran/33341] unnecessary stores for array constructor

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-09-08 11:32 ---
An equivalent C testcase eliminates the array stores:

int foo(int *a,int *b,int *c,int *d)
{
int val[3];
val[0] = *a;
val[1] = *b;
val[2] = *c;
return (val[0] != *d) && (val[1] != *d) && (val[2] != *d);
}
$ gcc -O3 -fdump-tree-optimized -S compare.c 
$ cat compare.c.116t.optimized 

;; Function foo (foo)

Analyzing Edge Insertions.

Opportunities in BB 5 for stmt/block reduction:
Splitting BB 5 for Common stmt list.  Original block is now BB6.
D.1138 = 0;
  Edge (2->5) lands here.
  Edge (3->5) lands here.
foo (a, b, c, d)
{
  int D.1143;
  int D.1138;
  int D.1137;
  int D.1136;

:
  D.1136 = *b;
  D.1137 = *c;
  D.1143 = *d;
  if (*a == D.1143)
goto ;
  else
goto ;

:
  if (D.1136 == D.1143)
goto ;
  else
goto ;

:
  (void) 0;
  D.1138 = (int) !(D.1137 == D.1143);
  goto ;

:
  D.1138 = 0;

:
  return D.1138;

}

$ gcc -O3 -fdump-tree-optimized -S compare.c 
$ cat compare.c.116t.optimized 

;; Function foo (foo)

Analyzing Edge Insertions.

Opportunities in BB 5 for stmt/block reduction:
Splitting BB 5 for Common stmt list.  Original block is now BB6.
D.1138 = 0;
  Edge (2->5) lands here.
  Edge (3->5) lands here.
foo (a, b, c, d)
{
  int D.1143;
  int D.1138;
  int D.1137;
  int D.1136;

:
  D.1136 = *b;
  D.1137 = *c;
  D.1143 = *d;
  if (*a == D.1143)
goto ;
  else
goto ;

:
  if (D.1136 == D.1143)
goto ;
  else
goto ;

:
  (void) 0;
  D.1138 = (int) !(D.1137 == D.1143);
  goto ;

:
  D.1138 = 0;

:
  return D.1138;

}


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341

[Bug target/33329] [4.3 Regression] ICE in expand_simple_binop, at optabs.c:1294

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2007-09-08 11:33 ---
Subject: Bug 33329

Author: uros
Date: Sat Sep  8 11:33:08 2007
New Revision: 128269

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128269
Log:
PR target/33329
PR target/26449
* config/i386/sse.md (mulv4si3): Do not expand sse2 sequence.
(*sse2_mulv4si3): New define_insn_and_split pattern. Split insn in
split1 pass.
(mulv16qi3): Implement as define_insn_and_split pattern instead of
define_expand, to split insn in split1 pass.
(mulv2di3): Ditto.

testsuite/ChangeLog:

PR target/33329
PR target/26449
* gcc.target/i386/pr33329.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr33329.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33329

[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion

[uros at gcc dot gnu dot org]

--- Comment #14 from uros at gcc dot gnu dot org  2007-09-08 11:33 ---
Subject: Bug 26449

Author: uros
Date: Sat Sep  8 11:33:08 2007
New Revision: 128269

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128269
Log:
PR target/33329
PR target/26449
* config/i386/sse.md (mulv4si3): Do not expand sse2 sequence.
(*sse2_mulv4si3): New define_insn_and_split pattern. Split insn in
split1 pass.
(mulv16qi3): Implement as define_insn_and_split pattern instead of
define_expand, to split insn in split1 pass.
(mulv2di3): Ditto.

testsuite/ChangeLog:

PR target/33329
PR target/26449
* gcc.target/i386/pr33329.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr33329.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449

[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion

[ubizjak at gmail dot com]

--- Comment #15 from ubizjak at gmail dot com  2007-09-08 11:35 ---
Reopened. Ther is really no magic here.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449

[Bug fortran/33337] ICE in Sep 6 snapshot in gfc_finish_var_decl, at fortran/trans-decl.c:510

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-09-08 11:40 ---
Confirmed.

Backtrace:

(gdb) b fancy_abort
Breakpoint 1 at 0x817cfe0: file ../../../gcc/trunk/gcc/diagnostic.c, line 654.
(gdb) r mm.f90
Starting program: /home/ig25/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 mm.f90
 local_cum_nc_chisq
Breakpoint 1, fancy_abort (file=0x876a8e4
"../../../gcc/trunk/gcc/fortran/trans-decl.c", line=510, 
function=0x876adf0 "gfc_finish_var_decl") at
../../../gcc/trunk/gcc/diagnostic.c:654
654 {
(gdb) up
#1  0x080e0cf1 in gfc_finish_var_decl (decl=0xb7b1d05c, sym=0x8926b58) at
../../../gcc/trunk/gcc/fortran/trans-decl.c:510
510   gcc_assert (current_function_decl == NULL_TREE || sym->result ==
sym);
(gdb) p current_function_decl
$1 = (tree) 0xb7b1c180
(gdb) p *sym
$2 = {name = 0x892554c "the_chi_square", module = 0x89254f5 "cdf_nc_chisq_mod",
declared_at = {nextc = 0x88d7336 " = &", 
lb = 0x88d72f0}, ts = {type = BT_DERIVED, kind = 0, derived = 0x8926790, cl
= 0x0, is_c_interop = 0, is_iso_c = 0, 
f90_type = BT_DERIVED}, attr = {allocatable = 0, dimension = 0, external =
0, intrinsic = 0, optional = 0, pointer = 0, 
target = 0, value = 0, volatile_ = 0, dummy = 0, result = 0, assign = 0,
threadprivate = 0, not_always_present = 0, 
implied_index = 0, save = SAVE_IMPLICIT, data = 0, protected = 0, use_assoc
= 0, use_only = 0, imported = 0, 
in_namelist = 0, in_common = 0, in_equivalence = 0, function = 0,
subroutine = 0, procedure = 0, generic = 0, 
generic_copy = 0, implicit_type = 0, untyped = 0, is_bind_c = 0,
is_c_interop = 0, is_iso_c = 0, sequence = 0, 
elemental = 0, pure = 0, recursive = 0, unmaskable = 0, masked = 0,
contained = 0, mod_proc = 0, abstract = 0, 
noreturn = 0, entry = 0, entry_master = 0, mixed_entry_master = 0,
always_explicit = 0, referenced = 1, 
ambiguous_interfaces = 0, is_main_program = 0, access = ACCESS_UNKNOWN,
intent = INTENT_UNKNOWN, flavor = FL_PARAMETER, 
if_source = IFSRC_UNKNOWN, proc = PROC_UNKNOWN, cray_pointer = 0,
cray_pointee = 0, alloc_comp = 0, pointer_comp = 0, 
private_comp = 0, volatile_ns = 0x0}, generic = 0x0, component_access =
ACCESS_UNKNOWN, formal = 0x0, formal_ns = 0x0, 
  value = 0x8927410, as = 0x0, result = 0x0, components = 0x0, interface = 0x0,
cp_pointer = 0x0, common_next = 0x0, 
  common_head = 0x0, dummy_order = 0, entry_id = 0, namelist = 0x0,
namelist_tail = 0x0, old_symbol = 0x0, tlink = 0x0, 
  mark = 1, new = 0, equiv_built = 0, forall_index = 0, refs = 1, ns =
0x8925f68, backend_decl = 0x0, 
  from_intmod = INTMOD_NONE, intmod_sym_id = 0, binding_label = '\0' , common_block = 0x0}
(gdb) p sym->result
$3 = (struct gfc_symbol *) 0x0
(gdb) bt
#0  fancy_abort (file=0x876a8e4 "../../../gcc/trunk/gcc/fortran/trans-decl.c",
line=510, 
function=0x876adf0 "gfc_finish_var_decl") at
../../../gcc/trunk/gcc/diagnostic.c:654
#1  0x080e0cf1 in gfc_finish_var_decl (decl=0xb7b1d05c, sym=0x8926b58) at
../../../gcc/trunk/gcc/fortran/trans-decl.c:510
#2  0x080dfc1c in gfc_get_symbol_decl (sym=0x8926b58) at
../../../gcc/trunk/gcc/fortran/trans-decl.c:995
#3  0x080e8365 in gfc_conv_variable (se=0xbff0ec34, expr=0x89275a8) at
../../../gcc/trunk/gcc/fortran/trans-expr.c:404
#4  0x080e5821 in gfc_conv_expr (se=0xbff0ec34, expr=0x89275a8) at
../../../gcc/trunk/gcc/fortran/trans-expr.c:3292
#5  0x080e7af3 in gfc_conv_expr_val (se=0xbff0ec34, expr=0xb7b1c180) at
../../../gcc/trunk/gcc/fortran/trans-expr.c:3337
#6  0x080ea8c6 in gfc_conv_intrinsic_function_args (se=0xbff0f04c, expr=, argarray=0xbff0ec80, nargs=1)
at ../../../gcc/trunk/gcc/fortran/trans-intrinsic.c:209
#7  0x080ebe54 in gfc_conv_intrinsic_conversion (se=0xbff0f04c, expr=0x8927d78)
at ../../../gcc/trunk/gcc/fortran/trans-intrinsic.c:267
#8  0x080f2a89 in gfc_conv_intrinsic_function (se=0xbff0f04c, expr=0x8927d78)
at ../../../gcc/trunk/gcc/fortran/trans-intrinsic.c:3820
#9  0x080e5147 in gfc_conv_function_expr (se=0xbff0f04c, expr=0xb7b1d05c)
at ../../../gcc/trunk/gcc/fortran/trans-expr.c:2809
#10 0x080e5846 in gfc_conv_expr (se=0xbff0f04c, expr=0x8927d78) at
../../../gcc/trunk/gcc/fortran/trans-expr.c:3284
#11 0x080e688a in gfc_trans_assignment_1 (expr1=0x8927210, expr2=0x8927d78,
init_flag=0 '\0')
at ../../../gcc/trunk/gcc/fortran/trans-expr.c:4001
#12 0x080e6a55 in gfc_trans_assignment (expr1=0x8927210, expr2=0x8927d78,
init_flag=32 ' ')
at ../../../gcc/trunk/gcc/fortran/trans-expr.c:4152
#13 0x080e77b1 in gfc_trans_assign (code=0x8927280) at
../../../gcc/trunk/gcc/fortran/trans-expr.c:4164
#14 0x080c7512 in gfc_trans_code (code=0x8927280) at
../../../gcc/trunk/gcc/fortran/trans.c:970
#15 0x080de492 in gfc_generate_function_code (ns=0x8927698) at
../../../gcc/trunk/gcc/fortran/trans-decl.c:3258
#16 0x080c498a in gfc_generate_module_code (ns=0x8925f68) at
../../../gcc/trunk/gcc/fortran/trans.c:1190
#17 0x080991c6 in gfc_parse_file () at
../../../gcc/trunk/gcc/fortran/parse.c:3316
#18 0x080c023d in gfc_be_par

[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion

[uros at gcc dot gnu dot org]

--- Comment #16 from uros at gcc dot gnu dot org  2007-09-08 11:48 ---
Subject: Bug 26449

Author: uros
Date: Sat Sep  8 11:48:17 2007
New Revision: 128270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128270
Log:
PR rtl-optimization/26449
* gcc.target/i386/pr26449-1.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr26449-1.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449

[Bug rtl-optimization/26449] [4.2/4.3 Regression] ICE in loop invariant motion

[ubizjak at gmail dot com]

--- Comment #17 from ubizjak at gmail dot com  2007-09-08 11:51 ---
The testcase from comment #11 was added to the testsuite, but let's keep this
PR resolved as WORKSFORME for now. Please note that force_operand() will still
ICE for optabs with no handler.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449

[Bug target/33329] [4.3 Regression] ICE in expand_simple_binop, at optabs.c:1294

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2007-09-08 11:52 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||09/msg00668.html
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33329

[Bug rtl-optimization/33353] New: Vector RTL arithmetic operations with constant arguments are not fully folded.

[ubizjak at gmail dot com]

Following testcase from PR target/33329 shows the problem where gcc doesn't
fold vector arithmetic operations with constant arguments to a load of vector
constant. 

For clarity, sse4 will be used, but the same problem is present on sse2.

--cut here--
extern void g (int *);

void f (void)
{
  int tabs[8], tabcount;

  for (tabcount = 1; tabcount <= 8; tabcount += 7)
{
  int i;
  for (i = 0; i < 8; i++)
tabs[i] = 2 * i;
  g (tabs);
}
}
--cut here--

produces (gcc -O2 -msse4 -ftree-vectorize):

.LCFI2:
movdqa  .LC0(%rip), %xmm1
leaq16(%rsp), %rbp
movdqa  .LC1(%rip), %xmm0
paddd   .LC2(%rip), %xmm1
pmulld  %xmm1, %xmm0# 19*sse4_1_mulv4si3[length = 4]
movdqa  %xmm0, (%rsp)
.L2:
movdqa  .LC3(%rip), %xmm0   # 54
movq%rbp, %rdi
addl$1, %ebx
movdqa  (%rsp), %xmm2   # 55
movdqa  %xmm0, (%rbp)
movdqa  %xmm2, 16(%rbp)
callg
cmpl$2, %ebx
jne .L2

All instructions above the loop have constant arguments. This is evident from
combine RTL dump, where insn 19 is represented using following RTX:

(insn 19 17 25 2 pr33329.c:13 (set (reg:V4SI 78)
(mult:V4SI (reg:V4SI 77)
(reg:V4SI 73))) 1136 {*sse4_1_mulv4si3} (expr_list:REG_DEAD
(reg:V4S
I 73)
(expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 8 [0x8])
(const_int 10 [0xa])
(const_int 12 [0xc])
(const_int 14 [0xe])
])
(nil

Actually gcc already calculated correct const_vector value, but it looks like
it doesn't know what to do with it. For optimal code, insn #55 should load
vector constant from the constant pool in the same way as insn #54.


-- 
   Summary: Vector RTL arithmetic operations with constant arguments
are not fully folded.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33353

[Bug middle-end/33351] [4.3 Regression] segfault in assembler function

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-08 12:45 ---
Confirmed.

Program received signal SIGSEGV, Segmentation fault.
0x0842837c in reload_as_needed (live_known=1)
at /home/richard/src/trunk/gcc/reload1.c:4161
4161  if (p != insn && INSN_P (p)
(gdb) bt
#0  0x0842837c in reload_as_needed (live_known=1)
at /home/richard/src/trunk/gcc/reload1.c:4161
#1  0x08421375 in reload (first=0xb7cce680, global=1)
at /home/richard/src/trunk/gcc/reload1.c:1146
#2  0x08910765 in global_alloc () at /home/richard/src/trunk/gcc/global.c:683
#3  0x08914e4f in rest_of_handle_global_alloc ()
at /home/richard/src/trunk/gcc/global.c:2055
(gdb) print p
$1 = (rtx) 0x0
(gdb) call debug_rtx (insn)
(insn 11 29 12 2 t.i:12 (parallel [
(set (reg/f:SI 0 ax [orig:63 .fn ] [63])
(asm_operands/v:SI ("pushl %%ebp; pushl %3; movl %2,%%ebp; call
*%%eax; popl %%ebp; popl %%ebp") ("=a") 0 [
(reg/f:SI 0 ax [orig:63 .fn ] [63])
(reg:SI 4 si)
(reg:SI 5 di)
]
 [
(asm_input:SI ("0") ("") 0)
(asm_input:SI ("r") ("") 0)
(asm_input:SI ("r") ("") 0)
] ("t.i") 12))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg:QI 1 dx))
(clobber (reg:QI 2 cx))
]) -1 (expr_list:REG_DEAD (reg/f:SI 5 di [64])
(expr_list:REG_UNUSED (reg/f:SI 0 ax [orig:63 .fn ] [63])
(expr_list:REG_UNUSED (reg:QI 18 fpsr)
(expr_list:REG_UNUSED (reg:QI 17 flags)
(expr_list:REG_UNUSED (reg:QI 2 cx)
(expr_list:REG_UNUSED (reg:QI 1 dx)
(nil

I think this is because of the NEXT_INSN changes.

2007-09-05  Laurynas Biveinis  <[EMAIL PROTECTED]>

* regrename.c (copyprop_hardreg_forward_1): New variable next. Use
FOR_BB_INSNS_SAFE instead of for loop.
* cse.c (cse_extended_basic_block): Likewise.
* postreload.c (reload_cse_regs_1): New variable next. Make sure
that the for loop does not invoke NEXT_INSN on a deleted insn.
...


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||laurynas dot biveinis at
   ||gmail dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|i586-unknown-linux-gnu  |i?86-*-*
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 12:45:26
   date||
Summary|segfault in assembler   |[4.3 Regression] segfault in
   |function|assembler function
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351

[Bug tree-optimization/33344] if(!z) {a.b = x->b + 1; z = &a; } else if (!x) { a.b = z->b+1; x = &a; } use z->b and x->b; is not optimized

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-08 13:00 ---
It's currently not optimized because the simple phiprop does neither handle
component references nor inserts loads from pointers.

See the thread starting at
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html
on how to teach PRE to do a small set of possible transformations like this.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 13:00:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33344

[Bug fortran/33354] New: MINLOC in combination with SUM gives wrong result

[enok at lysator dot liu dot se]

A simple program should print "1" but prints "2". Of some reason MINLOC fails
to find the minium location (first location) for the SUM expression.

PROGRAM TST
  IMPLICIT NONE
  REAL :: A(1,3)
  A(:,1) = 10
  A(:,2) = 20
  A(:,3) = 30
  WRITE(*,*) SUM(A(:,1:3),1)
  WRITE(*,*) MINLOC(SUM(A(:,1:3),1),1)
END PROGRAM TST

bash%> gfortran -o tst tst.f90
bash%> ./tst
   10.0   20.0   30.0
   2
bash%>


-- 
   Summary: MINLOC in combination with SUM gives wrong result
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
 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=33354

[Bug rtl-optimization/32283] Missed induction variable optimization

[rakdver at gcc dot gnu dot org]

--- Comment #11 from rakdver at gcc dot gnu dot org  2007-09-08 13:19 
---
Subject: Bug 32283

Author: rakdver
Date: Sat Sep  8 13:18:49 2007
New Revision: 128272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128272
Log:
PR tree-optimization/32283
* tree-ssa-loop-ivopts.c (may_eliminate_iv): Use
estimated_loop_iterations.
(determine_use_iv_cost_condition): Decrease cost of expressions
used in iv elimination.

* gcc.dg/tree-ssa/loop-31.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-31.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283

[Bug c++/33355] New: GCC has an invalid pointer.

[shw_mail at wp dot pl]

Dears

I would like to send a bug which was explicit by compiling the code:

BOOST_STATIC_ASSERT (
typeid (::connection::SPLight).name()
== typeid(::connection::LightsStructure::value_type).name()
);

This line is wrong, but it causes that gcc is going out of compilation process
due to internal errors (see backtrace below).

Regards.

CC optimal_gls.cpp
optimal_gls.cpp: In function ‘std::ostream&
connection::operator<<(std::ostream&, const connection::LightsStructure&)’:
optimal_gls.cpp:370: error: `typeid' operator cannot appear in a
constant-expression
optimal_gls.cpp:388: error: template argument 1 is invalid
*** glibc detected *** /usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus:
free(): invalid pointer: 0x084aaef4 ***
=== Backtrace: =
/lib/libc.so.6[0x400b06d0]
/lib/libc.so.6(__libc_free+0x89)[0x400b1d59]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809980f]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8098f4c]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8097432]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80978a4]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809d25e]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809d751]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809db0a]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809dfcb]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8099958]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8099c70]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x809aef1]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a067e]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a08f4]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a0edb]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a184d]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a18ff]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a1aa9]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a1e30]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a23aa]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a06f4]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a08f4]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a355e]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a39f9]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a3647]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a39f9]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x80a3fe5]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8108a7a]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8389c9c]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8112092]
/lib/libc.so.6(__libc_start_main+0xd8)[0x40062838]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus[0x8049d11]
=== Memory map: 
08048000-08549000 r-xp  08:03 22296326  
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus
08549000-0854e000 rw-p 0050 08:03 22296326  
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1plus
0854e000-08688000 rw-p 0854e000 00:00 0  [heap]
4000-4001a000 r-xp  08:03 26409389   /lib/ld-2.5.so
4001a000-4001b000 r--p 00019000 08:03 26409389   /lib/ld-2.5.so
4001b000-4001c000 rw-p 0001a000 08:03 26409389   /lib/ld-2.5.so
4001c000-40023000 r--s  08:03 13415888  
/usr/lib/gconv/gconv-modules.cache
40023000-40024000 r--p  08:03 44117520  
/usr/lib/locale/pl_PL.utf8/LC_MESSAGES/SYS_LC_MESSAGES
40024000-4004c000 rw-p 40024000 00:00 0 
4004c000-4004d000 rw-p 4004c000 00:00 0 
4004d000-4016f000 r-xp  08:03 26409409   /lib/libc-2.5.so
4016f000-4017 r--p 00122000 08:03 26409409   /lib/libc-2.5.so
4017-40172000 rw-p 00123000 08:03 26409409   /lib/libc-2.5.so
40172000-40176000 rw-p 40172000 00:00 0 
40176000-401b1000 r--p  08:03 21037921  
/usr/lib/locale/pl_PL.utf8/LC_CTYPE
401b1000-418ad000 rw-p 401b1000 00:00 0 
418dd000-418e7000 r-xp  08:03 44228654  
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1
418e7000-418e8000 rw-p 9000 08:03 44228654  
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1
4190-41921000 rw-p 4190 00:00 0 
41921000-41a0 ---p 41921000 00:00 0 
bffe8000-bfffe000 rw-p bffe8000 00:00 0  [stack]
e000-f000 ---p  00:00 0  [vdso]
optimal_gls.cpp:370: confused by earlier errors, bailing out
make[1]: *** [optimal_gls.o] Błąd 1


-- 
   Summary: GCC has an invalid pointer.
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shw_mail at wp dot pl


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug fortran/31547] Document when CPP is called and document the f95-cpp-input option

[patchapp at dberlin dot org]

--- Comment #2 from patchapp at dberlin dot org  2007-09-08 14:00 ---
Subject: Bug number PR31547

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00684.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31547

Configure PATH error in attempting GCC installation

[Haroldo C G Pereira]

Dear Sir
I would like to know how to correct this bug
Thank you for your attention
Haroldo C G Pereira


   

Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

Configure execution error on gcc installation .odt
Description: 51650238-Configure execution error on gcc installation .odt

[Bug c++/33355] GCC has an invalid pointer.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-08 14:45 ---
Can you please attach preprocessed source for a testcase triggering this?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug c++/33314] Ill-formed program compiles without error. Ternary (expr.cond) operands, ambiguous conversion.

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2007-09-08 15:20 ---
You omit the part of the section that talks about lvalues and rvalues. That
part clarifies which of the conversions is to be taken here.

If you really want to make your program ambiguous do this:
---
  const char *p="";
  MyString s1 = (isEmpty) ? p : s0;
---
Now the first argument is an lvalue and the conversions become ambiguous.
W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33314

[Bug c++/33176] strange diagnostic with "if (a) && b"

[bangerth at dealii dot org]

--- Comment #5 from bangerth at dealii dot org  2007-09-08 15:25 ---
I think there is very little that can be done here given the gcc extension
of taking the address of labels.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33176

[Bug c++/33226] class name permitted in enum

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2007-09-08 15:27 ---
Yes, this is allowed.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33226

[Bug c++/33355] GCC has an invalid pointer.

[shw_mail at wp dot pl]

--- Comment #2 from shw_mail at wp dot pl  2007-09-08 15:31 ---
(In reply to comment #1)
> Can you please attach preprocessed source for a testcase triggering this?
> 

Below is separated FULL example :-).

// test_case.cpp
#include 
#include 

struct MyType1{};
typedef Mytype1 MyType2;

int main ()
{
BOOST_STATIC_ASSERT (
typeid (Mytype1).name()
== typeid(MyType2).name()
);
}

$ g++ test_case.cpp 

causes internal error.

The macro is expanded to:

typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE<
(bool)( typeid (Mytype1).name() == typeid(MyType2).name() ) >)>
boost_static_assert_typedef_12;

Regards.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug fortran/33354] MINLOC in combination with SUM gives wrong result

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2007-09-08 15:31 ---
The code compiles and runs correctly with trunk (aka 4.3).
I'm guessing that Thomas had fixed the problem and that
he did not back port the fix because the bug isn't a
regression.  If Thomas does not comment on the PR in a
reasonable time, I'm inclinded to cloase the PR.  Thanks
for the bug report.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354

[Bug c++/33129] C++ frontend finds static function in argument dependent lookup based on template parameter

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2007-09-08 15:33 ---
This is a duplicate of PR 19092
W.

*** This bug has been marked as a duplicate of 19092 ***


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33129

[Bug c++/19092] [DR 561] template code does not ignore static functions overloads

[bangerth at dealii dot org]

--- Comment #10 from bangerth at dealii dot org  2007-09-08 15:33 ---
*** Bug 33129 has been marked as a duplicate of this bug. ***


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092

[Bug fortran/33354] MINLOC in combination with SUM gives wrong result

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-09-08 16:16 ---
I want to add that you can find gfortran 4.3.0 binaries at
   http://gcc.gnu.org/wiki/GFortranBinaries

I'm actually unsure which patch fixed it. It might be Paul's PR32298 even
though it is about PARAMETER arrays.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.2
  Known to work||4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33354

[Bug c++/33355] GCC has an invalid pointer.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-08 17:23 ---
Can you attach the *.ii file that is generated if you compile this with
-save-temps added to the command line?

Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug tree-optimization/33344] if(!z) {a.b = x->b + 1; z = &a; } else if (!x) { a.b = z->b+1; x = &a; } use z->b and x->b; is not optimized

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-09-08 17:49 ---
So the following brute force approach will make PRE to do insertion for _all_
loads.  It produces then

g (b, c)
{
  int prephitmp.15;
  int prephitmp.10;
  struct f g;

:
  if (b == 0B)
goto ;
  else
goto ;

:
  prephitmp.10 = c->a + 1;
  g.a = prephitmp.10;
  prephitmp.15 = c->a;
  goto ;

:
  if (c == 0B)
goto ;
  else
goto ;

:
  prephitmp.15 = c->a;
  prephitmp.10 = b->a;
  goto ;

:
  prephitmp.15 = b->a + 1;
  g.a = prephitmp.15;
  prephitmp.10 = b->a;

:
  return prephitmp.10 + prephitmp.15;

}


Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c  (revision 128275)
+++ tree-ssa-pre.c  (working copy)
@@ -2598,6 +2598,7 @@ do_regular_insertion (basic_block block,
  bool by_some = false;
  bool cant_insert = false;
  bool all_same = true;
+ bool is_load = false;
  tree first_s = NULL;
  edge pred;
  basic_block bprime;
@@ -2614,6 +2615,10 @@ do_regular_insertion (basic_block block,
  continue;
}

+ if (TREE_CODE (expr) == INDIRECT_REF
+ || handled_component_p (expr))
+   is_load = true;
+
  avail = XCNEWVEC (tree, last_basic_block);
  FOR_EACH_EDGE (pred, ei, block->preds)
{
@@ -2672,7 +2677,7 @@ do_regular_insertion (basic_block block,
 already existing along every predecessor, and
 it's defined by some predecessor, it is
 partially redundant.  */
- if (!cant_insert && !all_same && by_some)
+ if (!cant_insert && !all_same && (by_some || is_load))
{
  if (insert_into_preds_of_block (block, get_expression_id (expr),
  avail))


The is_load should be really walk leading exprs looking for an inner
indirect_ref.  And edges should be walked to look for at least one
addr_expr in the phi arguments affected.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33344

[Bug tree-optimization/33344] if(!z) {a.b = x->b + 1; z = &a; } else if (!x) { a.b = z->b+1; x = &a; } use z->b and x->b; is not optimized

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-08 17:51 ---
Note that basic cleanups after PRE are missing, for example FRE of inserted
loads.
And of course it makes code larger.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33344

[Bug rtl-optimization/33346] [4.3 Regression] g++.old-deja/g++.eh/ia64-1.C ICEs at -O1 on spu-elf

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2007-09-08 18:23 ---
Also see the same ICE at -O2 on hppa.

Program received signal SIGSEGV, Segmentation fault.
0x0041e7a4 in reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.c:4161
4161  if (p != insn && INSN_P (p)
(gdb) p p
$1 = (rtx) 0x0


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33346

[Bug middle-end/33351] [4.3 Regression] segfault in assembler function

[lauras at gcc dot gnu dot org]

--- Comment #4 from lauras at gcc dot gnu dot org  2007-09-08 18:36 ---
It sure looks like it is caused by my patch. I will be able to take care of
that on Monday. 

I think this change should fix it (completely untested): rewrite


for (p = NEXT_INSN (prev); p != next; p = NEXT_INSN (p))
  if (p != insn && INSN_P (p)
 ...

as 
rtx next_p;
...
for (p = NEXT_INSN (prev); p != next; p = next_p)
  {
next_p = NEXT_INSN (p);
if (p != insn && INSN_P (p))
  ...
  }

Sorry for the trouble.


-- 

lauras at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |lauras at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-08 12:45:26 |2007-09-08 18:36:18
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351

[Bug c++/33355] GCC has an invalid pointer.

[shw_mail at wp dot pl]

--- Comment #4 from shw_mail at wp dot pl  2007-09-08 19:04 ---
Created an attachment (id=14175)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14175&action=view)
-save-temp from the code.

This is an .ii file contains preprocessed code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug c++/33355] GCC has an invalid pointer.

[shw_mail at wp dot pl]

--- Comment #5 from shw_mail at wp dot pl  2007-09-08 19:05 ---
Created an attachment (id=14176)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14176&action=view)
The program which causes error.

Source code of the program.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33355

[Bug c++/33124] C++ frontend should not warn about new a[0] in template context

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2007-09-08 19:09 ---
Hi. So, what shall we do here? I can remove the warning completely or
conditionalize it to -Wextra, for example. Just let me know...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||pcarlini at suse dot de
 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 19:09:06
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124

[Bug rtl-optimization/33356] New: Incomplete documentation of REG_RETVAL and REG_LIBCALL notes

[steven at gcc dot gnu dot org]

The documentation of REG_RETVAL and REG_LIBCALL notes is incomplete.  The
following additional information should be added to doc/rtl.texi:

1. LIBCALL and RETVAL notes always appear in pairs.
2. Operand 0 the libcall reg note always points to the other note of the pair.
3. Nested pairs of libcall notes are not allowed.

Nested libcalls are not allowed, but there is one pass that is prepared to
handle them anyway, and that is the local const/copy propagation pass in
gcse.c.  A patch for that is attached to Bug 33029
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=14064).

A patch for the documentation is pasted below:

Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 128277)
+++ doc/rtl.texi(working copy)
@@ -3640,13 +3640,16 @@ library call), and @var{op} is the first
 library call, the first insn that was generated to set up the arguments
 for the library call).

-Loop optimization uses this note to treat such a sequence as a single
-operation for code motion purposes and flow analysis uses this note to
-delete such sequences whose results are dead.
+The RTL dead code elimination pass uses this note to delete such
+sequences whose results are dead.

 A @code{REG_EQUAL} note will also usually be attached to this insn to
 provide the expression being computed by the sequence.

+A @code{REG_RETVAL} note always appears in pair with a @code{REG_LIBCALL}
+note.  The first operand of the @code{REG_RETVAL} note is a pointer to
+the @code{REG_LIBCALL} note of the pair.
+
 These notes will be deleted after reload, since they are no longer
 accurate or useful.

@@ -3655,6 +3658,10 @@ accurate or useful.
 This is the inverse of @code{REG_RETVAL}: it is placed on the first
 insn of a multi-insn sequence, and it points to the last one.

+A @code{REG_LIBCALL} note always appears in pair with a @code{REG_LIBCALL}
+note.  The first operand of the @code{REG_LIBCALL} note is a pointer to
+the @code{REG_RETVAL} note of the pair.
+
 These notes are deleted after reload, since they are no longer useful or
 accurate.


-- 
   Summary: Incomplete documentation of REG_RETVAL and REG_LIBCALL
notes
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
 BugsThisDependsOn: 33029


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33356

[Bug middle-end/33351] [4.3 Regression] segfault in assembler function

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-09-08 19:19 ---
I think PR 33346 is the same issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||33346
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351

[Bug fortran/33339] GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #3 from sgk at troutmask dot apl dot washington dot edu  
2007-09-08 19:17 ---
Subject: Re:  GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST
F90_RMA/BASEATTRWINF90.F90

> 
> >>> ftn -o x -O2 bug2867.f90
> >>> aprun -n 1 ./x
> >>>   
> >>  Got incorrect value for WIN_SIZE (  140733193389056 , should be
> >>
> >> 1024 )
> >>  Got wrong value for WIN_DISP_UNIT (  140733193388036 , should be
> >> 
> >
> > What is ftn?  On my system, when I build MPICH2 I get mpf90.
> >   
> 
> ftn is a script that allows the user to see a common interface for all 
> the compilers we  document.  Which compiler is used is controlled by the 
> module facility. Library sets are selected based on the compiler and OS 
> combinations.  The same command is used for both serial and parallel 
> programs.
> 

Any chance that you can skip the script and use mpif90 directly?
Also, I have MPICH2 1.05p4.  Can you this version?  Is the 
version of MPICH2 that you used patched by Cray?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9

[Bug c++/33357] New: collect2: ld terminated with signal 11 [Segmentation fault]

[don-gcc at isis dot cs3-inc dot com]

I don't know how to fill in much of this form but I hope all will be clear from
the following transcript.
I'm hoping for advice on what to do (upgrade?) to fix the problem or failing
that what to do to help diagnose it.

===
[EMAIL PROTECTED]:~/mysql-5.0.45/client> g++ -O3 -DDBUG_OFF 
-fno-implicit-templates 
-fno-exceptions -fno-rtti -rdynamic -o .libs/mysql mysql.o readline.o
sql_string
.o completion_hash.o  ../cmd-line-utils/libedit/libedit.a -lncurses
../libmysql/
.libs/libmysqlclient.so -lcrypt -lnsl -lm -lz -Wl,--rpath
-Wl,/home/dcohen/mysql
/lib/mysql
collect2: ld terminated with signal 11 [Segmentation fault]
[EMAIL PROTECTED]:~/mysql-5.0.45/client> g++ --version
g++ (GCC) 4.1.0 (SUSE Linux)
Copyright (C) 2006 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.

[EMAIL PROTECTED]:~/mysql-5.0.45/client> uname -a
Linux saturn 2.6.16.27-0.9-default #1 SMP Tue Feb 13 09:35:18 UTC 2007 ia64
ia64 ia64 GNU/Linux
[EMAIL PROTECTED]:~/mysql-5.0.45/client>


-- 
   Summary: collect2: ld terminated with signal 11 [Segmentation
fault]
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: don-gcc at isis dot cs3-inc dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357

[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-09-08 19:29 ---
This is ld crashing and ld is part of the binutils project.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |other


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357

[Bug middle-end/23488] [4.1/4.2/4.3 Regression] GCSE load PRE does not work with non sets (or missing load PRE with plain decls)

[steven at gcc dot gnu dot org]

--- Comment #23 from steven at gcc dot gnu dot org  2007-09-08 19:37 ---
Load PRE does still not optimize the test cases of comment #0 and comment #2.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-08-06 14:33:14 |2007-09-08 19:37:41
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488

[Bug rtl-optimization/33346] [4.3 Regression] g++.old-deja/g++.eh/ia64-1.C ICEs at -O1 on spu-elf

[lauras at gcc dot gnu dot org]

--- Comment #2 from lauras at gcc dot gnu dot org  2007-09-08 19:40 ---
I will be able to handle this on Monday. If it's urgent, you can try (untested)
suggestion at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351#c4

Sorry for the trouble.


-- 

lauras at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||lauras at gcc dot gnu dot
   ||org
 AssignedTo|unassigned at gcc dot gnu   |lauras at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 19:40:49
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33346

[Bug c++/33124] C++ frontend should not warn about new a[0] in template context

[gdr at cs dot tamu dot edu]

--- Comment #7 from gdr at cs dot tamu dot edu  2007-09-08 20:00 ---
Subject: Re:  C++ frontend should not warn about new a[0] in template context

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| Hi. So, what shall we do here? I can remove the warning completely or
| conditionalize it to -Wextra, for example. Just let me know...

I'm inclined to remove the warning.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33124

[Bug c++/33358] New: Slow calls through simple member function pointers

[dleska at gmail dot com]

Hi,

By simple MFPs I mean those that point to a class with single or no inheritance
and the class is fully defined at the time of the call. For example:

class SomeClass {};

typedef void (SomeClass::*MemberFunc)();

void callMemberFunc(SomeClass *object, MemberFunc func)
{
   (object->*func)();
} 

g++ seems to generate the same code whether SomeClass is a complete type or
not. In the above example, VS 2005 can significantly optimise the call when
SomeClass is defined:

00424D40  mov ecx,dword ptr [esp+4]
00424D44  jmp dword ptr [esp+8] 

g++ 4.2.1 generates the following:

.file   "test.cpp"
.text
.align 2
.p2align 4,,15
.globl __Z12callDelegateRN12fastdelegate12FastDelegateIFvvEEE
.def__Z12callDelegateRN12fastdelegate12FastDelegateIFvvEEE; .scl   
2;  .type   32; .endef
__Z12callDelegateRN12fastdelegate12FastDelegateIFvvEEE:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
movl8(%ebp), %eax
movl4(%eax), %ecx
movl(%eax), %ebx
movl8(%eax), %edx
testb   $1, %cl
je  L7
leal(%ebx,%edx), %edx
movl(%edx), %eax
movl-1(%eax,%ecx), %ecx
movl%edx, 8(%ebp)
popl%ebx
popl%ebp
jmp *%ecx
.p2align 4,,7
L7:
leal(%ebx,%edx), %edx
movl%edx, 8(%ebp)
popl%ebx
popl%ebp
jmp *%ecx

I've reproduced this on 4.2.1 and 3.4.2 on x86 (MinGW) and 4.1.1, 4.1.0, 4.0.1
and 3.4.4 on arm/thumb.

Would it be possible for gcc to optimise such calls?


-- 
   Summary: Slow calls through simple member function pointers
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dleska at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33358

[Bug fortran/33338] ERROR MSG FOR "READ (11,FMT='(Q,A)'..." POINTS AT END-OF-LINE RATHER THAN AT Q.

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-09-08 20:16 
---
This one is already reported.

*** This bug has been marked as a duplicate of 29835 ***


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

[Bug fortran/29835] Error message of unknown edit descriptor needs improvement

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-09-08 20:16 
---
*** Bug 8 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||longb at cray dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29835

[Bug c++/33358] Slow calls through simple member function pointers

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-09-08 20:40 ---
VS seems to dispatch to some other function.  Dependend on whether the method
is virtual or not the code path has to be more complicated.  Of course this is
also dependent on the actual ABI.  That is,

L7:
leal(%ebx,%edx), %edx
movl%edx, 8(%ebp)
popl%ebx
popl%ebp
jmp *%ecx

is the equivalent to the direct jump, and the rest involves loading the
vtable pointer.

leal(%ebx,%edx), %edx
movl(%edx), %eax
movl-1(%eax,%ecx), %ecx
movl%edx, 8(%ebp)
popl%ebx
popl%ebp
jmp *%ecx

and of course the check if this is a virtual method or not.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33358

[Bug target/33359] New: [4.3 Regression] libgcc is miscompiled on SH

[kkojima at gcc dot gnu dot org]

Trunk fails for sh-elf during compiling libgcc with a missing
local label:

/exp/ldroot/dodes/xsh-elf-gcc-orig/./gcc/xgcc
-B/exp/ldroot/dodes/xsh-elf-gcc-orig/./gcc/ -B/usr/local/sh-unknown-elf/bin/
-B/usr/local/sh-unknown-elf/lib/ -isystem /usr/local/sh-unknown-elf/include
-isystem /usr/local/sh-unknown-elf/sys-include -O2 -g -O2 -O2  -O2 -g -O2  
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../ORIG/trunk/libgcc -I../../../ORIG/trunk/libgcc/.
-I../../../ORIG/trunk/libgcc/../gcc -I../../../ORIG/trunk/libgcc/../include 
-DHAVE_CC_TLS -o _muldc3.o -MT _muldc3.o -MD -MP -MF _muldc3.dep -DL_muldc3 -c
../../../ORIG/trunk/libgcc/../gcc/libgcc2.c \

/tmp/ccghCTLN.s: Assembler messages:
/tmp/ccghCTLN.s:782: Error: displacement to undefined symbol .L162 overflows
12-bit field

I've found that it started after

r128224 | lauras | 2007-09-07 11:58:06 +0900 (Fri, 07 Sep 2007) | 25 lines

2007-09-05  Laurynas Biveinis  <[EMAIL PROTECTED]>

* regrename.c (copyprop_hardreg_forward_1): New variable next. Use
FOR_BB_INSNS_SAFE instead of for loop.
* cse.c (cse_extended_basic_block): Likewise.
* postreload.c (reload_cse_regs_1): New variable next. Make sure
that the for loop does not invoke NEXT_INSN on a deleted insn.
* function.c (instantiate_virtual_regs): Likewise.
* lower-subreg.c (remove_retval_note): Likewise.
(decompose_multiword_subregs): Use FOR_BB_INSNS_SAFE instead of
FOR_BB_INSNS.
* emit-rtl.c (remove_insn): Set NEXT_INSN and PREV_INSN to NULL on
a deleted insn.
* cfgrtl.c (delete_insn): Set JUMP_LABEL to NULL on a deleted
insn, if it's a jump.
(try_redirect_by_replacing_jump): New variable jump_p. Call
tablejump_p before delete_insn_chain.
* reload1.c (reload): New variable next. Make sure that the for
loop does not invoke NEXT_INSN on a deleted insn.
(fixup_eh_region_note): Make the loop terminate if i becomes NULL.
(delete_output_reload): New variable prev. Make sure the the for
loops do not invoke PREV_INSN on a deleted insn.

Reverting a hunk in the patch:

--- TMP/gcc-128223/gcc/emit-rtl.c   2007-09-08 17:52:26.0 +0900
+++ TMP/gcc-128224/gcc/emit-rtl.c   2007-09-08 17:08:27.0 +0900
@@ -3688,6 +3688,8 @@ remove_insn (rtx insn)
   if (BB_END (bb) == insn)
BB_END (bb) = prev;
 }
+  NEXT_INSN (insn) = NULL;
+  PREV_INSN (insn) = NULL;
 }

 /* Append CALL_FUSAGE to the CALL_INSN_FUNCTION_USAGE for CALL_INSN.  */

gets rid of the above failure.  Although I can't specify
the problematic part in the SH back end yet, it looks there
are other places which assume that NEXT_INSN and PREV_INSN
aren't cleared with remove_insn.
For example, jump.c:delete_related_insns uses NEXT_INSN (insn)
after delete_insn (insn) which may call remove_insn.


-- 
   Summary: [4.3 Regression] libgcc is miscompiled on SH
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-elf


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359

[Bug target/33359] [4.3 Regression] libgcc is miscompiled on SH

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33359

[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked

[anrp at mit dot edu]

--- Comment #10 from anrp at mit dot edu  2007-09-08 21:44 ---
(In reply to comment #9)
> Here's what I see:
> 
> The array __clz_tab is used in a macro, count_leading_zeros, which is called 
> in
> the function __clzSI2 in libgcc2.c, which (AFAICT) gets compiled to the
> function __clzsi2 and aggregated in libgcc. The __clzsi2 function is called
> from the function clzusi() (in fp-bit.c) which is also included in libgcc. The
> clzusi() function is called from si_to_float() and usi_to_float() (also in
> fp-bit.c and included in libgcc). AFAICT, these two functions are used to
> convert an int or unsigned int to float. 
> 
> The test case does exactly this type of conversion in main() in comment #5.
> Testing shows that with gcc 4.2.1, and all int-to-float conversions removed,
> that __clz_tab is correctly not linked into the application.
> 
> The clzusi() function was created in revision 107345, on Nov 22, 2005:
> http://gcc.gnu.org/viewcvs?view=rev&revision=107345
> 
> This seems like it was an intended change. However, it is unfortunate that a
> 256-byte array is used in the count_leading_zeros macro. While using a table 
> is
> fast and the size is neglible on larger platforms, using up 256 bytes is very
> significant on the AVR where 4K, 2K or even 1K of RAM is common. What is 
> really
> needed is an alternative implementation (non-array) that is perhaps specific 
> to
> the AVR.

Here's an untested (I'm going to try to figure out how to get it to build into
the AVR build) function that replaces the definition of clz_tab with a 6
instruction bit of code:

; r2 in, r3 out
; r2 clobbered
; Z, C, N. V clobbered
clz_compute:
ldi r3, 0x09   ; preload output
clc; clear C (guarentees termination with 8 loops)
clz_compute_loop1:
rol r2 ; push MSB into C
dec r3 ; dec output
brcs clz_end   ; if C is set (msb was set), we're done
rjmp clz_compute_loop1 ; otherwise, repeat
clz_end:


-- 

anrp at mit dot edu changed:

   What|Removed |Added

 CC||anrp at mit dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524

[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked

[anrp at mit dot edu]

--- Comment #11 from anrp at mit dot edu  2007-09-08 21:48 ---
(In reply to comment #10)
> Here's an untested (I'm going to try to figure out how to get it to build into
> the AVR build) function that replaces the definition of clz_tab with a 6
> instruction bit of code:
> 
> ; r2 in, r3 out
> ; r2 clobbered
> ; Z, C, N. V clobbered
> clz_compute:
> ldi r3, 0x09   ; preload output
> clc; clear C (guarentees termination with 8 loops)
> clz_compute_loop1:
> rol r2 ; push MSB into C
> dec r3 ; dec output
> brcs clz_end   ; if C is set (msb was set), we're done
> rjmp clz_compute_loop1 ; otherwise, repeat
> clz_end:
> 

And the first bug of the day, clc should be sec. brcs will only jump out if C
is set. On to prodding gcc...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29524

[Bug target/33360] New: cris build failure

[segher at kernel dot crashing dot org]

/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:93: error: unrecognizable insn:
(call_insn 26 25 27 7 /home/segher/src/gcc/libgcc/../gcc/libgcc2.c:90 (parallel 
[
(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] ) [0 S1 A8])
(const_int 0 [0x0]))
(clobber (reg:SI 16 srp))
]) -1 (expr_list:REG_NORETURN (const_int 0 [0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(nil))
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:93: internal compiler error: in
extract_insn, at recog.c 1990


configured as:

/home/segher/src/gcc/configure --target=cris-linux --enable-targets=all
--prefix=/home/segher/cross --enable-languages=c --without-headers
--enable-sjlj-exceptions --with-system-libunwind --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --enable-checking=yes,rtl


-- 
   Summary: cris build failure
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: cris-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33360

[Bug target/33360] cris build failure

[segher at kernel dot crashing dot org]

--- Comment #1 from segher at kernel dot crashing dot org  2007-09-08 23:06 
---
SVN revision 128276


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33360

[Bug c++/33101] Bad C++ error on invalid code: has incomplete type

[bangerth at dealii dot org]

--- Comment #9 from bangerth at dealii dot org  2007-09-08 23:24 ---
This sounds good to me to. I guess we can now confirm the PR.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 23:24:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101

[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2007-09-08 23:27 ---
Confirmed. In particular, the value 1.1 is of type 'double' for which
it hardly ever makes sense to print it to 47 digits :-)
W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 23:27:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067

[Bug c++/33041] g++ incorrectly resolves an identically named templated struct in a super class

[bangerth at dealii dot org]

--- Comment #3 from bangerth at dealii dot org  2007-09-08 23:33 ---
I don't know whether gcc's result is correct or not (I suspect it is)
but here's two more data points:
- icc produces the same output
- Sun Studio produces the following compiler output:
--
g/x> ~/bin/sunstudio-2007-03/bin/CC x.cc
"x.cc", line 17: Error: foo is not a member of foo.
"x.cc", line 17: Error: Badly formed expression.
2 Error(s) detected.
--


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33041

[Bug libstdc++/33016] type_info::before() will not return the same value

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2007-09-08 23:43 ---
I have to admit that the result is strange. However, it appears entirely
within the compiler's right to do this, as [18.5.1/5] says:
-
   bool before(const type_info& rhs) const;

5 Effects:
Compares the current object with rhs.
6 Returns:
true if *this precedes rhs in the implementation's collation  order.
-
So the result is compiler defined.

In reality what happens is this: the before() compares two addresses in memory
that depend on the time at which the compiler emitted the typeinfo data. This
in turn depends on which class's typeinfo first needed to be emitted. This
can be seen using this little program:

#include "stdio.h"
#include "typeinfo"

class A {};
class B {};

int main(void)
{
#ifdef XX
printf("typeid(B).name(): %s\n", typeid(B).name());
printf("typeid(A).name(): %s\n", typeid(A).name());
#else
printf("typeid(A).name(): %s\n", typeid(A).name());
printf("typeid(B).name(): %s\n", typeid(B).name());
#endif

printf("A is before B: %d\n", typeid(A).before(typeid(B)));

return 0;
}
-
Depending on whether XX is set or not, the result of before() is either
true or false. But as explained above, this is entirely within the
implementation's discretion.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |RESOLVED
  Component|c++ |libstdc++
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33016

[Bug c++/32997] duplicate nested type error has disappeared

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-09-08 23:45 ---
Confirmed. 


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2007-09-08 23:45:39
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32997

[Bug c++/32997] duplicate nested type error has disappeared

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2007-09-08 23:47 ---
As a matter of fact, if the types had not been inside a struct, gcc would
have produced the warning.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32997

[Bug c++/32549] Wrong template instance resolution among multiple object files.

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2007-09-08 23:52 ---
The code is definitely invalid. The two typedefs declare two types with
external linkage. This is an ODR violation making the code invalid. The
standard doesn't require compilers to produce an error for a very good
reason: it is almost impossible to detect this without support from a linker
that understands all wrinkles and depths of the C++ language.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32549

[Bug c++/33361] New: ICE in find_outermost_region_in_block, at tree-cfg.c:4803

[gcc at abeckmann dot de]

Hi,

I'm getting an
internal compiler error: in find_outermost_region_in_block, at 
tree-cfg.c:4803
in -fopenmp mode with g++ 4.2.[012]. g++ 4.3 produces no error.

Andreas

$ /suse/NOBACKUP/gcc/gcc-4.2-branch/bin/g++ -v -save-temps -march=i686
-DSORT_OPTIMAL_PREFETCHING -DUSE_MALLOC_LOCK -DCOUNT_WAIT_TIME
-I/home/andreas/work/uka/stxxl/parpipe/include -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE   -O3   -W -Wall -fopenmp -D__MCSTL__
 -I/home/andreas/work/uka/mcstl/libstdc++/c++ -c
ICE_find_outermost_region_in_block.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4_2-branch/configure --enable-languages=c,c++
--prefix=/suse/NOBACKUP/gcc/gcc-4.2-branch
Thread model: posix
gcc version 4.2.2 20070908 (prerelease)
 /suse/NOBACKUP/gcc/gcc-4.2-branch/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus
-E -quiet -v -I/home/andreas/work/uka/stxxl/parpipe/include
-I/home/andreas/work/uka/mcstl/libstdc++/c++ -D_GNU_SOURCE -D_REENTRANT
-DSORT_OPTIMAL_PREFETCHING -DUSE_MALLOC_LOCK -DCOUNT_WAIT_TIME
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D__MCSTL__
ICE_find_outermost_region_in_block.cpp -march=i686 -W -Wall -fopenmp -O3
-fpch-preprocess -o ICE_find_outermost_region_in_block.ii
ignoring nonexistent directory
"/suse/NOBACKUP/gcc/gcc-4.2-branch/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/andreas/work/uka/stxxl/parpipe/include
 /home/andreas/work/uka/mcstl/libstdc++/c++

/suse/NOBACKUP/gcc/gcc-4.2-branch/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2

/suse/NOBACKUP/gcc/gcc-4.2-branch/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu

/suse/NOBACKUP/gcc/gcc-4.2-branch/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward
 /usr/local/include
 /suse/NOBACKUP/gcc/gcc-4.2-branch/include
 /suse/NOBACKUP/gcc/gcc-4.2-branch/lib/gcc/i686-pc-linux-gnu/4.2.2/include
 /usr/include
End of search list.
 /suse/NOBACKUP/gcc/gcc-4.2-branch/libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus
-fpreprocessed ICE_find_outermost_region_in_block.ii -quiet -dumpbase
ICE_find_outermost_region_in_block.cpp -march=i686 -auxbase
ICE_find_outermost_region_in_block -O3 -W -Wall -version -fopenmp -o
ICE_find_outermost_region_in_block.s
GNU C++ version 4.2.2 20070908 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.2.2 20070908 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7993b3af5142d87e347d8f7153b00978
/home/andreas/work/uka/mcstl/libstdc++/c++/bits/mcstl_par_loop.h: In function
‘Op mcstl::for_each_template_random_access_ed(RandomAccessIterator,
RandomAccessIterator, Op, Fu&, Red, Result, Result&, typename
std::iterator_traits<_Iterator>::difference_type) [with RandomAccessIterator =
stxxl::request_ptr*, Op = stxxl::request_ptr, Fu =
mcstl::fill_selector, Red = mcstl::dummy_reduct, Result =
bool]’:
/home/andreas/work/uka/mcstl/libstdc++/c++/bits/mcstl_par_loop.h:45: internal
compiler error: in find_outermost_region_in_block, at tree-cfg.c:4803


-- 
   Summary: ICE in find_outermost_region_in_block, at tree-
cfg.c:4803
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33361

[Bug web/33057] version-independent url for documentation

[gerald at pfeifer dot com]

--- Comment #2 from gerald at pfeifer dot com  2007-09-09 01:09 ---
Karl discussed this with me and despite some concerns on my side as well
I agreed to implement something like this.  It's just a single line in a
config file that can be controlled via remote CVS, it turns out.


-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33057

[Bug web/33057] version-independent url for documentation

[gerald at pfeifer dot com]

-- 

gerald at pfeifer dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |gerald at pfeifer dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-09 01:09:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33057

[Bug c++/33350] copy constructor error

[stevenyi at 163 dot com]

--- Comment #2 from stevenyi at 163 dot com  2007-09-09 02:46 ---
(In reply to comment #1)
> Yes the copy constructor is going to be called implicately here.

the copy constructor is not actually called at runtime. and both intel compiler
and vc++ can compile this code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350

[Bug c++/33350] copy constructor error

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-09-09 02:58 ---
There is a C++ defect report about this really.  GCC follows exactly what the
standard says but the defect report says something different.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350

[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]

[don-gcc at isis dot cs3-inc dot com]

--- Comment #2 from don-gcc at isis dot cs3-inc dot com  2007-09-09 03:43 
---
Subject:  collect2: ld terminated with signal 11 [Segmentation fault]

pinskia at gcc dot gnu dot org writes:
 > This is ld crashing and ld is part of the binutils project.
Mike Frysinger writes:
 > you should start with what version of binutils you're actually using ... run 
 > `ld --version`
 > if that version != 2.18, then you should first upgrade

Thank you both for your replies.  I have now built binutils 2.18.
However I'm not root on this machine and so cannot install it in the
place where the original command (g++ -O3 -DDBUG_OFF ...) will find
it.  Can either of you tell me how to arrange for the g++ command to
use the version of ld I've just built?
I see at least two problems here.  First, g++ is not simply calling ld
on the same arguments - when I replace g++ with ld I get an error
about unrecognized option -DDBUG_OFF.
Second, I suspect that the ld I just built is the file
~/binutils-2.18/ld/ld-new - is that correct?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357

[Bug c++/33342] [4.3 Regression] ICE in dependent_type_p, at cp/pt.c:15081

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2007-09-09 04:33 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33342

[Bug middle-end/33351] [4.3 Regression] segfault in assembler function

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2007-09-09 05:01 ---
Please try after r128284.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33351

[Bug rtl-optimization/33345] [4.3 Regression] gcc.c-torture/execute/20030323-1.c ICEs at -O2 and above on spu-elf

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2007-09-09 05:02 ---
Please try after r128284.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33345

[Bug rtl-optimization/33346] [4.3 Regression] g++.old-deja/g++.eh/ia64-1.C ICEs at -O1 on spu-elf

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2007-09-09 05:05 ---
Please try after r128284.  See also story about this test-case for cris-elf at
.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33346

[Bug c++/33350] copy constructor error

[stevenyi at 163 dot com]

--- Comment #4 from stevenyi at 163 dot com  2007-09-09 05:26 ---
I can not see any reason to call the copy constructor here. If you remove
keyword explicit so that let the code compile, you can find that the copy
constructor is not called at all.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33350

[Bug c/33362] New: [4.3 Regression] Bootstrap comparison failure (rev. 128287)

[victork at il dot ibm dot com]

Mainline revision 128287.

Configured with:
% ../gcc/configure --enable-languages=c,c++,fortran
bootsrapped with:
% make -j 8

Comparing stages 2 and 3
/home/victork/mainline/build.128287/stage3-gcc
warning: ./cc1plus-checksum.o differs
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./cfg.o differs
./cfgloopmanip.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/victork/mainline/build.128287'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/victork/mainline/build.128287'
make: *** [all] Error 2


-- 
   Summary: [4.3 Regression] Bootstrap comparison failure (rev.
128287)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: victork at il dot ibm 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=33362

[Bug c++/33358] Slow calls through simple member function pointers

[dleska at gmail dot com]

--- Comment #2 from dleska at gmail dot com  2007-09-09 06:47 ---
(In reply to comment #1)
> VS seems to dispatch to some other function.

Yep - if the function is virtual, VS generates a stub that does the vtable
lookup.  However for non virtual function the call is direct - which is much
faster than what gcc does.

Note that if I replace the first line of my example with 'class SomeClass;' -
gcc and VS generate comparable code. However when the class is defined at the
point of the call and does not use multiple/virtual inheritance, VS generates
significantly faster calls (at least for non-virtual functions).

Is this optimisation not possible in gcc?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33358