[Bug libstdc++/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 08:00:38 
UTC ---
Following testcase shows the problem in libstdc++:

--cut here--
#include iostream
#include sstream
#include cassert

void test01()
{
  using namespace std;

  stringstream ostr1;

  ostr1.setf(ios_base::oct);
  ostr1.setf(ios_base::hex);

  short s = -1;
  ostr1  s;

  cout  result:   ostr1.str()  endl;

  assert( ostr1.str() == -1 );
}

int main()
{
  test01();
  return 0;
}
--cut here--

[uros@localhost test]$ ./a.out
result: 65535
a.out: 7.cc:19: void test01(): Assertion `ostr1.str() == -1' failed.
Aborted

Sign-extension from short is missing somewhere.

[Bug c++/51671] New: g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter

[jwalden+ggo at mit dot edu]

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

 Bug #: 51671
   Summary: g++ fails to allow a redundant typedef if the
redundant typedef depends on a template parameter
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jwalden+...@mit.edu


[jwalden@wheres-wally reduction]$ cat minimal.cpp 
template int T
struct S
{
  static void f()
  {
typedef int q[1];
typedef int q[T];
  }
};
[jwalden@wheres-wally reduction]$ ~/Programs/gcc-build/prefixdir/bin/g++
minimal.cpp 
minimal.cpp: In static member function ‘static void ST::f()’:
minimal.cpp:7:20: error: conflicting declaration ‘typedef int q [T]’
minimal.cpp:6:17: error: ‘q’ has a previous declaration as ‘typedef int q [1]’
[jwalden@wheres-wally reduction]$ (cd ~/Programs/gcc-build/trunk/  svn info)
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 182676
Node Kind: directory
Schedule: normal
Last Changed Author: torvald
Last Changed Rev: 182676
Last Changed Date: 2011-12-23 20:42:48 -0500 (Fri, 23 Dec 2011)

If S is only instantiated with T = 1, the second typedef redefines q to the
same type as the first, so it should be allowed.

I happened to hit this while attempting to roll my own static_assert macro. 
(The C++11 static_assert isn't an option for various reasons.)

[Bug c++/51671] g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter

[jwalden+ggo at mit dot edu]

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

--- Comment #1 from Jeff Walden (remove +ggo to email) jwalden+ggo at mit dot 
edu 2011-12-24 09:18:51 UTC ---
For what it's worth, clang also has this bug.  See
http://llvm.org/bugs/show_bug.cgi?id=11630, which is this bug plus an extra
testcase that GCC handles correctly.

[Bug target/51670] [4.7.0] conflicts with new declaration with 'C++' linkage

[marc.glisse at normalesup dot org]

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

Marc Glisse marc.glisse at normalesup dot org changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #8 from Marc Glisse marc.glisse at normalesup dot org 2011-12-24 
09:40:54 UTC ---
This is supposed to be handled by fixinclude in the solaris_cxx_linkage rule.
Can you try and see why it isn't applied?

[Bug libstdc++/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
10:17:00 UTC ---
Note that the library code for this is very old and didn't change lately. I'll
have a look but a compiler issue seems much more likely.

[Bug tree-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

  Component|libstdc++   |tree-optimization

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
10:44:55 UTC ---
Ah now I see you already identified a pass.

[Bug tree-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-24 
10:50:45 UTC ---
Does it occur with the 32-bit compiler as well?  If so, how come the pass has
been enabled in 32-bit mode by default?

[Bug c++/51672] New: The optimization flags O2 O3 produces wrong code

[benmeida at hotmail dot com]

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

 Bug #: 51672
   Summary: The optimization flags O2  O3 produces wrong code
Classification: Unclassified
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: benme...@hotmail.com


Created attachment 26180
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26180
preprocessed file

Compiling with the optimization flags O2  O3 produces wrong code  wrong
results. But with the flag O1 or O2, the program output the correct results :

3
1
2
0

O2  O3 flags output :

65535
1
2
0

Compiled by : g++ -g -O3 -W -Wall -mtune=native -march=native -msse3
test_all.cpp -o test_all

Using :
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.2
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=x86_64-suse-linux
Thread model: posix
gcc version 4.2.1 (SUSE Linux)


The wrong assembly part marked by ! with (-O3):

  400b0a:48 ba 0f 00 0f 00 0f mov$0xf000f000f000f,%rdx
  400b11:00 0f 00 
  400b14:48 33 11 xor(%rcx),%rdx
!  400b17:66 c7 04 41 0f 00movw   $0xf,(%rcx,%rax,2) Insert
function
  400b1d:66 83 fa 01  cmp$0x1,%dx
  400b21:48 89 d0 mov%rdx,%rax

[Bug c++/51672] The optimization flags O2 O3 produces wrong code

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
11:34:22 UTC ---
Note that gcc4.2.x is very old and not maintained anymore.

[Bug c++/51672] The optimization flags O2 O3 produces wrong code

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
11:41:22 UTC ---
Plus, your *.ii doesn't even compile with modern GCCs. Please see if you can
reproduce the problem with gcc4.6.x and in case open a new PR. Thanks.

[Bug ada/51114] ICE when creating a private derived type

[frederic.praca at free dot fr]

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

--- Comment #2 from Frédéric Praca frederic.praca at free dot fr 2011-12-24 
11:43:37 UTC ---
Created attachment 26181
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26181
Simpler source code that triggers the problem

To make the problem easier to understand, I coded a simpler source code.

[Bug c++/51671] g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-24
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
11:56:22 UTC ---
ICC is fine instead, indeed in my experience in quite a few cases tries to do
less at definition time. Delaying the check shouldn't be too hard.

[Bug c++/51671] g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
12:11:22 UTC ---
I suppose tweaking comp_array_types should do it...

[Bug tree-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 12:20:24 
UTC ---
REE pass miscompiles std::ostream::operator(short):

Dump of assembler code for function std::ostream::operator(short):
= 0x001998f0 +0: push   %ebx
   0x001998f1 +1: sub$0x18,%esp
   0x001998f4 +4: call   0x156e4b __x86.get_pc_thunk.bx
   0x001998f9 +9: add$0x5a6fb,%ebx
   0x001998ff +15:mov0x20(%esp),%edx
   0x00199903 +19:movzwl 0x24(%esp),%ecx
   0x00199908 +24:mov%edx,(%esp)
   0x0019990b +27:mov%ecx,0x4(%esp)
   0x0019990f +31:call   0x154630 _ZNSo9_M_insertIlEERSoT_@plt
   0x00199914 +36:add$0x18,%esp
   0x00199917 +39:pop%ebx
   0x00199918 +40:ret
End of assembler dump.

This is without REE pass:

Dump of assembler code for function std::ostream::operator(short):
= 0x00199960 +0: push   %ebx
   0x00199961 +1: sub$0x18,%esp
   0x00199964 +4: mov0x20(%esp),%edx
   0x00199968 +8: call   0x156e4b __x86.get_pc_thunk.bx
   0x0019996d +13:add$0x5b687,%ebx
   0x00199973 +19:movzwl 0x24(%esp),%ecx
   0x00199978 +24:mov(%edx),%eax
   0x0019997a +26:mov-0xc(%eax),%eax
   0x0019997d +29:mov0xc(%edx,%eax,1),%eax
   0x00199981 +33:and$0x4a,%eax
   0x00199984 +36:cmp$0x8,%eax
   0x00199987 +39:je 0x1999a8 std::ostream::operator(short)+72
   0x00199989 +41:cmp$0x40,%eax
   0x0019998c +44:je 0x1999a8 std::ostream::operator(short)+72
   0x0019998e +46:movswl %cx,%ecx
   0x0011 +49:mov%ecx,0x4(%esp)
   0x0015 +53:mov%edx,(%esp)
   0x0018 +56:call   0x154630 _ZNSo9_M_insertIlEERSoT_@plt
   0x001d +61:add$0x18,%esp
   0x001999a0 +64:pop%ebx
   0x001999a1 +65:ret
   0x001999a2 +66:lea0x0(%esi),%esi
   0x001999a8 +72:movzwl %cx,%ecx
   0x001999ab +75:mov%ecx,0x4(%esp)
   0x001999af +79:mov%edx,(%esp)
   0x001999b2 +82:call   0x154630 _ZNSo9_M_insertIlEERSoT_@plt
   0x001999b7 +87:add$0x18,%esp
   0x001999ba +90:pop%ebx
   0x001999bb +91:ret
End of assembler dump.

Just break at _ZNSolsEs to see wrong code in action. Please also note movsl in
good code.

[Bug tree-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 12:23:17 
UTC ---
(In reply to comment #6)
 Does it occur with the 32-bit compiler as well?  If so, how come the pass has
 been enabled in 32-bit mode by default?

The problem is exposed for 32bit targets. REE pass was enabled also for 32bit
targets with commit [1].

[1] http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00745.html

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 12:39:50 
UTC ---
This is rtl-optimization problem.

FYI: 64bit targets compile to:

Dump of assembler code for function _ZNSolsEs:
= 0x003dd2c98c10 +0: mov(%rdi),%rax
   0x003dd2c98c13 +3: mov-0x18(%rax),%rax
   0x003dd2c98c17 +7: mov0x18(%rdi,%rax,1),%eax
   0x003dd2c98c1b +11:and$0x4a,%eax
   0x003dd2c98c1e +14:cmp$0x8,%eax
   0x003dd2c98c21 +17:je 0x3dd2c98c38 _ZNSolsEs+40
   0x003dd2c98c23 +19:cmp$0x40,%eax
   0x003dd2c98c26 +22:je 0x3dd2c98c38 _ZNSolsEs+40
   0x003dd2c98c28 +24:movswq %si,%rsi
   0x003dd2c98c2c +28:jmpq   0x3dd2c58df0
_ZNSo9_M_insertIlEERSoT_@plt
   0x003dd2c98c31 +33:nopl   0x0(%rax)
   0x003dd2c98c38 +40:movzwl %si,%esi
   0x003dd2c98c3b +43:jmpq   0x3dd2c58df0
_ZNSo9_M_insertIlEERSoT_@plt
End of assembler dump.

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 12:46:38 
UTC ---
The problem is illustrated in the second code dump of Comment #7. The second
movzwl can be merged with the first one, but we still need movswl to correctly
extend the HImode value to SImode.

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

[pluto at agmk dot net]

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

 Bug #: 51673
   Summary: undefined references / libstdc++-7.dll
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


Created attachment 26182
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26182
testcase with libstdc++-6/7.dll

with gcc crosscompiler configured for target x86_64-pc-mingw32 with
--enable-symvers=gnu-versioned-namespace --enable-libstdcxx-allocator=mt
i'm getting linker errors on trivial testcase.


/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb18allocateEyPKv[__gnu_cxx::__7::__mt_allocint,
__gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true
::allocate(unsigned long long, void const*)]+0x63): undefined reference to
`operator new(unsigned long long)'
/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb18allocateEyPKv[__gnu_cxx::__7::__mt_allocint,
__gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true
::allocate(unsigned long long, void const*)]+0x142): undefined reference to
`__gnu_cxx::__7::__pooltrue::_M_reserve_block(unsigned long long, unsigned
long long)'
/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb110deallocateEPiy[__gnu_cxx::__7::__mt_allocint,
__gnu_cxx::__7::__common_pool_policy__gnu_cxx::__7::__pool, true
::deallocate(int*, unsigned long long)]+0x6d): undefined reference to
`__gnu_cxx::__7::__pooltrue::_M_reclaim_block(char*, unsigned long long)'


