[Bug tree-optimization/47714] [4.6 Regression] verify_ssa fails with error: invalid argument to gimple call

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-09 
08:43:32 UTC ---
BTW, if you adjust the testcase (at least not to use explicit DImode type), I'd
say this patch is obvious, thunks never take addresses of its parameters and
whether the original method takes those addresses is irrelevant to thunks.
You could certainly handle TREE_ADDRESSABLE in assemble_thunk by copying siuch
arguments into a temporary, but that would be good just to shut up
verification.

[Bug libstdc++/48038] New: stable_sort problem with C++0x and comparator by value

[vincenzo.innocente at cern dot ch]

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

   Summary: stable_sort problem with C++0x and comparator by value
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


if one uses a comparator where arguments are passed by value such as
inline bool operator(V rh, V lh) {
something goes wrong with move and default constructed objects are passed in
the comparator
It happens in stable_sort for sure
I'm using a recent version of 4.6
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-gold=yes --enable-lto --with-fpmath=avx
Thread model: posix
gcc version 4.6.0 20110205 (experimental) (GCC) 

this is an example I use that produces a seg-fault (easy to detect)
 g++ -O2 -std=gnu++0x -g rvalue.cpp -DBYVALUE
will seg-fault
 g++ -O2 -std=gnu++0x -g rvalue.cpp
is ok
the seg-fault is in
Program received signal SIGSEGV, Segmentation fault.
std::mergestd::move_iteratorV*,
std::move_iterator__gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV   , __gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV(__first1=..., __last1=..., __first2=value optimized
out, __last2=..., 
__result=value optimized out) at
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:5390
5390  if (*__first2  *__first1)
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.7.el6_0.3.x86_64
(gdb) where
#0  std::mergestd::move_iteratorV*,
std::move_iterator__gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV   , __gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV(__first1=..., __last1=..., __first2=value optimized
out, __last2=..., 
__result=value optimized out) at
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:5390
#1  0x00406f86 in
std::__merge_adaptive__gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV  , long, V* (__first=..., 
__middle=..., __last=..., __len1=value optimized out, __len2=value
optimized out, __buffer=0x615cc0, __buffer_size=6)
at
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:2835
#2  0x00408195 in
std::__stable_sort_adaptive__gnu_cxx::__normal_iteratorV*, std::vectorV,
std::allocatorV  , V*, long (
__first=..., __last=..., __buffer=0x615cc0, __buffer_size=6)
at
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:3312
#3  0x0040d0e0 in stable_sort__gnu_cxx::__normal_iteratorV*,
std::vectorV, std::allocatorV()
at
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algo.h:5508
#4  goV () at rvalue.cpp:114
#5  0x0040f6f9 in main () at rvalue.cpp:135

the test program
cat rvalue.cpp
#include vector
#include iostream
#includefunctional
#includealgorithm

typedef std::vectordouble VI;

struct V {
   VI v;

   V(){std::cout dc  std::endl;}

   virtual ~V(){std::cout dd   v.size() std::endl;}

   V(V const  rh) : v(rh.v) {
 std::cout cc  std::endl;
   }

   V(size_t n, double d) : v(n,d){} 


   V  operator=(V const rh) {
 std::cout ac  std::endl;
 V tmp(rh);
 v.swap(tmp.v);
 return *this;
  }

#if defined( __GXX_EXPERIMENTAL_CXX0X__)

   V(V  rh) : v(std::move(rh.v)) {
 std::cout rc  std::endl;
   }

   V  operator=(V  rh) {
 std::cout ar  std::endl;
 std::swap(rh.v,v);
 return *this;
  }

#else

  void swap(V  rh) {
std::cout V::swap  std::endl;
std::swap(rh.v,v);
  }


#endif

};


struct A : public V {
  A(size_t n, double d) : V(n,d){}

};

/*
inline
void swap(V  lh, V  rh) {
std::cout ::swap  std::endl;
std::swap(lh.v,rh.v);
}
*/

#ifdef BYVALUE
inline bool operator(V rh, V lh) {
#else
 inline bool operator(V const rh, V const lh) {
#endif
  return rh.v[0]lh.v[0];
}


templatetypename T
void go() {

   std::vectorT vvs;
   std::cout  push_back   std::endl;
   vvs.push_back(T(50,0.));
   for (int i=1;i5; ++i) 
 vvs.push_back(T(100*i,i));
   std::cout  push_front   std::endl;
   vvs.insert(vvs.begin(),T(300,1.));


#if defined( __GXX_EXPERIMENTAL_CXX0X__)

   auto vov = std::bind(T::v,std::placeholders::_1);
   vov(vvs[0]).size();


   auto myless = std::bindbool(std::lessVI(),
   std::bindVI const(V::v,std::placeholders::_1),
   std::bindVI const(V::v,std::placeholders::_2)
   );

   std::cout  ( myless(vvs[0],vvs[2]) ? less : greater )  std::endl;
#endif

   std::cout  shuffle   std::endl;
   std::random_shuffle(vvs.begin(),vvs.end());

   std::cout  sort   std::endl;
   std::sort(vvs.begin(),vvs.end());

#if defined( 

[Bug ada/48039] New: Legal program rejected, a formal function is not visible in generic

[demoonlit at panathenaia dot halfmoon.jp]

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

   Summary: Legal program rejected, a formal function is not
visible in generic
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: demoon...@panathenaia.halfmoon.jp


Created attachment 23589
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23589
minimal bug triggering source code

Name lookup is abnormal in complex generic code with gcc-4.5.1/4.5.2.

-- p.ads
package p is
end p;

-- p-gh.ads
generic
function p.gh return Integer;

-- p-gh.adb
function p.gh return Integer is
begin
   return 0;
end p.gh;

-- p-gu.ads
generic
package p.gu is
   generic
  with function h return Integer is ;
  -- with function fh return Integer is ; -- ok
   function gh return Integer;
end p.gu;

-- p-gu.adb
package body p.gu is
   function gh return Integer is
   begin
  return h; -- error !!
  -- return fh; -- ok
   end gh;
end p.gu;

-- p-h.ads
with p.gh;
function p.h is new gh;

-- p-u.ads
with p.gu;
package p.u is new gu;

-- p-r.ads
with p.u;
package p.r is
end p.r;

-- p-r-h.ads
with p.h;
function p.r.h is new u.gh (h);

% gnatmake p-r-h.ads 
gcc -c p-r-h.ads
p-r-h.ads:4:01: instantiation error at p-gu.adb:6
p-r-h.ads:4:01: h is not visible
p-r-h.ads:4:01: instantiation error at p-gu.adb:6
p-r-h.ads:4:01: non-visible declaration at line 4
p-r-h.ads:4:01: instantiation error at p-gu.adb:6
p-r-h.ads:4:01: non-visible declaration at p-h.ads:4
gnatmake: p-r-h.ads compilation error

This code will be compiled If we rename formal function h to another name (for
example, fh).

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de rguenther at suse dot de 
2011-03-09 09:21:46 UTC ---
On Tue, 8 Mar 2011, mikpe at it dot uu.se wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48031
 
 Mikael Pettersson mikpe at it dot uu.se changed:
 
What|Removed |Added
 
  CC||rguenth at gcc dot gnu.org
 
 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-03-08 
 21:40:03 UTC ---
 The bug in 4.4 branch began with r154046, Jakub's fix for PR40946 which
 backported r151559 (PR41317 fix) from 4.5.  Checking 4.5 branch confirmed that
 r151558 works while r151559 has the bug.

Which means that change triggers a latent bug.

[Bug libstdc++/48038] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
09:30:17 UTC ---
I will analyse this properly asap, but there are a few things that look odd in
your example. Why does your move assignment do a swap not a move?

[Bug libstdc++/48038] stable_sort problem with C++0x and comparator by value

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-03-09 09:40:33 UTC ---
Thanks for the quick answer.

On 9 Mar, 2011, at 10:30 AM, redi at gcc dot gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
 
 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
 09:30:17 UTC ---
 I will analyse this properly asap, but there are a few things that look odd in
 your example. Why does your move assignment do a swap not a move?
 
Most probably for symmetry w.r.t. the copy assignment.
In any case this is test code I started to write long ago trying several
variants (move, forward, swap)
I'm sure it is not optimized for the current compiler, so please feel free to
suggest the best idiom to use in each case.

 vincenzo

 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.

[Bug libstdc++/48038] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
09:42:25 UTC ---
(In reply to comment #0)
 
 #ifdef BYVALUE
 inline bool operator(V rh, V lh) {
 #else
  inline bool operator(V const rh, V const lh) {
 #endif
   return rh.v[0]lh.v[0];

Changing this to use vector::at() results in an out_of_range exception

[Bug libstdc++/48038] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
09:47:33 UTC ---
replacing the swap in the move assignment doesn't change anything, so ignore my
comment on that, still looking...

[Bug c/48040] New: .pushsection causes bogus debug records when options -O2 -g are used

[rwhitton at bluearc dot com]

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

   Summary: .pushsection causes bogus debug records when options
-O2 -g are used
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rwhit...@bluearc.com


Created attachment 23590
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23590
This is the preprocessed test program that demonstrates the problem

Inline assembler that uses .pushsection and .popsection to change the section
being used for code results in bogus debug records which causes a failure at
assembly time if the attached code is compiled with the -O2 -g options. The
code
compiles and works correctly with the following options:

-g
-O
-g -O
-O2

it will fail with -O3 but this is just due to the compiler performing inlining
and is to be expected.

[Bug c/48040] .pushsection causes bogus debug records when options -O2 -g are used

[rwhitton at bluearc dot com]

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

--- Comment #1 from rwhitton at bluearc dot com 2011-03-09 09:54:56 UTC ---
Created attachment 23591
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23591
This is the original non preprocessed source code of the test program

[Bug debug/48041] New: dwarf2out emits unnecessary null byte in empty .debug_abbrev section

[mark at gcc dot gnu.org]

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

   Summary: dwarf2out emits unnecessary null byte in empty
.debug_abbrev section
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


Detected by the elfutils dwarflint tool.

Example:
$ echo  empty.c 
$ gcc -g -c empty.c 
$ readelf -x .debug_abbrev empty.o
Hex dump of section '.debug_abbrev':
  0x 00  .

Although harmless it might add up if a project has a lot of objects without any
real debuginfo in them. There might not actually be many such projects though.

The fix seems easy:

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c(revision 170813)
+++ gcc/dwarf2out.c(working copy)
@@ -11058,7 +11058,8 @@
 }

   /* Terminate the table.  */
-  dw2_asm_output_data (1, 0, NULL);
+  if (abbrev_die_table_in_use  1)
+dw2_asm_output_data (1, 0, NULL);
 }

 /* Output a symbol we can use to refer to this DIE from another CU.  */

Bootstraps fine on x86_64-gnu-linux and no regressions seen with make check -k

I'll submit it to gcc-patches when the tree opens up again for stage one.

[Bug c/48040] .pushsection causes bogus debug records when options -O2 -g are used

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
10:04:06 UTC ---
You can't leave sections changed when leaving asm() context.

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 10:22:09
 CC||law at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
10:22:09 UTC ---
In theory vsqrt2 should be the best way to encode this but at least at the
tree level we miss the opportunity to re-write x into SSA form.  That would
change

__m128d vsqrt2(__m128d) (const __m128d x)
{
  __m128d D.5962;
  __m128d D.5962;
  const double b;
  const double a;
  const double D.5940;
  const double D.5938;

bb 2:
  D.5938_2 = MEM[(const double *)x];
  a_3 = sqrt (D.5938_2);
  D.5940_5 = MEM[(const double *)x + 8B];
  b_6 = sqrt (D.5940_5);
  D.5962_12 = {a_3, b_6};
  return D.5962_12;

to use

  D.5938_2 = BIT_FIELD_REF x_1(D), 0, 64
...

not pushing the argument to the stack (well, hopefully).

As of the register moves you are seeing, we have the long-time known problem
that we fail to allocate registers in a way to have the function return
value in-place.  Maybe we are just confusing IRA with the explicit move
to that register?

(insn 13 11 18 2 (set (reg:V2DF 72)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
 (expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil

(insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
(reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
 (expr_list:REG_DEAD (reg:V2DF 72)
(nil)))

why is combine not able to change this to

(insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
(vec_concat:V2DF (reg:DF 67)
(reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
 (expr_list:REG_DEAD (reg:DF 69)
(expr_list:REG_DEAD (reg:DF 67)
(nil

? (it doesn't even try this combination)

Does IRA model the cost benefit of coalescing the two registers?

I'm looking at the bit-field-ref issue.

[Bug libstdc++/48038] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
10:24:42 UTC ---
slightly reduced ...

#include vector
#include iostream
#includealgorithm

typedef std::vectordouble VI;

struct V {
   VI v;

   V(){std::cout dc  std::endl;}

   ~V(){std::cout dd   v.size() std::endl;}

   V(V const  rh) : v(rh.v) {
 std::cout cc  std::endl;
   }

   V(size_t n, double d) : v(n,d){} 


   V  operator=(V const rh) {
 std::cout ac  std::endl;
 V tmp(rh);
 v.swap(tmp.v);
 return *this;
  }

   V(V  rh) : v(std::move(rh.v)) {
 std::cout rc  std::endl;
   }

   V  operator=(V  rh) {
 std::cout ar  std::endl;
 v = std::move(rh.v);
 return *this;
  }

};


inline bool operator(V lh, V rh) {
  return lh.v.at(0)  rh.v.at(0);
}


int main()
{
   std::vectorV vvs;
   vvs.push_back(V(1, 0.));
   vvs.push_back(V(1, 1.));
   vvs.insert(vvs.begin(),V(1, 2.));

   std::stable_sort(vvs.begin(), vvs.end());

}

[Bug bootstrap/47779] Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #1 from Stu Stuart.Henderson at analog dot com 2011-03-09 
10:45:07 UTC ---
Created attachment 23592
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23592
first attempt to fix bug #47779

[Bug bootstrap/47779] Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #2 from Stu Stuart.Henderson at analog dot com 2011-03-09 
10:47:33 UTC ---
oops, missed the comment field, sorry.

To get the ball rolling, this is a first attempt to fix the bug.  Taking Ian
Lance Taylor's advice:
I doubt there is a clean way to solve this.  Probably the simplest way
is to rename the conflicting constants in gcc/config/bfin/*.
I have simply changed the constants from the REG_x form to the more common
x_REG form.

Does this seem reasonable?

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 11:11:23
 CC||paolo.carlini at oracle dot
   ||com
Summary|stable_sort problem with|[C++0x] stable_sort problem
   |C++0x and comparator by |with C++0x and comparator
   |value   |by value
 Ever Confirmed|0   |1

--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
11:11:23 UTC ---
#include algorithm
#include assert.h

struct V
{
int val;
bool ok;

V(int v) : val(v), ok(true) { } 

V(V const  rh) : val(rh.val), ok(rh.ok) {
assert(rh.ok);
}

V  operator=(V const rh) {
assert(rh.ok);
val = rh.val;
ok = rh.ok;
return *this;
}

V(V  rh) : val(rh.val), ok(rh.ok) {
assert(rh.ok);
rh.ok = false;
}

V  operator=(V  rh) {
assert(rh.ok);
val = rh.val;
rh.ok = false;
return *this;
}

};


inline bool operator(V lh, V rh) {
  assert(rh.ok);
  assert(lh.ok);
  return lh.val  rh.val;
}


int main()
{
   V vvs[] = { 2, 0 };

   std::stable_sort(vvs, vvs+2);
}

The first element has ok=false after constructing the Temporary_buffer in
std::stable_sort, because __uninitialized_construct_buf_dispatch::__ucr uses
_GLIBCXX_MOVE which leaves vvs[0] in a moved-from state

Paolo, could you take a look?

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||chris at bubblescope dot
   ||net

--- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
11:18:02 UTC ---
Let's ask first Chris, he invented that logic.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
11:18:09 UTC ---
N.B. that last testcase still fails if operator takes its arguments by
reference, the problem is not caused by taking the args by value, that just
made it show up in the original example

[Bug lto/48042] New: lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

   Summary: lto segfaults while building Qt 4.7.2 with -g -flto
-fwhole-program
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@arklinux.org


Trying to build Qt 4.7.2 with -g -flto for the library and -g -flto
-fwhole-program for the tools crashes gcc.

[bero@matterhorn uic3]$ g++ -Wl,-rpath-link,/usr/src/ark/BUILD/qt/lib -m64 -O2
-g -Wl,-rpath,/usr/lib64/qt4-embedded/lib
-Wl,-rpath,/usr/lib64/qt4-embedded/lib -flto -fwhole-program -o
../../../bin/uic3 .obj/release-static-emb-x86_64/customwidgetsinfo.o
.obj/release-static-emb-x86_64/databaseinfo.o
.obj/release-static-emb-x86_64/driver.o
.obj/release-static-emb-x86_64/treewalker.o
.obj/release-static-emb-x86_64/ui4.o .obj/release-static-emb-x86_64/validator.o
.obj/release-static-emb-x86_64/cppextractimages.o
.obj/release-static-emb-x86_64/cppwritedeclaration.o
.obj/release-static-emb-x86_64/cppwriteicondata.o
.obj/release-static-emb-x86_64/cppwriteicondeclaration.o
.obj/release-static-emb-x86_64/cppwriteiconinitialization.o
.obj/release-static-emb-x86_64/cppwriteincludes.o
.obj/release-static-emb-x86_64/cppwriteinitialization.o
.obj/release-static-emb-x86_64/main.o
.obj/release-static-emb-x86_64/ui3reader.o
.obj/release-static-emb-x86_64/parser.o
.obj/release-static-emb-x86_64/domtool.o
.obj/release-static-emb-x86_64/object.o
.obj/release-static-emb-x86_64/subclassing.o
.obj/release-static-emb-x86_64/form.o
.obj/release-static-emb-x86_64/converter.o
.obj/release-static-emb-x86_64/widgetinfo.o
.obj/release-static-emb-x86_64/embed.o .obj/release-static-emb-x86_64/qt3to4.o
.obj/release-static-emb-x86_64/deps.o .obj/release-static-emb-x86_64/uic.o   
-L/usr/src/ark/BUILD/qt/lib -lQt3Support -L/usr/src/ark/BUILD/qt/lib -lQtSql
-lsqlite3 -lQtXml -lQtGui -ljpeg -lmng -ltiff -lpng -lfreetype -lQtNetwork
-lssl -lcrypto -lQtCore -lz -lm -ldl -pthread -lgthread-2.0 -lrt -lglib-2.0
-lpthread
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status

This is with yesterday's gcc svn (rev. 170774).

It works (and actually produces a working binary) if I omit -g. Replacing -g
with -ggdb or -gdrawf-4 doesn't change anything.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #9 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
11:28:13 UTC ---
Just to say, I am looking at this. Thanks for the small test case.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
11:29:22 UTC ---
Of course we already have testcases using the checked __gnu_test::rvalstruct.
We should figure out first what's special here.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
11:30:06 UTC ---
Thanks a lot Chris, it would be nice if we could resolve it in time for 4.6.0.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.03.09 11:37:32
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
11:37:32 UTC ---
Any chance you can reduce this to a managable testcase?  LTO and debug
information are not exactly best friends, but we at least try to avoid ICEs
like this.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[vincenzo.innocente at cern dot ch]

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

--- Comment #12 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-03-09 11:39:24 UTC ---
On 9 Mar, 2011, at 12:30 PM, paolo.carlini at oracle dot com wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
 
 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 
 2011-03-09 11:30:06 UTC ---
 Thanks a lot Chris, it would be nice if we could resolve it in time for 4.6.0.
 
It would be critical for us.
We need 4.6 for other reasons (for instance real support of AVX).
stable_sort not working (and pontentially other subbtle bugs in move)   makes
it unusable for our scopes.

Thanks for the effort you all are putting in resolving this issue.
We are ready to test a new snapshot of the compiler as soon as posted.

   vincenzo

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
11:43:00 UTC ---
gah - there was a bug in my reduced testcase, the move assignment operator
should have done:
  ok = rh.ok;
that was missing which is why Temporary_buffer left the first element !ok

The logic in __ucr is ok, sorry!

This one still fails (and only if the operator takes args by value)

#include algorithm
#include assert.h

struct V
{
int val;
bool ok;

V(int v) : val(v), ok(true) { } 

V(V const  rh) : val(rh.val), ok(rh.ok) {
// assert(rh.ok);
}

V  operator=(V const rh) {
// assert(rh.ok);
val = rh.val;
ok = rh.ok;
return *this;
}

V(V  rh) : val(rh.val), ok(rh.ok) {
// assert(rh.ok);
rh.ok = false;
}

V  operator=(V  rh) {
// assert(rh.ok);
val = rh.val;
ok = rh.ok;
rh.ok = false;
return *this;
}

};


inline bool operator(V lh, V rh) {
  assert(rh.ok);
  assert(lh.ok);
  return lh.val  rh.val;
}


int main()
{
   V vvs[] = { 2, 0, 1 };

   std::stable_sort(vvs, vvs+3);
}

[Bug c++/48035] [4.4/4.5/4.6 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes

[dodji at gcc dot gnu.org]

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

Dodji Seketeli dodji at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dodji at gcc dot gnu.org

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #14 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
11:51:24 UTC ---
Ah yes, I see the problem now.

The problem is to do with using move_iterator. When we compare two values which
we dereference from a move_iterator, then we end up moving into the
comparator, which breaks things.

Hmm.. to be honest, this seems like a fairly serious practical flaw in
move_iterator, removing most of the practical reasons for it's presence in the
standard.

I'm having a very quick think about the best way to fix this. Will report back
shortly.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
11:55:05 UTC ---
hum, if that is confirmed, we should also quickly audit the other uses of
move_iterator as implementation detail, we have a few, not many.

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-03-09 
12:01:10 UTC ---
 As of the register moves you are seeing, we have the long-time known problem
 that we fail to allocate registers in a way to have the function return
 value in-place.  Maybe we are just confusing IRA with the explicit move
 to that register?
 
 (insn 13 11 18 2 (set (reg:V2DF 72)
 (vec_concat:V2DF (reg:DF 67)
 (reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
  (expr_list:REG_DEAD (reg:DF 69)
 (expr_list:REG_DEAD (reg:DF 67)
 (nil
 
 (insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
 (reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
  (expr_list:REG_DEAD (reg:V2DF 72)
 (nil)))
 
 why is combine not able to change this to
 
 (insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
 (vec_concat:V2DF (reg:DF 67)
 (reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
  (expr_list:REG_DEAD (reg:DF 69)
 (expr_list:REG_DEAD (reg:DF 67)
 (nil
 
 ? (it doesn't even try this combination)

Probably because of the check in cant_combine_insn_p (SSE_FIRST_REG is likely
spilled on x86).

[Bug tree-optimization/47714] [4.6 Regression] verify_ssa fails with error: invalid argument to gimple call

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-09 
12:02:34 UTC ---
I have posted the patch (with the simpler testcase, thanks) to the
mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00461.html

If there are no objections, I'll commit it in a few hours.

[Bug middle-end/48043] New: pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

   Summary: pr47201: var-tracking loc_order_check fails for type
punning examples
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org


Created attachment 23593
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23593
pr47201.i.214r.vartrack

The pr47201 testcase contains a union of an int and a float value.
The way these values are accessed seems to confuse the
canonicalize_loc_order_check done during var-tracking.

/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c: In function ‘foo’:
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:18:1: internal compiler error:
in loc_cmp, at var-tracking.c:2753
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.


pr47201.i.212r.alignments:

(insn 29 10 11 2 (set (reg:SI 1 %r1)
(mem/u/c:SI (plus:SI (reg:SI 12 %r12)
(const:SI (unspec:SI [
(symbol_ref:SI (u)  var_decl 0x779eb060 u)
] 111))) [0 S4 A8]))
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 67 {*movsi_esa}
 (nil))

(insn 11 29 30 2 (set (reg:SF 16 %f0 [orig:53 u.d ] [53])
(mem/s/j/c:SF (reg:SI 1 %r1) [0 u.d+0 S4 A32]))
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 87 {movsf}
 (expr_list:REG_DEAD (reg:SI 1 %r1)
(expr_list:REG_EQUIV (mem/s/j/c:SF (mem/u/c:SI (plus:SI (reg:SI 12
%r12)
(const:SI (unspec:SI [
(symbol_ref:SI (u)  var_decl 0x779eb060
u)
] 111))) [0 S4 A8]) [0 u.d+0 S4 A32])
(nil

(insn 30 11 12 2 (set (reg:SF 17 %f2)
(mem/u/c:SF (plus:SI (reg:SI 12 %r12)
(const:SI (unspec:SI [
(symbol_ref:SI (u)  var_decl 0x779eb060 u)
] 111))) [0 S4 A8]))
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 87 {movsf}
 (expr_list:REG_DEAD (reg:SI 12 %r12)
(nil)))

(insn 12 30 13 2 (set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SF 16 %f0 [orig:53 u.d ] [53])
(reg:SF 17 %f2)))
/build3/gcc-head/gcc/testsuite/gcc.dg/pr47201.c:17 49 {*cmpsf_ccs}
 (expr_list:REG_DEAD (reg:SF 17 %f2)
(expr_list:REG_DEAD (reg:SF 16 %f0 [orig:53 u.d ] [53])
(nil


log_cmp complains about the mode differences of:

(reg:SF 17 %f2)
(reg:SI 1 %r1)

both holding: (symbol_ref:SI (u)  var_decl 0x779eb060 u)

from:

(value/u:SI 12:5945 @0xe15b28/0xe27910)
 locs:
  from insn 30 (reg:SF 17 %f2)
  from insn 29 (reg:SI 1 %r1)
  from insn 29 (symbol_ref:SI (u)  var_decl 0x779eb060 u)
 addr list:
  (value/u:SF 14:14 @0xe15b58/0xe27950)

[Bug middle-end/48043] pr47201: var-tracking loc_order_check fails for type punning examples

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org 2011-03-09 
12:04:32 UTC ---
Created attachment 23594
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23594
pr47201.i.212r.alignments

[Bug middle-end/48044] New: [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875

[rguenth at gcc dot gnu.org]

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

   Summary: [4.6 Regression] ICE in
function_and_variable_visibility, at ipa.c:875
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Target: ia64-*-linux


Created attachment 23595
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23595
testcase

Building uClibc on ia64 ICEs.

/usr/lib/gcc/ia64-suse-linux/4.6/cc1 -fpreprocessed errno.i -quiet -dumpbase
errno.c -auxbase-strip libc/misc/internals/errno.os -g3 -O0 -Wall
-Wstrict-prototypes -Wnested-externs -Wshadow -Wmissing-noreturn
-Wmissing-format-attribute -Wformat=2 -Wmissing-prototypes
-Wmissing-declarations -Wnonnull -Wundef -std=gnu99 -version
-fno-strict-aliasing -fstack-protector -fno-builtin -fno-asm -fPIC -o errno.s
GNU C (SUSE Linux) version 4.6.0 20110308 [trunk revision 170774]
(ia64-suse-linux)
compiled by GNU C version 4.6.0 20110308 [trunk revision 170774], GMP
version 5.0.1, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (SUSE Linux) version 4.6.0 20110308 [trunk revision 170774]
(ia64-suse-linux)
compiled by GNU C version 4.6.0 20110308 [trunk revision 170774], GMP
version 5.0.1, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: d99dab1301ec0970f4d6fd131beca4b3
libc/misc/internals/errno.c:14:1: internal compiler error: in
function_and_variable_visibility, at ipa.c:875
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.

[Bug middle-end/48044] [4.6 Regression] ICE in function_and_variable_visibility, at ipa.c:875

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target|ia64-*-linux|ia64-*-linux,
   ||x86_64-*-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 12:28:26
 CC||hubicka at gcc dot gnu.org
  Known to work||4.5.2
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
12:28:26 UTC ---
Reduced testcase:

extern int errno;
extern __typeof (errno) errno __asm__ (__GI_errno);
int errno = 0;
extern __typeof (errno) __EI_errno __asm__(errno);
extern __typeof (errno) __EI_errno __attribute__((alias (__GI_errno)));
extern __typeof (errno) _errno __attribute__ ((weak, alias (errno)));

fails with a cross to ia64-linux and also on x86_64-*-*.

gcc ./cc1 -quiet errno.3.i 
errno.3.i:6:1: internal compiler error: in function_and_variable_visibility, at
ipa.c:875
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

works with -O1 and 4.5.2.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf markus at trippelsdorf dot de changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #52 from Markus Trippelsdorf markus at trippelsdorf dot de 
2011-03-09 12:37:00 UTC ---
Just a warning: Building a -fprofile-generate libxul uses
~13GB of memory. (I have 8GB on my build-system and lto1
got killed several times by the OOM killer, until I added
enough swap space.)
The build process still fails later on as described in Comment 28.

[Bug middle-end/48043] pr47201: var-tracking loc_order_check fails for type punning examples

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 12:39:00
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
12:39:00 UTC ---
We should either prune non-compatible locations from the list (they are
only bitwise identical, the values as interpreted in the locations mode
differ) or simply accept these locations.

[Bug c++/47952] [trans-mem] undefined reference to transaction clone

[aldyh at gcc dot gnu.org]

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

--- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-03-09 
12:41:11 UTC ---
Unless Patrick has reduced the test case, the only way I was able to reproduce
it was to build the entire Glob2 benchmark which he mentions.  It has lots of
dependencies, but is really easy to reproduce.

The dependencies are scons, libboost, SDL, OpenGL, speex, vorbis, ogg, ...  All
are yum installable from fedora.

To reproduce you must do:

$ scons COMPILER=GCC SYNC=FINETM

You can download the application here:
http://members.unine.ch/patrick.marlier/downloads/glob2.tar.bz2

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
12:46:07 UTC ---
By the way, as a note to Vincenzo, in general I don't really see the point of
comparators taking the arguments by value, thus ruling out move-only types,
among other issues (that clearly shows up in other areas of C++0x). In other
terms, I don't see the temporary workaround for this issue as a proper
workaround, more as a best practice ;)

[Bug c++/48035] [4.4/4.5/4.6 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-09 
12:46:12 UTC ---
I think this started with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=138355

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[schnetter at gmail dot com]

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

Erik Schnetter schnetter at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
12:50:20 UTC ---
I can compile this source file without problems with

g++ (GCC) 4.6.0 20110308 (experimental)

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[schnetter at gmail dot com]

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

Erik Schnetter schnetter at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |

--- Comment #2 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
12:55:28 UTC ---
Strangely, I now receive the same error message for a different source file. I
am therefore reopening this bug report instead of opening a new one.

I am using:

g++ (GCC) 4.6.0 20110308 (experimental)

When I execute:

$ /Users/eschnett/gcc/bin/g++ -fopenmp -Wall -g3 -m128bit-long-double
-march=native -std=gnu++0x -fbounds-check -fstack-protector-all -ftrapv -O0
-fopenmp -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align
-Woverloaded-virtual -c iobasic.ii

I receive the error message:

/Users/eschnett/EinsteinToolkit-hg/arrangements/Carpet/CarpetIOBasic/src/iobasic.cc:
In function ‘bool CarpetIOBasic::UseScientificNotation(const T) [with T =
int]’:
/Users/eschnett/EinsteinToolkit-hg/arrangements/Carpet/CarpetLib/src/typecase.hh:149:118:
  instantiated from here
/Users/eschnett/EinsteinToolkit-hg/arrangements/Carpet/CarpetIOBasic/src/iobasic.cc:703:22:
internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13386

I can compile the same source code without problems with g++ 4.5.2.

[Bug c++/30952] Unclear error message when callling via a function pointer

[schnetter at gmail dot com]

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

--- Comment #2 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
12:56:16 UTC ---
Created attachment 23596
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23596
failing source code

[Bug c++/30952] Unclear error message when callling via a function pointer

[schnetter at gmail dot com]

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

Erik Schnetter schnetter at gmail dot com changed:

   What|Removed |Added

  Attachment #23596|0   |1
is obsolete||

--- Comment #3 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
12:57:23 UTC ---
Comment on attachment 23596
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23596
failing source code

I attached this source file to the wrong bug report. Please disregard it.

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[schnetter at gmail dot com]

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

Erik Schnetter schnetter at gmail dot com changed:

   What|Removed |Added

  Attachment #23398|0   |1
is obsolete||

--- Comment #3 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
12:58:17 UTC ---
Created attachment 23597
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23597
failing source code

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

--- Comment #2 from bero at arklinux dot org 2011-03-09 12:58:58 UTC ---
Somewhat reduced, still too large:
$ g++ -m64 -O2 -g -flto  -o ../../../bin/uic3
.obj/release-static-emb-x86_64/widgetinfo.o -L/usr/src/ark/BUILD/qt/lib
-lQt3Support
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 13:17:11
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
13:17:11 UTC ---
Confirmed.  Trying to reduce.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

--- Comment #3 from bero at arklinux dot org 2011-03-09 13:19:53 UTC ---
If I reduce widgetinfo.cpp to just say

#include q3glist.h

it still breaks and produces a different, potentially more useful error:


In file included from tools/q3glist.h:164:0,
 from :88:
tools/q3gvector.cpp: In member function ‘write’:
tools/q3gvector.cpp:159:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
13:27:02 UTC ---
(In reply to comment #2)

 $ /Users/eschnett/gcc/bin/g++ -fopenmp -Wall -g3 -m128bit-long-double
 -march=native -std=gnu++0x -fbounds-check -fstack-protector-all -ftrapv -O0
 -fopenmp -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align
 -Woverloaded-virtual -c iobasic.ii

Most of these options have no effect on the ICE, when reporting bugs it is
helpful if you could reduce the command to the minimum that still causes the
error.  In this case I don't think any of the options  are relevant to the
error except -std=gnu++0x and maybe -fopenmp.

It's even more helpful if you can reduce the source code to something smaller
that still fails, see http://gcc.gnu.org/bugs/minimize.html for tips.

At the very least, compiling with -DNDEBUG would remove the __assert_rtn calls
which don't compile anywhere except Mac OS X.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

--- Comment #4 from bero at arklinux dot org 2011-03-09 13:27:24 UTC ---
Created attachment 23598
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23598
Preprocessed source of remaining widgetinfo.cpp

Preprocessed source of remaining widgetinfo.cpp

$ g++ -g -O2 -flto -o test.o -c widgetinfo.i
$ g++ -g -O2 -flto -o test test.o -L/usr/src/ark/BUILD/qt/lib -lQt3Support
In file included from tools/q3glist.h:164:0,
 from :88:
tools/q3gvector.cpp: In member function ‘write’:
tools/q3gvector.cpp:159:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status

Still requires a libQt3Support.so built with -flto to trigger the crash
though...

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
13:31:13 UTC ---
Would be interesting to know if it also happens without -fwhole-program
(I am assuming you either use the gold or GNU ld linker-plugin).

You can also try linking to the libQT object files instead of the .so
and reduce the set of required files by incremental linking
(-r -nostdlib).

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #17 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
13:34:22 UTC ---
Created attachment 23599
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23599
Patch to make stable_sort work with comparitors that take by value.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #18 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
13:34:51 UTC ---
Just to update:

I have checked other users of MOVE_ITERATOR (there are only two) and they
appear fine, as they do not use a comparator.

Attached is an initial patch. Very sorry if the formatting (particular tabs)
are off, I am using a different texteditor to normal and am having trouble
configuring correctly.

This patch might look quite long but it is actually fairly minimal.

Basically we introduce methods __move_merge_backward and __move_merge, which
act similarly to merge but move values. We call the comparitor methods without
any moving, so they behave themselves.

__merge_backward was only ever used with arguments that move, so I have renamed
it to __move_merge_backward for clarity and changed the places it is called.
Also introduce __move_merge which is identical to std::merge, except it moves
values into place rather than copies them.

Then fix all places which call merge or __merge_backward with MOVE_ITERATORS to
use the new methods.

Finally, there is a little testcase.


As a sanity check, I would like to make sure that other types (the other sorts
being the obvious target) also work correctly. I can't imagine why they
wouldn't, but I'm very suprised this broke!

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #19 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
13:35:48 UTC ---
Ignore that patch, there is a problem with it (tester wasn't working properly).
Sorry.

[Bug fortran/45044] Different named COMMON block size: No warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 13:38:24
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-09 
13:38:24 UTC ---
Still around at revision 170786.

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[burnus at gcc dot gnu.org]

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

--- Comment #37 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-09 
13:41:57 UTC ---
(In reply to comment #30)
 On Fri, 25 Feb 2011, burnus at gcc dot gnu.org wrote:
  TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions 
  and
  _REENTRANT, cf. comment 20 and comment 23.
 
 In testing fix for above, I see:
 ../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization
 makes pointer from integer without a cast [enabled by default]
 Unfortunately, localtime_r has a different proto:

While the latter is fixed, I think the _REENTRANT issue isn't. Or is it?

If it it not fixed, I think we should have (a different) PR open to track that
issue. Dave, you wrote you were testing a patch for _REENTRANT ...

[Bug fortran/45045] Named COMMON with different size: No warning with -fwhole-file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 13:42:50
 Ever Confirmed|0   |1

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-09 
13:42:50 UTC ---
Still there at revision 170786. Note that '-Wall -fwhole-program' generates

pr45045.f90:8:0: warning: 'xx' defined but not used [-Wunused-variable]
pr45045.f90:1:0: warning: 'one' defined but not used [-Wunused-function]

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #53 from Markus Trippelsdorf markus at trippelsdorf dot de 
2011-03-09 13:46:39 UTC ---
Building fails with GNU ld (Linux/GNU Binutils) 2.21.51.0.7.20110306:

c++ -o xpcshell -fno-rtti -fno-exceptions -Wall -Wpointer-arith
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type
-Wno-long-long -march=native -fpermissive -flto=4 -fuse-linker-plugin
-fwhole-program -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG
-DTRIMMED -O3  xpcshell.o   -lpthread
-Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory 
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
-Wl,-rpath-link,/usr/lib  -L../../../../dist/bin -L../../../../dist/lib
../../../../dist/lib/libxpcomglue_s.a
-L/var/tmp/mozilla-central/moz-build-dir/dist/bin -lxpcom -lmozalloc -lxul 
-L/var/tmp/mozilla-central/moz-build-dir/dist/bin -lxpcom -lmozalloc -lxul  
-Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl
../../../../dist/bin/libxul.so: undefined reference to `PR_smprintf_free'
../../../../dist/bin/libxul.so: undefined reference to `PR_SetEnv'
../../../../dist/bin/libxul.so: undefined reference to `PR_Now'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetErrorText'
../../../../dist/bin/libxul.so: undefined reference to `PR_FindFunctionSymbol'
../../../../dist/bin/libxul.so: undefined reference to `PR_PushIOLayer'
../../../../dist/bin/libxul.so: undefined reference to `PR_ntohs'
../../../../dist/bin/libxul.so: undefined reference to `PR_FormatTimeUSEnglish'
../../../../dist/bin/libxul.so: undefined reference to `PR_MemMap'
../../../../dist/bin/libxul.so: undefined reference to `PR_LocalTimeParameters'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetDefaultIOMethods'
../../../../dist/bin/libxul.so: undefined reference to `PR_ReadDir'
../../../../dist/bin/libxul.so: undefined reference to `PR_SetPollableEvent'
../../../../dist/bin/libxul.so: undefined reference to `PR_FindSymbol'
/usr/lib/libssl3.so: undefined reference to `PR_OpenAnonFileMap'
/usr/lib/libssl3.so: undefined reference to `PR_ExportFileMapAsString'
../../../../dist/bin/libxul.so: undefined reference to `PR_Delete'
../../../../dist/bin/libxul.so: undefined reference to `PR_AtomicSet'
/usr/lib/libnss3.so: undefined reference to `PR_NewRWLock'
../../../../dist/bin/libxul.so: undefined reference to `PR_SetNetAddr'
../../../../dist/bin/libxul.so: undefined reference to
`PR_GetNumberOfProcessors'
../../../../dist/bin/libxul.so: undefined reference to `PR_SecondsToInterval'
../../../../dist/bin/libxul.so: undefined reference to `PR_Close'
../../../../dist/bin/libxul.so: undefined reference to `PR_vsprintf_append'
../../../../dist/bin/libxul.so: undefined reference to `PR_Bind'
../../../../dist/bin/libxul.so: undefined reference to `PR_Sleep'
../../../../dist/bin/libxul.so: undefined reference to `PR_OpenTCPSocket'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetRandomNoise'
../../../../dist/bin/libxul.so: undefined reference to `PR_Send'
../../../../dist/bin/libxul.so: undefined reference to
`PR_GetPhysicalMemorySize'
../../../../dist/bin/libxul.so: undefined reference to `PR_NotifyAllCondVar'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetUniqueIdentity'
../../../../dist/bin/libxul.so: undefined reference to `PR_ConnectContinue'
../../../../dist/bin/libxul.so: undefined reference to `PR_snprintf'
../../../../dist/bin/libxul.so: undefined reference to `PR_CreateFileMap'
/usr/lib/libnss3.so: undefined reference to `PR_NewTCPSocket'
/usr/lib64/libplc4.so: undefined reference to `PR_Assert'
../../../../dist/bin/libxul.so: undefined reference to `PR_htons'
../../../../dist/bin/libxul.so: undefined reference to `PR_FreeAddrInfo'
/usr/lib/libnss3.so: undefined reference to `PR_Shutdown'
/usr/lib/libssl3.so: undefined reference to `PR_ImportFileMapFromString'
/usr/lib/libnss3.so: undefined reference to `PR_EnumerateHostEnt'
../../../../dist/bin/libxul.so: undefined reference to `PR_Malloc'
/usr/lib/libnss3.so: undefined reference to `PR_SetErrorText'
../../../../dist/bin/libxul.so: undefined reference to `PR_EnumerateAddrInfo'
../../../../dist/bin/libxul.so: undefined reference to
`PR_ConvertIPv4AddrToIPv6'
../../../../dist/bin/libxul.so: undefined reference to `PR_WaitProcess'
../../../../dist/bin/libxul.so: undefined reference to `PR_IntervalNow'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetHostByName'
../../../../dist/bin/libxul.so: undefined reference to `LL_MaxUint'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetSocketOption'
../../../../dist/bin/libxul.so: undefined reference to `PR_Free'
../../../../dist/bin/libxul.so: undefined reference to `PR_GetPageShift'
../../../../dist/bin/libxul.so: undefined reference to `PR_LogPrint'
../../../../dist/bin/libxul.so: undefined reference to `PR_JoinThread'

[Bug c++/47808] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[schnetter at gmail dot com]

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

Erik Schnetter schnetter at gmail dot com changed:

   What|Removed |Added

  Attachment #23597|0   |1
is obsolete||

--- Comment #6 from Erik Schnetter schnetter at gmail dot com 2011-03-09 
13:47:38 UTC ---
Created attachment 23600
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23600
failing source code

I reduced the source code slightly and used -DNDEBUG. This code fails with the
simplified command

/Users/eschnett/gcc/bin/g++ -std=gnu++0x -c iobasic.ii

[Bug debug/48045] New: dwarf2out emits CU with DW_AT_stmt_list to empty line table

[mark at gcc dot gnu.org]

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

   Summary: dwarf2out emits CU with DW_AT_stmt_list to empty line
table
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


Found using the elfutils dwarflint tool.

Example:
$ echo static int empty;  empty.c
$ gcc -g -c empty.c 
$ readelf --debug-dump=info empty.o | grep DW_AT_stmt
29   DW_AT_stmt_list   : 0x0
$ readelf --debug-dump=decodedline empty.o
Decoded dump of debug contents of section .debug_line:

CU: empty.c:
File nameLine numberStarting address


It seems wrong to output a DW_AT_stmt_list if there are no statements at all.

Possible patch:

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c(revision 170813)
+++ gcc/dwarf2out.c(working copy)
@@ -23485,7 +23486,7 @@
 add_ranges (NULL);
 }

-  if (debug_info_level = DINFO_LEVEL_NORMAL)
+  if (debug_info_level = DINFO_LEVEL_NORMAL  line_info_table_in_use  1)
 add_AT_lineptr (comp_unit_die (), DW_AT_stmt_list,
 debug_line_section_label);

@@ -23512,7 +23513,7 @@
   /* Add a pointer to the line table for the main compilation unit
  so that the debugger can make sense of DW_AT_decl_file
  attributes.  */
-  if (debug_info_level = DINFO_LEVEL_NORMAL)
+  if (debug_info_level = DINFO_LEVEL_NORMAL  line_info_table_in_use 
1)
 add_AT_lineptr (ctnode-root_die, DW_AT_stmt_list,
 debug_line_section_label);

[Bug c++/48035] [4.4/4.5/4.6 Regression] Mismatch on size of class when initializing hierarchy involving virtual inheritance and empty base classes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-09 
14:03:35 UTC ---
I think the problem is that build_zero_init isn't aware of the
DECL_FIELD_IS_BASE FIELD_DECLs and CLASSTYPE_AS_BASE stuff.  So when
simplify_aggr_init_expr decides to call build_zero_init on the
SpecificImplementation type, while the first FIELD_DECL has size 8 and its type
also size 8, the second FIELD_DECL has size 12 (CLASSTYPE_SIZE_UNIT), its type
has size 24 and thus what build_zero_init returns on the subtype isn't directly
usable as ctor of the outer type.

[Bug c++/47808] [C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
14:05:35 UTC ---
template typename T
struct typeprops {
typedef T complex;
typedef T real;
};


namespace good {

template typename T
inline typename typepropsT::real abs (T const  x)
{ return 1; }

}



template typename T bool UseScientificNotation (T const  x);

void
OutputVar (int const n)
{

if (UseScientificNotation (n))
return;
}

template typename T
bool
UseScientificNotation (T const  x)
{

typedef int ai[(good::abs(0.1)  0) ? 1 : -1];

}

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[ian at airs dot com]

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

--- Comment #17 from Ian Lance Taylor ian at airs dot com 2011-03-09 14:11:36 
UTC ---
I have the exact same glibc and kernel versions on FC14, and I don't see it.

Can you attach your executable and your core dump?

[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||4.5.2
   Target Milestone|--- |4.6.0
Summary|[C++0x] internal compiler   |[4.6 Regression][C++0x]
   |error: in   |internal compiler error: in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:13326   |cp/pt.c:13326

[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
14:14:08 UTC ---
that was reduced using the most recent snapshot not HEAD of trunk, so apologies
if it doesn't fail with an up-to-date build

[Bug c++/47808] [4.6 Regression][C++0x] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:13326

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
14:40:48 UTC ---
I can confirm the ICE with r170818.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #54 from Markus Trippelsdorf markus at trippelsdorf dot de 
2011-03-09 14:40:25 UTC ---
Turned out that GNU ld doesn't like --as-needed;
LDFLAGS=-Wl,-O1,--hash-style=gnu,--no-keep-memory works fine.
(although GNU ld uses way more memory than gold.)

[Bug c++/48046] New: [4.5/4.6 Regression] Expected diagnostic reference to 'type' is ambiguous not given for function-local static declaration

[dev.lists at jessamine dot co.uk]

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

   Summary: [4.5/4.6 Regression] Expected diagnostic reference to
 'type' is ambiguous not given for function-local
static declaration
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dev.li...@jessamine.co.uk


In g++ 4.5 and 4.6, a function-local static declared with an ambiguous type
does not yield the expected diagnostic.  It appropriately fails to compile due
to a type not being resolved but doesn't give the user the root cause of the
failure as it did in 4.4.

Given the following code:

   namespace N1 { typedef int   T; }
   namespace N2 { typedef float T; }

   int main()
   {
  using namespace N1;
  using namespace N2;

  static T t;
   }

4.4.5 outputs:

  stdin: In function 'int main()':
  stdin:9: error: reference to 'T' is ambiguous
  stdin:2: error: candidates are: typedef float N2::T
  stdin:1: error: typedef int N1::T
  stdin:9: error: 'T' does not name a type

Both 4.5.0 (an old build I had lying around) and 4.6.0 (at rev 170646) output:

  stdin: In function ‘int main()’:
  stdin:9:14: error: ‘T’ does not name a type

If the static declaration and preceding using directives are moved to namespace
scope rather than being function-local, the expected diagnostic is output.

If the function-local declaration is made non-static, the expected diagnostic
is output.

[Bug tree-optimization/16427] dead memset not optimized away

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
14:56:26 UTC ---
Related to this is

struct X { int i; int j; int k; };
void foo (void)
{
  struct X a, b;
  __builtin_memcpy (a, b, 4);
}

where we are unable to DCE the memcpy call.

Both issues should be tackled at tree DCE level by better handling of
aliased (local) variables.  Needs the same infrastructure changes as
PR41490.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

--- Comment #6 from bero at arklinux dot org 2011-03-09 15:02:55 UTC ---
Created attachment 23601
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23601
stripped down libQt3Support.a

Here's a stripped down version of libQt3Support.a -- linking the preprocessed
widgetinfo.cpp to it causes the crash.

I have both ld 2.21.51.0.6.20110118 with plugin support and gold 1.10
installed; not sure which gcc uses by default. /usr/bin/ld is ld.

[Bug c++/48046] [4.5/4.6 Regression] Expected diagnostic reference to 'type' is ambiguous not given for function-local static declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.09 15:06:48
 Ever Confirmed|0   |1

[Bug target/47619] ICE in printf() with -fsplit-stack enabled.

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu hjl.tools at gmail dot com 2011-03-09 15:11:38 
UTC ---
(In reply to comment #17)
 I have the exact same glibc and kernel versions on FC14, and I don't see it.
 
 Can you attach your executable and your core dump?

I think it may have something to do with system configuration.
The same binary works on another Fedora 13.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

Chris Jefferson chris at bubblescope dot net changed:

   What|Removed |Added

  Attachment #23599|0   |1
is obsolete||

--- Comment #20 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
15:25:19 UTC ---
Created attachment 23602
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23602
Stable sort patch with testcases

Corrected patch.

This is designed the same as the first one, just with some typos fixed.

I have added some more tests for the various sorting algorithms, just so we can
keep an eye on things.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[vincenzo.innocente at cern dot ch]

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

--- Comment #21 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-03-09 15:27:49 UTC ---
On 9 Mar, 2011, at 1:46 PM, paolo.carlini at oracle dot com wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
 
 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 
 2011-03-09 12:46:07 UTC ---
 By the way, as a note to Vincenzo, in general I don't really see the point of
 comparators taking the arguments by value, thus ruling out move-only types,
 among other issues (that clearly shows up in other areas of C++0x). In other
 terms, I don't see the temporary workaround for this issue as a proper
 workaround, more as a best practice ;)
 
The bug showed up initially in a real-software use case were we use a vector of
smart pointer which are typically handled by value.
I then resued an old test of mine to fast prove that the issue was in gcc 4.6.
I will try to build an example using std::shared_ptr  (ours are boost intrusive
shared pointers!)
if is of interest for you.

vincenzo

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
15:28:55 UTC ---
Great. While I test it locally, can you please prepare a ChangeLog entry? For
sure it's much easier for you to write down which are the new functions, the
renames, etc.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
15:33:33 UTC ---
Vincenzo no hurry, thankfully Chris has a patch essentially ready (apparently)
and most likely we can fix the problem over the next hours. But in general I'm
unconvinced that it makes sense for a comparison operator of class types to use
pass by value. I would be interested in understanding more about your use case
(maybe in private, whatever you prefer)

[Bug libfortran/48047] New: Incorrect output rounding of double precision numbers

[thenlich at users dot sourceforge.net]

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

   Summary: Incorrect output rounding of double precision numbers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Created attachment 23603
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23603
Test case

The Fortran library does not round real(8) numbers correctly on output if 39
decimal digits are requested and real(16) is supported. This violates IEEE Std
754-2008 which demands that the minimum of supported significant digits for
correct rounding of all supported binary formats (H) is at least H=39 if the
binary128 format is supported.

Thus, GCC misses this requirement by 1 digit.

The attached program fails because the exact value, as given by
quadmath_snprintf(..., (__float128)0.14285714285714285) is
0.142857142857142849212692681248881854116916656494...

IEEE Std 754-2008 says:
===
5.12.2 External decimal character sequences representing finite numbers   
...
For the purposes of discussing the limits on correctly rounded conversion,
define the following quantities:
...
- for binary128, Pmin (binary128) = 36
...
- M = max(Pmin(bf)) for all supported binary formats bf
...

There might be an implementation-defined limit on the number of significant
digits that can be converted with correct rounding to and from supported binary
formats. That limit, H, shall be such that H = M + 3 and it should be that H
is unbounded.

For all supported binary formats the conversion operations shall support
correctly rounded conversions to or from external character sequences for all
significant digit counts from 1 through H (that is, for all
expressible counts if H is unbounded).
...
===

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
15:53:43 UTC ---
Chris, thanks for dealing with this so quickly.
A small nit, in the new testcase I think the move-assignment operator should
use
ok = rh.ok;
instead of
ok = true;
to preserve the moved-from-ness of the source.
i.e. move-assigning from a moved-from value should make the target have the
same valid but unspecified state as the source.
That's certainly what happens if you move-assign from e.g. an empty unique_ptr,
you don't summon up a new pointee out of nowhere!

[Bug go/48018] libgo needs to handle Solaris 2 syslog

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-03-09 15:55:06 UTC ---
 --- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-03-09 
 06:24:43 UTC ---
 I'm not sure it matters to the syslog writer that Solaris syslog uses 
 STREAMS. 
 I think it only matters to the syslog daemon itself.

I don't think so: vsyslog() in libc (as can be seen in the OpenSolaris
sources: usr/src/lib/libc/port/gen/syslog.c) uses putmsg to communicate
with syslogd.

 What happens if you add /dev/conslog to logPaths in unixSyslog in
 libgo/go/syslog/syslog.go?

Fails: in truss, one sees

10807/4:so_socket(PF_UNIX, SOCK_STREAM, 0, , SOV_DEFAULT) = 3
10807/4:fcntl(3, F_SETFD, 0x0001)   = 0
10807/4:setsockopt(3, SOL_SOCKET, SO_REUSEADDR, 0xFE48F4A0, 4,
SOV_DEFAULT) = 0
10807/4:setsockopt(3, SOL_SOCKET, SO_BROADCAST, 0xFE48F4A8, 4,
SOV_DEFAULT) = 0
10807/4:connect(3, 0xFE4B5588, 15, SOV_DEFAULT) Err#95 ENOTSOCK
10807/4:AF_UNIX  name = /dev/conslog

This isn't a unix domain socket and cannot be used as such.

Rainer

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #25 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
15:55:38 UTC ---
Jon, I'm doing that here, while reformatting a bit the testcases.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #26 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
15:58:24 UTC ---
But, the first line of the method (of all the methods) is:

VERIFY(rh.ok);

So, we know it's true. That might still look more consistent/clear.

Very sorry about the formatting. If this can wait until tomorrow I can get to a
computer with a better editor. It's time like this I wish I'd ever bothered to
learn emacs or vim, or some other editor that runs on all machines and won't
mangle tabs.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[paolo.carlini at oracle dot com]

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

--- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-09 
16:00:52 UTC ---
No problem Chris with the trivial formatting, but please spend a minute on the
ChangeLog, if you can. Thanks.

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[vincenzo.innocente at cern dot ch]

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

--- Comment #28 from vincenzo Innocente vincenzo.innocente at cern dot ch 
2011-03-09 16:01:33 UTC ---
The use case was sloppy coders (we have hundreds of them, a real resource to
find bugs!)

I personally have no problem with const .
Still I remember many tutorials and code examples that suggest that smart
pointers should be passed by value.
const is often perceived as an implementation detail by many non
professional software developers that would like to see those details hidden.
Smart pointers were seen as one of the way to hide memory management from them. 
Move semantics gives new opportunities to move optimization away from user
code: this is one of the reason we are pushing C++0x and we would really like
to be usable now.

vincenzo


here is the code for the shared pointer.

#includememory
#includevector
#includefunctional

#includeiostream
#includealgorithm


struct A {
  A(int ii=-1) : i(ii){}
  int i;
};

typedef std::shared_ptrA Aptr;

struct Aless {
  bool operator()(Aptr lh, Aptr rh) {
return lh-i  rh-i;
  }
};

int main() {

  std::vectorAptr v;
  v.push_back(Aptr(new A(2)));
  v.push_back(Aptr(new A(0)));
  v.push_back(Aptr(new A(1)));
  v.push_back(v[1]);

  for (auto p=v.begin(); p!=v.end(); ++p)
std::cout   (*p)-i   ;
  std::cout  std::endl;


  std::stable_sort(v.begin(),v.end(),Aless());

  for (auto p=v.begin(); p!=v.end(); ++p)
std::cout   (*p)-i   ;
  std::cout  std::endl;

}

On 9 Mar, 2011, at 4:33 PM, paolo.carlini at oracle dot com wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038
 
 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 
 2011-03-09 15:33:33 UTC ---
 Vincenzo no hurry, thankfully Chris has a patch essentially ready (apparently)
 and most likely we can fix the problem over the next hours. But in general I'm
 unconvinced that it makes sense for a comparison operator of class types to 
 use
 pass by value. I would be interested in understanding more about your use case
 (maybe in private, whatever you prefer)
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.

--
Il est bon de suivre sa pente, pourvu que ce soit en montant. 
A.G.
http://www.flickr.com/photos/vin60/1320965757/

[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value

[chris at bubblescope dot net]

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

--- Comment #29 from Chris Jefferson chris at bubblescope dot net 2011-03-09 
16:07:15 UTC ---
Created attachment 23604
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23604
Changelog for stable sort change

Changelog

I've put Jonathan in here, because part of the test case is his example,
copy+pasted.

[Bug fortran/48048] New: [F2003] Remove constraint on namelist group objects

[w6ws at earthlink dot net]

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

   Summary: [F2003] Remove constraint on namelist group objects
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@earthlink.net


Fortran-90/95 had a major constraint on namelist group objects which prevented
the use of non-fixed-length objects.  In F2003, this constraint was removed. 
Compare section 5.4 in F95 with section 5.4 in F2003.

This is not a critical need for me at this point in time.  But I wanted to see
it in the bugzilla for completeness.

[Bug go/48020] libgo flag test FAILs on Solaris 2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot 
Uni-Bielefeld.DE 2011-03-09 16:09:42 UTC ---
 --- Comment #1 from Ian Lance Taylor ian at airs dot com 2011-03-09 
 07:09:58 UTC ---
 I think that the problem is that the functions are not being run in the order
 they appear in the file.  Most likely the Solaris nm program is sorting the
 test functions by name.  The gotest script passes the -p option, which tells

Right, by default it does.

 GNU nm to not sort the functions.  Of course, the gcc middle-end may sort the
 functions anyhow, so this is imperfect?

Sun nm uses -p to produce the portable output format.

 Does the Solaris nm have any option to not sort the symbols?  I don't see one
 on the man page I found on the web.

You could use -v:

 -vSorts  external  symbols  by  value  before  they  are
   printed.

which of course matches the order of the functions in the object file.
This seems to be reasonably portable: GNU nm and the vendor nm's on IRIX
and Tru64 UNIX support it.

 I'm not sure what the best fix is going to be here.

I wonder if it might be an option (at least for a DejaGnu-ified libgo
testsuite) to have individual tests per function instead of per
directory?  This way, it might be easier to see which subtest is
failing, and (undesirable) interactions between them would be avoided.

Rainer

[Bug debug/48049] New: 4.6 Regression? DW_AT_accessibility change breaks GDB

[jan.kratochvil at redhat dot com]

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

   Summary: 4.6 Regression? DW_AT_accessibility change breaks GDB
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: ja...@gcc.gnu.org
Target: x86_64-fedora15-linux-gnu


Only -gdwarf-3 is affected here:

debug/45124 has changed DW_AT_accessibility generation for DWARF-3+.

GGC-4.5 was compatible with GDB but both were not compliant with DWARF-3+.
GCC-4.6 is now DWARF-3+ compliant but it breaks GDB.

By providing DW_AT_accessibility explicitly even for cases when one could
assume a default value may be both compatible with existing GDBs and DWARF-3+
compliant.
I believe this was the Jakub's intention but it did not get implemented in GCC
that way:
Bug 45124 Comment 1:
 I'm afraid we need to live with some extra DW_AT_accessibility attributes for 
  compatibility.

class C { private: int private_; } v;
gcc -c -Wall -gdwarf-3
GNU gdb (GDB) 7.2.50.20110309-cvs

PASS: g++ (GCC) 4.5.3 20110124 (prerelease)
(gdb) ptype C
type = class C {
int private_;
}
 237: Abbrev Number: 3 (DW_TAG_member)
38   DW_AT_name: (indirect string, offset: 0x2e): private_
3c   DW_AT_decl_file   : 1
3d   DW_AT_decl_line   : 4
3e   DW_AT_type: 0x45   
42   DW_AT_data_member_location: 0
43   DW_AT_accessibility: 3   (private)

but:
FAIL: g++ (GCC) 4.6.0 20110309 (experimental)
(gdb) ptype C
type = class C {
  public:
  ^^^
int private_;
}
because:
 237: Abbrev Number: 3 (DW_TAG_member)
38   DW_AT_name: (indirect string, offset: 0x54): private_
3c   DW_AT_decl_file   : 1
3d   DW_AT_decl_line   : 4
3e   DW_AT_type: 0x44   
42   DW_AT_data_member_location: 0


(That GDB should be changed is sure but there may be some DW_AT_producer
checks, depending on how it gets resolved for GCC-4.6.0.)

[Bug c++/48029] [4.5/4.6 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3
Summary|ICE in  |[4.5/4.6 Regression] ICE in
   |finish_member_declaration() |finish_member_declaration()
   |with --param|with --param
   |ggc-min-expand=0 --param|ggc-min-expand=0 --param
   |ggc-min-heapsize=0  |ggc-min-heapsize=0

[Bug c++/48029] [4.5/4.6 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0

[bergner at gcc dot gnu.org]

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

Peter Bergner bergner at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc64-linux |powerpc64-linux,
   ||x86_64-linux
   Host|powerpc64-linux |powerpc64-linux,
   ||x86_64-linux
  Build|powerpc64-linux |powerpc64-linux,
   ||x86_64-linux

--- Comment #6 from Peter Bergner bergner at gcc dot gnu.org 2011-03-09 
16:24:11 UTC ---
Not power64-linux specific, since richi saw this on x86_64-linux too.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

bero at arklinux dot org changed:

   What|Removed |Added

  Attachment #23598|0   |1
is obsolete||
  Attachment #23601|0   |1
is obsolete||

--- Comment #7 from bero at arklinux dot org 2011-03-09 16:27:45 UTC ---
Created attachment 23605
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23605
Much smaller test case

Small self-contained test case, source-only.

$ tar xzf bug48042.tar.gz
$ cd bug48042
$ ./bug48042.sh
In file included from
../../../include/QtCore/../../src/corelib/global/qglobal.h:899:0,
 from :10:
../../../include/Qt3Support/../../src/qt3support/tools/q3glist.h: In member
function ‘count’:
../../../include/Qt3Support/../../src/qt3support/tools/q3glist.h:161:1:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status


The problem goes away if -g is added to the first compiler invocation as well
-- lto seems to fall over some constructs if linking is done with -g but an
object file was built without -g.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
16:32:51 UTC ---
(In reply to comment #7)
 Created attachment 23605 [details]
 Much smaller test case
 
 Small self-contained test case, source-only.
 
 $ tar xzf bug48042.tar.gz
 $ cd bug48042
 $ ./bug48042.sh
 In file included from
 ../../../include/QtCore/../../src/corelib/global/qglobal.h:899:0,
  from :10:
 ../../../include/Qt3Support/../../src/qt3support/tools/q3glist.h: In member
 function ‘count’:
 ../../../include/Qt3Support/../../src/qt3support/tools/q3glist.h:161:1:
 internal compiler error: Segmentation fault
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://gcc.gnu.org/bugs.html for instructions.
 lto-wrapper: g++ returned 1 exit status
 /usr/bin/ld: lto-wrapper failed
 collect2: ld returned 1 exit status
 
 
 The problem goes away if -g is added to the first compiler invocation as well
 -- lto seems to fall over some constructs if linking is done with -g but an
 object file was built without -g.

Ah, yeah - that's a known problem (and hard to fix).  What should work
is dropping -g at link time.

Basically to make your way reliably all conditional clearing in
free_lang_data_in_* based on debug_info_level checks have to be dropped.

[Bug c++/48050] New: [c++] ice with c++ code

[denis.campredon at gmail dot com]

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

   Summary: [c++] ice with c++ code
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.campre...@gmail.com


Created attachment 23606
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23606
reduced preproceded file

whith this command :
g++ test-min.i 

gcc emit this message :


/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.5/include/stddef.h: In
constructor ‘std::Poney::Poney()’:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.5/include/stddef.h:2164:
internal compiler error: Segmentation fault



Here are the configurations:
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.4.5 (GCC)

I tried to with GCC 4.5 a week ago, and there was the ICE too

[Bug target/46419] [4.4, 4.5, 4.6 Regression] _mm_cvtpu16_ps (and hence _mm_cvtpu8_ps) returns false result

[ubizjak at gmail dot com]

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

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||cck0011 at yahoo dot com

--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2011-03-09 16:42:11 
UTC ---
*** Bug 48036 has been marked as a duplicate of this bug. ***

[Bug target/48036] unexpected byte swap in sse _mm_cvtpu16_ps in 64-bit 4.5.1

[ubizjak at gmail dot com]

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

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-03-09 16:42:11 
UTC ---
Duplicate of 46419.

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

[Bug c++/48029] [4.5/4.6 Regression] ICE in finish_member_declaration() with --param ggc-min-expand=0 --param ggc-min-heapsize=0

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|GC  |
   Priority|P3  |P2

--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
16:46:19 UTC ---
Also ICEs when not collecting at all.

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[bero at arklinux dot org]

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

bero at arklinux dot org changed:

   What|Removed |Added

  Attachment #23605|0   |1
is obsolete||

--- Comment #9 from bero at arklinux dot org 2011-03-09 16:46:24 UTC ---
Created attachment 23607
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23607
Reduced test case

Reduced test case, comes down to 10 lines of code

[Bug c++/48050] [c++] ice with c++ code

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
16:51:05 UTC ---
4.6 correctly rejects it
error: assigning to an array from an initializer list

I think this is a dup of PR 44045

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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 CC||denis.campredon at gmail
   ||dot com

--- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-09 
16:51:05 UTC ---
*** Bug 48050 has been marked as a duplicate of this bug. ***

[Bug lto/48042] lto segfaults while building Qt 4.7.2 with -g -flto -fwhole-program

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||lto

--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-09 
16:56:31 UTC ---
Thanks.  Quoted:

class A {
virtual int x() = 0;
};

class B:public A {
int x();
};

int B::x() {
}

rguenther@murzim:/tmp/bug48042 /space/rguenther/install/gcc-4.6.0/bin/g++ -c
test.cpp -flto
rguenther@murzim:/tmp/bug48042 /space/rguenther/install/gcc-4.6.0/bin/g++
test.o -flto -g
In file included from test.cpp:10:0,
 from :5:
test.cpp: In member function 'x':
test.cpp:10:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

[Bug tree-optimization/47714] [4.6 Regression] verify_ssa fails with error: invalid argument to gimple call

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2011-03-09 
16:59:59 UTC ---
Author: jamborm
Date: Wed Mar  9 16:59:55 2011
New Revision: 170822

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170822
Log:
2011-03-09  Martin Jambor  mjam...@suse.cz

PR tree-optimization/47714
* cp/method.c (use_thunk): Clear addressable flag of thunk arguments.

* testsuite/g++.dg/torture/pr47714.C: New test.



Added:
trunk/gcc/testsuite/g++.dg/torture/pr47714.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog