[Bug fortran/44927] static linkage with -lgomp fails on simple program

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2010-07-16 07:09 ---
(In reply to comment #9)
> (In reply to comment #6)
> > Please don't keep reopening this bug.
> > The symbols are weak undefs because libgfortran doesn't require (and 
> > shouldn't
> > require) libpthread, it is thread-safe only when libpthread is linked in.
> > 
> 
> After reviewing the thread (and recalling others along this line),
> Jakub, if you want to make the combination of -static -fopenmp
> a fatal error for gfortran, a patch is pre-approved.

I am against it - if you "properly" link it, e.g. using -Wl,--whole-archive or
with a POSIX Threads (pthread) library, which is linked with "ld -r", it works.

That's a similar issue to -m(no-)align-double: It leads to difficult to
understand crashes, but it is nontrivial to diagnose properly as there are
valid/working combinations - even though most combinations lead to crashes.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/33097] Function decl trees without proper argument list

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-07-16 07:17 ---
(In reply to comment #15)
> By now we have proper whole-file checking. Is this PR still relevant?

I think it is - though there should be some PR about it. The correct way is to
construct the dummy argument list from the actual argument list. For
procedures, where the explicit interface is known, this is not an issue, but
those with implicit interface ("EXTERNAL") it is. Additionally, one can improve
the diagnostic as conflicting use of such procedures can be diagnosed.

Cf. PR 40976. I thought there was another PR, but I cannot find it at the
moment.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2007-08-20 14:47:58 |2010-07-16 07:17:03
   date||


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

[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-07-16 07:31 
---
I am able to reproduce this on the PPC machine I have access to.  I think I see
the problem and will submit a patch in the next few days when I can squeeze in
some time.

Dominique, can you do me a favor and test the READ patch as well that I 
submitted to see if the issue is there as well.  I suspect it is.


-- 


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

[Bug middle-end/24434] [4.3/4.4/4.5/4.6 Regression] get_varargs_alias_set returns 0 always

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-07-16 08:22 
---
What does the standard say here?  What is the type in effect for aliasing
when doing

 int i = va_arg (va, int);

?  Is type-punning allowed when unpacking args?

Note that we would need to make sure to use the correct alias set when
setting up args at the callers site as well.

But yes, this now looks easily fixable (and also was with INDIRECT_REFs
via type casts).


-- 


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

[Bug tree-optimization/24169] Address (full struct) escapes even though the called function does not cause it to escape

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-07-16 08:29 ---
IPA-PTA computes the required information (but we do not store sub-field
granular points-to or clobber sets):

h.clobber = { k.8+8 }
h.use = { }
f.clobber = { k.8+8 } same as f.arg0
f.use = { }
f.arg0 = { k.8+8 }
k.0+8 = { }
k.8+8 = { }

:
  k.i = 2;
  k.j = 2;
  # CLB = { k }
  f (&k.j);
  D.2724_1 = k.i;
  if (D.2724_1 != 2)
goto ;
  else
goto ;

:
  # USE = nonlocal
  # CLB = nonlocal
  link_error ();

:
  return;


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2010-07-15 22:50:25 |2010-07-16 08:29:05
   date||


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

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5 Regression] bootstrap  |[4.5 Regression] bootstrap
   |failed at Comparing stages 2|failed at Comparing stages 2
   |and 3   |and 3
   Target Milestone|--- |4.5.1


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

[Bug c/44961] New: size_t typedef failure

[aj at member dot fsf dot org]

In stddef.h, __GNUG__ appears to be undefined while size_t is defined so that
this will fail:

#if !(defined (__GNUG__) && defined (size_t))
typedef __SIZE_TYPE__ size_t;

Compiler invocation:

gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude-m32  -O2  -Wall -MT
antlr3basetree.lo -MD -MP -MF ".deps/antlr3basetree.Tpo" -c -o
antlr3basetree.lo `test -f 'src/antlr3basetree.c' || echo
'./'`src/antlr3basetree.c; 

Compiler output:

In file included from /usr/include/stdio.h:34,
 from include/antlr3defs.h:219,
 from include/antlr3basetree.h:37,
 from src/antlr3basetree.c:1:
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include/stddef.h:211: error: duplicate
‘unsigned’
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include/stddef.h:211: error: two or more
data types in declaration specifiers

Preprocessor output:

# 211 "/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include/stddef.h" 3 4
typedef unsigned int unsigned int;

Output of gcc -v:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-6'
--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
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-6)


-- 
   Summary: size_t typedef failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at member dot fsf dot org


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

[Bug fortran/44945] [4.6 Regression] FAIL: gfortran.dg/char_array_structure_constructor.f90

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-07-16 08:38 ---
Frontend issue then.  Does it work with -fwhole-file?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |fortran


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