afaics the libstdc++7.dll doesn't export e.g. _Znwy* symbols
while libstdc++-6.dll looks fine in this area:

$ 86_64-pc-mingw32-objdump -p libstdc++-6.dll|grep _Znw

[3472] _Znwy
[3473] _ZnwyRKSt9nothrow_t

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

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org,
   ||paolo.carlini at oracle dot
   ||com

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
13:01:47 UTC ---
Versioned is for Benjamin to look at, I guess.

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 13:36:43 
UTC ---
Testcase:

--cut here--
void abort (void);

void __attribute__((noinline))
bar (int a)
{
  if (a != -1)
abort ();
}

void __attribute__((noinline))
foo (short *a, int t)
{
  unsigned int r = *a;

  if (t)
bar ((unsigned short) r);
  else
bar ((signed short) r);
}

short v = -1;

int main()
{
  foo (v, 0);
  return 0;
}
--cut here--

Fails also on x86_64-pc-linux-gnu.

$ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc -O2 -free pr51667.c
$ ./a.out
Aborted
$ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc -O2 -fno-ree pr51667.c
$ ./a.out
$

[Bug c++/51672] The optimization flags O2 O3 produces wrong code

[benmeida at hotmail dot com]

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

--- Comment #3 from Marouane BENMEIDA benmeida at hotmail dot com 2011-12-24 
13:49:09 UTC ---
Problems gone on g++ 4.6.2

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 13:50:16 
UTC ---
foo can be simplified a bit:

void __attribute__((noinline))
foo (short *a, int t)
{
  short r = *a;

  if (t)
bar ((unsigned short) r);
  else
bar ((signed short) r);
}

[Bug c++/51672] The optimization flags O2 O3 produces wrong code

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
13:52:24 UTC ---
Ah, very good, thanks for checking.

[Bug c++/51674] New: No errors on non-existent symbol in costructor

[so.townsend at gmail dot com]

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

 Bug #: 51674
   Summary: No errors on non-existent symbol in costructor
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: so.towns...@gmail.com


Created attachment 26183
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26183
Example of problem

Creating a class with a constructor that calls another construct with a non
existent symbol yields a segfault and no compile time errors or warnings.

Both -std=C++0x and standard compilation have the same issue.

[Bug c++/51674] No errors on non-existent symbol in constructor

[so.townsend at gmail dot com]

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

--- Comment #1 from So Townsend so.townsend at gmail dot com 2011-12-24 
14:02:34 UTC ---
Comment on attachment 26183
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26183
Example of problem

#include iostream

class Foo
{
public:
   Foo()
   {
   Foo(a);
   }

   Foo(int x)
   {
   }
};

int main()
{
   Foo f;
   return 0;
}

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ubizjak at gmail dot com]

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

--- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2011-12-24 14:10:44 
UTC ---
I'll leave this one to somebody more familiar with dataflow.

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

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-24 
14:11:00 UTC ---
Do we want to define mt_allocator in v7?
Is it worth keeping all the ext allocators in the library forever?

