C++ template bugs in gcc 4.6

[Ruben Safir]

I've been working with gcc 4.6 with C++ doing some templates exercises

I seem to have some unexplained behavior which might be a bug, or maybe
I'm ignorant.

First - let me give you a link for my code

http://www.nylxs.com/docs/linklist.tgz

gcc version

ruben@www2:~> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-suse-linux/4.6/lto-wrapper
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib
--with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.6
--enable-linux-futex --without-system-libunwind
--with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic
--build=i586-suse-linux
Thread model: posix
gcc version 4.6.0 20110415 [gcc-4_6-branch revision 172496] (SUSE Linux) 




specifically, I wrote a program to test my templates that create a
linked list class. There is a simple library to do some statistics on the list
members. It is doing a double delete core dump in a section of code that
I see no reason for a destructor call. It didn't do this for a simpler
version of the template argument call.

ddd ./test_del2
test_del2.cpp:84

79 for( i=0; i < 100; ++i){
80 std::cout << "index " << i << "---
\n";
81 tally = new chainlist::List >;
82 stats::take_tally(a[i], tally );
83 std::cout << "Creating Tally " << std::endl;
84 tallies->insert(*tally);
85 std::cout << "inserted population figures for index " << i <<
"---\n";
86 delete tally;
87
88 //visual inspection of population data to make sure the resiults work
89 // std::cout << "visual inspection of population data to make sure
the results work" << std::endl;

breaking on line 84 and the stepping through

263 void List::insert ( T val )
264 {
265 if(!front()){
266 Node * tmp = new Node(val);
267 front(tmp);
268 endd(tmp);
269 cursor(tmp);
270 sizeup();
271 return;
272 }else{
273 Node * tmp = new Node(val, endd());
274 // endd()->next(tmp); // redundant
275 endd(tmp);
276 cursor(tmp);
277 sizeup();
278 return;
279 }
280 } /* --- end of method List::insert 

/home/ruben/cplus/link_list_template_mysql/linklist.h:265
is the next line

on line 266 is where it seems to be doing weird stuff

home/ruben/cplus/link_list_template_mysql/linklist.h:266

it calls the correct constructor for the node object
/home/ruben/cplus/link_list_template_mysql/linklist.h:82
81 Node::Node(unk val, Node *item_to_link_to){
82 value(val);
83 if(!item_to_link_to){
84 next_ = 0;
85 }
86
87 else{
88 next(item_to_link_to->next());
89 item_to_link_to->next(this);
90 }
91 }

I the calls the accessory method value() from the list class

108 }
109
110 template
111 void Node::value(unk val){
112 value_ = new unk(val);
113 }
114
/home/ruben/cplus/link_list_template_mysql/linklist.h:112

it returns nomally

81 Node::Node(unk val, Node *item_to_link_to){
82 value(val);
83 if(!item_to_link_to){
84 next_ = 0;
85 }
86
87 else{
88 next(item_to_link_to->next());
89 item_to_link_to->next(this);
90 }
91 }
92 chainlist::Node > >::Node
(this=0x809f488, val=..., item_to_link_to=0x0) at
/home/ruben/cplus/link_list_template_mysql/linklist.h:83


then it calls for the List destructor, I have no idea way

373 template
374 List::~List(){
375 remove_all();
376 // std::cout << "Deleted All*" << __LINE__ << std::endl;
377 }
378
(gdb) ptype List
Type chainlist::List > has no component named
List.
(gdb) *** glibc detected ***
/home/ruben/cplus/link_list_template_mysql/test_del2: double free or
corruption (out): 0x0809f460 ***
=== Backtrace: =
/lib/libc.so.6[0xb7d9150b]
/lib/libc.so.6[0xb7d92de4]
/lib/libc.so.6(cfree+0x6d)[0xb7d95fdd]
/usr/lib/libstdc++.so.6(_ZdlPv+0x1f)[0xb7f7c87f]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804b4a4]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804b2c6]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804aa30]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x804987d]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x80498f0]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x8048d42]
/lib/libc.so.6(__libc_start_main+0xfe)[0xb7d3aace]
/home/ruben/cplus/link_list_template_mysql/test_del2[0x8048961]
=== Memory map: 
08048000-0804d000 r-xp  08:12 270203586
/home/ruben/cplus/link_list_template_mysql/test_del2
0804d000-0804e000 r--p 4000 08:12 270203586
/home/ruben/cplus/link_list_template_mysql/test_del2
0804e000-0804f000 rw-p 5000 08:12 270203586
/home/ruben/cplus/link_list_template_mysql/te

[Bug c++/48780] [C++0x] scoped enumerations and va_arg (default argument promotions)

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-05-22 
00:28:47 UTC ---
Author: jason
Date: Sun May 22 00:28:44 2011
New Revision: 174022

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174022
Log:
PR c++/48780
* cvt.c (type_promotes_to): Warn about promoting scoped enums.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/enum13.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/cvt.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/48945] [C++0x] static constexpr member function cannot be defined out-of class

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-22 
00:29:06 UTC ---
Author: jason
Date: Sun May 22 00:29:03 2011
New Revision: 174023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174023
Log:
PR c++/48945
* decl.c (revert_static_member_fn): Ignore const on constexpr fn.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-static7.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c/49096] internal compiler error: in calc_dfs_tree, at dominance.c:394

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #3 from Steven Bosscher  2011-05-21 
23:49:13 UTC ---
If you wrote the plugin then you are the author.

It's impossible to tell what's going wrong here, because obviously the problem
is caused by the plugin. You are on your own to debug this, or if you publish
your plugin and it does something interesting then perhaps someone else is
willing and able to help.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[xinliangli at gmail dot com]

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

--- Comment #7 from davidxl  2011-05-22 00:01:13 
UTC ---
(In reply to comment #6)
> Created attachment 24323 [details]
> fix

Please verify.

Davdi

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  
2011-05-21 23:32:58 UTC ---
The patch in comment #11 fixes the runtime for the tests in comments #0 and #9.
However the other tests give a backtrace on x86_64-apple-darwin10. and valgrind
reports errors of the kind

==27268== Invalid read of size 8
==27268==at 0x10D48: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268==  Address 0x100442470 is 0 bytes inside a block of size 96 free'd
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10D34: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268== 
==27268== Invalid write of size 8
==27268==at 0x10D69: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268==  Address 0x100442470 is 0 bytes inside a block of size 96 free'd
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10D34: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268== 
==27268== Invalid read of size 8
==27268==at 0x10D77: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268==  Address 0x1004424a0 is 48 bytes inside a block of size 96 free'd
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10D34: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268== 
==27268== Invalid write of size 8
==27268==at 0x10D9A: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268==  Address 0x1004424a0 is 48 bytes inside a block of size 96 free'd
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10D34: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268== 
==27268== Invalid free() / delete / delete[]
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10DB0: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)
==27268==  Address 0x100442470 is 0 bytes inside a block of size 96 free'd
==27268==at 0x10001146F: free (vg_replace_malloc.c:366)
==27268==by 0x10D34: MAIN__ (pr48699_1.f90:16)
==27268==by 0x10DE8: main (pr48699_1.f90:16)

for the test in comment #4.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[xinliangli at gmail dot com]

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

--- Comment #6 from davidxl  2011-05-21 23:30:34 
UTC ---
Created attachment 24323
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24323
fix

[Bug c++/49105] New: [C++0x][SFINAE] ICE during list-initialization of rvalue-references to const

[daniel.kruegler at googlemail dot com]

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

   Summary: [C++0x][SFINAE] ICE during list-initialization of
rvalue-references to const
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com


gcc 4.7.0 20110514 (experimental) in C++0x mode produces an internal compiler
error when compiling this code at the line marked with #:

//
template
char f(int);

template
auto f(...) -> char(&)[2];

static_assert(sizeof(f(0)) == 1, "Error"); // #
//

"internal compiler error: in cp_build_c_cast, at cp/typeck.c:6442|"

The code should be accepted.

Further tests provided evidence that we need an value-initialization of an
rvalue reference to const T to reproduce the ICE, even though the sole
initialization written as 

const int&& rri{};

does not cause the same kind of problem. This is odd, because the functional
cast T{} has exactly the same semantics as the corresponding
direct-list-initialization.

Additionally, the same error occurs, when the list has one element, e.g. the
expression T{0} results in the same kind of error.

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-05-21 
23:11:01 UTC ---
Reverting revision 169083 on trunk fixes this pr (see
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01442.html for its motivation).
Further reduced test:

!--
module dg_grid

implicit none

integer :: par_world_dims = 3

type world_t
   integer :: dims
   real(kind=8), dimension(:), pointer :: lengths
end type

contains

subroutine grid_new(grid)
   type(world_t), intent(inout) :: grid

   grid%dims = par_world_dims
   call grid_faces(grid)

end subroutine

! Start looking here: This is the routine that gives trouble.
subroutine grid_faces(grid)
   type(world_t), intent(inout) :: grid

   integer :: dimi, bordi
   integer, dimension(par_world_dims-1) :: fgrades
   integer, dimension(par_world_dims-1) :: fbasegrades

   do dimi=1,grid%dims-2

  ! The bug makes those two arrays exchange values temporarily.
  fbasegrades = (/ 1, 1 /)
  fgrades = (/ 2, 2 /)
  do bordi=1,2
 write(*,*) 'Here is the bug. The grades should be (2 2):', fgrades
 write(*,*) 'Compare the base grades:', fbasegrades
  end do
  write(*,*) 'grades again', fgrades

   end do
end subroutine

end module

program test_gcc46gridbug

use dg_grid

implicit none

type(world_t) :: grid

call grid_new(grid)

end program
!--

[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  2011-05-21 
22:47:34 UTC ---
This PR seems similar to PR rtl-optimization/40710.

It seems opposite_needed is incorrectly calculated after the
first delay slot iteration in fill_slots_from_thread:

mark_target_live_regs (get_insns (), opposite_thread, &opposite_needed);

Breakpoint 22, fill_slots_from_thread (insn=0x1b98f30, condition=0x1b99fa0,
thread=0x1b981e0, opposite_thread=0x1b98f90, likely=0, thread_if_true=1,
own_thread=0, slots_to_fill=1, pslots_filled=0xbfffee4c, delay_list=0x0) at
../../gcc/gcc/reorg.c:2600
2600  new_thread = thread = try_split (PATTERN (thread), thread, 0);
(gdb) p/x opposite_needed
$69 = {
  memory = 0x1, 
  unch_memory = 0x0, 
  volatil = 0x0, 
  cc = 0x0, 
  regs = {0x44e8, 0x0, 0x0}
}

Register %r4 is no longer marked as alive, so

(gdb) p debug_rtx (thread)
(insn 107 106 438 ../../gcc/gcc/tree-cfgcleanup.c:695 (set (reg/v:SI 4 %r4
[orig:111 i ] [111])
(plus:SI (reg/v:SI 4 %r4 [orig:111 i ] [111])
(const_int 1 [0x1]))) 111 {addsi3} (nil))

is moved from the branch target.

[Bug c++/48780] [C++0x] scoped enumerations and va_arg (default argument promotions)

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-05-21 
22:01:32 UTC ---
Author: jason
Date: Sat May 21 22:01:29 2011
New Revision: 174005

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174005
Log:
PR c++/48780
* cvt.c (type_promotes_to): Don't promote scoped enums.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum12.C
trunk/gcc/testsuite/g++.dg/cpp0x/enum13.C
Modified:
trunk/gcc/common.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/48945] [C++0x] static constexpr member function cannot be defined out-of class

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-05-21 
22:01:48 UTC ---
Author: jason
Date: Sat May 21 22:01:45 2011
New Revision: 174007

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174007
Log:
PR c++/48945
* decl.c (grokdeclarator): Don't add set const function-cv-qual
for constexpr fns to memfn_quals, just add it to the type.
(revert_static_member_fn): Don't complain about quals.
(check_static_quals): New.
(grokfndecl): Call it.
(start_preparsed_function): Don't call revert_static_member_fn.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-static7.C

[Bug c++/48945] [C++0x] static constexpr member function cannot be defined out-of class

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-05-21 
22:01:40 UTC ---
Author: jason
Date: Sat May 21 22:01:38 2011
New Revision: 174006

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174006
Log:
PR c++/48945
* decl.c (revert_static_member_fn): Ignore const on constexpr fn.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-static7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49066] [C++0x] Non-defining declaration of deleted function suppresses usage validation

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-05-21 
21:35:53 UTC ---
Author: jason
Date: Sat May 21 21:35:50 2011
New Revision: 174003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174003
Log:
PR c++/49066
* decl.c (duplicate_decls): Preserve DECL_DELETED_FN.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/defaulted26.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-05-21 
21:21:09 UTC ---
Created attachment 24322
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24322
reduced test

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|local variables exchange|[4.6/4.7 Regression] local
   |values / wrong code with|variables exchange values /
   |-O3 |wrong code with -O3

--- Comment #2 from Dominique d'Humieres  2011-05-21 
21:19:47 UTC ---
This pr is due to revision 169083.

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

[torva...@linux-foundation.org]

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

--- Comment #3 from Linus Torvalds  2011-05-21 
20:42:26 UTC ---
Hmm. Looking at that code generation, it strikes me that even with the odd load
store situation, why do we have that "test" instruction?

   c:8b 10mov(%eax),%edx
   e:83 ea 01 sub$0x1,%edx
  11:85 d2test   %edx,%edx
  13:89 10mov%edx,(%eax)
  15:74 09je 20 

iow, regardless of any complexities of the store, that "sub + test" is just
odd. Gcc knows to simplify that particular sequence in other situations, why
doesn't it simplify it here?

IOW, I can make gcc generate code like

   c:83 e8 01 sub$0x1,%eax
   f:75 07jne18 

with no real problem when it's in registers. No "test" instruction after the
sub. Why does that store matter so much?

It looks like the combine is bring driven by the conditional branch, and then
when the previous instruction from the conditional branch is that store,
everything kind of goes to hell.

Would it be possible to have a peephole for the "arithmetic/logical +
compare-with-zero" case (causing us to just drop the compare), and then have a
separate peephole optimization that triggers the "load + op + store with dead
reg" and turns that into a "op to mem" case?

The MD files do make me confused, so maybe there is some fundamental limitation
to the peephole patterns that makes this impossible?

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org 2011-05-21 20:09:07 UTC ---
(In reply to comment #9)
> program testmv1
> 
>   type bar
>   end type
> 
>   type, extends(bar) ::  bar2
>   end type
> 
>   class(bar), allocatable :: sm
>   type(bar2), allocatable :: sm2
> 
>   allocate(sm2)
>   call move_alloc(sm2,sm)
> 
> end program
> 
> 
> /tmp/ccSfRlZ5.o:(.data+0x38): undefined reference to 
> `__copy_testmv1_Bar2.1582'

The problem here simply is that the vtab is constructed too late (only at
translation stage), so that the __copy routine is never generated. The
following obvious patch fixes it:

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c(Revision 174000)
+++ gcc/fortran/check.c(Arbeitskopie)
@@ -2588,6 +2588,10 @@ gfc_check_move_alloc (gfc_expr *from, gfc_expr *to
   return FAILURE;
 }

+  /* Make sure the vtab is present.  */
+  if (to->ts.type == BT_CLASS)
+gfc_find_derived_vtab (from->ts.u.derived);
+
   return SUCCESS;
 }

