[Bug libstdc++/52476] New: [C++11] Unordered multimap reorders equivalent elements

[daniel.kruegler at googlemail dot com]

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

 Bug #: 52476
   Summary: [C++11] Unordered multimap reorders equivalent
elements
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


gcc 4.7.0 20120225 (experimental) and also gcc 4.6.3 perform reordering of
equivalent elements of unordered_multimap in violation of the standard
specification.

Testcase:

//-
#include 
#include 

void printHashTable(const std::unordered_multimap& map)
{
  for (unsigned i = 0; i < map.bucket_count(); ++i) {
std::cout << "b[" << i << "]:" << std::endl;
for (auto it = map.begin(i); it != map.end(i); ++it) {
  std::cout << "   " << map.hash_function()(it->first) << " ["
<< it->first << "," << it->second << "]" << std::endl;
}
  }
  std::cout << "--" << std::endl;
}

int main()
{
  std::unordered_multimap dict = {
{0,0},
{1,0},
{2,0},
{3,0},
{4,0},
{1,1}
  };
  printHashTable(dict);

  dict.insert({{3,1},
   {3,2},
   {5,0}
  });
  printHashTable(dict);

  dict.max_load_factor(0.5);
  printHashTable(dict);
}
//-

The observed output is:

//-
b[0]:
   0 [0,0]
b[1]:
   1 [1,1]
   1 [1,0]
b[2]:
   2 [2,0]
b[3]:
   3 [3,0]
b[4]:
   4 [4,0]
b[5]:
b[6]:
--
b[0]:
   0 [0,0]
b[1]:
   1 [1,0]
   1 [1,1]
b[2]:
   2 [2,0]
b[3]:
   3 [3,2]
   3 [3,1]
   3 [3,0]
b[4]:
   4 [4,0]
b[5]:
   5 [5,0]
b[6]:
b[7]:
b[8]:
b[9]:
b[10]:
--
b[0]:
   0 [0,0]
b[1]:
   1 [1,1]
   1 [1,0]
b[2]:
   2 [2,0]
b[3]:
   3 [3,0]
   3 [3,1]
   3 [3,2]
b[4]:
   4 [4,0]
b[5]:
   5 [5,0]
b[6]:
b[7]:
b[8]:
b[9]:
b[10]:
b[11]:
b[12]:
b[13]:
b[14]:
b[15]:
b[16]:
b[17]:
b[18]:
b[19]:
b[20]:
b[21]:
b[22]:
b[23]:
b[24]:
b[25]:
b[26]:
b[27]:
b[28]:
--
//-

The relevant library constraints are described in [unord.req] p6:

"Mutating operations on unordered containers shall preserve the relative order
of elements within each equivalent-key group unless otherwise specified."

and in [unord.req] p9:

"For unordered_multiset and unordered_multimap, rehashing preserves the
relative ordering of equivalent elements."

The actual defects in above output are the following:

1) The second output should not reorder

   1 [1,1]
   1 [1,0]

to

   1 [1,0]
   1 [1,1]

2) The third output should not reorder

   1 [1,0]
   1 [1,1]

to

   1 [1,1]
   1 [1,0]

and it should not reorder

   3 [3,2]
   3 [3,1]
   3 [3,0]

to

   3 [3,0]
   3 [3,1]
   3 [3,2]

[Bug libstdc++/52476] [C++11] Unordered multimap reorders equivalent elements

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-04
 CC||fdumont at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-03-04 
11:28:05 UTC ---
Thanks a lot Daniel. Thus I suspect the issue may be very old, maybe even
dating back to the tr1 code (we should double check that by avoiding any use of
fancy C++11 features like initializer lists in the testcase), because, if I
remember correctly, up to 4.7 we changed minor details as regards the core
algorithms.

Time to fix it!

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com,
   ||jwakely.gcc at gmail dot
   ||com

--- Comment #13 from Paolo Carlini  2012-03-04 
11:32:02 UTC ---
Thus, since we do have indeed sfinae-friendly iterator-traits, I mean to
consistently deply something like the below in all the relevant places. Even
better ideas? Speak now or remain silent forever ;)

Index: include/bits/stl_deque.h
===
--- include/bits/stl_deque.h(revision 184879)
+++ include/bits/stl_deque.h(working copy)
@@ -888,6 +888,20 @@
*  input iterators are used, then this will do at most 2N calls to the
*  copy constructor, and logN memory reallocations.
*/
+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+  template::iterator_category,
+input_iterator_tag>::value>::type>
+deque(_InputIterator __first, _InputIterator __last,
+ const allocator_type& __a = allocator_type())
+   : _Base(__a)
+{
+ typedef typename iterator_traits<_InputIterator>::
+   iterator_category _IterCategory;
+ _M_range_initialize(__first, __last, _IterCategory());
+   }
+#else
   template
 deque(_InputIterator __first, _InputIterator __last,
  const allocator_type& __a = allocator_type())