[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail

[iains at gcc dot gnu dot org]

--- Comment #21 from iains at gcc dot gnu dot org  2010-07-16 08:39 ---
Subject: Bug 42843

Author: iains
Date: Fri Jul 16 08:39:37 2010
New Revision: 162254

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162254
Log:

2010-07-16  Jack Howarth  

PR testsuite/42843
* gcc.dg/plugin/selfassign.c: Include diagnostic.h.
* gcc.dg/plugin/ggcplug.c: Likewise.
* g++.dg/plugin/selfassign.c: Likewise.
* g++.dg/plugin/attribute_plugin.c: Likewise.
* g++.dg/plugin/dumb_plugin.c: Likewise.
* g++.dg/plugin/pragma_plugin.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/plugin/attribute_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c
trunk/gcc/testsuite/g++.dg/plugin/selfassign.c
trunk/gcc/testsuite/gcc.dg/plugin/ggcplug.c
trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c


-- 


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

[Bug fortran/44962] New: [OOP] ICE with specification expression SIZE()

[burnus at gcc dot gnu dot org]

Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00206.html

The following program segfaults. The crucial part is that the argument has is
CLASS and not TYPE - and that it is used in a specification expression.

The ICE occurs when it is written to the .MOD file.


Valgrind shows:

==15819== Invalid read of size 8
==15819==at 0x50E636: mio_expr (module.c:3091)
==15819==by 0x50F0C9: mio_array_spec (module.c:2179)
==15819==by 0x50F208: mio_component (module.c:2371)
==15819==by 0x50F3E7: mio_symbol (module.c:2420)
==15819==by 0x50F82A: write_symbol (module.c:4804)
==15819==by 0x510CE5: write_symbol0 (module.c:4844)
==15819==by 0x51132B: gfc_dump_module (module.c:5022)
==15819==by 0x51BFE0: gfc_parse_file (parse.c:4388)


module array
  type :: t_array
 real, dimension(10) :: coeff
   contains
 procedure, nopass :: get_coeff
  end type t_array
contains
  function get_coeff(self) result(coeff)
class(t_array), intent(in) :: self
real, dimension(5) :: coeff
i = size(self%coeff)
  end function get_coeff
end module array


-- 
   Summary: [OOP] ICE with specification expression SIZE()
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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=44962

[Bug fortran/44945] [4.6 Regression] FAIL: gfortran.dg/char_array_structure_constructor.f90

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2010-07-16 08:51 ---
> Does it work with -fwhole-file?

Nope, but it works with -fcheck=all at -O2 and not at -O3.


-- 


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

[Bug fortran/44953] FAIL: gfortran.dg/char4_iunit_1.f03 * execution test

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2010-07-16 09:03 ---
> Dominique, can you do me a favor and test the READ patch as well that I 
> submitted to see if the issue is there as well.  I suspect it is.

Yes!-(


FAIL: gfortran.dg/char4_iunit_1.f03  -O0  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O1  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O2  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -O3 -g  execution test
FAIL: gfortran.dg/char4_iunit_1.f03  -Os  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O0  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O1  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O2  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -O3 -g  execution test
FAIL: gfortran.dg/char4_iunit_2.f03  -Os  execution test

char4_iunit_2.f03 fails at the last test with 

widestring=  ?test?345?  52.542999?0 hijklmnp qwertyuiopasd 


-- 


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

[Bug target/44942] Bug in argument passing of long double

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-07-16 09:06 ---
Subject: Bug 44942

Author: jakub
Date: Fri Jul 16 09:06:02 2010
New Revision: 162255

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162255
Log:
PR target/44942
* config/i386/i386-protos.h (ix86_function_arg_boundary): Change second
argument to const_tree.
* config/i386/i386.c (function_arg_advance): If padding needs to be
inserted before argument, increment cum->words by number of padding
words as well.
(contains_aligned_value_p): Change argument to const_tree.
(ix86_function_arg_boundary): Change second argument to const_tree.

* gcc.c-torture/execute/pr44942.c: New test.
* gcc.target/i386/pr44942.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr44942.c
trunk/gcc/testsuite/gcc.target/i386/pr44942.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2010-07-16 09:11 ---
Seemingly, we currently only "recycle" DECLs for procedure decls, but not for
module variable decls.

Looking at
gfortran -fdump-tree-optimized-all -O3 char_array_structure_constructor.f90

one finds (grep MOD_c):
  __global_MOD_cD.1586
  __global_MOD_cD.1606
However, if one removes the second "USE global" and uses the host-associated
variable, it works (i.e. there is only one "__global_MOD_cD").

Expected: The same DECL is used for host associated variables - and, at least
with -fwhole-file, the same DECL is used for the whole file.

I wonder whether the same problem also exists for COMMON symbols.

(Note: While the wrong-code only becomes apparent on x86_64-apple-darwin10, the
bug itself exists on all platforms. Thus, I have emptied the PR's target
field.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-apple-darwin10   |
   GCC host triplet|x86_64-apple-darwin10   |
 GCC target triplet|x86_64-apple-darwin10   |
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-07-16 09:11:44
   date||
Summary|[4.6 Regression] FAIL:  |[4.6 Regression] Wrong decl
   |gfortran.dg/char_array_struc|for module vars / FAIL:
   |ture_constructor.f90|gfortran.dg/char_array_struc
   ||ture_constructor.f90


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

[Bug c/44961] size_t typedef failure

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-07-16 09:39 ---
Looks like a bug in antlr3.


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-07-16 10:08 ---
As can be seen on:
module mm
contains
  function a ()
integer :: a, b, c
common /blk/ b, c
b = 6
c = 7
a = 8
  end function
end module mm
function b ()
  integer :: b, d, e
  common /blk/ d, e
  b = d + e
end function
program qq
  use mm
  integer :: d, e
  common /blk/ d, e
  interface
function b ()
  integer :: b
end function b
  end interface
  if (a () .ne. 8) call abort
  if (b () .ne. (d + e)) call abort
end
with -fdump-tree-original-all, I believe common decls are fine:
grep blk a.f90.003t.original
  static integer(kind=4)D.8 bD.1555 [value-expr: blk_D.1554.bD.1552];
  static integer(kind=4)D.8 cD.1556 [value-expr: blk_D.1554.cD.1553];
  static integer(kind=4)D.8 dD.1562 [value-expr: blk_D.1554.dD.1560];
  static integer(kind=4)D.8 eD.1563 [value-expr: blk_D.1554.eD.1561];
  static integer(kind=4)D.8 dD.1569 [value-expr: blk_D.1554.dD.1567];
  static integer(kind=4)D.8 eD.1570 [value-expr: blk_D.1554.eD.1568];


-- 


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

[Bug libstdc++/44963] New: Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[oakad at yahoo dot com]

The example program below will exhibit the problem when compiled with
-std=c++0x or gnu++0x flag. The problem is particularly unfortunate, as rope is
designed for use with back_inserter style constructs.

Example program:
#include 
#include 

using namespace std;

int main(int argc, char **argv)
{
__gnu_cxx::crope line("test");
auto ii(back_inserter(line));

*ii++ = 'm';
*ii++ = 'e';

cout << line << endl;
return 0;
}

Compilation error message:
testrope1.cpp: In function ‘int main(int, char**)’:
testrope1.cpp:11: error: ambiguous overload for ‘operator=’ in
‘ii.std::back_insert_iterator<_Container>::operator++ [with _Container =
__gnu_cxx::rope
>](0).std::back_insert_iterator<_Container>::operator* [with _Container =
__gnu_cxx::rope >]() = 'm'’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:415:
note: candidates are: std::back_insert_iterator<_Container>&
std::back_insert_iterator<_Container>::operator=(typename
_Container::const_reference) [with _Container = __gnu_cxx::rope >]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:423:
note: std::back_insert_iterator<_Container>&
std::back_insert_iterator<_Container>::operator=(typename
_Container::value_type&&) [with _Container = __gnu_cxx::rope >]
testrope1.cpp:12: error: ambiguous overload for ‘operator=’ in
‘ii.std::back_insert_iterator<_Container>::operator++ [with _Container =
__gnu_cxx::rope
>](0).std::back_insert_iterator<_Container>::operator* [with _Container =
__gnu_cxx::rope >]() = 'e'’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:415:
note: candidates are: std::back_insert_iterator<_Container>&
std::back_insert_iterator<_Container>::operator=(typename
_Container::const_reference) [with _Container = __gnu_cxx::rope >]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:423:
note: std::back_insert_iterator<_Container>&
std::back_insert_iterator<_Container>::operator=(typename
_Container::value_type&&) [with _Container = __gnu_cxx::rope >]


-- 
   Summary: Ambiguous function overload using __gnu_cxx::crope with
std::back_inserter in c++0x mode
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug target/44942] Bug in argument passing of long double

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-07-16 10:35 ---
Fixed on the trunk so far, will backport to branches later on.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|3.2.3 3.3.3 4.1.2 4.3.4 |3.2.3 3.3.3 4.1.2 4.3.4
   |4.4.3 4.5.0 4.6.0   |4.4.3 4.5.0
  Known to work||4.6.0


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

[Bug target/29996] sh-elf: should enable -fomit-frame-pointer

[chrbr at gcc dot gnu dot org]

--- Comment #1 from chrbr at gcc dot gnu dot org  2010-07-16 11:34 ---
done since http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01147.html

needed ACCUMULATE_OUTGOING_ARG to fix unwinding (can go back to previous
behavior with -mno-accumulate-outgoing-args -fno-omit-frame-pointer)


-- 

chrbr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44963] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-07-16 12:00 ---
confirmed, the ambiguity comes because crope::const_reference is a typedef for
char, not const char&

  template 
class rope : public _Rope_base<_CharT, _Alloc>
{
public:
  typedef _CharT value_type;
  typedef ptrdiff_t difference_type;
  typedef size_t size_type;
  typedef _CharT const_reference;


-- 

redi 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-07-16 12:00:48
   date||


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #13 from burnus at gcc dot gnu dot org  2010-07-16 12:08 ---
Patch for -fwhole-file (not regtested).

Paul, do you know why derived types where excluded?

Index: trans-decl.c
===
--- trans-decl.c(revision 162255)
+++ trans-decl.c(working copy)
@@ -1149,11 +1149,9 @@ gfc_get_symbol_decl (gfc_symbol * sym)
 return sym->backend_decl;

   /* If use associated and whole file compilation, use the module
- declaration.  This is only needed for intrinsic types because
- they are substituted for one another during optimization.  */
+ declaration.  */
   if (gfc_option.flag_whole_file
&& sym->attr.flavor == FL_VARIABLE
-   && sym->ts.type != BT_DERIVED
&& sym->attr.use_assoc
&& sym->module)
 {


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-07-16 12:08 ---
(In reply to comment #13)
> Paul, do you know why derived types where excluded?
s/where/were/ - Firefox needs a grammar checker ...


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2010-07-16 12:32 ---
I wonder whether the middle-end will not mind different types (the "recycled"
decl will use backend_decl and its type from wherever it has been generated,
and the current function will likely have a different type).  Or are backend
types shared for module derived types?  Perhaps conversion between the two
types will be considered useless, still something that needs checking.

Plus there is -fno-whole-file (unless we want to make -fwhole-file default and
remove -fno-whole-file for 4.6).


-- 


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

[Bug bootstrap/44807] [4.6 Regression] bootstrap failure on i686 with BOOT_CFLAGS='-O3'

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-07-16 13:02 ---
It is caused by revision 161744:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00097.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-16 13:03:00
   date||


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

[Bug libstdc++/44963] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-07-16 13:12 
---
Bah, I'm afraid this is going to be a wontfix. Certainly the
back_insert_iterator assignment operators are fine per se in C++0x mode, and I
don't think we really want to, eg, add specializations of back_insert_iterator
& co for rope...


-- 


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

[Bug fortran/42385] [OOP] poylmorphic operators do not work

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2010-07-16 13:20 ---
Created an attachment (id=21221)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21221&action=view)
Fix for the PR

Please note that this patch contains part of Janus' clean-up of vtabs diff. 
This came about because the tree on my laptop is too old.

I will separate out the fix for PR42385 tonight.

It bootstraps and regtests on RHEL5.3/i686.

Paul

The following runs correctly:
module foo_module
 implicit none
 private
 public :: foo

 type :: foo
   integer :: i
 contains
   procedure :: times => times_foo
   procedure :: assign => assign_foo
   generic :: operator(*) => times
   generic :: assignment(=) => assign
 end type

contains

   function times_foo(this,factor) result(product)
 class(foo) ,intent(in) :: this
 class(foo) ,pointer :: product
 real, intent(in) :: factor
 allocate (product, source = this)
 product%i = this%i * int (factor)
   end function

   subroutine assign_foo(lhs,rhs)
 class(foo) ,intent(inout) :: lhs
 class(foo) ,intent(in) :: rhs
 lhs%i = rhs%i
end subroutine

end module

module bar_module
 use foo_module ,only : foo
 implicit none
 private
 public :: bar

 type ,extends(foo) :: bar
   real :: x
 contains
   procedure :: times => times_bar
   procedure :: assign => assign_bar
 end type

contains
 subroutine assign_bar(lhs,rhs)
   class(bar) ,intent(inout) :: lhs
   class(foo) ,intent(in) :: rhs
   lhs%i = rhs%i
   select type(rhs)
 type is (bar)
   lhs%x = rhs%x
   end select
 end subroutine
 function times_bar(this,factor) result(product)
   class(bar) ,intent(in) :: this
   real, intent(in) :: factor
   class(foo), pointer :: product
   select type(this)
 type is (bar)
   allocate(product,source=this)
   select type(product)
 type is(bar)
   product%i = this%i*int(factor)
   product%x = this%x*factor
   end select
   end select
 end function
end module

program main
 use foo_module ,only : foo
 use bar_module ,only : bar
 implicit none
 type(foo) :: uniti = foo(2) 
 type(bar) :: unitx = bar(2, 1.0)
 call rescale(uniti, 3.141592654)
 call rescale(unitx, 3.141592654)
 print *, uniti%i
 print *, unitx%x, unitx%i
contains
 subroutine rescale(this,scale)
   class(foo) ,intent(inout) :: this
   real, intent(in) :: scale
   this = this*scale
 end subroutine
end program


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug libstdc++/44963] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2010-07-16 13:22 
---
Wait a minute, however, what about vector? We can ignore the super-legacy
rope, but is the vector version of the problem known to LWG?


-- 


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

[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-07-16 13:31 
---
It is, LWG 1334. I'll try to figure in Rapperswil if there is enough consensus
about the resolution to warrant an early implementation even if the issue isn't
really resolved.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|Ambiguous function overload |[DR 1334] Ambiguous function
   |using __gnu_cxx::crope with |overload using
   |std::back_inserter in c++0x |__gnu_cxx::crope with
   |mode|std::back_inserter in c++0x
   ||mode


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

[Bug target/44948] -msse/-mavx change ABI

[hjl dot tools at gmail dot com]

--- Comment #18 from hjl dot tools at gmail dot com  2010-07-16 13:31 
---
The problem isn't new:

[...@gnu-6 case3]$ cat x.c
#include "x.h"

void
foo (long double x, struct A y, long double z)
{
  int i;
  struct A a = { { 0, 1, 2, 3 } };

  if (x != 8.0L || z != 8.0L)
__builtin_abort ();
  if (__builtin_memcmp (&a, &y, sizeof (a)))
__builtin_abort ();
}
[...@gnu-6 case3]$ cat x.h
struct A
{ 
  float V4SF __attribute__ ((vector_size (16)));
};

void foo (long double, struct A, long double);
[...@gnu-6 case3]$ cat main.c 
#include "x.h"

int
main (void)
{
  struct A a = { { 0, 1, 2, 3 } };
  foo (8.0L, a, 8.0L);
  return 0;
}
[...@gnu-6 case3]$ make CC=gcc
gcc -m32 -g -O -msse2   -c -o x.o x.c
gcc -m32 -g -O -mno-sse   -c -o main.o main.c
gcc -m32 -g -O -o x x.o main.o
./x
make: *** [all] Aborted
[...@gnu-6 case3]$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|-mavx changes ABI   |-msse/-mavx change ABI


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

[Bug tree-optimization/44964] New: [4.6 Regression] ICE: SIGSEGV in gimple_default_def (tree-dfa.c:539) with -fkeep-inline-functions

[zsojka at seznam dot cz]

Command line:
$ gcc -fkeep-inline-functions -O[123s] testcase.c

Valgrind output:
$ valgrind -q --trace-children=yes
/mnt/svn/gcc-trunk/binary-162056-lto-fortran-checking-yes-rtl-df/bin/gcc
-fkeep-inline-functions -O1 testcase.c
==20756== Invalid read of size 8
==20756==at 0x8CD66D: gimple_default_def (tree-dfa.c:539)
==20756==by 0xADB938: setup_one_parameter (tree-inline.c:2527)
==20756==by 0xAE140D: optimize_inline_calls (tree-inline.c:2690)
==20756==by 0xAB9129: cgraph_early_inlining (ipa-inline.c:1783)
==20756==by 0x7B813D: execute_one_pass (passes.c:1565)
==20756==by 0x7B83D4: execute_pass_list (passes.c:1620)
==20756==by 0x7B763B: do_per_function_toporder (passes.c:1158)
==20756==by 0x7B87F5: execute_ipa_pass_list (passes.c:1920)
==20756==by 0xAB0350: cgraph_optimize (cgraphunit.c:1851)
==20756==by 0xAB05AA: cgraph_finalize_compilation_unit (cgraphunit.c:1171)
==20756==by 0x4DF2D2: c_write_global_declarations (c-decl.c:9698)
==20756==by 0x8A41E5: toplev_main (toplev.c:997)
==20756==  Address 0x40 is not stack'd, malloc'd or (recently) free'd
==20756== 
testcase.c: In function 'bar':
testcase.c:11:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r162056 - crash
r159696 - crash
r158969 - crash
r158095 - OK
4.5 r160526 - OK


-- 
   Summary: [4.6 Regression] ICE: SIGSEGV in gimple_default_def
(tree-dfa.c:539) with -fkeep-inline-functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug tree-optimization/44964] [4.6 Regression] ICE: SIGSEGV in gimple_default_def (tree-dfa.c:539) with -fkeep-inline-functions

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-07-16 13:37 ---
Created an attachment (id=21222)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21222&action=view)
reduced testcase (from ffmpeg sources)

Command line:
$ gcc -fkeep-inline-functions -O1 pr44964.c


-- 


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

[Bug target/44948] -msse/-mavx change ABI

[hjl dot tools at gmail dot com]

--- Comment #19 from hjl dot tools at gmail dot com  2010-07-16 13:41 
---
Created an attachment (id=21223)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21223&action=view)
A patch with psABI warning