[Bug c++/49102] [C++0x] Use of deleted copy constructor not diagnosed

[schaub.johannes at googlemail dot com]

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

--- Comment #1 from Johannes Schaub  
2011-05-21 20:04:16 UTC ---
(In reply to comment #0)
> The following program should be diagnosed at the call to "f" for using a
> deleted copy constructor in an lvalue to rvalue conversion
> 

I'm sorry. I meant: "for using a inaccessible copy constructor", of course.

[Bug ada/49097] gnatbind link fails to find version_string, potential ranlib concurrency problem

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from Joseph S. Myers  2011-05-21 
19:47:09 UTC ---
Fixed.

[Bug ada/49097] gnatbind link fails to find version_string, potential ranlib concurrency problem

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  2011-05-21 
19:45:31 UTC ---
Author: jsm28
Date: Sat May 21 19:45:27 2011
New Revision: 174002

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174002
Log:
PR ada/49097
* gcc-interface/Make-lang.in (gnatbind$(exeext)): Depend on
$(LIBDEPS).

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Make-lang.in

[Bug fortran/48699] [4.6/4.7 Regression] [OOP] MOVE_ALLOC inside SELECT TYPE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] MOVE_ALLOC inside |[4.6/4.7 Regression] [OOP]
   |SELECT TYPE |MOVE_ALLOC inside SELECT
   ||TYPE

--- Comment #10 from janus at gcc dot gnu.org 2011-05-21 19:37:16 UTC ---
(In reply to comment #9)
> program testmv1
> 
>   type bar
>   end type
> 
>   type, extends(bar) ::  bar2
>   end type
> 
>   class(bar), allocatable :: sm
>   type(bar2), allocatable :: sm2
> 
>   allocate(sm2)
>   call move_alloc(sm2,sm)
> 
> end program
> 
> 
> /tmp/ccSfRlZ5.o:(.data+0x38): undefined reference to 
> `__copy_testmv1_Bar2.1582'


Btw, this one works with 4.5, but fails with 4.6 and 4.7, which makes it a
regresssion.

[Bug fortran/48699] [OOP] MOVE_ALLOC inside SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-05-21 19:33:32 UTC ---
r174001 fixes the test cases in comment #1 and #4.

The test case in comment #0 still fails. Reduced version:


program testmv1

  type bar
  end type

  type, extends(bar) ::  bar2
  end type

  class(bar), allocatable :: sm
  type(bar2), allocatable :: sm2

  allocate(sm2)
  call move_alloc(sm2,sm)

end program


/tmp/ccSfRlZ5.o:(.data+0x38): undefined reference to `__copy_testmv1_Bar2.1582'

[Bug ada/49097] gnatbind link fails to find version_string, potential ranlib concurrency problem

[amylaar at gcc dot gnu.org]

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

--- Comment #2 from Jorn Wolfgang Rennecke  
2011-05-21 19:23:15 UTC ---
(In reply to comment #1)
> Created attachment 24317 [details]
> untested patch

Looking at the patch, I agree that it should fix the problem.

> Please see if this patch (untested) fixes the problem for you.

I have tested the patch, and no such link problems with gnatbind were evident.
However, that doesn't really mean much.  I also ran a test yesterday for
mainline + patch for PR46500, and the problem was not evident.
These things are fickle as they depend on load.
We can get a bit more detail when we look at near misses.  I.e. if the
dependency is known to make, it should try to arrange the build so that
some commands can be run between the ranlib and the link that uses the
affected library, and conversely it should cease to prefer to run the link
in preference to other commands with equal dependencies.

Looking for instances where the ranlib use on libcommon.a appears later than
ten lines before the gnatbind link in the logfile, we find for yesterday's
mainline build:
 distance -2 (i.e. the link was launched before ranlib, but the link succeeded,
  presumably because the link finished reading the library before ranlib
  altered it): i686-solaris2.9
 distance 1 (i.e. gnatbind link follows immediately after ranlib on
  libcommon.a): arm-elf, avr-elf, bfin-linux-uclibc, frv-linux, hppa64-hpux11.0
--enable-sjlj-exceptions=yes, hppa64-hpux11.3, mipsisa32r2-linux-gnu,
mn10300-elf, powerpcle-eabi, sh-rtems, vax-linux-gnu, x86_64-freebsd6,
x86_64-mingw32 --enable-sjlj-exceptions=yes, x86_64-pc-linux-gnu
--with-fpmath=avx, x86_64-w64-mingw32, xtensa-linux
 distance 3: powerpcle-eabisim
 distance 7: x86_64-netbsd, xstormy16-elf
 distance 8: i686-cygwin --enable-threads=yes, pdp11-aout
 distance 9: ia64-elf, ia64-hp-vms, mips-wrs-vxworks

For yesterdays's build of mainline + patch for 46500:
 distance 1: avr-rtems, crisv32-linux, i686-mingw32crt, ia64-hpux,
powerpc-darwin7, powerpcle-eabi, powerpc-linux_paired, rs6000-ibm-aix4.3,
rs6000-ibm-aix5.1.0, sparc-sun-solaris2.9, x86_64-freebsd6, x86_64-mingw32
--enable-sjlj-exceptions=yes
 distance 2: x86_64-pc-linux-gnu --with-fpmath=avx
 distance 8: i686-cygwin --enable-threads=yes
 distance 9: mep-elf

For yesterday's mainline + your patch:
 distance 4: x86_64-apple-darwin, x86_64-netbsd
 distance 5: i686-solaris2.9, powerpcle-elf, x86_64-w64-mingw32
 distance 8: x86_64-elf --with-fpmath=sse
 distance 9: alpha64-dec-vms, alpha-freebsd6, alpha-netbsd, rs6000-ibm-aix4.3,
spu-elf

For the above distance 4 cases we find gcov and gcov-dump as being built
between the ranlib and link (the gcov-dump rule has a backslash so it counts
as two lines).

For i686-solaris2.9 / x86_64-w64-mingw32, it also dovetails the libbackend.a
ranlib run there, while for powerpcle-elf, it builds gnat1 before gnatbind.
Overall, I think we have evidence that the dependency has an effect on the
build order.

>  If so I'll
> commit it as obvious.  This missing dependency was pre-existing, but maybe it
> didn't matter before.

Agreed.  The other used libraries tend to be built much sooner.

[Bug fortran/48699] [OOP] MOVE_ALLOC inside SELECT TYPE

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org 2011-05-21 19:12:56 UTC ---
Author: janus
Date: Sat May 21 19:12:51 2011
New Revision: 174001

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174001
Log:
2011-05-21  Janus Weil  

PR fortran/48699
* match.c (select_type_set_tmp): Make the temporary ALLOCATABLE if the
selector is ALLOCATABLE.

2011-05-21  Janus Weil  

PR fortran/48699
* gfortran.dg/select_type_23.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/select_type_23.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  2011-05-21 
19:05:36 UTC ---
> On x86_linux, I can not reproduce the problem:

Try to increase your ulimit settings.

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

[torva...@linux-foundation.org]

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

--- Comment #2 from Linus Torvalds  2011-05-21 
18:41:15 UTC ---
(In reply to comment #1)
>
> On the RTL side combine tries to do
> 
> Trying 7, 8 -> 9:
> Failed to match this instruction:
> (parallel [
> (set (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8 A64])
> (plus:DI (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8
> A64])
> (const_int -1 [0x])))
> (set (reg/f:DI 60 [ D.2723 ])
> (plus:DI (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8
> A64])
> (const_int -1 [0x])))
> ])
> 
> because we have a use of the decrement result in the comparison.  It doesn't
> try to combine this with the comparison though.