If not, we could conditionally define them only when configured for v6, which
would solve this problem.

[Bug c++/51674] No errors on non-existent symbol in constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-24 
14:12:08 UTC ---
that doesn't call a constructor, it declares an object called a, so is
identical to:

Foo()
{
  Foo a;
}

which causes an infinite recursion

[Bug c++/51674] No errors on non-existent symbol in constructor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-24 
14:14:16 UTC ---
well, sorry, it does call a constructor, but it calls the same one (the default
cosntructor) 

it doesn't call the other constructor with a non-existent symbol

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

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-24 
14:37:23 UTC ---
I don't have a strong opinion, but it's a bit hard to make a choice: the legacy
HP/SGI pool still makes sense; mt too, has some problems, but we spent quite a
bit of time on it, works decently well in a few circumstances (still, I have to
tell Pawel, enabling it as default allocator isn't something one should do with
light heart); bitmap I would not include, actually I would deprecate and remove
it completely, you know that already.

[Bug middle-end/47602] Permit inline asm to clobber PIC register

[kaffeemonster at googlemail dot com]

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

Jan Seiffert kaffeemonster at googlemail dot com changed:

   What|Removed |Added

 CC||kaffeemonster at googlemail
   ||dot com

--- Comment #15 from Jan Seiffert kaffeemonster at googlemail dot com 
2011-12-24 15:54:23 UTC ---
As a heavy inline asm user myself, i can understand the pain to handle PIC
yourself, but there is no way around that.

You can accidentally use the PIC register by a memory operand (m). Then the
compiler can not save it for you.

Greetings
Jan

[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org

--- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-24 
16:37:25 UTC ---
Investigating.

[Bug c++/51675] New: [C++11][New in 4.7] Cannot create constexpr unions

[classixretrox at gmail dot com]

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

 Bug #: 51675
   Summary: [C++11][New in 4.7] Cannot create constexpr unions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: classixret...@gmail.com


union foo
{
int x = 0;
short y;

constexpr foo() = default;
};

This code compiles under GCC 4.6, however, not GCC 4.7.  It works if I remove
the constexpr keyword.

Output of GCC:
test.cc:6:12: error: explicitly defaulted function ‘constexpr foo::foo()’
cannot be declared as constexpr because the implicit declaration is not
constexpr:
test.cc:4:8: note: defaulted default constructor does not initialize ‘short int
foo::y’

If I provide only one initialization, it tells me that the others are
initialized.  If I initialize the others, it tells me that I can't initialize
more than one.  It essentially prevents the creation of constexpr unions.

[Bug c++/51675] [C++11][New in 4.7] Cannot create constexpr unions

[classixretrox at gmail dot com]

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

--- Comment #1 from RétroX classixretrox at gmail dot com 2011-12-24 18:24:45 
UTC ---
More information: initializing in the constructor doesn't work, either.

union foo
{
int x;
short y;

constexpr foo() : x(0) { }
};

Also does not compile.

[Bug target/51670] [4.7.0] conflicts with new declaration with 'C++' linkage

[pashev.igor at gmail dot com]

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

Igor Pashev pashev.igor at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #9 from Igor Pashev pashev.igor at gmail dot com 2011-12-24 
18:39:49 UTC ---
(In reply to comment #8)
 This is supposed to be handled by fixinclude in the solaris_cxx_linkage rule.
 Can you try and see why it isn't applied?

Well, I'm a little confused.

Directory /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include-fixed was mostly
empty.
I run /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/install-tools/mkheaders, and now
that directory is full on fixed headers.

Now g++ does work.


BTW GCC 4.6.2 in Solaris ships all possible fixed headers :-\

[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|[C++11][New in 4.7] Cannot  |[C++11][4.7 Regression]
   |create constexpr unions |Cannot create constexpr
   ||unions
   Severity|major   |normal

[Bug libstdc++/51653] More compact std::tuple

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2011-12-24 
22:25:51 UTC ---
(In reply to comment #1)
 I'm not yet convinced we want to apply it,

Hi,

just so I know, what part are you not convinced about?
1) that we want a library solution? it is just a proof of concept, I would be
happy with a compiler solution (although it might still require a library
rewrite so it can be applied).
2) that we want a more compact tuple? sizeof(tuplechar,tuplechar,int) is
currently 16, that's twice as much as necessary (in case someone wonders, the
unexpected extra 4 is there for the same reason that tupletupletupleint
has size 12, ie derivation from the empty tuple).

Note that it is not obvious how to efficiently (you can't try all n! orders...)
determine the best layout. In the code I just put all the empty types first and
then the rest sorted by decreasing alignment, but that heuristic is not optimal
for several reasons:
- there can be hidden empty types in the bigger types
- if we use derivation also for non-empty types, the size (without tail
padding) is not a multiple of the alignment anymore and the heuristic doesn't
make much sense anymore.

[Bug c/51676] New: -Wsuggest-attribute={pure,const} should give line number of declaration, not definition

[b.r.longbons at gmail dot com]

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

 Bug #: 51676
   Summary: -Wsuggest-attribute={pure,const} should give line
number of declaration, not definition
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26184
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26184
minimal testcase for both attributes

Although it's obvious why GCC does what it does, it would be much more useful
if these warnings would give the location at which the attribute would be
added.

Expected result:
Warnings at the (first) declaration. In attached testcase, on lines 2 and 3
(which would usually be in a header file).

Actual result:
Warnings at the definition. In testcase, on lines 4 and 5 (which are usually in
the implementation file).

Tested with: 4.6.0, 4.6.1, 4.6.2, and trunk r182496

[Bug c/51677] New: don't suggest giving main() __attribute__((const))

[b.r.longbons at gmail dot com]

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

 Bug #: 51677
   Summary: don't suggest giving main() __attribute__((const))
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


With -O -Wsuggest-attribute=const, the following line will generate a warning:
int main() {}

This behavior is bad for 2 reasons:
1. Having an empty main() is quite useful for testing, as it allows linking to
succeed.
2. __attribute__((const)) is only meaningful when you can call the function.

Tested: 4.6.{0..2}, trunk r182496