This patch changes and warns psABI:

[...@gnu-6 case3]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -g -O -msse2   -c -o x.o
x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -g -O -mno-sse   -c -o
main.o main.c
main.c: In function ‘main’:
main.c:7:7: note: The ABI of passing parameter with 16byte or greater alignment
has changed in GCC 4.6
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -g -O -o x x.o main.o
./x
[...@gnu-6 case2]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -mavx   -c -o x.o x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O   -c -o main.o main.c
main.c: In function ‘main’:
main.c:7:7: note: The ABI of passing parameter with 16byte or greater alignment
has changed in GCC 4.6
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -o x x.o main.o
./x
[...@gnu-6 case2]$ 


-- 


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

[Bug middle-end/44763] [4.4/4.5/4.6 regression] SEGV in allocno_priority_compare_func on Solaris 8

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2010-07-16 13:52 ---
This is a regression from GCC 3.4.6.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.5 4.5.1 4.6.0
  Known to work||3.4.6
Summary|SEGV in |[4.4/4.5/4.6 regression]
   |allocno_priority_compare_fun|SEGV in
   |c on Solaris 8  |allocno_priority_compare_fun
   ||c on Solaris 8


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

[Bug target/44948] -msse/-mavx change ABI

[hjl dot tools at gmail dot com]