Why isn't there a trivial pattern for the combination of "add+cmp0"? It sounds
like a peephole optimization to me.

> So this case is really special ;)  Without the use of the decremented
> value we get the desired subq $1, (%rsi).

The whole notion of "decrement and check if zero" is just about as special as
mud. 

And I realize that without the "check if zero" part I get the single rmw
instruction, but I was really hoping that gcc would get this kind of really
obvious code right. There is absolutely no question about what the correct
result is, and gcc simply doesn't generate it.

I'm used to gcc sometimes being confused by more complicated things (inline
asms, bitfields etc), but this is really basic code.

The load-store model is fine for a Pentium 4 - those things were not very good
at complex instructions. But it generates horribly big code, and modern x86
chips all want the "operate on memory" version.

> Manually sinking the store to *argv into the if and the else yields

Yeah. And that's pretty horrible. 

> As usual combine doesn't like stores.

Is there some reason this can't just be a peephole pattern?

I really thought that gcc has done this before. 

   Linus

[Bug fortran/49103] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.21 18:08:15
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-05-21 
18:08:15 UTC ---
Confirmed on x86_64-apple-darwin10. Revision 169049 is OK, revision 169161 is
bugged.

[Bug inline-asm/48637] %c in ARM inline asm leads to ICE (in arm_print_operand)

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.21 18:14:27
 CC||rearnsha at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Richard Earnshaw  2011-05-21 
18:14:27 UTC ---
Confirmed.  The back-end doesn't currently know how to handle symbol+offset in
%c.

[Bug c++/49092] [4.7 Regression] ice in tree_add_const_value_attribute

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.21 17:30:49
 CC||jason at redhat dot com
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-21 17:30:49 
UTC ---
It is caused by revision 173582:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00360.html

[Bug bootstrap/49104] New: bootstrap failure on AMD K6-2 with illegal instruction (cmove) in stage2

[rfo at gmx dot de]

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

   Summary: bootstrap failure on AMD K6-2 with illegal instruction
(cmove) in stage2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gmx.de


I get the error in 4.6.0 and 4.6-20110520. 4.5.3 is fine.

$ ../gcc-4.6-20110520/configure --prefix=/usr/pkg/gcc-4.6 \
--enable-languages=c --disable-nls --disable-multilib --disable-lto \
--enable-checking=release --with-system-zlib

$ make bootstrap
...
Configuring stage 2 in i586-pc-linux-gnu/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... i586-pc-linux-gnu
checking host system type... i586-pc-linux-gnu
checking for i586-pc-linux-gnu-ar... ar
checking for i586-pc-linux-gnu-lipo... lipo
checking for i586-pc-linux-gnu-nm... /home/rf11/src/build1/./gcc/nm
checking for i586-pc-linux-gnu-ranlib... ranlib
checking for i586-pc-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for i586-pc-linux-gnu-gcc... /home/rf11/src/build1/./gcc/xgcc
-B/home/rf11/src/build1/./gcc/ -B/usr/pkg/gcc-4.6/i586-pc-linux-gnu/bin/
-B/usr/pkg/gcc-4.6/i586-pc-linux-gnu/lib/ -isystem
/usr/pkg/gcc-4.6/i586-pc-linux-gnu/include -isystem
/usr/pkg/gcc-4.6/i586-pc-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/home/rf11/src/build1/i586-pc-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage2-target-libgcc] Error 1
make[2]: Leaving directory `/home/rf11/src/build1'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/rf11/src/build1'
make: *** [bootstrap] Error 2

from ./i586-pc-linux-gnu/libgcc/config.log:
configure:3268: /home/rf11/src/build1/./gcc/xgcc -B/home/rf11/src/build1/./gcc/
-B/usr/pkg/gcc-4.6/i586-pc-linux-gnu/bin/
-B/usr/pkg/gcc-4.6/i586-pc-linux-gnu/lib/ -isystem
/usr/pkg/gcc-4.6/i586-pc-linux-gnu/include -isystem
/usr/pkg/gcc-4.6/i586-pc-linux-gnu/sys-include-c -g -O2  conftest.c >&5
xgcc: internal compiler error: Illegal instruction (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3272: $? = 4
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3286: error: in `/home/rf11/src/build1/i586-pc-linux-gnu/libgcc':
configure:3289: error: cannot compute suffix of object files: cannot compile


The illegal insn is at the end of init_vectorized_lexer() in cc1:

Program received signal SIGILL, Illegal instruction.
0x086f977c in init_vectorized_lexer ()
(gdb) disas init_vectorized_lexer
...
0x086f9745 : cpuid
0x086f9747 : test   %eax,%eax
0x086f9749 : je 0x86f96fa

0x086f974b : mov$0x1,%eax
0x086f9750 : mov$0x86f65b0,%esi
0x086f9755 : cpuid  
0x086f9757 : and$0x10,%ecx
0x086f975d : jne0x86f973a

0x086f975f : mov$0x86f6530,%esi
0x086f9764 : test   $0x400,%edx
0x086f976a : jne0x86f973a

0x086f976c : mov$0x86f64c0,%esi
0x086f9771 : mov$0x86f6060,%eax
0x086f9776 : and$0x200,%edx
0x086f977c : cmove  %eax,%esi
0x086f977f : jmp0x86f973a


$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
cpu MHz : 400.922
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr
bogomips: 801.84
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual


  Reinhard

[Bug fortran/49103] New: local variables exchange values / wrong code with -O3

[thomas.orgis at awi dot de]

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

   Summary: local variables exchange values / wrong code with -O3
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thomas.or...@awi.de
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


Created attachment 24321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24321
test program exposing the bug

