[Bug fortran/44584] [4.6 Regression] Invalid memory access with gfortran.dg/typebound_proc_15.f03

[ubizjak at gmail dot com]

--- Comment #19 from ubizjak at gmail dot com  2010-08-04 07:10 ---
Also fixes ICE on alpha.


-- 


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

[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment

[janus at gcc dot gnu dot org]

--- Comment #19 from janus at gcc dot gnu dot org  2010-08-04 07:31 ---
(In reply to comment #16)
> Here is a better patch:

This patch also fixes the error messages in comment #0 on darwin with -m32.


-- 


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

[Bug testsuite/43283] ld: Unsatisfied symbol "start" in file c_lto_20091216-1_0.o

[uros at gcc dot gnu dot org]

--- Comment #9 from uros at gcc dot gnu dot org  2010-08-04 07:46 ---
Subject: Bug 43283

Author: uros
Date: Wed Aug  4 07:46:00 2010
New Revision: 162856

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162856
Log:
Backport from mainline:
2010-07-20  Bingfeng Mei  

* gcc.dg/lto/20090313_0.c: Use dg-require-effective-target
sync_char_short

2010-06-24  Steve Ellcey  

PR testsuite/43283
* gcc.dg/lto/20091216-1_0.c: Use newline instead of semicolon
and add argument to nop for IA64.


Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20090313_0.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20091216-1_0.c


-- 


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

[Bug fortran/44065] [OOP] Undefined reference to vtab$...

[janus at gcc dot gnu dot org]

--- Comment #10 from janus at gcc dot gnu dot org  2010-08-04 08:32 ---
(In reply to comment #9)
> With the patch in comment #5 there is one regression:
> 
> FAIL: gfortran.dg/typebound_operator_4.f03  -O  (test for excess errors)
> 
> the extra errors are:
> 
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_4.f03:73.7:
> 
>   USE m
>1
> Error: Invalid expression in the derived type constructor for pointer 
> component
> '$extends' at (1) in PURE procedure


This regression can be fixed by:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 162842)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12320,6 +12323,10 @@ gfc_impure_variable (gfc_symbol *sym)
   gfc_symbol *proc;
   gfc_namespace *ns;

+  if (sym->attr.vtab)
+return 0;
+
   if (sym->attr.use_assoc || sym->attr.in_common)
 return 1;



-- 


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

[Bug c/45176] New: restrict qualifier is not used in a manually unrolled loop

[bmei at broadcom dot com]

void foo (int * restrict a, int * restrict b, int * restrict c)
{
   int i;
   for(i = 0; i < 100; i+=4)
 {
   a[i] = b[i] * c[i];
   a[i+1] = b[i+1] * c[i+1];
   a[i+2] = b[i+2] * c[i+2];
   a[i+3] = b[i+3] * c[i+3];
 }
}   

Trunk x86-64 compiler (162821) produces code that later load instructions are
not scheduled before the previous store instructions as expected. Clearly,
restrict qualifier is not used here. 

 ~/work/install-x86/bin/gcc tst3.c -O2 -S -std=c99 -da -fschedule-insns
-frename-registers
.L2:
movl(%rdx,%rax), %r10d
imull   (%rsi,%rax), %r10d
movl%r10d, (%rdi,%rax)
movl4(%rdx,%rax), %r9d
imull   4(%rsi,%rax), %r9d
movl%r9d, 4(%rdi,%rax)
movl8(%rdx,%rax), %r8d
imull   8(%rsi,%rax), %r8d
movl%r8d, 8(%rdi,%rax)
movl12(%rdx,%rax), %ecx
imull   12(%rsi,%rax), %ecx
movl%ecx, 12(%rdi,%rax)
addq$16, %rax
cmpq$400, %rax

Richard has a patch and it seems to work for this example. 
Index: expr.c
===
--- expr.c  (revision 162841)
+++ expr.c  (working copy)
@@ -8665,7 +8665,7 @@ expand_expr_real_1 (tree exp, rtx target
set_mem_addr_space (temp, as);
base = get_base_address (TMR_ORIGINAL (exp));
if (base
-   && INDIRECT_REF_P (base)
+   && (INDIRECT_REF_P (base) || TREE_CODE (base) == MEM_REF)
&& TMR_BASE (exp)
&& TREE_CODE (TMR_BASE (exp)) == SSA_NAME
&& POINTER_TYPE_P (TREE_TYPE (TMR_BASE (exp

The code generated:
.L2:
movl(%rdx,%rax), %r10d
movl4(%rdx,%rax), %r9d
imull   (%rsi,%rax), %r10d
imull   4(%rsi,%rax), %r9d
movl8(%rdx,%rax), %r8d
movl12(%rdx,%rax), %ecx
imull   8(%rsi,%rax), %r8d
imull   12(%rsi,%rax), %ecx
movl%r10d, (%rdi,%rax)
movl%r9d, 4(%rdi,%rax)
movl%r8d, 8(%rdi,%rax)
movl%ecx, 12(%rdi,%rax)
addq$16, %rax
cmpq$400, %rax
jne .L2


-- 
   Summary: restrict qualifier is not used in a manually unrolled
loop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmei at broadcom dot com


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

[Bug bootstrap/45177] New: [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[mikpe at it dot uu dot se]

Attempting to build gcc-4.6 r162856 (head as of a few minutes ago) on
i686-linux as a cross to armv5tel-linux-gnueabi fails with cc1 running out of
memory:

/tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/bin/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/lib/
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/include
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/sys-include
   -g -O2 -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -Wno-missing-prototypes -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I.
-I. -I../.././gcc -I/tmp/gcc-4.6-r162856/libgcc -I/tmp/gcc-4.6-r162856/libgcc/.
-I/tmp/gcc-4.6-r162856/libgcc/../gcc -I/tmp/gcc-4.6-r162856/libgcc/../include 
-DHAVE_CC_TLS  -o _udivmoddi4.o -MT _udivmoddi4.o -MD -MP -MF _udivmoddi4.dep
-DL_udivmoddi4 -c /tmp/gcc-4.6-r162856/libgcc/../gcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions 

cc1: out of memory allocating 171803424 bytes after a total of 46485504 bytes
make[2]: *** [_udivmoddi4.o] Error 1
make[2]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/tmp/objdir'
make: *** [all] Error 2

This happend twice in a row now.  Repeating it a third time and watching the
process with 'top' I see that cc1 grows to somewhere over 2.5 GB virtual before
dying.  The machine has 6 GB of RAM and 4 GB of swap, but it didn't start
swapping before cc1 died.

4.6-20100731 (r162788) did not have this problem.

Full configuration line:
/tmp/gcc-4.6-r162856/configure --target=armv5tel-unknown-linux-gnueabi
--with-arch=armv5te --with-tune=xscale
--prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto
--disable-nls --disable-shared --disable-libmudflap --disable-multilib
--enable-threads=posix --enable-checking=release --enable-languages=c


-- 
   Summary: [4.6 regression] cc1 runs out of memory building libgcc
in ARM cross-compiler
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: armv5tel-unknown-linux-gnueabi


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-04 09:19 ---
Can you check where it sits eating all emmory?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c/45176] restrict qualifier is not used in a manually unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-04 09:19 ---
I'll bootstrap & test that patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 09:19:37
   date||


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

[Bug tree-optimization/45178] New: CDDCE doesn't eliminate conditional code in infinite loop

[rguenth at gcc dot gnu dot org]

Reduced from gcc.dg/tree-ssa/ssa-dce-3.c:

int main(void)
{
  unsigned j = 0;
  while (1)
{
  j += 500;
  if (j % 7)
j++;
  else
j--;
}
  return 0;
}


-- 
   Summary: CDDCE doesn't eliminate conditional code in infinite
loop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-08-04 10:01 ---
Attaching gdb after cc1 just passed 2.5 G virtual:

0x080c0c93 in pool_alloc (pool=0xa45d708) at
/tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252
252 {
Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.i686
(gdb) bt
#0  0x080c0c93 in pool_alloc (pool=0xa45d708) at
/tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252
#1  0x0812091e in df_ref_create_structure (cl=DF_REF_REGULAR,
collection_rec=, 
reg=0xb757a1c0, loc=0xb734d814, bb=0xb7534400, info=0xa46b930,
ref_type=DF_REF_REG_MEM_STORE, 
ref_flags=0, width=-1, offset=-1, mode=VOIDmode) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:2802
#2  0x08120a8c in df_ref_record (cl=,
collection_rec=, 
reg=, loc=0xb734d814, bb=0xb7534400,
insn_info=0xa46b930, 
ref_type=DF_REF_REG_MEM_STORE, ref_flags=0, width=-1, offset=-1,
mode=VOIDmode)
at /tmp/gcc-4.6-r162856/gcc/df-scan.c:2928
#3  0x081210d7 in df_uses_record (cl=,
collection_rec=, 
loc=, ref_type=DF_REF_REG_MEM_STORE, bb=0xb7534400,
insn_info=0xa46b930, 
flags=0, width=-1, offset=-1, mode=VOIDmode) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:3159
#4  0x081219d7 in df_insn_refs_collect (collection_rec=, 
bb=, insn_info=0x1f68fb8) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:3571
#5  0x08121f3a in df_insn_refs_verify (collection_rec=0xbfb95d50, bb=0x7,
insn=, 
abort_if_fail=0 '\0') at /tmp/gcc-4.6-r162856/gcc/df-scan.c:4466
#6  0x081222b6 in df_insn_rescan (insn=0x13e97828) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:1260
#7  0x0826d4f3 in peep2_update_life (prev=, last=, 
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3313
#8  peephole2_optimize (prev=, last=, 
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3441
#9  rest_of_handle_peephole2 (prev=, last=, 
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3619
#10 0x082534cb in execute_one_pass (pass=0x8863640) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1564
#11 0x0825374d in execute_pass_list (pass=0x8863640) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1619
#12 0x08253760 in execute_pass_list (pass=0x88634e0) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1620
#13 0x08253760 in execute_pass_list (pass=0x88634a0) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1620
#14 0x0831f87a in tree_rest_of_compilation (fndecl=0xb74dc400)
at /tmp/gcc-4.6-r162856/gcc/tree-optimize.c:452
#15 0x0844c02f in cgraph_expand_function (node=)
at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1643
#16 0x0844d201 in cgraph_expand_all_functions () at
/tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1722
#17 cgraph_optimize () at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1978
#18 0x0844da15 in cgraph_finalize_compilation_unit () at
/tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1185
#19 0x08056f9c in c_write_global_declarations () at
/tmp/gcc-4.6-r162856/gcc/c-decl.c:9698
#20 0x082e2324 in compile_file () at /tmp/gcc-4.6-r162856/gcc/toplev.c:957
#21 do_compile () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2295
#22 toplev_main () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2336
#23 0x080baeeb in main (argc=62, argv=0xbfb96134) at
/tmp/gcc-4.6-r162856/gcc/main.c:36


-- 


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

[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return "stdin"

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-08-04 10:02 ---
(In reply to comment #10)
> Reply to comment #9.
> 
> Yes, this is what I was thinking. I wanted to float the first step out there 
> to
> see what else we would discover.

I think now that there are essentially no test suite failures (except some old
ones one more obscure targets), one could add a patch similar to the one in
comment 9...


-- 


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

[Bug fortran/45179] New: Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)

[burnus at gcc dot gnu dot org]

libcpp allows one to directly input non-ascii characters in source files (.f90
etc.); the used encoding can be set using the options:

  -finput-charset=UTF-8

Cf. also: -fexec-charset and -fwide-exec-charset
and http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html


If one uses   gfortran -cpp -finput-charset=UTF-8 wide.f90
one currently gets the error:

f951: warning: command line option "-finput-charset=UTF-8" is valid for
C/C++/ObjC/ObjC++ but not for Fortran [enabled by default]


The files scanner.c etc. do support the reading of wide chars thus, in
principle, only few changes should be required.

Caveat: Many people still use kind=1 strings - but with non-ASCII characters;
one should try to make sure that this continues to work. Stuffing the
characters in as one currently does is one option. For Latin1 (ISO 8859-1)
characters one can also simply strip off the high bytes and write only the
first byte. Using UTF-8 also works - though len() will report too many
characters.


-- 
   Summary: Support UTF-8 (and other encodings) in the source file
(.f90) for CHARACTER(kind=4)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/45179] Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-08-04 10:19 ---
Created an attachment (id=21392)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21392&action=view)
Test case in UTF-8 encoding

Compile with:
  gfortran -cpp -finput-charset=UTF-8 wide.f90

Expected output:
  Hello World = 你好
  你好

Currently, the second line is wrong; the two Chinese characters Ni (you) and
Hao (good) [ni hao = hello, good morning/afternoon] are split into six one-byte
characters as len() shows.


-- 


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

[Bug c/45176] restrict qualifier is not used in a manually unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-04 11:09 ---
Subject: Bug 45176

Author: rguenth
Date: Wed Aug  4 11:08:54 2010
New Revision: 162862

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162862
Log:
2010-08-04  Richard Guenther  

PR middle-end/45176
* expr.c (expand_expr_real_1): Also preserve TARGET_MEM_REF
points-to set for original MEM_REF.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c


-- 


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

[Bug c/45176] restrict qualifier is not used in a manually unrolled loop

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-08-04 11:09 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[kkojima at gcc dot gnu dot org]

--- Comment #5 from kkojima at gcc dot gnu dot org  2010-08-04 11:19 ---
FYI, SH fails to bootstrap with similar comparison failures:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/double-int.o differs
gcc/tree-vect-data-refs.o differs
gcc/value-prof.o differs
gcc/cgraph.o differs

for revision 162730 on sh4-unknown-linux-gnu and yes, -O2 and
-O2 -g produce different codes for those files.
The non-reduced testcase in #3 is also a testcase for SH.


-- 

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=45162

[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-08-04 11:51 ---
Subject: Bug 44857

Author: burnus
Date: Wed Aug  4 11:51:32 2010
New Revision: 162863

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162863
Log:
2010-08-04  Tobias Burnus  

PR fortran/44857
* resolve.c (resolve_structure_cons): Fix handling of
initialization structcture constructors with character
elements of the wrong length.
* array.c (gfc_check_iter_variable): Add NULL check.
(gfc_resolve_character_array_constructor): Also truncate
character length.

2010-08-04  Tobias Burnus  

PR fortran/44857
* gfortran.dg/derived_constructor_char_1.f90: New.
* gfortran.dg/derived_constructor_char_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/derived_constructor_char_1.f90
trunk/gcc/testsuite/gfortran.dg/derived_constructor_char_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-08-04 11:53 ---
FIXED on the trunk (4.6). Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2010-08-04 12:17 ---
At r162860, I see only one problem left: A linker error (undefined reference to
`vtab$inner.1582') on the following variation of comment #5/#6:


module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
contains
subroutine set(this)
class(inner) :: this
end subroutine
end module

module module_mysubclass
implicit none
integer :: shit = 5
contains
subroutine init()
use module_myclass, only : myclass
type(myclass) :: this
call this%slice%set() ! XXX PROBLEM HERE
shit = shit + 1
end subroutine
end module

program test
end


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-15 20:02:24 |2010-08-04 12:17:08
   date||


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2010-08-04 12:27 ---
The -O2 -fcompare-debug failure on ARM is caused by r162678:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01032.html

Both the original large testcase and the reduced one compile fine with
gcc-4.6-r162677 -O2 -fcompare-debug, but fail with r162678.

I haven't checked more recent revisions yet due to PR45177.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org


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

[Bug fortran/45179] Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-08-04 12:39 ---
Created an attachment (id=21393)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21393&action=view)
Support -finput-charset=  (accepts option, but does not fix the issue)

This patch allows the -finput-charset= but it does not fix the actual problem.


scanner.c has: load_line, which works with wide strings, but gets the letters
via getc(). Maybe one could implement UTF-8 reading for strings in scanner.c -
and use libcpp (-cpp) to convert the input encoding to UTF-8, if it isn't
UTF-8.

http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/io/read.c;hb=HEAD#l236


If one uses CPP, one probably needs to set (internally) wide_charset to UTF-8
such that CPP outputs UTF-8.


Possible work plan:

a) if -finput-charset= is used but CPP is not used: Allow UTF-8 but print an
error for other encodings. Read internally as UTF-8.

b) if -finput-charset= is used with -cpp: Allow it and set exec encoding (or
whatever it is called) to UTF-8 such that libcpp returns an UTF-8 string to
gfortran

c) By default continue to use the current means of input, i.e. a simple getc.


-- 


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #7 from bernds at gcc dot gnu dot org  2010-08-04 12:47 ---
Created an attachment (id=21394)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21394&action=view)
A patch that should fix it

DEBUG_INSNs got me again.  Actually the old byte dce was disabled and thus not
converted to handling them.

Try this patch.


-- 


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

[Bug tree-optimization/45180] New: bogus warning: array subscript is above array bounds

[joachim dot reichel at gmx dot de]

Please see 43949 which was about a very similar test case.

$ cat test.cpp
void f();

int c[3];
int result;

struct Vector {
static int get(int i) {
if (i >= 3)
f();
return c[i];
}
};

void g(int index)
{
result = Vector::get(index) + Vector::get(index);
}

$ g++ -Wall -c test.cpp
[no warnings]

$ g++ -Wall -c -O2 test.cpp
test.cpp: In function ‘void g()’:
test.cpp:10:19: error: array subscript is above array bounds

$ g++ -v
Using built-in specs.
COLLECT_GCC=/prefix/gcc-4.5.0/x86_64-unknown-linux-gnu/bin/g++
COLLECT_LTO_WRAPPER=/prefix/gcc-4.5.0/x86_64-unknown-linux-gnu/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/prefix/gcc-4.5.0
--exec-prefix=/prefix/gcc-4.5.0/x86_64-unknown-linux-gnu
--enable-version-specific-runtime-libs --enable-stage1-checking --disable-nls
--with-system-zlib --enable-multilib --enable-languages=c,c++,objc
--with-gmp-include=/prefix/gmp-4.2.2/x86_64-unknown-linux-gnu/include
--with-gmp-lib=/prefix/gmp-4.2.2/x86_64-unknown-linux-gnu/lib
--with-mpfr-include=/prefix/mpfr-2.4.2/include
--with-mpfr-lib=/prefix/mpfr-2.4.2/x86_64-unknown-linux-gnu/lib
--with-mpc-include=/prefix/mpc-0.8.1/include
--with-mpc-lib=/prefix/mpc-0.8.1/x86_64-unknown-linux-gnu/lib --with-gnu-as
--with-as=/prefix/binutils-2.20.1/x86_64-unknown-linux-gnu/bin/as --with-gnu-ld
--with-ld=/prefix/binutils-2.20.1/x86_64-unknown-linux-gnu/bin/ld
Thread model: posix
gcc version 4.5.0 (GCC)

The bogus warning disappears if
- Vector::get(index) is assigned to result (no addition)
- get() is a global function

The bogus warning does not appear in gcc 4.2.4 (Debian 4.2.4-6). It appears
also in 4.3.2 (Debian 4.3.2-1.1), 4.4.4 (Debian 4.4.4-7) and 4.5.0 (GCC).

Note that in contrast to PR43949 in this case the array subscript *could* be
above array bounds depending on how g() is called, but in the code snippet
itself there is no such call.


-- 
   Summary: bogus warning: array subscript is above array bounds
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joachim dot reichel at gmx dot de
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug tree-optimization/45178] CDDCE doesn't eliminate conditional code in infinite loop

[hubicka at ucw dot cz]

--- Comment #1 from hubicka at ucw dot cz  2010-08-04 13:05 ---
Subject: Re:   New: CDDCE doesn't eliminate
conditional code in infinite loop

Hmm, so the problem is that we produce two alternating loops and both with
unknown number of iterations?
We might teach loop discovery to preffer single infinite loop over alternation
I guess.


-- 


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

[Bug target/44919] ICE on ia64 with -O3 at sel-sched.c:4672

[joachim dot reichel at gmx dot de]

--- Comment #5 from joachim dot reichel at gmx dot de  2010-08-04 13:06 
---
Is there any reason not to commit the patch?


-- 


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

[Bug tree-optimization/45180] bogus warning: array subscript is above array bounds

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-04 13:09 ---
The reasoning of GCC goes as follows.  There is a partial redundancy
along the two invocations of get(), as c[i] is possibly clobbered by f().
So we transform g() to

  if (i >= 3)
 f();
  tem1 = c[i];
  if (i >= 3)
{
f();
tem2 = c[i];
   }
  else tem2 = tem1;
  return tem1 + tem2;

now you can see that the load to tem2 is _always_ accessing c with
an out-of-bound index.

There is no code in the warning machinery to restrict the "is above"
warning to code regions that are always executed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 13:09:50
   date||


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

[Bug target/44919] ICE on ia64 with -O3 at sel-sched.c:4672

[abel at gcc dot gnu dot org]

--- Comment #6 from abel at gcc dot gnu dot org  2010-08-04 13:17 ---
My employer's copyright assignment has expired, this would be fixed within a
week or so.  Never mind because there's still time before the next 4.4 release.


-- 


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

[Bug tree-optimization/45178] CDDCE doesn't eliminate conditional code in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-04 13:21 ---
(In reply to comment #1)
> Subject: Re:   New: CDDCE doesn't eliminate
> conditional code in infinite loop
> 
> Hmm, so the problem is that we produce two alternating loops and both with
> unknown number of iterations?
> We might teach loop discovery to preffer single infinite loop over alternation
> I guess.

Yeah, that might help.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 13:21:34
   date||


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

[Bug debug/45181] New: No debug information for parameter type

[nikolay at totalviewtech dot com]

If parameter of function is passed as reference or pointer, there is no debug
information for type and all pointers/references are of type void*/&.


-- 
   Summary: No debug information for parameter type
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nikolay at totalviewtech dot com


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

[Bug debug/45181] No debug information for parameter type

[nikolay at totalviewtech dot com]

--- Comment #1 from nikolay at totalviewtech dot com  2010-08-04 13:29 
---
Created an attachment (id=21395)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21395&action=view)
Reproducer

How to Repeat:
Untar reproducer and run debugger to line 53. 
check all parameters, they all of type void


-- 


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

[Bug debug/45181] No debug information for parameter type

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-08-04 13:54 ---
related to PR 44645 ?


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|No debug information for|No debug information for
   |parameter type  |parameter type


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

[Bug debug/45181] No debug information for parameter type

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-08-04 14:01 ---
there's no need to attach executables, people working on gcc bugs have access
to a compiler!

I think this is the same issue as I reported in PR 44645 as it only happens
with 4.5 not 4.1, 4.4 or 4.6


-- 


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

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

[ubizjak at gmail dot com]

--- Comment #14 from ubizjak at gmail dot com  2010-08-04 14:04 ---
Following patch fixes my failures:

Index: lib/scanasm.exp
===
--- lib/scanasm.exp (revision 162854)
+++ lib/scanasm.exp (working copy)
@@ -316,7 +316,7 @@
}
 }

-set pattern [format {%s:[^\t]*(\t.file[^\t]*)?\t[^:]+:%d\n} \
+set pattern [format {%s:[^\t]*(\t.(frame|mask|file)[^\t]*)*\t[^:]+:%d\n} \
  $symbol $line]

 # The lack of spaces around $pattern is important, since they'd


-- 


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

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

[mikael at gcc dot gnu dot org]

--- Comment #22 from mikael at gcc dot gnu dot org  2010-08-04 14:17 ---
Subject: Bug 42051

Author: mikael
Date: Wed Aug  4 14:17:31 2010
New Revision: 162865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162865
Log:
2010-08-04  Mikael Morin  

PR fortran/42051
PR fortran/44064
* symbol.c (changed_syms): Made static again.
(gfc_symbol_state): Don't conditionalize on GFC_DEBUG. 
Changed conditional internal error into assert.
Rename function to ...
(gfc_enforce_clean_symbol_state): ... this.
* gfortran.h (gfc_symbol_state, gfc_enforce_clean_symbol_state): 
Rename the former to the latter.
* parse.c (decode_statement, decode_omp_directive,
decode_gcc_attribute): Update callers accordingly. Don't conditionalize
on GFC_DEBUG.
(changed_syms): Remove declaration.
(next_statement): Use gfc_enforce_clean_symbol_state.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c


-- 


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

[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

[mikael at gcc dot gnu dot org]

--- Comment #12 from mikael at gcc dot gnu dot org  2010-08-04 14:17 ---
Subject: Bug 44064

Author: mikael
Date: Wed Aug  4 14:17:31 2010
New Revision: 162865

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162865
Log:
2010-08-04  Mikael Morin  

PR fortran/42051
PR fortran/44064
* symbol.c (changed_syms): Made static again.
(gfc_symbol_state): Don't conditionalize on GFC_DEBUG. 
Changed conditional internal error into assert.
Rename function to ...
(gfc_enforce_clean_symbol_state): ... this.
* gfortran.h (gfc_symbol_state, gfc_enforce_clean_symbol_state): 
Rename the former to the latter.
* parse.c (decode_statement, decode_omp_directive,
decode_gcc_attribute): Update callers accordingly. Don't conditionalize
on GFC_DEBUG.
(changed_syms): Remove declaration.
(next_statement): Use gfc_enforce_clean_symbol_state.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c


-- 


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

[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996

[clerman at fuse dot net]

--- Comment #15 from clerman at fuse dot net  2010-08-04 14:18 ---
Subject: Re:  [4.6 Regression] ICE in
 output_constructor_regular_field, at varasm.c:4996

You're welcome. Thanks for your help.

Norm

 burnus at gcc dot gnu dot org  wrote: 

=


--- Comment #14 from burnus at gcc dot gnu dot org  2010-08-04 11:53
---
FIXED on the trunk (4.6). Thanks for the report!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.


-- 


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

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

[uros at gcc dot gnu dot org]

--- Comment #15 from uros at gcc dot gnu dot org  2010-08-04 14:19 ---
Subject: Bug 44641

Author: uros
Date: Wed Aug  4 14:19:01 2010
New Revision: 162866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162866
Log:
PR c++/44641
* lib/scanasm.exp (dg-function-on-line): Expand regex to also ignore
.frame and .mask assembler directives.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/scanasm.exp


-- 


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

[Bug debug/45181] No debug information for parameter type

[nikolay at totalviewtech dot com]

--- Comment #4 from nikolay at totalviewtech dot com  2010-08-04 14:23 
---
Yes, this looks similar. The same error is seen in dwarf


-- 


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

[Bug c++/44641] Generated constructors and destructors get wrong debug location when a typedef uses a forward declaration of the type before the definition

[ubizjak at gmail dot com]

--- Comment #16 from ubizjak at gmail dot com  2010-08-04 14:28 ---
Fixed (for alpha) by extending regexp in dg-function-on-line procedure.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0


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

[Bug debug/45181] No debug information for parameter type

[redi at gcc dot gnu dot org]

--- Comment #5 from redi at gcc dot gnu dot org  2010-08-04 14:29 ---
reduced

struct S { int f(S*); };

int S::f(S* p)
{
return 0;
}

int main()
{
S s;
return s.f(&s);
}

within S::f p has type void*


-- 


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

[Bug middle-end/45182] New: [4.6 regression] Failed to build SPEC CPU 2000/2006

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 162853 failed to
build SPEC CPU 2000/2006:

With runspec -c lnx-x86_64-gcc.cfg -T base -n 1 -l -o asc -I all -e o3
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build >
make.out 2> make.err': check file
'/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CINT2000/254.gap/run/0001/make.err'
  Error with make!
*** Error building 254.gap
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build >
make.out 2> make.err': check file
'/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CINT2000/256.bzip2/run/0001/make.err'
  Error with make!
*** Error building 256.bzip2
Error: 1x254.gap 1x256.bzip2

With runspec -c lnx-x86_64-gcc.cfg -T base -n 1 -l -o asc -I all -e o3
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/benchspec/CPU2006/401.bzip2/build/build_base_o3./make.err'
  Error with make!
*** Error building 401.bzip2
Error with make 'specmake -j `/usr/bin/getconf _NPROCESSORS_ONLN` build': check
file
'/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/benchspec/CPU2006/464.h264ref/build/build_base_o3./make.err'
  Error with make!
*** Error building 464.h264ref
Build errors: 401.bzip2(base; CE), 464.h264ref(base; CE)
Error: 1x401.bzip2 1x464.h264ref

Revision 162839 is OK. One error is:

gcc -c -o range.o   -DSPEC_CPU2000_LP64 -DSYS_IS_USG -DSYS_HAS_IOCTL_PROTO
-DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_CALLOC_PROTO
-DSYS_HAS_READ_PROTO-O2 -ffast-math -O3 -ffast-math -funroll-loops 
range.c
range.c: In function 'PlainRange':
range.c:557:1: internal compiler error: in trunc_int_for_mode, at explow.c:57
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.6 regression] Failed to build SPEC CPU 2000/2006
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-08-04 14:49 ---
[...@gnu-35 delta]$ cat testcase-min.i
 typedef struct TypHeader {
 struct TypHeader * * ptr;
 } * TypHandle;
 void PlainRange ( hdList ) TypHandle hdList;
 {
 long lenList;
 long low;
 long inc;
 long i;
 for ( i = 1;
 i <= lenList;
 i++ ) {
 (((TypHandle*)((hdList)->ptr))[i] = (((TypHandle) (((long)(low + (i-1)
* inc) << 2) + 1;
 }
 }
[...@gnu-35 delta]$ ./usr/bin/gcc -S -O3 -ffast-math -funroll-loops 
testcase-min.i 
testcase-min.i: In function \u2018PlainRange\u2019:
testcase-min.i:15:2: internal compiler error: in trunc_int_for_mode, at
explow.c:57
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-35 delta]$ 


-- 


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

[Bug tree-optimization/45180] bogus warning: array subscript is above array bounds

[joachim dot reichel at gmx dot de]

--- Comment #2 from joachim dot reichel at gmx dot de  2010-08-04 15:00 
---
Ok, I see. But that seems a bit unfortunate. Isn't there a great deal of such
code? Just think of some vector class: c would be a class member, get()
non-static and "if...f()" is an assert-like statement (that might return or
not).

void f();

int result;

struct Vector {
int c[3];
int get(int i) const {
if (i >= 3)
f();
return c[i];
}
};

void g(const Vector& x, int index)
{
result = x.get(index) + x.get(index);
}

--

In the original test case if I make get() a global function, then there is no
warning. Is the code then transformed differently?

And if I replace the argument in the second call of get() by index+1 I also
don't get the warning. I guess that's because the load into tem2 gets moved out
of the if-block then?

Just trying to understand how common the problem is ...


-- 


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

[Bug middle-end/45150] [4.6 Regression] bootstrap debug-compare fail

[danglin at gcc dot gnu dot org]

--- Comment #4 from danglin at gcc dot gnu dot org  2010-08-04 15:00 ---
I back-ported r162697 to r162678 and see comparison fail at r162678.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 15:00:59
   date||


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #8 from bernds at gcc dot gnu dot org  2010-08-04 15:16 ---
*** Bug 45150 has been marked as a duplicate of this bug. ***


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||iains at gcc dot gnu dot org


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

[Bug middle-end/45150] [4.6 Regression] bootstrap debug-compare fail

[bernds at gcc dot gnu dot org]

--- Comment #5 from bernds at gcc dot gnu dot org  2010-08-04 15:16 ---


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


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-08-04 15:30 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 15:30:30
   date||
   Target Milestone|--- |4.6.0


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-08-04 15:36 ---
It is caused by revision 162849:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00060.html


-- 


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

[Bug tree-optimization/45180] bogus warning: array subscript is above array bounds

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2010-08-04 15:44 ---
Since the compiler does not know that f() will never return, it is hard problem
to solve.  If you mark f with the attribute noreturn, the warning will
disappear.


-- 


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

[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-08-04 15:57 ---
This testcase doesn't have any warnings:

---
typedef struct TypHeader {
  struct TypHeader ** ptr;
} *TypHandle;
void PlainRange (TypHandle hdList, long lenList, long low, long inc)
{
  long i;
  for (i = 1; i <= lenList; i++ )
(((TypHandle*)((hdList)->ptr))[i] = (((TypHandle) (((long)(low + (i-1) *
inc) << 2) + 1;
}
---


-- 


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

[Bug fortran/45183] New: [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 162863 gave

FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "five = ..txt=..AbCdE., .ZyXwV...;" 1: dump file does not exist
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "four = ..txt=..ABC  ., .ZYX  ...;" 1: dump file does not exist
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "one = ..txt=..12345., .67890...;" 1: dump file does not exist
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "six = ..txt=..aBcDe., .zYxWv...;" 1: dump file does not exist
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "three = ..txt=..12345., .abcde...;" 1: dump file does not exist
FAIL: gfortran.dg/derived_constructor_char_1.f90  -O  scan-tree-dump-times
original "two = ..txt=..123  ., .678  ...;" 1: dump file does not exist

Revision 162860 is OK


-- 
   Summary: [4.6 Regression] FAIL:
gfortran.dg/derived_constructor_char_1.f90
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/45184] New: integer lexem error-bug

[altmer at arts-union dot ru]

Wrong code example:

int Test(int src)
{
 a=0x5E+src; //here 
 return a;
}


-- 
   Summary: integer lexem error-bug
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: altmer at arts-union dot ru


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[danglin at gcc dot gnu dot org]

--- Comment #9 from danglin at gcc dot gnu dot org  2010-08-04 16:38 ---
The patch fixes the darwin comparison failure.


-- 

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=45162

[Bug c++/45184] integer lexem error-bug

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2010-08-04 16:40 ---


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


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug preprocessor/33547] invalid suffix "+0x23" on integer constant

[schwab at linux-m68k dot org]

--- Comment #2 from schwab at linux-m68k dot org  2010-08-04 16:40 ---
*** Bug 45184 has been marked as a duplicate of this bug. ***


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 CC||altmer at arts-union dot ru


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

[Bug lto/45185] New: Building GCC-4.5.1 for arm-elf

[e0600347 at student dot tuwien dot ac dot at]

I am trying to build 4.5.1 for arm-elf. Although I succeed for 4.5.1 RC
(07-22-2010), the compilation fails for the final release. I have double
checked that I am compiling both versions exactly the same way.

1) export PATH=/data/gcc-arm/arm-elf/bin:$PATH  
2) (build and install binutils 2.20.1 for arm-elf)
3) symlink mpfr-2.3.2 and gmp-4.3.2 into gcc source
4) uncomment lines in gcc/config/arm/t-arm-elf:
 MULTILIB_OPTIONS+= mno-thumb-interwork/mthumb-interwork
 MULTILIB_DIRNAMES   += normal interwork
5) configure with:
../gcc-4.5.1/configure --target=arm-elf --enable-multilib --enable-languages=c
--enable-clocale=gnu --disable-libm --disable-libc --disable-threads
--disable-nls --disable-libssp --disable-intl --with-newlib
--prefix=/data/gcc-arm/arm-elf --srcdir=/data/gcc-arm/wa/gcc-4.5.1
6) build with:
(unset LIBRARY_PATH; unset CFLAGS; make -j 3 && make install)

Results:
gcc-4.5.1-RC-20100722 succeeds, compiles and works perfectly.
gcc-4.5.1 final fails compile with (last lines of build output):

gcc  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H  -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-elf.o attribs.o main.o 
libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lcloog  -lppl_c
-lppl -lgmpxx -L/data/gcc-arm/wa/gcc_obj2/./gmp/.libs
-L/data/gcc-arm/wa/gcc_obj2/./mpfr/.libs -lmpc -lmpfr -lgmp -ldl  -L../zlib -lz
-lelf ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -lelf
/usr/bin/ld: __gmpfr_cache_const_euler: TLS definition in /usr/lib/libmpfr.so.4
section .tdata mismatches non-TLS definition in
/data/gcc-arm/wa/gcc_obj2/./mpfr/.libs/libmpfr.a(const_euler.o) section .data
/usr/lib/libmpfr.so.4: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [lto1] Error 1
make[2]: *** Waiting for unfinished jobs
/usr/bin/ld: __gmpfr_cache_const_euler: TLS definition in /usr/lib/libmpfr.so.4
section .tdata mismatches non-TLS definition in
/data/gcc-arm/wa/gcc_obj2/./mpfr/.libs/libmpfr.a(const_euler.o) section .data
/usr/lib/libmpfr.so.4: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [cc1-dummy] Error 1
rm gcc.pod
make[2]: Leaving directory `/data/gcc-arm/wa/gcc_obj2/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/data/gcc-arm/wa/gcc_obj2'
make: *** [all] Error 2


-- 
   Summary: Building GCC-4.5.1 for arm-elf
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e0600347 at student dot tuwien dot ac dot at
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-elf


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

[Bug lto/45185] Building GCC-4.5.1 for arm-elf

[e0600347 at student dot tuwien dot ac dot at]

--- Comment #1 from e0600347 at student dot tuwien dot ac dot at  
2010-08-04 16:48 ---
Created an attachment (id=21396)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21396&action=view)
./configure output

Configure output before failing compile attached.


-- 


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

[Bug bootstrap/45185] Building GCC-4.5.1 with gmp/mpfr in source

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-08-04 17:05 ---
What distribution are you running on your x86_64 machine?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|lto |bootstrap
 GCC target triplet|arm-elf |
   Keywords||build
Summary|Building GCC-4.5.1 for arm- |Building GCC-4.5.1 with
   |elf |gmp/mpfr in source


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

[Bug bootstrap/45185] Building GCC-4.5.1 with gmp/mpfr in source

[e0600347 at student dot tuwien dot ac dot at]

--- Comment #3 from e0600347 at student dot tuwien dot ac dot at  
2010-08-04 17:26 ---
Arch Linux
GCC version of host: 4.5.0 20100610
binutils of host: 2.20.1-3


-- 

e0600347 at student dot tuwien dot ac dot at changed:

   What|Removed |Added

 CC||e0600347 at student dot
   ||tuwien dot ac dot at


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

[Bug bootstrap/45185] Building GCC-4.5.1 with gmp/mpfr in source

[e0600347 at student dot tuwien dot ac dot at]

--- Comment #4 from e0600347 at student dot tuwien dot ac dot at  
2010-08-04 17:35 ---
(In reply to comment #3)
> Arch Linux
> GCC version of host: 4.5.0 20100610
> binutils of host: 2.20.1-3
> 

One more bit of info about host compiler:

 gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib
--disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
Thread model: posix
gcc version 4.5.0 20100610 (prerelease) (GCC) 


-- 


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

[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-08-04 17:39 ---
PATCH - lightly tested. Now regtesting.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (Revision 162868)
+++ gcc/fortran/resolve.c   (Arbeitskopie)
@@ -936,11 +936,26 @@ resolve_structure_cons (gfc_expr *expr)
  p = gfc_constructor_first (cons->expr->value.constructor);
  if (cons->expr->ts.u.cl != p->expr->ts.u.cl)
{
- gfc_free_expr (cons->expr->ts.u.cl->length);
- gfc_free (cons->expr->ts.u.cl);
+ gfc_charlen *cl, *cl2;
+
+ cl2 = NULL;
+ for (cl = gfc_current_ns->cl_list; cl; cl = cl->next)
+   {
+ if (cl == cons->expr->ts.u.cl)
+   break;
+ cl2 = cl;
+   }
+
+ gcc_assert (cl);
+
+ if (cl2)
+   cl2->next = cl->next;
+
+ gfc_free_expr (cl->length);
+ gfc_free (cl);
}

- cons->expr->ts.u.cl = gfc_get_charlen ();
+ cons->expr->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
  cons->expr->ts.u.cl->length_from_typespec = true;
  cons->expr->ts.u.cl->length = gfc_copy_expr
(comp->ts.u.cl->length);
  gfc_resolve_character_array_constructor (cons->expr);


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 17:39:41
   date||


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

[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2010-08-04 18:09 ---
(In reply to comment #1)
> PATCH - lightly tested. Now regtesting.
> 
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c   (Revision 162868)
> +++ gcc/fortran/resolve.c   (Arbeitskopie)
> @@ -936,11 +936,26 @@ resolve_structure_cons (gfc_expr *expr)
>   p = gfc_constructor_first (cons->expr->value.constructor);
>   if (cons->expr->ts.u.cl != p->expr->ts.u.cl)
> {
> - gfc_free_expr (cons->expr->ts.u.cl->length);
> - gfc_free (cons->expr->ts.u.cl);
> + gfc_charlen *cl, *cl2;
> +
> + cl2 = NULL;
> + for (cl = gfc_current_ns->cl_list; cl; cl = cl->next)
> +   {
> + if (cl == cons->expr->ts.u.cl)
> +   break;
> + cl2 = cl;
> +   }
> +
> + gcc_assert (cl);
> +
> + if (cl2)
> +   cl2->next = cl->next;
> +
> + gfc_free_expr (cl->length);
> + gfc_free (cl);
> }
> 
> - cons->expr->ts.u.cl = gfc_get_charlen ();
> + cons->expr->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
>   cons->expr->ts.u.cl->length_from_typespec = true;
>   cons->expr->ts.u.cl->length = gfc_copy_expr
> (comp->ts.u.cl->length);
>   gfc_resolve_character_array_constructor (cons->expr);
> 

I must be missing something here.  What does cl2 do in the above
patch?  You set it, but it is never used.


-- 


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

[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2010-08-04 18:13 ---
>
> I must be missing something here.  What does cl2 do in the above
> patch?  You set it, but it is never used.
> 

Nevermind, I understand what the code does.  I can't even claim
that I haven't had enough coffee this morning. :(


-- 


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

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[sje at gcc dot gnu dot org]

--- Comment #11 from sje at gcc dot gnu dot org  2010-08-04 18:32 ---
Subject: Bug 44583

Author: sje
Date: Wed Aug  4 18:32:37 2010
New Revision: 162869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162869
Log:
2010-07-29  Steve Ellcey  

PR target/44583
* config/ia64/constraints.md (Z): New.
* config/ia64/predicates.md (fr_reg_or_signed_fp01_operand): New.
(xfreg_or_signed_fp01_operand): New.
* config/ia64/ia64.md (addsf3): Replace fr_reg_or_fp01_operand
with fr_reg_or_signed_fp01_operand and constraint G with Z.
(subsf3): Ditto.
(*maddsf4): Ditto.
(*msubsf4): Ditto.
(adddf3): Ditto.
(adddf3_trunc): Ditto.
(subdf3): Ditto.
(*subdf3_trunc): Ditto.
(*madddf4): Ditto.
(*madddf4_trunc): Ditto.
(*msubdf4): Ditto.
(*msubdf4_trunc): Ditto.
(addxf3): Replace xfreg_or_fp01_operand with
xfreg_or_signed_fp01_operand and constraint G with Z.
(*addxf3_truncsf): Ditto.
(*addxf3_truncdf): Ditto.
(subxf3): Ditto.
(*subxf3_truncsf): Ditto.
(*subxf3_truncdf): Ditto.
(*maddxf4): Ditto.
(*maddxf4_truncsf): Ditto.
(*maddxf4_truncdf): Ditto.
(*msubxf4): Ditto.
(*msubxf4_truncsf): Ditto.
(*msubxf4_truncdf): Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/ia64/constraints.md
trunk/gcc/config/ia64/ia64.md
trunk/gcc/config/ia64/predicates.md


-- 


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

[Bug fortran/44857] [4.6 Regression] ICE in output_constructor_regular_field, at varasm.c:4996

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-08-04 18:49 ---
Subject: Bug 44857

Author: burnus
Date: Wed Aug  4 18:49:23 2010
New Revision: 162871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162871
Log:
2010-08-04  Tobias Burnus  

PR fortran/45183
PR fortran/44857
* resolve.c (resolve_structure_cons): Fix
freeing of charlen.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c


-- 


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

[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-08-04 18:49 ---
Subject: Bug 45183

Author: burnus
Date: Wed Aug  4 18:49:23 2010
New Revision: 162871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162871
Log:
2010-08-04  Tobias Burnus  

PR fortran/45183
PR fortran/44857
* resolve.c (resolve_structure_cons): Fix
freeing of charlen.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c


-- 


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

[Bug fortran/45183] [4.6 Regression] FAIL: gfortran.dg/derived_constructor_char_1.f90

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-08-04 18:50 ---
FIXED. Thanks for the timely report.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[howarth at nitro dot med dot uc dot edu]

--- Comment #17 from howarth at nitro dot med dot uc dot edu  2010-08-04 
19:20 ---
Unverified but I am told that this issue should be fixed in Xcode 3.2.3.


-- 


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

[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros

[sje at cup dot hp dot com]

--- Comment #12 from sje at cup dot hp dot com  2010-08-04 19:25 ---
Fixed on ToT.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *

[jamborm at gcc dot gnu dot org]

--- Comment #7 from jamborm at gcc dot gnu dot org  2010-08-04 19:33 ---
(In reply to comment #6)
> I think the thread about the patch became confused.
> 
> First, Janis essentially approved the testsuite patch.

OK, I've re-submitted the patch to the mailing list and will commit it
tomorrow if nobody objects.  Thanks.

> 
> Second, Martin commented that the failure probably was due to MOVE_RATIO not
> defined.  The statement caused some misunderstanding.  MOVE_RATIO does not 
> need
> to be defined and the failure is not caused by a missing definition.  The
> default value of MOVE_RATIO (used by PPC and ARM) cause the heuristic to
> disable the optimization being tested.
> 
> If the optimization is not expected to occur on some platforms, then the
> testcase should be disabled as implemented by the patch or the testcase
> explicitly should set some gcc param that ensures the optimization will occur
> on all targets.
> 

Well, MOVE_RATIO defines the ratio of costs of different methods of
copying memory.  Assuming that the default value is indeed the correct
one for those platforms, it is most probably OK that SRA decides not
to totally scalarize the aggregate in the testcase in question.  But
that is really what the platform maintainers should examine (or at
least someone who knows the platforms well enough should do it).


-- 


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

[Bug middle-end/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.

[rth at gcc dot gnu dot org]

--- Comment #10 from rth at gcc dot gnu dot org  2010-08-04 19:33 ---
Verified with

  typedef struct { int a, b; } x;

./cc1plus -g -fno-eliminate-unused-debug-types -dA z.c

.uleb128 0x2# (DIE (0x2d) DW_TAG_structure_type)
.byte   0x8 # DW_AT_byte_size
.byte   0x1 # DW_AT_decl_file (z.c)
.byte   0x3 # DW_AT_decl_line
.byte   0x8 # DW_AT_byte_size
.byte   0x1 # DW_AT_decl_file (z.c)
.byte   0x3 # DW_AT_decl_line

Note that both byte_size and and the decl location are replicated.
This happens with the C++ compiler, but not the C compiler.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-08-04 19:33:43
   date||


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

[Bug fortran/44065] [OOP] Undefined reference to vtab$...

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2010-08-04 19:49 ---
Subject: Bug 44065

Author: janus
Date: Wed Aug  4 19:49:19 2010
New Revision: 162879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162879
Log:
2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* class.c (gfc_find_derived_vtab): Do not generate vtabs for class
container types. Do not artificially increase refs. Commit symbols one
by one.
* interface.c (compare_parameter): Make sure vtabs are present before
generating module variables.
* resolve.c (resolve_allocate_expr): Ditto.


2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* gfortran.dg/class_25.f03: New.
* gfortran.dg/class_26.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_25.f03
trunk/gcc/testsuite/gfortran.dg/class_26.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

[janus at gcc dot gnu dot org]

--- Comment #13 from janus at gcc dot gnu dot org  2010-08-04 19:49 ---
Subject: Bug 44064

Author: janus
Date: Wed Aug  4 19:49:19 2010
New Revision: 162879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162879
Log:
2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* class.c (gfc_find_derived_vtab): Do not generate vtabs for class
container types. Do not artificially increase refs. Commit symbols one
by one.
* interface.c (compare_parameter): Make sure vtabs are present before
generating module variables.
* resolve.c (resolve_allocate_expr): Ditto.


2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* gfortran.dg/class_25.f03: New.
* gfortran.dg/class_26.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_25.f03
trunk/gcc/testsuite/gfortran.dg/class_26.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment

[janus at gcc dot gnu dot org]

--- Comment #20 from janus at gcc dot gnu dot org  2010-08-04 19:49 ---
Subject: Bug 42207

Author: janus
Date: Wed Aug  4 19:49:19 2010
New Revision: 162879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162879
Log:
2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* class.c (gfc_find_derived_vtab): Do not generate vtabs for class
container types. Do not artificially increase refs. Commit symbols one
by one.
* interface.c (compare_parameter): Make sure vtabs are present before
generating module variables.
* resolve.c (resolve_allocate_expr): Ditto.


2010-08-04  Janus Weil  

PR fortran/42207
PR fortran/44064
PR fortran/44065
* gfortran.dg/class_25.f03: New.
* gfortran.dg/class_26.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_25.f03
trunk/gcc/testsuite/gfortran.dg/class_26.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #55 from dave at hiauly1 dot hia dot nrc dot ca  2010-08-04 
19:52 ---
Subject: Re:  [4.6 regression] Revision 162270 failed
to bootstrap

The exception is caused by get_bb_copy returning NULL.  However, get_bb_copy
is not miscompiled.

The change to function.c changes various copies to extracts for
zero/sign extension.  These might cause a functional difference.
For example,

-   copy %r26,%r23
+   extrd,u %r26,63,32,%r23

It won't be easy to substitute functions in the .s file because
there are a many label changes.

Dave


-- 


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

[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

[janus at gcc dot gnu dot org]

--- Comment #14 from janus at gcc dot gnu dot org  2010-08-04 19:57 ---
Comment #11 is fixed with r162879. I think we can finally close this one.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/42207] [OOP] Compile-time errors on typed allocation and pointer function result assignment

[janus at gcc dot gnu dot org]

--- Comment #21 from janus at gcc dot gnu dot org  2010-08-04 20:00 ---
Fixed with r162879. Closing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/44065] [OOP] Undefined reference to vtab$...

[janus at gcc dot gnu dot org]

--- Comment #12 from janus at gcc dot gnu dot org  2010-08-04 20:05 ---
r162879 seems to fix all the test cases for me. Can anyone confirm that comment
#0 works now without any linking errors?


-- 


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-08-04 20:06 ---
It's caused by r162815:
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00026.html

The build failure still occurs with r162878.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2010-08-04 20:13 ---
Bernd's patch fixes the -fcompare-debug failures in my arm cross-compiler.


-- 


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

[Bug fortran/45186] New: Gfortran 4.5.0 emits wrong linenumbers

[nikolay at totalviewtech dot com]

This is pretty widespread. I have attached one example, but I see it in many
programs. 
How to repeat:
Compile with -g 
Do a next couple of times: Notice, that PC is jumping back and forth. Also
notice, that there is no linenumbers for lines 19 20 and 27


-- 
   Summary: Gfortran 4.5.0 emits wrong linenumbers
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nikolay at totalviewtech dot com


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

[Bug fortran/45186] Gfortran 4.5.0 emits wrong linenumbers

[nikolay at totalviewtech dot com]

--- Comment #1 from nikolay at totalviewtech dot com  2010-08-04 21:03 
---
Created an attachment (id=21397)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21397&action=view)
example


-- 


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #11 from bernds at gcc dot gnu dot org  2010-08-04 21:07 ---
Subject: Bug 45162

Author: bernds
Date: Wed Aug  4 21:07:05 2010
New Revision: 162881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162881
Log:
PR rtl-optimization/45162
* df-problems.c (df_word_lr_bb_local_compute): Ignore DEBUG_INSNs.
* dce.c (word_dce_process_block): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dce.c
trunk/gcc/df-problems.c


-- 


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

[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #12 from bernds at gcc dot gnu dot org  2010-08-04 21:14 ---
Fixed.


-- 

bernds at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[bernds at gcc dot gnu dot org]

--- Comment #4 from bernds at gcc dot gnu dot org  2010-08-04 21:16 ---
I'm not seeing this with my ARM cross-compilers.  Can you attach a .i file?


-- 


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

[Bug fortran/42526] bogus truncation warning for default-initialized character components

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-08-04 21:51 ---
This pr seems to have been fixed on trunk between revisions 156618 (present)
and 158215 (gone).


-- 


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

[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2010-08-04 22:15 ---
Created an attachment (id=21398)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21398&action=view)
preprocessed source for _udivmoddi4

In non-parallel builds _udivmoddi4 is always the first module to make cc1 run
out of memory.  I get the error on both i686 and x86_64 hosts, and with both
gcc-4.4.4 and gcc-4.3.5 as bootstrap compilers (only tried 4.3.5 on i686
though).

I did use --with-arch=armv5te --with-tune=xscale when configuring my compiler,
which may be relevant as it changes instruction selection defaults.


-- 


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

[Bug fortran/44065] [OOP] Undefined reference to vtab$...

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2010-08-04 22:58 ---
> r162879 seems to fix all the test cases for me. Can anyone confirm that 
> comment
> #0 works now without any linking errors?

On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have
for the PRs fixed by r162879 with both -m32 and -m64 without linking error.


-- 


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

[Bug other/24724] _Unwind_Backtrace() calls malloc

[rth at gcc dot gnu dot org]

--- Comment #13 from rth at gcc dot gnu dot org  2010-08-04 23:08 ---
There are two solutions to this:

(1) Make sure your binary provides PT_GNU_EH_FRAME.  This is the quickest
path through the unwinder, since the table is pre-sorted by the linker.

(2) Have your malloc detect the recursion and return NULL.  This will cause
the unwinder to perform a linear search through the unsorted tables.
It should not fail due to the fake out-of-memory condition, since it
was designed to handle throwing an exception during a true OOM condition.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug debug/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.

[rth at gcc dot gnu dot org]

--- Comment #11 from rth at gcc dot gnu dot org  2010-08-04 23:21 ---
This is fallout from c++/44188.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |debug


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

[Bug debug/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.

[rth at gcc dot gnu dot org]

--- Comment #12 from rth at gcc dot gnu dot org  2010-08-04 23:32 ---
Subject: Bug 45171

Author: rth
Date: Wed Aug  4 23:32:08 2010
New Revision: 162882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162882
Log:
PR debug/45171
* dwarf2out.c (gen_typedef_die): Don't re-generate the die of
an is_naming_typedef_decl.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug middle-end/45171] Invalid DWARF...DIE 0x00006a1d has multiple AT_byte_size attributes.

[rth at gcc dot gnu dot org]

--- Comment #13 from rth at gcc dot gnu dot org  2010-08-04 23:41 ---
Should be fixed, but I'll leave the bug open until you get a chance
to test the whole build against that darwin linker.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
  Component|debug   |middle-end


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

[Bug bootstrap/45174] Make fails in zlib

[dschlic1 at gmail dot com]

--- Comment #11 from dschlic1 at gmail dot com  2010-08-05 00:27 ---
Subject: Re:  Make fails in zlib

Hello;
Attached are all of the config.log files in the gcc build directory.
Please advise if you need any other files.

Thank You,
Donald Schlicht

On Wed, 2010-08-04 at 00:43 +, pinskia at gcc dot gnu dot org wrote:
> 
> --- Comment #10 from pinskia at gcc dot gnu dot org  2010-08-04 00:43 
> ---
> Can you attach all config.log files?
> 
> 


--- Comment #12 from dschlic1 at gmail dot com  2010-08-05 00:27 ---
Created an attachment (id=21399)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21399&action=view)


-- 


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

[Bug tree-optimization/45144] SRA optimization issue of bit-field

[jiez at gcc dot gnu dot org]

--- Comment #4 from jiez at gcc dot gnu dot org  2010-08-05 03:06 ---
Subject: Bug 45144

Author: jiez
Date: Thu Aug  5 03:05:35 2010
New Revision: 162897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162897
Log:
PR tree-optimization/45144
* tree-sra.c (type_consists_of_records_p): Return false
if the record contains bit-field.

testsuite/
PR tree-optimization/45144
* gcc.dg/tree-ssa/pr45144.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45144.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


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

[Bug fortran/45187] New: ICE with CRAY pointer in module depending on variable name

[billy dot baker at cox dot net]

The following generates an ICE with gfortran 4.3.5, 4.4.3, 4.4.5, and 4.5.1.
Version 4.4.3 was checked on Ubuntu 10.04. The rest were checked on 10.10.

foo_fail.f90:
module foo
   implicit none
   real :: a
   pointer(c_a, a)
end module foo

gfortran -fcray-pointer -c foo_fail.f90
f951: internal compiler error: backend decl for module variable c_a already
exists

However, if a is changed to x (or any letter which results in the variable
being alphabetically after the cray pointer name), the file compiles fine. 

foo_works.f90
module foo
   implicit none
   real :: x
   pointer(c_x, x)
end module foo

gfortran -fcray-pointer -c foo_works.f90

In both cases, a .mod is generated. If module is changed to subroutine, both
cases compile fine.


gcc -v:
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-8ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 20100728 (prerelease) (Ubuntu/Linaro 4.4.4-8ubuntu1)


-- 
   Summary: ICE with CRAY pointer in module depending on variable
name
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: billy dot baker at cox dot net


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

[Bug debug/45188] New: [4.6 regression] Failed to bootstrap on Linux/ia64

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 162896 gave:

../../src-trunk/gcc/dwarf2out.c:1195:1: error: 'initial_return_save' defined
but not used [-Werror=unused-function]
cc1: all warnings being treated as errors

It may be caused by revision 162883:

http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00094.html


-- 
   Summary: [4.6 regression] Failed to bootstrap on Linux/ia64
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug debug/45189] New: [4.6 regression] New stack alignment test failures

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 162891 gave

FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O2 -flto  execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O2 -fwhopr  execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-fastcall-1.C  -O3 -g  execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O1  execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O2  execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O2 -flto  execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O2 -fwhopr  execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O3 -fomit-frame-pointer 
execution test
FAIL: g++.dg/torture/stackalign/eh-thiscall-1.C  -O3 -g  execution test

Revision 162881 is OK.


-- 
   Summary: [4.6 regression] New stack alignment test failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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