--- Comment #20 from hjl dot tools at gmail dot com  2010-07-16 13:55 
---
The following testcases are affected:

gcc.c-torture/compile/20070522-1.c
gcc.c-torture/compile/pr33617.c
gcc.c-torture/execute/pr38151.c
gcc.dg/compat/struct-align-1
gcc.dg/compat/struct-align-2
gcc.dg/compat/vector-1a
gcc.dg/compat/vector-1
gcc.dg/compat/vector-2a
gcc.dg/compat/vector-2b
gcc.dg/compat/vector-2
gcc.dg/pr43300.c
gcc.dg/pr44136.c
gcc.target/i386/pr39162.c
gcc.target/i386/pr40906-2.c
gcc.target/i386/sse-5.c
g++.dg/abi/param2.C
g++.dg/vect/pr33860a.cc


-- 


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

[Bug fortran/37077] Implement Internal Unit I/O for character KIND=4

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2010-07-16 14:16 
---
Subject: Bug 37077

Author: jvdelisle
Date: Fri Jul 16 14:16:04 2010
New Revision: 162260

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162260
Log:
2010-07-16  Jerry DeLisle  

PR libfortran/37077
* io/read.c (read_default_char4): Add support for reading into a
kind-4 character variable from a character(kind=4) internal unit.
* io/io.h (read_block_form4): Add prototype.
* io/unit.c (get_internal_unit): Add call to fbuf_init.
(free_internal_unit): Add call to fbuf_destroy. (get_unit): Fix
whitespace.
* io/transfer.c (read_sf_internal): Use fbuf_alloc to allocate a string
to recieve the wide characters translated to single byte chracters.
(read_block_form): Fix whitespace. (read_block_form4): New function to
read from a character(kind=4) internal unit into a character(kind=4)
variable. (read_block_direct): Fix whitespace. (write_block): Fix
whitespace. (formatted_transfer_scalar_read): Likewise.
(formatted_transfer_scalar_write): Likewise.
* io/write.c (write_character): Add support for list directed write of
a kind=1 character string to a character(kind=4) internal unit.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/write.c


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #16 from burnus at gcc dot gnu dot org  2010-07-16 14:21 ---
(In reply to comment #15)
> I wonder whether the middle-end will not mind different types (the "recycled"
> decl will use backend_decl and its type from wherever it has been generated,
> and the current function will likely have a different type).

I am not sure whether I understand your concern. This is about recycling the
decl of a module variable (sym->attr.flavor == FL_VARIABLE) which should have
the same type everywhere. Thus, from that side there should be no problem.

The only potential issue I see is:

use module
type(t) :: x
x = y  ! where "y" is a module variable of type "t"

where "x" has locally been declared - and thus might have a different type decl
than the module variable. I think one should check this, but I think that does
not make the current patch wrong.

> Plus there is -fno-whole-file (unless we want to make -fwhole-file default and
> remove -fno-whole-file for 4.6).

My idea is to change at some point during 4.6 to using -fwhole-file by default
- though I would not yet remove -fno-whole-file, yet. But the ultimate goal is
to remove -fno-whole-file and add some new flag (-fpermissive) for the few
cases where one wants to disable compilations errors due to fwhole-file
diagnostics.


-- 


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

[Bug fortran/37077] Implement Internal Unit I/O for character KIND=4

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2010-07-16 14:21 
---
Subject: Bug 37077

Author: jvdelisle
Date: Fri Jul 16 14:21:10 2010
New Revision: 162261

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162261
Log:
2010-07-16  Jerry DeLisle  

PR libfortran/37077
* gfortran.dg/char4_iunit_2.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/char4_iunit_2.f03
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/32062] Some MASKs aren't sufficient in certain sse4_1 tests

[rob1weld at aol dot com]

--- Comment #10 from rob1weld at aol dot com  2010-07-16 14:31 ---
(In reply to comment #7)
> Subject: Bug 32062
> Author: hjl
> Date: Thu May 24 14:12:18 2007
> New Revision: 125025
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125025
> Log:
> 2007-05-24  H.J. Lu  
> PR testsuite/32062
> * gcc.target/i386/sse4_1-check.h (MASK): New.
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/gcc.target/i386/sse4_1-check.h

Here is a link to a Library from AMD that allows SSE5 for everyone:
http://sseplus.sourceforge.net/

Thanks,
Rob


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[paul dot richard dot thomas at gmail dot com]

--- Comment #17 from paul dot richard dot thomas at gmail dot com  
2010-07-16 14:38 ---
Subject: Re:  [4.6 Regression] Wrong decl for module vars / 
FAIL: gfortran.dg/char_array_structure_constructor.f90

Dear Tobias,

On Fri, Jul 16, 2010 at 2:08 PM, burnus at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #13 from burnus at gcc dot gnu dot org  2010-07-16 12:08 
> ---
> Patch for -fwhole-file (not regtested).
>
> Paul, do you know why derived types where excluded?

No - maybe because the TYPE_CANONICAL had not been set?

Paul


-- 


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

[Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90

[burnus at gcc dot gnu dot org]

--- Comment #18 from burnus at gcc dot gnu dot org  2010-07-16 14:47 ---
Answer: With the patch, one gets:
  gfortran -fwhole-file gfortran.dg/default_initialization_4.f90
without the patch (and still -fwhole-file) it works.

The reason is that one does not "copy" over the backend_decl for the components
- which one might need to do recursively as the components might again be
derived types. Thus, it fails at trans-expr.c's gfc_conv_component_ref for:
gcc_assert (c->backend_decl).

Actually, I do not quite understand why BT_CLASS works - the BT_DERIVED check
of comment 13 should be also false for BT_CLASS, which means its backend_decl
should already be imported with -fwhole-file.


-- 


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

[Bug fortran/44927] static linkage with -lgomp fails on simple program

[kargl at gcc dot gnu dot org]

--- Comment #11 from kargl at gcc dot gnu dot org  2010-07-16 14:48 ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Please don't keep reopening this bug.
> > > The symbols are weak undefs because libgfortran doesn't require (and 
> > > shouldn't
> > > require) libpthread, it is thread-safe only when libpthread is linked in.
> > > 
> > 
> > After reviewing the thread (and recalling others along this line),
> > Jakub, if you want to make the combination of -static -fopenmp
> > a fatal error for gfortran, a patch is pre-approved.
> 
> I am against it - if you "properly" link it, e.g. using -Wl,--whole-archive or
> with a POSIX Threads (pthread) library, which is linked with "ld -r", it 
> works.

I don't see this in the information in the gfortran documentation.

> That's a similar issue to -m(no-)align-double: It leads to difficult to
> understand crashes, but it is nontrivial to diagnose properly as there are
> valid/working combinations - even though most combinations lead to crashes.

Well, I would like to disable the use of -malign-double on gfortran
as well.


-- 


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

[Bug tree-optimization/44964] [4.6 Regression] ICE: SIGSEGV in gimple_default_def (tree-dfa.c:539) with -fkeep-inline-functions

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-07-16 15:31 ---
It is caused by revision 158477:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00583.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-16 15:31:35
   date||
   Target Milestone|--- |4.6.0


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #2 from sme at cs dot toronto dot edu  2010-07-16 16:03 ---
Created an attachment (id=21224)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21224&action=view)
three f90 files that reproduce the bug


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #3 from sme at cs dot toronto dot edu  2010-07-16 16:04 ---
I've investigated further, and can reproduce it, but with one more condition
that I didn't mention in the original bugreport. 
Basically, it happens when we have two modules, both defining a subroutine with
the same name, where one happens to use the other (with a renaming).
For example:


The module m_dropdead defines an interface 'die'.
The module m_die also defines an interface 'die'.

So far, so good, and both compile fine.
However the subroutines in m_die use the die interface from m_dropdead:
 use m_dropdead, only : ddie => die

Not a problem so far.

But then, when I attempt to compile other files that use m_die, the compiler
gets confused. For example, when compiling m_IndexBin_char, we get to the line:
   use m_die,   only : die
and the compiler complains that m_die doesn't have a die routine. It looks like
a compiler bug - somehow or other the remapping to ddie in m_die has messed up
the symbol table beyond the scope of the subroutine it was used in.

I'm attaching three files that demonstrate the bug.  If you remove the line
that's commented out in m_die, and run them through gfortran, you should see it
trip up when compiling m_IndexBin_char

BTW I'm running gcc 4.3.0
On Mac OS X 10.5.8.


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #4 from sme at cs dot toronto dot edu  2010-07-16 16:05 ---
Created an attachment (id=21225)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21225&action=view)
2nd of three F90 files that reproduce the bug


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #5 from sme at cs dot toronto dot edu  2010-07-16 16:06 ---
Created an attachment (id=21226)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21226&action=view)
3rd file to reproduce - compiling this one generates the error


-- 


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

[Bug c++/32505] Partial specialization halfway accepted after instantiation

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-07-16 16:22 ---
Confirmed; no diagnostic is required by the standard, but we really ought to
give one anyway.  Simpler testcase:

template  struct A { };
A a;
template  struct A { }; // { dg-error "A" }


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2010-07-16 16:22:18
   date||


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

[Bug c++/32505] Partial specialization halfway accepted after instantiation

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-07-16 16:22:18 |2010-07-16 16:48:35
   date||


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

[Bug fortran/44957] generic procedure name not included in symbol table

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2010-07-16 17:18 ---
(In reply to comment #3)
> I've investigated further, and can reproduce it, but with one more condition
> that I didn't mention in the original bugreport. 
> Basically, it happens when we have two modules, both defining a subroutine 
> with
> the same name, where one happens to use the other (with a renaming).
> For example:
> 
> 
> The module m_dropdead defines an interface 'die'.
> The module m_die also defines an interface 'die'.
> 
> So far, so good, and both compile fine.
> However the subroutines in m_die use the die interface from m_dropdead:
>  use m_dropdead, only : ddie => die
> 
> Not a problem so far.
> 
> But then, when I attempt to compile other files that use m_die, the compiler
> gets confused. For example, when compiling m_IndexBin_char, we get to the 
> line:
>use m_die,   only : die
> and the compiler complains that m_die doesn't have a die routine. It looks 
> like
> a compiler bug - somehow or other the remapping to ddie in m_die has messed up
> the symbol table beyond the scope of the subroutine it was used in.
> 
> I'm attaching three files that demonstrate the bug.  If you remove the line
> that's commented out in m_die, and run them through gfortran, you should see 
> it
> trip up when compiling m_IndexBin_char

What command line?  With the renaming line uncommented, I see

troutmask:sgk[209] gfc43 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
troutmask:sgk[210] rm *.mod
troutmask:sgk[211] gfc44 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
troutmask:sgk[212] rm *.mod
troutmask:sgk[213] gfc45 -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
troutmask:sgk[214] rm *.mod
troutmask:sgk[215] gfc4x -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90

> BTW I'm running gcc 4.3.0
> On Mac OS X 10.5.8.

Ah, here the potential problem, Mac OS X is notorious for having
problems that other OS's do not.


-- 


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

[Bug fortran/43986] [OOP] gfortran.dg/dynamic_dispatch_4.f03 doesn't work on Linux/ia64

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2010-07-16 17:35 ---
(In reply to comment #5)

Is this now fixed on trunk?  We had to deal with the TBAA problem with the
arrival of mem-ref2.

Paul


-- 


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

[Bug bootstrap/44905] --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-07-16 
17:36 ---
The offending commit here was...

Revision 155759

2010-01-09  Alexandre Oliva  

* config/i386/i386.c (ix86_vectorize_builtin_vec_perm): Silence
bogus uninitialized warning.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

Summary|--enable-build-with-cxx |--enable-build-with-cxx
   |bootstrap failure compiling |bootstrap failure compiling
   |gcc/cppdefault.c|gcc/cppdefault.c


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

[Bug bootstrap/44905] --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-07-16 
17:38 ---
Note that the proposed patch for the new flag -Wself-assign...

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02519.html

reverts the offending commit. That change...


Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 161236)
+++ gcc/config/i386/i386.c  (working copy)
@@ -29379,7 +29379,7 @@ ix86_vectorize_builtin_vec_perm (tree ve
   tree itype = TREE_TYPE (vec_type);
   bool u = TYPE_UNSIGNED (itype);
   enum machine_mode vmode = TYPE_MODE (vec_type);
-  enum ix86_builtins fcode = fcode; /* Silence bogus warning.  */
+  enum ix86_builtins fcode;
   bool ok = TARGET_SSE2;

   switch (vmode)

also solves the bootstrap failure with --enable-build-with-cxx on darwin.


-- 


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

[Bug fortran/44022] Spurious 'unused parameter' for a used procedure argument

[domob at gcc dot gnu dot org]

--- Comment #2 from domob at gcc dot gnu dot org  2010-07-16 17:50 ---
I just hit it, too:

subroutine foo (x)
  procedure(intf) :: x

  abstract interface
integer function intf ()
end function intf
  end interface

  print *, x()
end subroutine foo


-- 

domob 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-07-16 17:50:51
   date||


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

[Bug fortran/44957] generic procedure name not included in symbol table

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2010-07-16 18:28 ---
Works for me too on x86_64-apple-darwin10.4 and powerpc-apple-darwin9.

> Ah, here the potential problem, Mac OS X is notorious for having
> problems that other OS's do not.

urban legend!-)


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #8 from sme at cs dot toronto dot edu  2010-07-16 18:39 ---
Here's my command line, and the results:

% gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
m_IndexBin_char.F90:12.25:

  use m_die,   only : die
1
Error: Symbol 'die' referenced at (1) not found in module 'm_die'
m_IndexBin_char.F90:18.25:

  use m_die,   only : die
1
Error: Symbol 'die' referenced at (1) not found in module 'm_die'

% gfortran -v
Using built-in specs.
Target: i386-apple-darwin9.0.0
Configured with: ../gcc-4.3-20071026/configure --enable-languages=fortran
Thread model: posix
gcc version 4.3.0 20071026 (experimental) (GCC) 


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2010-07-16 18:45 ---
(In reply to comment #8)
> Here's my command line, and the results:
> 
> % gfortran -c m_dropdead.F90 m_die.F90 m_IndexBin_char.F90
> m_IndexBin_char.F90:12.25:
> 
>   use m_die,   only : die
> 1
> Error: Symbol 'die' referenced at (1) not found in module 'm_die'
> m_IndexBin_char.F90:18.25:
> 
>   use m_die,   only : die
> 1
> Error: Symbol 'die' referenced at (1) not found in module 'm_die'
> 
> % gfortran -v
> Using built-in specs.
> Target: i386-apple-darwin9.0.0
> Configured with: ../gcc-4.3-20071026/configure --enable-languages=fortran
> Thread model: posix
> gcc version 4.3.0 20071026 (experimental) (GCC) 

In that case, I think you need to update to a newer version
of gfortran.  gfc43 in my comment #6 is 
gcc version 4.3.6 20100622 (prerelease) (GCC) 

BUt, if you go with an upgrade, I'll suggest 4.4.x or 
even 4.5.x.  These versions of course have many more
bug fixes than in the 4.3.x branch.


-- 


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

[Bug target/44606] Wrong SPE floating point during computation

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #4 from Kyle dot D dot Moffett at boeing dot com  2010-07-16 
18:48 ---
(In reply to comment #0)
> I attached two testcase which is stripped down graphicsmagick code.
> tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug 
> is 
> the same.

I was able to get similarly erroneous results with just "-O1 -fschedule-insns":
gcc -o tc0 -O0 -Wall -Wextra tc-resize.c
gcc -o tc1x -O1 -fschedule-insns -Wall -Wextra tc-resize.c
( ./tc0 ; echo "-"; ./tc1x; )
.19 2484.00
.21 2700.00
.23 2916.00
.24 3132.00
.26 3348.00
-
.7 954.00
.8 1050.00
.9 1146.00
.10 1242.00
.10 1338.00


-- 


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

[Bug fortran/44957] generic procedure name not included in symbol table

[sme at cs dot toronto dot edu]

--- Comment #10 from sme at cs dot toronto dot edu  2010-07-16 19:00 ---
Okay, I just upgraded to 4.4.1 and it compiles fine. 
Thanks!


-- 


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

[Bug middle-end/29256] [4.3/4.4/4.5/4.6 regression] loop performance regression

[pthaugen at gcc dot gnu dot org]

--- Comment #33 from pthaugen at gcc dot gnu dot org  2010-07-16 19:14 
---
gcc.dg/tree-ssa/loop-19.c started failing on powerpc with -m64 between 7/5 and
7/7. The tree dump now looks like the following:

:
  ivtmp.10_12 = (long unsigned int) &a[-1];
  ivtmp.16_15 = (long unsigned int) &c[-1];
  a.21_18 = (long unsigned int) &a;
  D.2035_19 = a.21_18 + 1592;

:
  # ivtmp.10_9 = PHI 
  # ivtmp.16_13 = PHI 
  ivtmp.10_5 = ivtmp.10_9 + 8;
  D.2032_16 = (void *) ivtmp.10_5;
  D.2007_3 = MEM[(double[200] *)D.2032_16];
  ivtmp.16_14 = ivtmp.16_13 + 8;
  D.2033_17 = (void *) ivtmp.16_14;
  MEM[(double[200] *)D.2033_17] = D.2007_3;
  if (ivtmp.10_5 != D.2035_19)
goto ;
  else
goto ;


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-07-16 19:21 ---
Created an attachment (id=21227)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21227&action=view)
final __forced_unwind patch and fixes applied in 2007, for historical reference


-- 


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

[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[oakad at yahoo dot com]

--- Comment #5 from oakad at yahoo dot com  2010-07-16 19:21 ---
Why is rope super-legacy? It had not enough attention to it, true, but it's a
very convenient class in certain cases.

Does the bug resolution means that no more changes/updates are expected for gcc
supplied rope, so external implementation should be preferred? And if such is
the case, shouldn't rope class be marked as deprecated, so that similar
functionality class can be proposed for addition elsewhere, in boost, for
instance?


-- 


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

[Bug target/44617] Serial Output on the atmega1280 does not work

[Dr dot diesel at gmail dot com]

--- Comment #9 from Dr dot diesel at gmail dot com  2010-07-16 19:38 ---
I don't get any different output than Scott, no .ii file, but I have exactly
the same problem on Fedora 13 64bit.

avrdude-5.10-2.fc13.x86_64
avr-gcc-c++-4.5.0-2.fc13.x86_64
avra-1.2.3-4.fc13.x86_64
avr-gcc-4.5.0-2.fc13.x86_64
avr-binutils-2.20-2.fc13.x86_64
avr-libc-1.6.7-2.fc13.noarch
avr-gdb-7.1-1.fc13.x86_64


[r...@george george]# avr-g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/avr-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.5.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls
--disable-libssp --with-system-zlib --enable-version-specific-runtime-libs
--with-pkgversion='Fedora 4.5.0-2.fc13'
--with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 4.5.0 (Fedora 4.5.0-2.fc13) 
[r...@george george]# 

If I downgrade to:

avr-gcc-c++-4.3.3-2.fc11.x86_64
avr-gcc-4.3.3-2.fc11.x86_64

Everything works fine!


-- 

Dr dot diesel at gmail dot com changed:

   What|Removed |Added

 CC||Dr dot diesel at gmail dot
   ||com


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

[Bug fortran/44957] generic procedure name not included in symbol table

[kargl at gcc dot gnu dot org]

--- Comment #11 from kargl at gcc dot gnu dot org  2010-07-16 19:46 ---
Closing as WONTFIX.  With trunk being for active development
and 4.4 and 4.5 under maintenance commits, I doubt anyone 
will find time to investigate this further.

Thanks for the bug report.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[redi at gcc dot gnu dot org]

--- Comment #6 from redi at gcc dot gnu dot org  2010-07-16 20:33 ---
what resolution? this bug has no resolution, it's been suspended until we know
what the C++ committee decide to do about DR 1334.  The proposed resolution to
DR 1334 would solve the problem with rope.


-- 


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

[Bug c++/32505] Partial specialization halfway accepted after instantiation

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2010-07-16 21:05 ---
Subject: Bug 32505

Author: jason
Date: Fri Jul 16 21:05:16 2010
New Revision: 162269

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162269
Log:
PR c++/32505
* pt.c (process_partial_specialization): Diagnose partial
specialization after instantiation.
(most_specialized_class): Add complain parm.

Added:
trunk/gcc/testsuite/g++.dg/template/partial8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-07-16 21:37 
---
Yes, it's considered super-legacy vs hash_map, for example, which is just
legacy. The criterion is very simple: we are missing active maintainers. Just
for your information, I'm the one who voted for keeping it in the past, because
several times other library maintainers were tempted to simply remove it
completely from v3 for that reason. It will slowly rot, will not include new
ideas which are being included in all the other containers, will not be tested
in less common targets, the performance will deteriorate (because, for example,
if nobody really knows the details of the implementation, the bits having to do
will concurrency will just use slow locks even when not strictly necessary).
Thus, if you, or somebody else you are in contact with, really like it, please
consider investing time to study its internals and help maintaining it.

That said, this specific issue is just an example of LWG 1334, which is about
proxy iterators much more generally.


-- 


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

[Bug lto/44965] New: lto option code breaks file format with each added option

[andi-gcc at firstfloor dot org]

Had the following problem happen:

Create a LTO build of a program with a gcc git checkout
Update to a slightly newer checkout
The new checkout had one option in fortran more added
Continue compiling the program without make clean with the new compiler
LTO link failed with this assert failing:

392 else if (o->type == CL_COMMON) 
393gcc_assert (option->flag_var);

I think what happened is that the lto-opts code wrote the option
indexes into the object files and with the compiler update and the
new option they all shifted and become different. In my case the assert
happened
because it was trying to set a fortran specific option in a C
build.

There's some version checking in the lto-opts code

memset (&header, 0, sizeof (header));
  header.lto_header.major_version = LTO_major_version;
  header.lto_header.minor_version = LTO_minor_version;
  header.lto_header.section_type = LTO_section_opts;

but LTO_major/minor seems to be always just 1/0, so of course
didn't catch this.


-- 
   Summary: lto option code breaks file format with each added
option
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux


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

[Bug lto/44965] lto option code breaks file format with each added option

[andi-gcc at firstfloor dot org]

--- Comment #1 from andi-gcc at firstfloor dot org  2010-07-16 23:07 ---
One way to solve this would be to use a hash of the option table as a version
number.


-- 


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

[Bug bootstrap/44905] --enable-build-with-cxx bootstrap failure compiling gcc/cppdefault.c

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-07-16 
23:13 ---
According to Le-Chun Wu, the commit...

Author: davidxl
Date: Wed Apr 28 17:41:31 2010
New Revision: 158835

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158835
Log:
predicate aware uninitialized analysis

eliminates the need for Revision 155759 hack and it should be reverted.


-- 


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

[Bug lto/44966] New: weak LTO with gold causes ICE in lto_symtab_merge_decls_1

[andi-gcc at firstfloor dot org]

With the attached test case which tests WHOPR with weak aliases 
I get a segfault in lto_symtab_merge_decls_1 line 758

This happens in

  if (prevailing->node->same_body_alias)
prevailing->node->same_body->local.used_from_object_file = true;
  else
prevailing->node->local.used_from_object_file = true;

because node is NULL

Interestingly this only happens with gold, if I drop -fuse-linker-plugin
there is no segfault

This is an extract of a failure that occurred while buidling a much larger
project.


-- 
   Summary: weak LTO with gold causes ICE in
lto_symtab_merge_decls_1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug lto/44966] weak LTO with gold causes ICE in lto_symtab_merge_decls_1

[andi-gcc at firstfloor dot org]

--- Comment #1 from andi-gcc at firstfloor dot org  2010-07-16 23:23 ---
Created an attachment (id=21228)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21228&action=view)
test case


-- 


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

[Bug target/42235] redundant memory move from parameter space to spill space

[bernds at gcc dot gnu dot org]

--- Comment #5 from bernds at gcc dot gnu dot org  2010-07-16 23:48 ---
Subject: Bug 42235

Author: bernds
Date: Fri Jul 16 23:47:46 2010
New Revision: 162270

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162270
Log:
PR target/42235
* postreload.c (reload_cse_move2add): Return bool, true if anything.
changed.  All callers changed.
(move2add_use_add2_insn): Likewise.
(move2add_use_add3_insn): Likewise.
(reload_cse_regs): If reload_cse_move2add changed anything, rerun
reload_combine.
(RELOAD_COMBINE_MAX_USES): Bump to 16.
(last_jump_ruid): New static variable.
(struct reg_use): New members CONTAINING_MEM and RUID.
(reg_state): New members ALL_OFFSETS_MATCH and REAL_STORE_RUID.
(reload_combine_split_one_ruid, reload_combine_split_ruids,
reload_combine_purge_insn_uses, reload_combine_closest_single_use
reload_combine_purge_reg_uses_after_ruid,
reload_combine_recognize_const_pattern): New static functions.
(reload_combine_recognize_pattern): Verify that ALL_OFFSETS_MATCH
is true for our reg and that we have available index regs.
(reload_combine_note_use): New args RUID and CONTAINING_MEM.  All
callers changed.  Use them to initialize fields in struct reg_use.
(reload_combine): Initialize last_jump_ruid.  Be careful when to
take PREV_INSN of the scanned insn.  Update REAL_STORE_RUID fields.
Call reload_combine_recognize_const_pattern.
(reload_combine_note_store): Update REAL_STORE_RUID field.

* gcc.target/arm/pr42235.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr42235.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44967] New: [C++0x] decltype of method call dependand on pack expansion crashes