After upgrading to gfortran 4.6.0, I noticed crashes in my codebase. This seems
to boil down to some local messup of variable values. I observe this with -O3,
but not with -O2 plus all available flags that are included in -O3. So, this
must be one of the internal optimizations that are not accessible via
individual flags.

The example is ripped out of a larger codebase and it shows. I spent over a
whole day diagnosing and trimming down already. Hopefully, you will mainly have
to look at the lower 100 lines. The routine grid_faces is the point of
interest, with a call to base_new triggering the issue.

The bad example:

shell$ gfortran -O3 gcc46gridbug.f90
shell$ ./a.out 
 LOG: Coordinate mapping:   1   2   3
 LOG:   back mapping:   1   2   3
 LOG: Base point:   0.0.   
0. 
 generating base functions
 grid: faces
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   1   1
 Compare the base grades:   1   1
 grades again   2   2
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   1   1
 Compare the base grades:   1   1
 grades again   2   2
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   1   1
 Compare the base grades:   1   1
 grades again   2   2
 grid finished
 PASS


And the good example:

shell$ gfortran -O2 gcc46gridbug.f90 
shell$ ./a.out 
 LOG: Coordinate mapping:   1   2   3
 LOG:   back mapping:   1   2   3
 LOG: Base point:   0.0.   
0. 
 generating base functions
 grid: faces
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 grades again   2   2
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 grades again   2   2
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 Here is the bug. The grades should be (2 2):   2   2
 Compare the base grades:   1   1
 grades again   2   2
 grid finished
 PASS

The code worked with gcc 4.3.3 and 4.5.1, as well as the intel compiler 11.1. I
hesitate to count in open64 and the sun/oracle compilers as, while they might
not show this bug, they have enough others that stopped me from using them:-/

If this still should be an error on my side, I'd appreciate to be enlightened.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[xinliangli at gmail dot com]

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

davidxl  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #4 from davidxl  2011-05-21 17:13:22 
UTC ---
(In reply to comment #3)
> To reproduce on Linux, in the build dir:
> 
>   cp gcc/ada/rts/system.ads .
>   chmod a+w system.ads
>   edit system.ads and change ZCX_By_Default to False
>   gcc/gnat1 gcc/ada/rts/g-catiio.adb -Igcc/ada/rts -Wall -O
> 
> This breaks the compiler on all SJLJ platforms, e.g. arm-linux.


On x86_linux, I can not reproduce the problem:

Using the test case, got the following:

GNAT.CALENDAR.TIME_IO.AM_PM GNAT.CALENDAR.TIME_IO.HOUR_12
GNAT.CALENDAR.TIME_IO.IMAGE GNAT.CALENDAR.TIME_IO.IMAGE
GNAT.CALENDAR.TIME_IO.IMAGE GNAT.CALENDAR.TIME_IO.IMAGE.PAD_CHAR
GNAT.CALENDAR.TIME_IO.IMAGE GNAT.CALENDAR.TIME_IO.IMAGE
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B96B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B107B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B118B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B129B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B140B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B151B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B162B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B173B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B184B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B195B
GNAT.CALENDAR.TIME_IO.IMAGE.B_2.B224B GNAT.CALENDAR.TIME_IO.IMAGE.B_2.B239B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B250B GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B282B
GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B295B GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B308B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B319B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B342B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B359B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B376B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B392B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B408B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B420B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B432B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B444B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B455B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B478B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B489B
GNAT.CALENDAR.TIME_IO.IMAGE.B_4.B500B GNAT.CALENDAR.TIME_IO.IMAGE.B_5.B511B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B522B GNAT.CALENDAR.TIME_IO.IMAGE.B_6.B534B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B545B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B558B
GNAT.CALENDAR.TIME_IO.MONTH_NAME_TO_NUMBER GNAT.CALENDAR.TIME_IO.VALUE
GNAT.CALENDAR.TIME_IO.VALUE.EXTRACT_DATE
GNAT.CALENDAR.TIME_IO.VALUE.EXTRACT_TIME GNAT.CALENDAR.TIME_IO.PUT_TIME
GNAT.CALENDAR.TIME_IO.PUT_TIME GNAT.CALENDAR.TIME_IO
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
   Assembling functions:
 GNAT.CALENDAR.TIME_IO.PUT_TIME GNAT.CALENDAR.TIME_IO.HOUR_12
GNAT.CALENDAR.TIME_IO.MONTH_NAME_TO_NUMBER
GNAT.CALENDAR.TIME_IO.VALUE.EXTRACT_TIME GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B96B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B107B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B118B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B129B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B140B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B151B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B162B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B173B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B184B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B195B GNAT.CALENDAR.TIME_IO.IMAGE.B_2.B224B
GNAT.CALENDAR.TIME_IO.IMAGE.B_2.B239B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B250B
GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B282B GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B295B
GNAT.CALENDAR.TIME_IO.IMAGE.B_3.B308B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B319B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B342B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B359B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B376B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B392B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B408B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B420B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B432B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B444B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B455B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B478B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B489B GNAT.CALENDAR.TIME_IO.IMAGE.B_4.B500B
GNAT.CALENDAR.TIME_IO.IMAGE.B_5.B511B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B522B
GNAT.CALENDAR.TIME_IO.IMAGE.B_6.B534B GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B545B
GNAT.CALENDAR.TIME_IO.IMAGE.L_1.B558B GNAT.CALENDAR.TIME_IO.IMAGE
GNAT.CALENDAR.TIME_IO.AM_PM GNAT.CALENDAR.TIME_IO.IMAGE
GNAT.CALENDAR.TIME_IO.IMAGE GNAT.CALENDAR.TIME_IO.IMAGE
GNAT.CALENDAR.TIME_IO.IMAGE
raised STORAGE_ERROR : stack overflow (or erroneous memory access)

[Bug c++/49102] New: Use of deleted copy constructor not diagnosed

[schaub.johannes at googlemail dot com]

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

   Summary: Use of deleted copy constructor not diagnosed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com


The following program should be diagnosed at the call to "f" for using a
deleted copy constructor in an lvalue to rvalue conversion

struct A { 
  A() = default; 

private: 
  A(A const&) = default;
}; 

void f(...) { } 
int main() { 
  A a; 
  f(a); 
}

GCC compiles and links this code without complaining.

[Bug fortran/48955] [4.6/4.7 Regression] Wrong result for array assignment due to missing temporary

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  2011-05-21 
15:12:47 UTC ---
Created attachment 24320
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24320
Tentative patch

Paul,

what do you think of this approach?  It fixes the test case, and
passes regression-testing.

[Bug target/49098] unused parameters in rx.c:rx_memory_move_cost

[nickc at gcc dot gnu.org]

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

--- Comment #1 from Nick Clifton  2011-05-21 16:35:41 
UTC ---
Author: nickc
Date: Sat May 21 16:35:38 2011
New Revision: 173999

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173999
Log:
PR target/49098
* config/rx/rx.c (rx_memory_move_cost): Note unused parameters.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rx/rx.c

[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from H.J. Lu  2011-05-21 14:44:23 
UTC ---
It is caused by revision 166244:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00130.html

[Bug rtl-optimization/49007] ICE in extract_true_false_edges_from_block at tree-cfg.c:7379

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-05-21 14:57:02 UTC ---
> Could this have been fixed by PR 42775 which does not change reorg but rather
> free_cfg?

No.  I have tried it on hppa2.0w-hp-hpux11.11 and just tried it with
darwin cross.  Eric had mentioned it when I backported the fix for PR
45593.

I'm not sure why the ldo instruction at the branch target isn't deleted
when it is added to the delay slot.

Dave

[Bug target/41894] wrong code with -fno-split-wide-types

[ilya.lesokhin at gmail dot com]

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

--- Comment #12 from Ilya Lesokhin  2011-05-21 
14:47:33 UTC ---
Created attachment 24319
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24319
simple test case

i belive this is the same bug.

the problem occurs when using r28,r29 and accesing one of them.

as can be seen badCode() doesnt put the value 5 in tester. while goodCode does.


void badCode()
{
  a4:ef 92   pushr14
  a6:ff 92   pushr15
  a8:cf 93   pushr28
  aa:df 93   pushr29
} t;

t.deletedbyte = 5;
asm ("": "+y" (t) :);

t.otherbyte = 17;
  ac:81 e1   ldir24, 0x11; 17
  ae:ec 01   movwr28, r24

asm ("": "+y" (t) :);

tester = t.deletedbyte;
  b0:7e 01   movwr14, r28
  b2:f0 92 00 01 sts0x0100, r15
}
  b6:df 91   popr29
  b8:cf 91   popr28
  ba:ff 90   popr15
  bc:ef 90   popr14
  be:08 95   ret

00c0 :

void goodCode()
{
  c0:a0 e0   ldir26, 0x00; 0
  c2:b5 e0   ldir27, 0x05; 5
} t;

t.deletedbyte = 5;
asm ("": "+x" (t) :);

t.otherbyte = 17;
  c4:a1 e1   ldir26, 0x11; 17

asm ("": "+x" (t) :);

tester = t.deletedbyte;
  c6:b0 93 00 01 sts0x0100, r27
}
  ca:08 95   ret

[Bug target/48529] [x32] Testsuite failures

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-05-21 13:57:01 
UTC ---
Objective C failures:

FAIL: objc.dg/torture/forward-1.m  -O0  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O1  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O2  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O2 -flto  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O2 -flto -flto-partition=none 
-fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O3 -fomit-frame-pointer  -fgnu-runtime
execution test
FAIL: objc.dg/torture/forward-1.m  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O3 -fomit-frame-pointer -funroll-loops 
-fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -O3 -g  -fgnu-runtime execution test
FAIL: objc.dg/torture/forward-1.m  -Os  -fgnu-runtime execution test

[Bug target/49101] New: [x32] Extra instruction in compare

[hjl.tools at gmail dot com]

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

   Summary: [x32] Extra instruction in compare
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


[hjl@gnu-6 ilp32-41]$ cat foo.c
extern void abort (void);
typedef __SIZE_TYPE__ size_t;
extern size_t strcspn (const char *, const char *);
extern char *strcpy (char *, const char *);

int
main (void)
{
  char *s1 = "hello world";
  char dst[64], *d2;

  strcpy (dst, s1);
  d2 = dst;
  if (strcspn (++d2+5, "") != 5)
abort();

  return 0;
}
[hjl@gnu-6 ilp32-41]$ make foo.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -S -o foo.s -mx32 -O 
 foo.c
[hjl@gnu-6 ilp32-41]$ cat foo.s
.file"foo.c"
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
subq$72, %rsp
.cfi_def_cfa_offset 80
movl$1819043176, (%rsp)
movl$1870078063, 4(%rsp)
movl$6581362, 8(%rsp)
leaq6(%rsp), %rdi
movl$0, %eax
movq$-1, %rcx
repnz scasb
notq%rcx
cmpl$6, %ecx
je.L2
callabort
.L2:
movl$0, %eax
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
    .ident"GCC: (GNU) 4.7.0 20110521 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 ilp32-41]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o 64.s -O foo.c
[hjl@gnu-6 ilp32-41]$ diff -up 64.s foo.s
--- 64.s2011-05-21 06:16:11.260010306 -0700
+++ foo.s2011-05-21 06:15:38.076996129 -0700
@@ -14,7 +14,8 @@ main:
 movl$0, %eax
 movq$-1, %rcx
 repnz scasb
-cmpq$-7, %rcx
+notq%rcx
+cmpl$6, %ecx
 je.L2
 callabort
 .L2:
[hjl@gnu-6 ilp32-41]$ 

X32 generates

notq%rcx
cmpl$6, %ecx

instead of

cmpq$-7, %rcx

[Bug rtl-optimization/49088] Combine fails to properly handle zero-extension and signed int constant

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #24315|0   |1
is obsolete||

--- Comment #9 from H.J. Lu  2011-05-21 13:25:10 
UTC ---
Created attachment 24318
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24318
A new patch

For binary operations, if X is narrower than MODE and we want all
the bits in X's mode, just use the operand when it is CONST_INT.

[Bug c/49096] internal compiler error: in calc_dfs_tree, at dominance.c:394

[engrwahidmemon at gmail dot com]

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

--- Comment #2 from engrwahidmemon at gmail dot com 2011-05-21 11:52:13 UTC ---
Thanks alot. Can you please tell me who is the author of plugin? May
be I misunderstood, the plugin that I am using is written by me.

Regards

Abdul

On Sat, May 21, 2011 at 12:12 PM, rguenth at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49096
>
> Richard Guenther  changed:
>
>           What    |Removed                     |Added
> 
>             Status|UNCONFIRMED                 |RESOLVED
>         Resolution|                            |INVALID
>
> --- Comment #1 from Richard Guenther  2011-05-21 
> 09:57:25 UTC ---
> Report to the plugin author instead.
>

[Bug c++/49100] [OpenMP]: Compiler error when inline method defined within OpenMP loop

[bisqwit at iki dot fi]

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

--- Comment #1 from Joel Yliluoma  2011-05-21 11:31:46 
UTC ---
It also does not happen with C's nested functions. This for instance compiles
and works just fine (to my surprise).

#include 
int main()
{
int a;
#pragma omp parallel for
for(a=0; a<10; ++a)
{
int c() { return 65; }
putchar( c() );
}
return 0;
}

I venture into another bug report here, but I wonder if this is a bug or
intentional behavior, that the code below outputs "YY", as though the
variable "a" within c() is bound to the a from the surrounding context rather
than the OpenMP loop's private copy of "a". If the OpenMP loop is removed, it
outputs "ABCDEFGHIJ" as expected.

#include 
int main()
{
int a = 24;
#pragma omp parallel for
for(a=0; a<10; ++a)
{
int c() { return a+65; }
putchar( c() );
}
return 0;
}

[Bug ada/49097] gnatbind link fails to find version_string, potential ranlib concurrency problem

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  2011-05-21 
11:24:11 UTC ---
Created attachment 24317
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24317
untested patch

Please see if this patch (untested) fixes the problem for you.  If so I'll
commit it as obvious.  This missing dependency was pre-existing, but maybe it
didn't matter before.

[Bug c++/49100] New: [OpenMP]: Compiler error when inline method defined within OpenMP loop

[bisqwit at iki dot fi]

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

   Summary: [OpenMP]: Compiler error when inline method defined