@@ -897,6 +911,7 @@
  typedef typename std::__is_integer<_InputIterator>::__type _Integral;
  _M_initialize_dispatch(__first, __last, _Integral());
}
+#endif

   /**
*  The dtor only erases the elements, and note that if the elements

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2012-03-04 
11:39:29 UTC ---
Well, besides wrapping the thing in an __is_input_iterator helper.

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2012-03-04 
12:00:52 UTC ---
(In reply to comment #14)
> Well, besides wrapping the thing in an __is_input_iterator helper.

That's what I was going to suggest, possibly using an alias template:

+#ifdef __GXX_EXPERIMENTAL_CXX0X__
+  private:
+  template
+using _RequireInputerIter = typename
+  enable_if::iterator_category,
+input_iterator_tag>::value>::type;
+
+  public:
+  template>
+deque(_InputIterator __first, _InputIterator __last,
+ const allocator_type& __a = allocator_type())
+   : _Base(__a)
+{
+ typedef typename iterator_traits<_InputIterator>::
+   iterator_category _IterCategory;
+ _M_range_initialize(__first, __last, _IterCategory());
+   }
+#else

[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp

[redi at gcc dot gnu.org]

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

--- Comment #35 from Jonathan Wakely  2012-03-04 
12:05:13 UTC ---
Benjamin, should this be closed as fixed for 4.7?

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2012-03-04 
12:49:27 UTC ---
Author: redi
Date: Sun Mar  4 12:49:22 2012
New Revision: 184880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184880
Log:
PR libstdc++/52433
* include/debug/safe_iterator.h (_Safe_iterator): Add move
constructor and move assignment operator.
* testsuite/23_containers/vector/debug/52433.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/52433.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/safe_iterator.h

[Bug c++/52477] New: Wrong initialization order? __attribute__((constructor)) vs static data access

[przemoc at gmail dot com]

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

 Bug #: 52477
   Summary: Wrong initialization order?
__attribute__((constructor)) vs static data access
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: prze...@gmail.com


Created attachment 26821
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26821
Short exemplary code showing the problem

Attached file compiles flawlessly on 4.7.0, but the output binary segfaults.
Works fine in 4.6.2 though (as expected).

Looks like a serious regression.

g++-4.7 (GCC) 4.7.0 20120304 (prerelease)
built on debian wheezy x64 with:
--enable-languages=c,c++ --prefix=/opt/gcc-4.7 --program-suffix=-4.7

svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch@184878

[Bug middle-end/52478] New: -ftrapv calls the wrong functions in libgcc

[burnus at gcc dot gnu.org]

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

 Bug #: 52478
   Summary: -ftrapv calls the wrong functions in libgcc
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


As PR 19020 has been closed ("let's ditch antiquated stuff and start afresh") -
open a fresh bug.


Using -ftrapv works with i368-gnu-linux:

$ gcc -m32 -ftrapv hjfff.c && ./a.out
Aborted (core dumped)
$

But not on x86-64-gnu-linux:
$ gcc -m64 -ftrapv hjfff.c && ./a.out
$


In the debugger, one sees:

a) i386:

__addvsi3 (a=2147483647, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:79
(gdb) pt a
type = int


b) x86-64:

(gdb)
__addvdi3 (a=2147483647, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:82
(gdb) pt a
type = long int

Thus, there is no overflow in that function.


THUS: On i386 it calls the correct function but on x86-64 it should call the SI
not the DI function.

 * * *

For long/LONG_MAX, one has again:

a) -m32

__addvsi3 (a=2147483647, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:79
79  {
(gdb) pt a
type = int

b) -m64

__addvdi3 (a=9223372036854775807, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:82
82if (b >= 0 ? w < a : w > a)
(gdb) pt a
type = long int


THUS: x86-64 calls correctly the DI function but i386 wrongly the SI function

 * * *

long long / LLONG_MAX:

a) -m32:

__addvdi3 (a=9223372036854775807, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:82
82if (b >= 0 ? w < a : w > a)
(gdb) pt a
type = long int

b) -m64

__addvdi3 (a=9223372036854775807, b=1) at
/home/tob/projects/gcc-trunk-checkout/libgcc/libgcc2.c:82
82if (b >= 0 ? w < a : w > a)
(gdb) pt a  
type = long int


THUS: Both x86-64 and i386 call the "long int" instead of the "long long"
function. I had exepected a TI version, which does not seem to exist.

 * * *


#include 

int __attribute__((noinline))
iaddv (int a, int b)
{
  return a + b;
}

int main(void)
{
  return iaddv (INT_MAX, 1);
}

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2012-03-04 
12:58:51 UTC ---
Great. Only, I guess we want the alias somewhere out of class, we are going to
use it a lot, for the debug mode containers too.

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.8.0
   Target Milestone|--- |4.6.4

--- Comment #10 from Jonathan Wakely  2012-03-04 
12:59:33 UTC ---
Fixed on trunk so far.

I realised swapping isn't actually very simple, because the iterators need to
be unlinked/relinked into their container's lists so I just implemented it with
_M_attach and _M_detach instead.

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2012-03-04 
13:06:40 UTC ---
Probably better, yes.  As aliases are cheaper to instantiate than templates it
shouldn't affect compilation time or binary size to repeat it in each
container, but defining it only once would be easier to maintain.

[Bug target/52479] New: SH Target: SH4A DFmode fsca tests failing

[olegendo at gcc dot gnu.org]

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

 Bug #: 52479
   Summary: SH Target: SH4A DFmode fsca tests failing
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: kkoj...@gcc.gnu.org
Target: sh4a-*-*


As of rev 184877 the following SH4A target tests are failing:

gcc.target/sh/sh4a-cos.c scan-assembler fsca
gcc.target/sh/sh4a-sin.c scan-assembler fsca
gcc.target/sh/sh4a-sincos.c scan-assembler-times fsca 1

These tests check whether the fsca instruction is used for DFmode standard sin
and cos functions when -ffast-math is specified. 

While using fsca for SFmode and -ffast-math makes sense, for DFmode I think the
results might be too imprecise.  I would like to propose to remove the DFmode
fsca code altogether.


Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.8.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.8.0 20120304 (experimental) (GCC)

[Bug target/52480] New: SH Target: SH4A movua.l does not work for big endian

[olegendo at gcc dot gnu.org]

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

 Bug #: 52480
   Summary: SH Target: SH4A movua.l does not work for big endian
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: kkoj...@gcc.gnu.org
Target: sh4a-*-*


As of rev 184877 the following SH4A target test is failing:

gcc.target/sh/sh4a-bitmovua.c scan-assembler-times movua.l 6

The test checks the usage of SH4A's movua.l instruction for loading unaligned
SImode values.  While the movual.l instruction is generated for little endian,
it is not generated for big endian.

Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.8.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.8.0 20120304 (experimental) (GCC)

[Bug target/52479] SH Target: SH4A DFmode fsca tests failing

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Kazumoto Kojima  2012-03-04 
13:46:58 UTC ---
I'd like to add Alex to the CC list.  Alex, what do you think?

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||pluto at agmk dot net

--- Comment #1 from Pawel Sikora  2012-03-04 13:54:09 
UTC ---
looks like .init_array vs. .ctors problem.

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[pluto at agmk dot net]

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

--- Comment #2 from Pawel Sikora  2012-03-04 14:16:29 
UTC ---
you should specify explicit initialization order to avoid gpf, e.g.:

static std::map m __attribute__((init_priority(101)));
static void insert() __attribute__((constructor(102)));

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[przemoc at gmail dot com]

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

--- Comment #3 from Przemysław Pawełczyk  2012-03-04 
14:24:10 UTC ---
Thanks for solution, but...

Isn't such order obvious or isn't it at least the most widely used one? I mean
that by default static data initialization should precede
constructor-functions, no? It worked in gcc 4.6 and is there any good reason to
break it?

[Bug fortran/36160] show_locus doesn't deal well with wide characters

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert  
2012-03-04 14:36:03 UTC ---
Author: fxcoudert
Date: Sun Mar  4 14:35:56 2012
New Revision: 184884

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184884
Log:
PR fortran/36160
* error.c (gfc_widechar_display_length, gfc_wide_display_length):
New functions.
(print_wide_char_into_buffer): Return length written.
(show_locus): Fix locus displayed when wide characters are present.

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

[Bug fortran/36160] show_locus doesn't deal well with wide characters

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Francois-Xavier Coudert  
2012-03-04 14:38:30 UTC ---
Fixed.

[Bug libstdc++/52476] [C++11] Unordered multimap reorders equivalent elements

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  
2012-03-04 16:10:19 UTC ---
(In reply to comment #1)
> (we should double check that by avoiding any use of
> fancy C++11 features like initializer lists in the testcase)

I rewrote the testcase in C++03 form and based on TR1 unordered map:

//--
#include 
#include 
#include 

typedef std::tr1::unordered_multimap map_type;

void printHashTable(const map_type& map)
{
  for (unsigned i = 0; i < map.bucket_count(); ++i) {
std::cout << "b[" << i << "]:" << std::endl;
for (map_type::const_local_iterator it = map.begin(i); it != map.end(i);
++it) {
  std::cout << "   " << map.hash_function()(it->first) << " ["
<< it->first << "," << it->second << "]" << std::endl;
}
  }
  std::cout << "--" << std::endl;
}

int main()
{
  typedef std::pair P;
  const P input1[] = {
P(0,0),
P(1,0),
P(2,0),
P(3,0),
P(4,0),
P(1,1)
  };
  map_type dict(input1, input1 + sizeof(input1)/sizeof(input1[0]));
  printHashTable(dict);

  const P input2[] = {
P(3,1),
P(3,2),
P(5,0)
  };
  dict.insert(input2, input2 + sizeof(input2)/sizeof(input2[0]));
  printHashTable(dict);

  dict.max_load_factor(0.5);
  printHashTable(dict);
}
//--

The incorrect runtime behaviour is unchanged compared to the original form.
This means, one could actually remove the [C++11] tag from the bug title.

[Bug target/52408] Incorrect assembler generated for zvdep_imm64

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin  2012-03-04 
16:23:39 UTC ---
Author: danglin
Date: Sun Mar  4 16:23:26 2012
New Revision: 184888

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184888
Log:
Backport from mainline
2012-03-01  John David Anglin  

PR target/52408
* config/pa/pa.md (zvdep_imm32): Change type of variable x from int to
unsigned HOST_WIDE_INT.
(zvdep_imm64): Likewise.
(vdepi_ior): Change type of variable x from int to HOST_WIDE_INT.
(vdepi_and): Likewise.
Likewise for unamed 64-bit patterns.
* config/pa/predicates.md (lhs_lshift_cint_operand): Update comment.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/pa/pa.md
branches/gcc-4_6-branch/gcc/config/pa/predicates.md

[Bug libstdc++/52476] [C++11] Unordered multimap reorders equivalent elements

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-03-04 16:28:02 UTC ---
(In reply to comment #2)
> This means, one could actually remove the [C++11] tag from the bug title.

I withdraw this suggestion: In TR1 (N1836) there did no exist the reordering
constraints, actually the new constraint were added with:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#518

[Bug target/52408] Incorrect assembler generated for zvdep_imm64

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  2012-03-04 
17:17:18 UTC ---
Author: danglin
Date: Sun Mar  4 17:17:11 2012
New Revision: 184889

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184889
Log:
Backport from mainline
2012-03-01  John David Anglin  

PR target/52408
* config/pa/pa.md (zvdep_imm32): Change type of variable x from int to
unsigned HOST_WIDE_INT.
(zvdep_imm64): Likewise.
(vdepi_ior): Change type of variable x from int to HOST_WIDE_INT.
(vdepi_and): Likewise.
Likewise for unamed 64-bit patterns.
* config/pa/predicates.md (lhs_lshift_cint_operand): Update comment.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/pa/pa.md
branches/gcc-4_4-branch/gcc/config/pa/predicates.md

[Bug c++/52481] New: m68k-*: internal compiler error: in extract_insn, at recog.c:2123

[ralf_corsepius at rtems dot org]

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

 Bug #: 52481
   Summary: m68k-*: internal compiler error: in extract_insn, at
recog.c:2123
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ralf_corsep...@rtems.org
Target: m68k-rtems*


Bootstrapping gcc-4.7.0-RC-20120302 for m68k-rtems* fails with this error:
...
libtool: compile: 
/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/./gcc/xgcc
-shared-libgcc
-B/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/./gcc
-nostdinc++
-L/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/src
-L/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/src/.libs
-nostdinc
-B/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/newlib/
-isystem
/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/newlib/targ-include
-isystem
/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/newlib/libc/include
-B/opt/rtems-4.11/m68k-rtems4.11/bin/ -B/opt/rtems-4.11/m68k-rtems4.11/lib/
-isystem /opt/rtems-4.11/m68k-rtems4.11/include -isystem
/opt/rtems-4.11/m68k-rtems4.11/sys-include -mcpu=5206
-I/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/libstdc++-v3/../libgcc
-I/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/include/m68k-rtems4.11
-I/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/include
-I/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=compatibility-atomic-c++0x.lo -std=gnu++11 -g -O2 -mcpu=5206 -c
../../../../../../gcc-4.7.0-RC-20120302/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc
-o compatibility-atomic-c++0x.o
../../../../../../gcc-4.7.0-RC-20120302/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc:
In function 'bool
std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*,
std::memory_order)':
../../../../../../gcc-4.7.0-RC-20120302/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc:100:3:
error: unrecognizable insn:
(insn 11 10 12 3 (set (reg:QI 33 [ D.31990 ])
(neg:QI (reg:QI 33 [ D.31990 ])))
/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/include/bits/atomic_base.h:259
-1
 (nil))
../../../../../../gcc-4.7.0-RC-20120302/libstdc++-v3/src/c++11/compatibility-atomic-c++0x.cc:100:3:
internal compiler error: in extract_insn, at recog.c:2123
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[9]: *** [compatibility-atomic-c++0x.lo] Error 1
make[9]: *** Waiting for unfinished jobs
make[9]: Leaving directory
`/builddir/build/BUILD/rtems-4.11-m68k-rtems4.11-gcc-4.7.0/build/m68k-rtems4.11/m5206/libstdc++-v3/src/c++11'

Configuration:
CC='gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic'
../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11
--bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11
--includedir=/opt/rtems-4.11/include 
--libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec
--mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info
--datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=m68k-rtems4.11 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads --disable-lto
--disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-languages=c,c++

[Bug target/41557] gcc.exe: Internal error: (null) (program cc1plus)

[fabrizio.ge at tiscali dot it]

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

Fabrizio Gennari  changed:

   What|Removed |Added

 CC||fabrizio.ge at tiscali dot
   ||it

--- Comment #1 from Fabrizio Gennari  2012-03-04 
17:24:31 UTC ---
Just tried building gcc-4.6.3 as DJGPP cross-compiler running on Ubuntu, but
encountered a very similar bug to this one, only occurring in cc1 instead of
cc1plus.

The compiler builds fine, but then, when it has to compile libgcc, it
segfaults.

I tried running the compiler with a trivial C program (int main(){return 0;}).
It segfaults.

I tried to debug cc1 with gdb. The lines causing the crash are in c-common.c:
int16_type_node =
  TREE_TYPE (identifier_global_value (c_get_ident (INT16_TYPE)));

The call to identifier_global_value() returns NULL, and the pointer is
dereferenced by the macro TREE_TYPE, causing the crash.

This means that DJGPP cannot be used as a target with recent versions of gcc.
It may be little used nowadays, but, since it is not unsupported, it should
work.

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #26812|0   |1
is obsolete||

--- Comment #11 from Oleg Endo  2012-03-04 
17:24:44 UTC ---
Created attachment 26822
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26822
Proposed patch

This patch should be better now.
However, I'm not sure how well this will work with SH64 due to the (arbitrary)
TARGET_SH1 conditions in the insns.

[Bug libitm/52482] New: libitm INVALID MNEMONIC in .S (powerpc asm)

[fang at csl dot cornell.edu]

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

 Bug #: 52482
   Summary: libitm INVALID MNEMONIC in .S (powerpc asm)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@csl.cornell.edu
  Host: powerpc-apple-darwin8
Target: powerpc-apple-darwin8
 Build: powerpc-apple-darwin8


Created attachment 26823
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26823
RC1 entire build log

On powerpc-darwin8, with:
fang% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8
--target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)

h/w: dual 533 MHz G4
OS: 10.4.11

Using Jack Howarth's fink packaging for gcc-4.7.0-RC-20120302, slightly adapted
for darwin8:

configure:
../gcc-4.7.0-RC-20120302/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mand
ir=/sw/share/man --infodir=/sw/lib/gcc4.7/info
--enable-languages=c,c++,fortran,
lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw
-
-with-cloog=/sw --with-mpc=/sw --with-system-zlib
--x-includes=/usr/X11R6/includ
e --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7
--enable-cloog-backend=
isl --with-dwarf2 --disable-libjava-multilib --disable-libquadmath


gcc-4.7.0-RC1 (20120302) makes it all the way through stage 3 bootstrap
comparison, and then during libitm:

/bin/sh ./libtool   --mode=compile
/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1/
darwin_objdir/./gcc/xgcc
-B/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1/darwin_o
bjdir/./gcc/ -B/sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/
-B/sw/lib/gcc4.7/p
owerpc-apple-darwin8.11.0/lib/ -isystem
/sw/lib/gcc4.7/powerpc-apple-darwin8.11.
0/include -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/sys-include   
-DHA
VE_CONFIG_H -I. -I../../../gcc-4.7.0-RC-20120302/libitm 
-I../../../gcc-4.7.0-RC
-20120302/libitm/config/powerpc
-I../../../gcc-4.7.0-RC-20120302/libitm/config/p
osix -I../../../gcc-4.7.0-RC-20120302/libitm/config/generic
-I../../../gcc-4.7.0
-RC-20120302/libitm  -Wall -Werror  -Wc,-pthread -g -O2 -MT sjlj.lo -MD -MP -MF 
.deps/sjlj.Tpo -c -o sjlj.lo
../../../gcc-4.7.0-RC-20120302/libitm/config/powerp
c/sjlj.S
libtool: compile: 
/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1/darwin_objdir/./
gcc/xgcc -B/Volumes/Isolde/fink.build/gcc47-4.7.0-0.rc1/darwin_objdir/./gcc/
-B/
sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/bin/
-B/sw/lib/gcc4.7/powerpc-apple-dar
win8.11.0/lib/ -isystem /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/include
-isyst
em /sw/lib/gcc4.7/powerpc-apple-darwin8.11.0/sys-include -DHAVE_CONFIG_H -I.
-I.
./../../gcc-4.7.0-RC-20120302/libitm
-I../../../gcc-4.7.0-RC-20120302/libitm/con
fig/powerpc -I../../../gcc-4.7.0-RC-20120302/libitm/config/posix
-I../../../gcc-
4.7.0-RC-20120302/libitm/config/generic -I../../../gcc-4.7.0-RC-20120302/libitm 
-Wall -pthread -Werror -g -O2 -MT sjlj.lo -MD -MP -MF .deps/sjlj.Tpo -c
../../..
/gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S  -fno-common -DPIC -o
.libs/
sjlj.o
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:155:Invalid
mnemonic
 'FUNC'
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:250:Invalid
mnemonic
 'CALL'
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:259:Invalid
mnemonic
 'END'
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:262:Invalid
mnemonic
 'HIDDEN'
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:263:Invalid
mnemonic
 'FUNC'
../../../gcc-4.7.0-RC-20120302/libitm/config/powerpc/sjlj.S:407:Invalid
mnemonic
 'END'
make[4]: *** [sjlj.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libitm] Error 2
make[1]: *** Waiting for unfinished jobs

possibly continuation of PR 51031

[Bug target/52483] New: SH Target: Loads from volatile memory leave redundant sign/zero extensions

[olegendo at gcc dot gnu.org]

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

 Bug #: 52483
   Summary: SH Target: Loads from volatile memory leave redundant
sign/zero extensions
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*


The following cases seem to happen at any optimization level:

int test_0 (volatile char* x)
{
  return *x == 5;
}

mov.b   @r4,r0  ! 6 *extendqisi2_compact/2[length = 2]
exts.b  r0,r0   ! 7 *extendqisi2_compact/1[length = 2]
cmp/eq  #5,r0   ! 8 cmpeqsi_t/2[length = 2]
rts ! 27*return_i[length = 2]
movtr0  ! 14movsi_ie/10[length = 2]


int test_1 (volatile unsigned char* x)
{
  return *x == 0x80;
}

mov.b   @r4,r0! 6   *extendqisi2_compact/2[length = 2]
exts.b  r0,r0 ! 8   *extendqisi2_compact/1[length = 2]
cmp/eq  #-128,r0  ! 9   cmpeqsi_t/2[length = 2]
rts   ! 28  *return_i[length = 2]
movtr0  ! 15  movsi_ie/10[length = 2]


The same also happens for HImode.
Maybe a few peepholes would help here?

Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.8.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.8.0 20120304 (experimental) (GCC)

[Bug debug/47510] DW_TAG_typedef can have children when designating a naming typedef

[eu at doxos dot eu]

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

Václav Šmilauer  changed:

   What|Removed |Added

 CC||eu at doxos dot eu

--- Comment #16 from Václav Šmilauer  2012-03-04 18:30:15 
UTC ---
(In reply to comment #15)
> The same thing can happen for unions in c++11.
I am being hit by this bug in c++11, though I am not able to follow the whole
discussion. Can I get a concise summary on what kind of construct triggers the
problem so that I can work it around in my code? Stucts with default ctors
within unions? Thanks!

(Compiling gcc snapshot from 28/2/2012 now to see if it is still an issue).

[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from fabien at gcc dot gnu.org 2012-03-04 18:42:28 UTC ---
(In reply to comment #2)
> Yes, that's valid.  Fabien, can you take a look?

Yes, of course.

[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)

[fang at csl dot cornell.edu]

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

--- Comment #1 from David Fang  2012-03-04 
18:45:58 UTC ---
powerpc/sjlj.S contains:

#include "asmcfi.h"

#if defined(__powerpc64__) && defined(__ELF__)
...
#elif defined(__ELF__)
...
#elif defined(_CALL_DARWIN)
.macro FUNC name
.globl  _$0
_$0:
.endmacro
.macro END name
.endmacro
.macro HIDDEN name
.private_extern _$0
.endmacro
.macro CALL name
bl  _$0
.endmacro
# ifdef __ppc64__
.machine ppc64
# else
.machine ppc7400
# endif
#else
#error "unsupported system"
#endif

And I didn't see the "unsupported system" message, so maybe something's funky
with the asm macro definitions under _CALL_DARWIN?  Is there a particular
assembler or assembly-style that's assumed?

I have for /usr/bin/as:
Apple Computer, Inc. version cctools-622.9~2, GNU assembler version 1.38

[Bug fortran/43829] Scalarization of reductions

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||rajiv.adhikary at amd dot
   ||com

--- Comment #53 from Mikael Morin  2012-03-04 
19:13:53 UTC ---
*** Bug 36841 has been marked as a duplicate of this bug. ***

[Bug fortran/36841] Eliminate gfortran_sum_r8 call for calculation involving multidimensional array multiplication followed by a sum along first dimension

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|4.3.1   |4.7.0
 Resolution||DUPLICATE

--- Comment #10 from Mikael Morin  2012-03-04 
19:13:53 UTC ---
(In reply to comment #7)
> (In reply to comment #4)
> > (see pr43829)
> > 
> 
> I think it is a duplicate of (or close to) pr43829. 
> Marked as depending on it so that I don't forget it. 

This is fixed for the 4.7.0 version.
Closing.

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

[Bug target/52481] m68k-*: internal compiler error: in extract_insn, at recog.c:2123

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|m68k-rtems* |m68k-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-04
 CC||rth at gcc dot gnu.org
  Component|c++ |target
 Ever Confirmed|0   |1

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

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

--- Comment #12 from Pawel Sikora  2012-03-04 19:36:30 
UTC ---
with current 4.6.4 i've noticed a new undefined reference
during boost_rexeg.dll linking:

(...)
Creating library file:
bin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/libboost_regex.dll.abin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/cpp_regex_traits.o:
 In function
`boost::re_detail::cpp_regex_traits_base::imbue(std::__7::locale
const&)':
/home/users/pluto/buildenv/linux/x86_64-w64-mingw32/boost_1_49_0/./boost/regex/v4/cpp_regex_traits.hpp:216:
 undefined reference to `bool std::__7::has_facet
>(std::__7::locale const&)'


$ x86_64-w64-mingw32-objdump -t cpp_regex_traits.o|egrep
'_ZN.+has_facet.+messages'
[325](sec  0)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x
_ZNSt3__79has_facetINS_8messagesIcbRKNS_6localeE

i see a has_facet in symbols table:

$ x86_64-w64-mingw32-objdump -t libstdc++-7.dll|egrep
'_ZN.+has_facet.+messages'

[13096](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00093880
_ZNSt3__79has_facetINS_8messagesIcbRKNS_6localeE
[21476](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x000938e0
_ZNSt3__79has_facetINS_8messagesIwbRKNS_6localeE

but they aren't present in export-address-table. any ideas?

[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WORKSFORME

--- Comment #15 from Mikael Morin  2012-03-04 
19:47:27 UTC ---
Cannot reproduce anymore, even with -fno-whole-file.

[Bug rtl-optimization/52484] New: Wrong code from ce3 pass (deletes insn)

[gjl at gcc dot gnu.org]

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

 Bug #: 52484
   Summary: Wrong code from ce3 pass (deletes insn)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


The following code for AVR target that reads from address space __memx result
in wrong code:

long readx (const __memx long *p)
{
return *p;
}

== compile ==

$ avr-gcc flash.c -S -dp -Os -mmcu=avr51 -da

== configure ==

../../gcc.gnu.org/trunk/configure --target=avr --prefix=/gnu/install/gcc-4.7
--disable-nls --with-dwarf2 --enable-checking=yes,rtl --enable-languages=c,c++

GNU C (GCC) version 4.8.0 20120304 (experimental) (avr)

SVN 184887 from 2012-03-04

To see the bug RTL dumps will follow.

There is really bloaty code from lower-subreg that splits the 4-byte move into
4 individual byte moves. 

After pass .peephole2 there are 4 xload_qi_libgcc insns that perform these
moves.

After pass .ce3 one of these moves is gone, this is wrong because no byte must
be thrown away.

[Bug rtl-optimization/52484] Wrong code from ce3 pass (deletes insn)

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-04 
19:54:20 UTC ---
Created attachment 26824
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26824
flash.c.208r.peephole2

This dump looks ok: there are 4 xload_qi_libgcc insns.

peep2 did no optimizations except transform one 

(set (reg/f:PSI 12 r12 [58])
 (const_int 2 [0x2]))

to 

(parallel [(set (reg/f:PSI 12 r12 [58])
(const_int 2 [0x2]))
   (clobber (reg:QI 18 r18))])

which is ok (r18 is marked as dead above)

[Bug rtl-optimization/52484] Wrong code from ce3 pass (deletes insn)

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-03-04 
19:55:31 UTC ---
Created attachment 26825
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26825
flash.c.209r.ce3

One xload_qi_libgcc has been killed.

[Bug rtl-optimization/52484] Wrong code from ce3 pass (deletes insn)

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2012-03-04 
19:57:01 UTC ---
Created attachment 26826
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26826
flash.c

[Bug c++/52485] New: [c++11] add an option to disable c++11 user-defined literals

[eu at doxos dot eu]

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

 Bug #: 52485
   Summary: [c++11] add an option to disable c++11 user-defined
literals
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@doxos.eu


Some upstream code (e.g. #50917 for Mozilla, I have issues with Qt4's SLOT(...)
macros) is broken because of the support for c++11 literals in 4.7. In all
cases I've seen the cause was missing space between constructs like #define
FOO(a) "0"#a.

Sine this feature is little used, but lot of code, it would be reasonable to
provide a switch to disable user-defined literals, so that code which needs
c++11 but at the same time links to (technically broken) libs can be compiled,
until those libs get fixed upstream.

[Bug target/52481] m68k-*: internal compiler error: in extract_insn, at recog.c:2123

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2012-03-04 
21:01:28 UTC ---
Created attachment 26827
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26827
reduced test case in C

Depends on target CPU selection.  -mcpu=680[012346]0 and -mcpu=cpu32 all work,
but -mcpu=5206 (or apparently any other coldfire) ICEs.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

--- Comment #39 from Mikael Morin  2012-03-04 
21:05:36 UTC ---
Author: mikael
Date: Sun Mar  4 21:05:32 2012
New Revision: 184896

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184896
Log:
fortran/
PR fortran/50981
* trans-expr.c (gfc_conv_procedure_call): Save se->ss's value. 
Handle the case of unallocated arrays passed to elemental procedures.

testsuite/
PR fortran/50981
* gfortran.dg/elemental_optional_args_5.f03: Add array checks.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/elemental_optional_args_5.f03

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl at gcc dot gnu.org]

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

--- Comment #19 from hjl at gcc dot gnu.org  2012-03-04 
21:17:37 UTC ---
Author: hjl
Date: Sun Mar  4 21:17:34 2012
New Revision: 184898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184898
Log:
Update gcc.target/i386/pr52146.c to allow $-18874240

2012-03-04  H.J. Lu  

PR target/52146
* gcc.target/i386/pr52146.c: Update final-scan to allow $-18874240.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr52146.c

[Bug target/52408] Incorrect assembler generated for zvdep_imm64

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2012-03-04 
21:31:29 UTC ---
Author: danglin
Date: Sun Mar  4 21:31:25 2012
New Revision: 184902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184902
Log:
Backport from mainline
2012-03-01  John David Anglin  

PR target/52408
* config/pa/pa.md (zvdep_imm32): Change type of variable x from int to
unsigned HOST_WIDE_INT.
(zvdep_imm64): Likewise.
(vdepi_ior): Change type of variable x from int to HOST_WIDE_INT.
(vdepi_and): Likewise.
Likewise for unamed 64-bit patterns.
* config/pa/predicates.md (lhs_lshift_cint_operand): Update comment.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/pa/pa.md
branches/gcc-4_5-branch/gcc/config/pa/predicates.md

[Bug target/52408] Incorrect assembler generated for zvdep_imm64

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from John David Anglin  2012-03-04 
21:41:57 UTC ---
Fixed.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[mikael at gcc dot gnu.org]

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

--- Comment #40 from Mikael Morin  2012-03-04 
21:50:14 UTC ---
Author: mikael
Date: Sun Mar  4 21:50:08 2012
New Revision: 184904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184904
Log:
fortran/
PR fortran/50981
* gfortran.h (gfc_is_class_container_ref): New prototype.
* class.c (gfc_is_class_container_ref): New function.
* trans-expr.c (gfc_conv_procedure_call): Add a "_data" component
reference to polymorphic actual arguments.

testsuite/
PR fortran/50981
* gfortran.dg/elemental_optional_args_5.f03: Add subcomponent actual
argument checks.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/elemental_optional_args_5.f03

[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration

[fabien at gcc dot gnu.org]

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

--- Comment #4 from fabien at gcc dot gnu.org 2012-03-04 21:52:15 UTC ---
This is because some USING_DECLs are stored in IDENTIDIER_BINDINGs. Jason, do
you agree that cxx_binding->value and cxx_binding->type should not be
USING_DECLs ?

[Bug fortran/52475] option -imacros for fortran code is not supported

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-03-04 
22:01:15 UTC ---
Created attachment 26828
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26828
Draft patch

Confirmed. Attached a lightly tested draft patch. (There might be more -i*
flags missing.)

[Bug libstdc++/52486] New: money_put/money_get/moneypunct interpreting localeconv() result incorrectly and inserting/requiring an extra space

[jyasskin at gcc dot gnu.org]

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

 Bug #: 52486
   Summary: money_put/money_get/moneypunct interpreting
localeconv() result incorrectly and
inserting/requiring an extra space
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


Created attachment 26829
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26829
Test program to show monetary formatting results

The attached test program produces the following output with trunk gcc and
Ubuntu EGLIBC 2.13-20ubuntu5. Note that reading and writing values in the US
locale requires two spaces between "USD" and the currency value, and writes an
extra space when showbase is false (meaning the currency symbol should be
omitted). In the French locale, we're getting an extra space at the very end of
the output string.

I believe glibc is setting the locale data correctly for C11, and it matches
the example table in paragraph 10 of "7.11.2.1 The localeconv function". In C99
I think the normative wording was ambiguous, but the example table showed the
opposite value for int_*_sep_by_space. 

$ ~/src/gcc/install/bin/g++-4.8svn -Wall test.cc -o test && ./test en_US.UTF-8
Set locale to 'en_US.UTF-8'
lc->currency_symbol == '$'
lc->p_sep_by_space == 0
lc->n_sep_by_space == 0
lc->int_curr_symbol == 'USD '
lc->int_p_sep_by_space == 1
lc->int_n_sep_by_space == 1

'1.23' reads as: '0'
And advances the iterator from 0x227c028 to 0x227c028.
And leaves the stream in state failbit.

'USD 1.23' reads as: '0'
And advances the iterator from 0x227c028 to 0x227c02c.
And leaves the stream in state failbit.

'USD  1.23' reads as: '123'
And advances the iterator from 0x227c028 to 0x227c031.
And leaves the stream in state eofbit.

Testing 123:
!showbase: ' 1.23'; showbase: 'USD  1.23'
strfmon writes it/100 as: no-symbol: '1.23'; symbol: 'USD 1.23'

Testing -1:
!showbase: '- .01'; showbase: '-USD  .01'
strfmon writes it/100 as: no-symbol: '-0.01'; symbol: '-USD 0.01'
$ ~/src/gcc/install/bin/g++-4.8svn -Wall test.cc -o test && ./test fr_FR.UTF-8
Set locale to 'fr_FR.UTF-8'
lc->currency_symbol == '€'
lc->p_sep_by_space == 1
lc->n_sep_by_space == 1
lc->int_curr_symbol == 'EUR '
lc->int_p_sep_by_space == 1
lc->int_n_sep_by_space == 1

'1.23' reads as: '0'
And advances the iterator from 0x1c8f028 to 0x1c8f029.
And leaves the stream in state failbit.

'USD 1.23' reads as: '0'
And advances the iterator from 0x1c8f028 to 0x1c8f028.
And leaves the stream in state failbit.

'USD  1.23' reads as: '0'
And advances the iterator from 0x1c8f028 to 0x1c8f028.
And leaves the stream in state failbit.

Testing 123:
!showbase: '1,23 '; showbase: '1,23 EUR '
strfmon writes it/100 as: no-symbol: '1,23'; symbol: '1,23 EUR'

Testing -1:
!showbase: '-,01 '; showbase: '-,01 EUR '
strfmon writes it/100 as: no-symbol: '-0,01'; symbol: '-0,01 EUR'
jyasskin@abzu:~/tmp$

[Bug c++/52487] New: [4.6/4.7 Regression] [C++11] ICE at cp/semantics.c:5613 with lambda capturing reference to incomplete type by value

[hevanen at googlemail dot com]

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

 Bug #: 52487
   Summary: [4.6/4.7 Regression] [C++11] ICE at
cp/semantics.c:5613 with lambda capturing reference to
incomplete type by value
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: heva...@googlemail.com


The following code snippet causes an ICE:

struct A;
void foo(A& a)
{
  [=](){a;};
}

int main() {}


Confirmed with
gcc version 4.6.1 20110409 (prerelease) (Ubuntu 4.6.0-3~ppa1) and
GNU C++ (niXman build) version 4.7.0 20120203 (experimental) (i686-pc-mingw32)

The latter prints:
internal compiler error: in literal_type_p, at cp/semantics.c:5613

There is no ICE with this version:
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (x86_64-linux-gnu)
Instead, it prints the expected error message ("invalid use of incomplete type
‘struct A’").

[Bug fortran/52469] [4.6/4.7/4.8 Regression] Defining function pointer interface

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-04
 CC||burnus at gcc dot gnu.org
Summary|Defining function pointer   |[4.6/4.7/4.8 Regression]
   |interface   |Defining function pointer
   ||interface
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  2012-03-04 
22:37:59 UTC ---
The ICE appeared between 

gcc version 4.6.0 20100723 (experimental) [trunk revision 162456] (GCC) (OK)

and

gcc version 4.6.0 20100901 (experimental) [branch fortran-dev revision 163718]
(GCC)

[macbook] f90/bug% /opt/gcc/gcc4.6d/bin/gfortran pr52469.f90
pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:74:0: internal compiler error: in aggregate_value_p, at
function.c:1971

The error with the current trunk is

pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:74:0: internal compiler error: tree check: expected function_type
or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2437

and with revision 184852 configured with --enable-checking=release

pr52469.f90: In function 'test_proc_ptr':
pr52469.f90:60:0: error: non-function in gimple call
D.1883 = D.1882 (&C.1873);

pr52469.f90:60: confused by earlier errors, bailing out

[Bug bootstrap/52471] ICE bootstrapping GCC 4.7.0-20120302 on x86_64 OpenBSD

[kyle at arbyte dot us]

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

Kyle Markley  changed:

   What|Removed |Added

  Attachment #26819|0   |1
is obsolete||

--- Comment #1 from Kyle Markley  2012-03-04 22:39:07 
UTC ---
Created attachment 26830
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26830
minimized.i

Minimized .i file to provoke ICE

[Bug bootstrap/52471] ICE bootstrapping GCC 4.7.0-20120302 on x86_64 OpenBSD

[kyle at arbyte dot us]

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

Kyle Markley  changed:

   What|Removed |Added

  Known to work||4.6.2
  Known to fail||4.7.0

--- Comment #2 from Kyle Markley  2012-03-04 22:46:24 
UTC ---
I minimized the failing source; this command line provokes the ICE:
/storage/gcc470rc1/obj/./gcc/cc1 -fpreprocessed minimized.i -g

The ICE goes away if I remove the -g switch, or if I use cc1 from gcc 4.6.2. 
This ICE is unique to the bootstrapped cc1 for gcc 4.7.0.

[Bug c++/52485] [c++11] add an option to disable c++11 user-defined literals

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-03-04 
22:56:18 UTC ---
I think we should not have an option to disable user-defined literals at all. 
Since their code is not C++11, they should fix their code to be C++11 if they
use the -std=c++11/-std++0x option.

[Bug target/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net 2012-03-05 00:12:35 UTC ---
On 1-Mar-12, at 10:52 AM, rguenth at gcc dot gnu.org wrote:

> I think that's expected if your target does not provide a  
> movmisalign optab
> for whatever mode is used for
>
> typedef int v4si __attribute__((vector_size(16)));
>
> because of the ever-existing bug with misaligned stores on  
> STRICT_ALIGNMENT
> targets.
>
> Consider xfailing it.


I'm not convinced that implementing the movmisalign optab would fix  
the problem
without a major degradation in performance.  Sparc and mips also don't  
implement
movmisalign.

Structs are passed by reference on this target if they are larger than  
64 bits and
the reference is misaligned in this testcase.

So, I agree the test should be xfailed.

Dave
--
John David Anglindave.ang...@bell.net

[Bug ada/52280] FAIL: c974013 -- C974013 Abortable part did not execute

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net 2012-03-05 01:04:41 UTC ---
On 27-Feb-12, at 3:37 AM, ebotcazou at gcc dot gnu.org wrote:

> Is the failure reproducible manually?  With and without optimization?


Test doesn't fail when run manually.  It doesn't fail if the testsuite  
is
compiled with -O0.

Two new fails occurred at -O0: a74205e and c43222a.

Dave
--
John David Anglindave.ang...@bell.net

[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-03-05 
01:09:15 UTC ---
Ah, thanks, that explains a lot.

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #18 from paolo at gcc dot gnu.org  
2012-03-05 01:15:32 UTC ---
Author: paolo
Date: Mon Mar  5 01:15:28 2012
New Revision: 184911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184911
Log:
2012-03-04  Paolo Carlini  
Jonathan Wakely  

PR libstdc++/43813
* include/bits/stl_iterator_base_types.h (_RequireInputIter): New.
* include/ext/vstring.h (__versa_string<>::__versa_string
(_InputIterator, _InputIterator, const _Alloc&),
__versa_string<>::append(_InputIterator, _InputIterator),
__versa_string<>::assign(_InputIterator, _InputIterator),
__versa_string<>::insert(iterator, _InputIterator,
_InputIterator), __versa_string<>::replace(iterator, iterator,
_InputIterator, _InputIterator)): Use it.
* include/bits/stl_list.h (list<>::list(_InputIterator,
_InputIterator, const allocator_type&), list<>::assign(_InputIterator,
_InputIterator), list<>::insert(iterator, _InputIterator,
_InputIterator)): Likewise.
* include/bits/stl_vector.h (vector<>::vector(_InputIterator,
_InputIterator, const allocator_type&), vector<>::assign(_InputIterator,
_InputIterator), vectort<>::insert(iterator, _InputIterator,
_InputIterator)): Likewise.
* include/bits/stl_deque.h (deque<>::deque(_InputIterator,
_InputIterator, const allocator_type&), deque<>::deque(_InputIterator,
_InputIterator), deque<>::insert(iterator, _InputIterator,
_InputIterator)): Likewise.
* include/bits/stl_bvector.h (vector<>::vector(_InputIterator,
_InputIterator, const allocator_type&), vector<>::deque(_InputIterator,
_InputIterator), vector<>::insert(iterator, _InputIterator,
_InputIterator)): Likewise.
* include/bits/forward_list.h (forward_list<>::forward_list
(_InputIterator, _InputIterator, const allocator_type&),
forward_list<>::assign(_InputIterator, _InputIterator),
forward_list<>::insert_after(const_iterator, _InputIterator,
_InputIterator)): Likewise.
(forward_list<>::_M_initialize_dispatch(,, __true_type): Remove.
(forward_list<>::_M_range_initialize): Add, adjust everywhere.
* include/bits/forward_list.tcc: Adjust.
* include/debug/forward_list: Adjust.
* include/debug/vector: Likewise.
* include/debug/deque: Likewise.
* include/debug/list: Likewise.
* testsuite/ext/vstring/requirements/do_the_right_thing.cc: New.
* testsuite/23_containers/forward_list/requirements/
do_the_right_thing.cc: Likewise.
* testsuite/23_containers/vector/requirements/
do_the_right_thing.cc: Likewise.
* testsuite/23_containers/deque/requirements/
do_the_right_thing.cc: Likewise.
* testsuite/23_containers/list/requirements/
do_the_right_thing.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
assign_neg.cc: Adjust dg-error line number.
* testsuite/23_containers/forward_list/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
assign_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/vector/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
assign_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/deque/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
assign_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
constructor_2_neg.cc: Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/do_the_right_thing.cc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/do_the_right_thing.cc
   
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/do_the_right_thing.cc
   
trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/do_the_right_thing.cc
trunk/libstdc++-v3/testsuite/ext/vstring/requirements/do_the_right_thing.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/forward_list.h
trunk/libstdc++-v3/include/bits/forward_list.tcc
trunk/libstdc++-v3/include/bits/stl_bvector.h
trunk/libstdc++-v3/include/bits/stl_deque.h
trunk/libstdc++-v3/include/bits/stl_iterato

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #19 from Paolo Carlini  2012-03-05 
01:17:39 UTC ---
Done for containers and vstring. I'm intentionally leaving basic_string and its
exports alone.

[Bug tree-optimization/30997] FRE does not simplify comparisons in COND_EXPRs

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-03-05 
05:27:23 UTC ---
Some talk about this issue at http://gcc.gnu.org/ml/gcc/2012-02/msg00462.html .

[Bug tree-optimization/21485] [4.4/4.5/4.6/4.7/4.8 Regression] missed load PRE, PRE makes i?86 suck

[pinskia at gcc dot gnu.org]

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

--- Comment #49 from Andrew Pinski  2012-03-05 
05:29:54 UTC ---
PR 37242 is also needed from what I remember reading the IR.

[Bug target/52480] SH Target: SH4A movua.l does not work for big endian

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  2012-03-05 
05:30:18 UTC ---
Created attachment 26831
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26831
A possible patch

Looks to be a similar problem with PR52394.

[Bug tree-optimization/22586] GVN-PRE could do strength reduction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||37242

--- Comment #4 from Andrew Pinski  2012-03-05 
05:30:43 UTC ---
(In reply to comment #3)
> Related to PR 32120, actually I think PR 32120 is really asking for strength
> reduction just it was not called that in the bug report.

And it needs PR 37242 to fix the (long unsigned int) (i + 1)*4 and (long
unsigned int) (i)*4 issue.

[Bug target/52483] SH Target: Loads from volatile memory leave redundant sign/zero extensions

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  2012-03-05 
05:33:39 UTC ---
(In reply to comment #0)
> Maybe a few peepholes would help here?

Sure.  Peephole looks to be reasonable for this.

[Bug go/52342] 64-bit go.test/test/chan/doubleselect.go times out on Solaris/SPARC

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Ian Lance Taylor  2012-03-05 06:39:53 
UTC ---
Fixed on mainline.

I plan to merge the Go changes onto the 4.7 branch before the 4.7.0 release.

[Bug go/52342] 64-bit go.test/test/chan/doubleselect.go times out on Solaris/SPARC

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  2012-03-05 
06:39:13 UTC ---
Author: ian
Date: Mon Mar  5 06:39:08 2012
New Revision: 184914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184914
Log:
PR go/52342
runtime: Better big-endian identity hash function.

Modified:
trunk/libgo/runtime/go-type-identity.c

[Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123

[ralf_corsepius at rtems dot org]

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

 Bug #: 52488
   Summary: avr-*:  internal compiler error: in extract_insn, at
recog.c:2123
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ralf_corsep...@rtems.org
CC: joel.sherr...@oarcorp.com
Target: avr-*


Bootstrapping gcc-4.7.0-RC-20120203 ICEs for avr-rtems*:

/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/
-nostdinc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function
'glob':
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error:
unrecognizable insn:
(insn/f 305 304 306 2 (set (reg:QI 28 r28)
(plus:QI (reg:QI 28 r28)
(const_int -2050 [0xf7fe])))
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:160 -1
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28)
(plus:HI (reg/f:HI 28 r28)
(const_int -2050 [0xf7fe])))
(nil)))
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1:
internal compiler error: in extract_insn, at recog.c:2123
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [lib_a-glob.o] Error 1

Configuration:
CC='gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4  -m64 -mtune=generic'
../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11
--bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11
--includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib
--libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man
--infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=avr-rtems4.11  --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads --disable-lto
--disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-languages=c