[piotr dot rak at gmail dot com]

cat has_construct.cc && g++-trunk -v -std=c++0x has_construct.cc
#include 

template
struct has_construct
{
typedef char one;
typedef struct {char _m[2]; } two;

template
static decltype(std::declval().construct(std::declval(),
std::declval()...), one()) test(int);
template
static two test(...);

static const bool value = sizeof(test(0)) == 1;
};


class A0
{};

class A1
{
void construct(int*, int);
};

template
struct A2
{
  template
  void construct(_Tp1*, _Args&&...) {}
};


void foo()
{
static bool a0 = has_construct::value; // ok
static bool a1 = has_construct::value; // bang
static bool a2 = has_construct, int>::value; // bang
}

Using built-in specs.
COLLECT_GCC=/home/prak/Dev/gcc-install/bin/g++-trunk
COLLECT_LTO_WRAPPER=/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --prefix=/home/prak/Dev/gcc-install --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100716 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
 /home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet
-v -D_GNU_SOURCE has_construct.cc -quiet -dumpbase has_construct.cc
-mtune=generic -march=pentiumpro -auxbase has_construct -std=c++0x -version -o
/tmp/ccY4xmeE.s
GNU C++ (GCC) version 4.6.0 20100716 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /home/prak/Dev/gcc-install/include
 /home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include
 /home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20100716 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6d1c47967936e3e68fa845533411d5d9
has_construct.cc: In instantiation of ‘const bool has_construct::value’:
has_construct.cc:37:51:   instantiated from here
has_construct.cc:14:67: internal compiler error: Naruszenie ochrony pamiêci
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Same with released 4.5.0


-- 
   Summary: [C++0x] decltype of method call dependand on pack
expansion crashes
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot rak at gmail dot com


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

[Bug c++/44967] [C++0x] decltype of method call dependand on pack expansion crashes

[piotr dot rak at gmail dot com]

--- Comment #1 from piotr dot rak at gmail dot com  2010-07-16 23:49 ---
Created an attachment (id=21229)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21229&action=view)
Testcase


-- 


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

[Bug plugins/44968] New: structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[ehren dot m at gmail dot com]