within OpenMP loop
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi


This report is similar to PR49043, but unlike it, this does not involve C++0x.

This valid code fails to compile on GCC.
GCC spews an "invalid exit from OpenMP structured block" error message.

int main()
{
#pragma omp parallel for
for(int a=0; a<10; ++a)
{
struct x
{
void test() { return; };
};
}
}

If the explicit "return" statement is removed, it compiles.
It is also triggered by code such as this:

struct y
{
static bool test(int c) { return c==5; }
};

if put inside the OpenMP loop construct, meaning it happens for static and
non-static methods as long as they include an explicit "return" statement.

The purpose of this error is to catch exits from an OpenMP construct (return,
break, goto). No such thing happens when a function is called or defined. The
error is not given when the struct is defined outside the loop (even if invoked
inside the loop). It is clearly a parser error.

It failed on all GCC versions that I tried that support OpenMP. These include
GCC 4.2.4, 4.3.5, 4.4.6, 4.5.3 and 4.6.1.

I have not tested whether the patch committed as a result of PR49043 also fixes
this bug.

[Bug target/49099] New: sparc.c:‘sparc_solaris_elf_asm_named_section’ declared ‘static’ but never defined

[amylaar at gcc dot gnu.org]

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

   Summary: sparc.c:‘sparc_solaris_elf_asm_named_section’ declared
‘static’ but never defined
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: r...@gcc.gnu.org
Blocks: 44756
Target: sparc64-elf, sparc64-freebsd6, sparc64-linux,
sparc64-netbsd, sparc64-openbsd, sparc64-rtems,
sparc-elf, sparc-leon3-linux-gnu --enable-target=all,
sparc-leon-elf, sparc-linux-gnu, sparc-netbsdelf,
sparc-rtems, sparc-wrs-vxworks


gcc -c   -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 -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber\
../../../gcc/gcc/config/sparc/sparc.c -o sparc.o
../../../gcc/gcc/config/sparc/sparc.c:395:13: error:
‘sparc_solaris_elf_asm_named_section’ declared ‘static’ but never defined
[-Werror=unused-function]
cc1: all warnings being treated as errors

make[2]: *** [sparc.o] Error 1

[Bug target/49098] New: unused parameters in rx.c:rx_memory_move_cost

[amylaar at gcc dot gnu.org]

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

   Summary: unused parameters in rx.c:rx_memory_move_cost
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: ni...@redhat.com
Blocks: 44756
Target: rx-elf


gcc -c   -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 -Werror
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include
-I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
-I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber\
../../../gcc/gcc/config/rx/rx.c -o rx.o
../../../gcc/gcc/config/rx/rx.c: In function ‘rx_memory_move_cost’:
../../../gcc/gcc/config/rx/rx.c:2639:40: error: unused parameter ‘mode’
[-Werror=unused-parameter]
../../../gcc/gcc/config/rx/rx.c:2639:58: error: unused parameter ‘regclass’
[-Werror=unused-parameter]
cc1: all warnings being treated as errors

make[2]: *** [rx.o] Error 1

[Bug ada/49097] New: gnatbind link fails to find version_string, potential ranlib concurrency problem

[amylaar at gcc dot gnu.org]

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

   Summary: gnatbind link fails to find version_string, potential
ranlib concurrency problem
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: js...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: arm-ecos-elf, x86_64-elf


This is from the arm-ecos-elf build log, using svn revision 173975 on gcc20:

gcc -static-libgcc  -o gnatbind ada/b_gnatb.o ada/adaint.o ada/argv.o
ada/exit.o ada/cio.o ada/cstreams.o ada/env.o ada/final.o ada/init.o
ada/initialize.o ada/seh_init.o ada/link.o ada/targext.o ada/raise.o
ada/tracebak.o ada/ada.o ada/a-clrefi.o ada/a-comlin.o ada/a-elchha.o
ada/a-except.o ada/ali-util.o ada/ali.o ada/alloc.o ada/aspects.o ada/atree.o
ada/bcheck.o ada/binde.o ada/binderr.o ada/bindgen.o ada/bindusg.o ada/butil.o
ada/casing.o ada/csets.o ada/debug.o ada/einfo.o ada/elists.o ada/err_vars.o
ada/errout.o ada/erroutc.o ada/fmap.o ada/fname.o ada/g-hesora.o ada/g-htable.o
ada/s-os_lib.o ada/s-string.o ada/gnat.o ada/gnatbind.o ada/gnatvsn.o
ada/hostparm.o ada/interfac.o ada/lib.o ada/namet.o ada/nlists.o ada/opt.o
ada/osint-b.o ada/osint.o ada/output.o ada/rident.o ada/s-addope.o
ada/s-assert.o ada/s-carun8.o ada/s-casuti.o ada/s-conca2.o ada/s-conca3.o
ada/s-conca4.o ada/s-conca5.o ada/s-conca6.o ada/s-conca7.o ada/s-conca8.o
ada/s-conca9.o ada/s-crc32.o ada/s-crtl.o ada/s-except.o ada/s-exctab.o
ada/s-htable.o ada/s-imenne.o ada/s-imgenu.o ada/s-mastop.o ada/s-memory.o
ada/s-parame.o ada/s-restri.o ada/s-secsta.o ada/s-soflin.o ada/s-sopco3.o
ada/s-sopco4.o ada/s-sopco5.o ada/s-stache.o ada/s-stalib.o ada/s-stoele.o
ada/s-strhas.o ada/s-strops.o ada/s-traceb.o ada/s-traent.o ada/s-unstyp.o
ada/s-utf_32.o ada/s-wchcnv.o ada/s-wchcon.o ada/s-wchjis.o ada/scng.o
ada/scans.o ada/scil_ll.o ada/sdefault.o ada/sem_aux.o ada/sinfo.o ada/sinput.o
ada/sinput-c.o ada/snames.o ada/stand.o ada/stringt.o ada/switch-b.o
ada/switch.o ada/style.o ada/styleg.o ada/stylesw.o ada/system.o ada/table.o
ada/targparm.o ada/tree_io.o ada/types.o ada/uintp.o ada/uname.o ada/urealp.o
ada/widechar.o prefix.o libcommon.a ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -g -O2
ranlib  libcommon.a
ada/adaint.o: In function `get_gcc_version':
/home/amylaar/pr46489/may20/multi/arm-ecos-elf/gcc/../../../gcc/gcc/ada/adaint.c:3595:
undefined reference to `version_string'
ada/gnatvsn.o: In function `gnatvsn__gnat_version_string':
/home/amylaar/pr46489/may20/multi/arm-ecos-elf/gcc/../../../gcc/gcc/ada/gnatvsn.adb:75:
undefined reference to `version_string'
/home/amylaar/pr46489/may20/multi/arm-ecos-elf/gcc/../../../gcc/gcc/ada/gnatvsn.adb:73:
undefined reference to `version_string'
collect2: ld returned 1 exit status
make[2]: *** [gnatbind] Error 1

Likewise, for the x86_64-elf --with-fpmath=sse build, ranlib appears to be
called during the gnatbind link, and the latter fails with an undefined
reference to version_string.
In each case, libcommon.a contains version_string as a global read-only symbol.
Re-running the link command by hand succeeds.

[Bug c/49096] internal compiler error: in calc_dfs_tree, at dominance.c:394

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-05-21 
09:57:25 UTC ---
Report to the plugin author instead.

[Bug rtl-optimization/49095] Horrible code generation for trivial decrement with test

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2011.05.21 09:52:49
  Component|other   |rtl-optimization
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-05-21 
09:52:49 UTC ---
Confirmed (not using decq is because it is slower for some archs).  On the
tree level we cannot do better than

  D.2722_2 = *argv_1(D);
  D.2723_3 = D.2722_2 + -1;
  *argv_1(D) = D.2723_3;
  if (D.2723_3 == 0B)

because we lack anything like direct operations on memory (and that's good).
On the RTL side combine tries to do

Trying 7, 8 -> 9:
Failed to match this instruction:
(parallel [
(set (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8 A64])
(plus:DI (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8
A64])
(const_int -1 [0x])))
(set (reg/f:DI 60 [ D.2723 ])
(plus:DI (mem/f:DI (reg/v/f:DI 63 [ argv ]) [2 *argv_1(D)+0 S8
A64])
(const_int -1 [0x])))
])

because we have a use of the decrement result in the comparison.  It doesn't
try to combine this with the comparison though.

So this case is really special ;)  Without the use of the decremented
value we get the desired subq $1, (%rsi).

Manually sinking the store to *argv into the if and the else yields

movq(%rsi), %rbx
subq$1, %rbx
je  L4
L2:
movq%rbx, (%rsi)
...

L4:
LCFI4:
movq$0, (%rsi)
movq%rsi, %rdi
movq%rsi, 8(%rsp)
call_fncall

so at least we then can combine the decrement with the test ...

As usual combine doesn't like stores.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #2 from Matthias Klose  2011-05-21 09:21:55 
UTC ---
PR48799 shows an ICE in the same location

[Bug target/49089] Regression on CFP2006 on Bulldozer From Splitting AVX 32-byte Unaligned Loads

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.21 09:38:03
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-05-21 
09:38:03 UTC ---
Confirmed.  The default setting should be part of the tuning flags.

[Bug c++/49092] [4.7 Regression] ice in tree_add_const_value_attribute

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|ice in  |[4.7 Regression] ice in
   |tree_add_const_value_attrib |tree_add_const_value_attrib
   |ute |ute

[Bug tree-optimization/49093] [4.6/4.7 Regression] ICE in vect_enhance_data_refs_alignment() with volatile inside peeled loop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.21 09:40:47
   Target Milestone|--- |4.6.1
Summary|ICE in  |[4.6/4.7 Regression] ICE in
   |vect_enhance_data_refs_alig |vect_enhance_data_refs_alig
   |nment() with volatile   |nment() with volatile
   |inside peeled loop  |inside peeled loop
 Ever Confirmed|0   |1
  Known to fail||4.6.0

--- Comment #1 from Richard Guenther  2011-05-21 
09:40:47 UTC ---
Confirmed.

[Bug tree-optimization/48988] [4.7 regression] ICE at pred_chain_length_cmp at tree-ssa-uninit.c:1624

[ebotcazou at gcc dot gnu.org]

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

--- Comment #3 from Eric Botcazou  2011-05-21 
09:27:39 UTC ---
To reproduce on Linux, in the build dir:

  cp gcc/ada/rts/system.ads .
  chmod a+w system.ads
  edit system.ads and change ZCX_By_Default to False
  gcc/gnat1 gcc/ada/rts/g-catiio.adb -Igcc/ada/rts -Wall -O

This breaks the compiler on all SJLJ platforms, e.g. arm-linux.

[Bug c++/49085] Crash with SIGSEGV during compilation.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Richard Guenther  2011-05-21 
09:34:36 UTC ---
8473  off = size_binop_loc (input_location, PLUS_EXPR,
DECL_FIELD_OFFSET (t),
8474size_int (tree_low_cst (DECL_FIELD_BIT_OFFSET (t),
84751)
8476  / BITS_PER_UNIT));


and DECL_FIELD_BIT_OFFSET is NULL.

(gdb) call debug_tree (t)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x142818690 precision 64
min  max >
used private decl_3 VOID file t.ii line 6 col 19
align 1 offset_align 1 context  chain >

[Bug c/49096] New: internal compiler error: in calc_dfs_tree, at dominance.c:394

[dietwo at hotmail dot com]

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

   Summary: internal compiler error: in calc_dfs_tree, at
dominance.c:394
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: die...@hotmail.com


Created attachment 24316
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24316
save-temps file

A plugin containing two passes (one pass after "ch" and the second one after
"loop2_init). Purpose is just to get the number of loops by calling
number_of_loops function. Works fine and produces output if the called function
is not returning a value, but if there is a return value then it produces the
following error.
internal compiler error: in calc_dfs_tree, at dominance.c:394

Tested with 4.5.0, 4.5.2, 4.5.3 and 4.6.0

Command line: ~/compilers/gcc-4.5.3/install/bin/gcc -O3 -fplugin=./plugin.so
hello.c

(gdb) bt
#0  fancy_abort (file=0xd11258 "../../../gcc/dominance.c", line=394,
function=0xd113e0 "calc_dfs_tree") at ../../../gcc/diagnostic.c:762
#1  0x005b37b7 in calc_dfs_tree (di=0x7fffdac0, reverse=0 '\000')
at ../../../gcc/dominance.c:394
#2  0x005b5158 in calculate_dominance_info (dir=CDI_DOMINATORS) at
../../../gcc/dominance.c:655
#3  0x0057a23b in flow_loops_find (loops=0x75816240) at
../../../gcc/cfgloop.c:387
#4  0x006eb93f in loop_optimizer_init (flags=7) at
../../../gcc/loop-init.c:52
#5  0x7589c8bc in execute_rtl () at new.c:31
#6  0x0072868b in execute_one_pass (pass=0x75a9d100) at
../../../gcc/passes.c:1568
#7  0x00728915 in execute_pass_list (pass=0x75a9d100) at
../../../gcc/passes.c:1623
#8  0x00819ac5 in tree_rest_of_compilation (fndecl=0x7580cf00) at
../../../gcc/tree-optimize.c:413
#9  0x009a0311 in cgraph_expand_function (node=0x75812750) at
../../../gcc/cgraphunit.c:1555
#10 0x009a2b95 in cgraph_expand_all_functions () at
../../../gcc/cgraphunit.c:1634
#11 cgraph_optimize () at ../../../gcc/cgraphunit.c:1890
#12 0x009a32f5 in cgraph_finalize_compilation_unit () at
../../../gcc/cgraphunit.c:1103
#13 0x004b1083 in c_write_global_declarations () at
../../../gcc/c-decl.c:9520
#14 0x007c8cd5 in compile_file (argc=4, argv=0x7fffdeb8) at
../../../gcc/toplev.c:1065
#15 do_compile (argc=4, argv=0x7fffdeb8) at ../../../gcc/toplev.c:2417
#16 toplev_main (argc=4, argv=0x7fffdeb8) at ../../../gcc/toplev.c:2459
#17 0x76437bfd in __libc_start_main () from /lib64/libc.so.6
#18 0x00494f59 in _start () at ../sysdeps/x86_64/elf/start.S:113