For the dehydra plugin, we unfortunately have to delay processing certain types
until after their completion (see
http://hg.mozilla.org/rewriting-and-analysis/dehydra/file/1248fd227e7f/dehydra_plugin.c#l426).

We do this by saving the types in a vector and then processing them during
PLUGIN_FINISH_UNIT. I've created a minimal plugin which, when used to compile
sqlite3, demonstrates that a number of types have been mangled by this point.
Could they have been GCed?

Perhaps it's not safe to save types in this manner but it's strange that
sqlite3.c is the only file in the mozilla code base that causes this problem.

gcc version (4.5 branch tip):

Using built-in specs.
COLLECT_GCC=/home/ehren/gcc4.5/dist-4_5-branch/bin/gcc
COLLECT_LTO_WRAPPER=/home/ehren/gcc4.5/dist-4_5-branch/libexec/gcc/x86_64-unknown-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_5-branch/configure --enable-checking
--disable-bootstrap CFLAGS='-g3 -O0' --enable-languages=c,c++
--enable-__cxa_atexit --disable-multilib
--prefix=/home/ehren/gcc4.5/dist-4_5-branch/ : (reconfigured)
../gcc-4_5-branch/configure --enable-checking --disable-bootstrap CFLAGS='-g3
-O0' --enable-languages=c,c++ --enable-__cxa_atexit --disable-multilib
--prefix=/home/ehren/gcc4.5/dist-4_5-branch/
Thread model: posix
gcc version 4.5.1 20100713 (prerelease) (GCC)

(I'll attach the plugin, sqlite3.i, and the plugin's output)


-- 
   Summary: structs saved (in a vector) during PLUGIN_FINISH_TYPE
are mangled by the time of PLUGIN_FINISH_UNIT
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ehren dot m at gmail dot com


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

[Bug lto/44965] lto option code breaks file format with each added option

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-07-16 23:52 ---
Really it is kinda expected that for development versions, lto file format is
going to be unstable.  Now crashing is not the right thing to do.  Doing a hash
is not going to work either I think.  


-- 


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

[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[ehren dot m at gmail dot com]

--- Comment #1 from ehren dot m at gmail dot com  2010-07-16 23:53 ---
Created an attachment (id=21230)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21230&action=view)
plugin


-- 


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

[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[ehren dot m at gmail dot com]

--- Comment #2 from ehren dot m at gmail dot com  2010-07-16 23:55 ---
Created an attachment (id=21231)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21231&action=view)
test code (sqlite3)


-- 


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

[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[ehren dot m at gmail dot com]

--- Comment #3 from ehren dot m at gmail dot com  2010-07-16 23:57 ---
Created an attachment (id=21232)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21232&action=view)
plugin output

in particular, look at the series of RECORD_TYPES beginning with #511.
Interestingly, their definitions are all embedded in other structs.


-- 


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

[Bug lto/44965] lto option code breaks file format with each added option

[andi-gcc at firstfloor dot org]

--- Comment #3 from andi-gcc at firstfloor dot org  2010-07-16 23:58 ---
It's not only development versions, options can change between minor releases
Also I don't think LTO_major/minor is always increased anyways.

Why should a hash over the option table not work?


-- 


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

[Bug libstdc++/44969] New: [C++0x] std::is_constructible broken for fundamental types.

[piotr dot rak at gmail dot com]

cat is_constructible_bug.cc && g++-trunk -v -c -std=c++0x
is_constructible_bug.cc 
#include 

class allocator_arg_t {};

class A {};

// From n3092: [allocator.uses.construction] 20.9.2.2 p1.2
//  (2nd part of condition, in FCD use case first part never true)
template 
struct alloc_arg_1st : 
std::is_constructible
{
};

bool foo()
{
struct B {};
bool val = alloc_arg_1st::value;// ok
return val || alloc_arg_1st::value; // bang
}
Using built-in specs.
COLLECT_GCC=/home/prak/Dev/gcc-install/bin/g++-trunk
COLLECT_LTO_WRAPPER=/home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc.git/configure --enable-languages=c,c++
--program-suffix=-trunk --prefix=/home/prak/Dev/gcc-install --disable-bootstrap
Thread model: posix
gcc version 4.6.0 20100716 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-std=c++0x' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
 /home/prak/Dev/gcc-install/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet
-v -D_GNU_SOURCE is_constructible_bug.cc -quiet -dumpbase
is_constructible_bug.cc -mtune=generic -march=pentiumpro -auxbase
is_constructible_bug -std=c++0x -version -o /tmp/ccocsKE0.s
GNU C++ (GCC) version 4.6.0 20100716 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu

/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /home/prak/Dev/gcc-install/include
 /home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include
 /home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20100716 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.4, GMP version 4.3.2, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 6d1c47967936e3e68fa845533411d5d9
In file included from is_constructible_bug.cc:1:0:
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:
In instantiation of ‘const bool std::__is_constructible_helper::__value’:
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:231:12:
  instantiated from ‘std::is_constructible’
is_constructible_bug.cc:10:8:   instantiated from ‘alloc_arg_1st’
is_constructible_bug.cc:19:40:   instantiated from here
/home/prak/Dev/gcc-install/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/type_traits:209:71:
error: expression list treated as compound expression in functional cast
[-fpermissive]


-- 
   Summary: [C++0x]  std::is_constructible broken for
fundamental types.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot rak at gmail dot com


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

[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-07-17 00:03 ---
>Could they have been GCed?

Most likely yes.  easy way to find out is to configure with valgrind checking
and run valgrind over cc1plus with your plugin loaded.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/44969] [C++0x] std::is_constructible broken for fundamental types.

[piotr dot rak at gmail dot com]

--- Comment #1 from piotr dot rak at gmail dot com  2010-07-17 00:03 ---
Created an attachment (id=21233)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21233&action=view)
Testcase


-- 


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

[Bug lto/44965] lto option code breaks file format with each added option

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-07-17 00:04 ---
(In reply to comment #3)
> It's not only development versions, options can change between minor releases
> Also I don't think LTO_major/minor is always increased anyways.

I think we should just store out the GCC version.


-- 


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

[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-07-17 00:08 ---
Oh one more thing, bugzilla is not the right form for help debugging plugins
really.


-- 


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

[Bug c++/44967] [C++0x] decltype of method call dependand on pack expansion crashes

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-07-17 00:21:40
   date||


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

[Bug libstdc++/44969] [C++0x] std::is_constructible broken for fundamental types.

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-07-17 00:56 
---
I don't think this is a library issue, the implementation is straightforward.
The below C++03 snippet already shows the problem, is rejected (ICC likes it).

Jason, can you have a look to this one too?



template struct enable_if { typedef T type; };
template struct enable_if { };

template
  class mini_is_constructible
  {
typedef char one;
typedef struct { char arr[2]; } two;

template
  static typename
  enable_if<(sizeof(Tp1(Arg1_(), Arg2_()), 1) > 0), one>::type
  test(int);

template
  static two test(...);

  public:
static const bool value = sizeof(test(0)) == 1;
  };

class A { };

int Test[mini_is_constructible::value ? -1 : 1];


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

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

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 162270:

http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00624.html

caused:

make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/dwarf2out.o differs
gcc/i386.o differs
gcc/java/expr.o differs
gcc/reload.o differs
gcc/reg-stack.o differs
gcc/recog.o differs
libiberty/hashtab.o differs
make[5]: *** [compare] Error 1

On Linux/x86-64, it caused:

FAIL: gcc.c-torture/execute/nest-stdar-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/nest-stdar-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O1
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/pr44575.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/pr44575.c execution,  -Os
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O1
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-3.c execution,  -Os
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O1
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 -flto
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O2 -fwhopr
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-4.c execution,  -Os
FAIL: gcc.c-torture/execute/va-arg-26.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/va-arg-26.c execution,  -O3 -g
FAIL: gcc.target/i386/amd64-abi-5.c execution test
FAIL: gcc.target/i386/vararg-3.c execution test
FAIL: gcc.target/i386/vararg-7.c execution test


-- 
   Summary: [4.6 regression] Revision 162270 failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
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=44970

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

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug c++/32505] Partial specialization halfway accepted after instantiation

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-07-17 04:13 ---
Fixed for 4.6.


-- 

jason 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=32505