[Bug bootstrap/51648] [4.7 Regression] Profiledbootstrap failure on x86_64-linux

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-23 
08:21:18 UTC ---
Created attachment 26169
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26169
gcc.i

Somewhat delta reduced gcc.i which still triggers it.  Surprisingly even
removing an unused function definition from it makes the bug go away, will have
to review the code generation differences.

[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
09:10:27 UTC ---
Author: rguenth
Date: Fri Dec 23 09:10:18 2011
New Revision: 182653

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182653
Log:
2011-12-23  Richard Guenther  rguent...@suse.de

PR rtl-optimization/50396
* simplify-rtx.c (simplify_binary_operation_1): Properly
guard code that only works for integers.

* gcc.dg/torture/pr50396.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr50396.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug c/51656] C front end and strtold handle hexadecimal floating differently

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
09:14:28 UTC ---
This looks more like a glibc issue, so please file it at sourceware.org.
For me on a x86_64 host, i686 target system it does:

0x9.1a1c9420419a1a0p+0
-0xd.cbc6d7cp+27

same on x86_64 target.  Huh ;)  glibc 2.9.

[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
09:16:16 UTC ---
Author: rguenth
Date: Fri Dec 23 09:16:08 2011
New Revision: 182654

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182654
Log:
2011-12-23  Richard Guenther  rguent...@suse.de

PR rtl-optimization/50396
* simplify-rtx.c (simplify_binary_operation_1): Properly
guard code that only works for integers.

* gcc.dg/torture/pr50396.c: New testcase.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr50396.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/simplify-rtx.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
09:17:41 UTC ---
Thanks ... :(

[Bug rtl-optimization/50396] SSE division by zero generates incorrect code with optimizations enabled

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.6.3, 4.7.0
 Resolution||FIXED
   Target Milestone|--- |4.6.3
  Known to fail|4.7.0   |4.6.2
   Severity|major   |normal

--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
09:19:30 UTC ---
Fixed for 4.6.3.

[Bug c++/51661] ICE when template class list repeated

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-23
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-23 
10:19:06 UTC ---
No ICE in release-mode.

[Bug c++/51660] ICE on function missing argument list

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-23
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-23 
10:19:35 UTC ---
No ICE in release-mode.

[Bug other/51662] New: Temporary objects gets garbage collected in cc1

[max at duempel dot org]

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

 Bug #: 51662
   Summary: Temporary objects gets garbage collected in cc1
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@duempel.org


Created attachment 26170
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26170
Workaround

After rebasing cegcc/mingw32ce on gcc 4.6.2, I found cc1 crashing.
locate_fn_flags() creates an object ob that is not yet inserted into the root
tree, and lookup_fnfields() eventually causes a garbage collection. This may
kill the page where ob lives in, causing a segmentation fault.

I found a kludge to work around it: I increase function_depth to inhibit
garbage collection. See attached patch.

Another idea would be to call lookup_fnfields() before allocating ob, but
since I don't know the code base, I don't know if this is safe.

Also note that this may or may not be caused / triggered by cegcc specific
patches. Just in case you want to review these:
http://git.xcsoar.org/cgit/max/cegcc-gcc.git/log/?h=ice

[Bug other/51662] Temporary objects gets garbage collected in cc1

[max at duempel dot org]

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

--- Comment #1 from Max Kellermann max at duempel dot org 2011-12-23 10:34:50 
UTC ---
Created attachment 26171
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26171
Backtrace of garbage collector; #19 is the allocation

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
10:41:02 UTC ---
(In reply to comment #13)
 Reduced (it almost identical to the first testcase):
 
 struct T;
 class C
 {
 public:
 typedef ::T T;
 virtual void E();
 static T *m ()
   {
 static T *d;
 return d;
   }
 };
 int
 fn ()
 {
   C::m ();
 }
 int main() {}

From the C++ frontend the sequence is that we call debug_hooks-function_decl
for C::m from rest_of_handle_final which creates the type DIE for T.  With
LTO everything but main is optimized out, but we still emit debug info for
C::m::d via emit_debug_global_declarations () because we think C::m::d is
still live (for some reason ...).

That is, without LTO but with -fwhole-program we do not output
_ZZN1C1mEvE1d but with -flto we do (but we do not output C::m in either
case).  That seems to be a missed optimization (at least), probably
caused by applying the whole-program assumption late at WPA time:


Marking local functions: fn m


Marking externally visible functions: main


Marking externally visible variables:


Needed variables: d

why is d needed?

Reclaiming functions: fn m


cgraph pre whole_program_function_and_variable_visibility time:

main/2 @0x75a29900 (asm: main) availability:available analyzed reachable
body externally_visible prevailing_def finalized
  called by: 
  calls: 
  References: 
  Refering this function: 
fn/1 @0x75a297e0 (asm: _Z2fnv) availability:available analyzed reachable
body externally_visible prevailing_def_ironly finalized
  called by: 
  calls: m/0 (1.00 per call) 
  References: 
  Refering this function: 
m/0 @0x75a296c0 (asm: _ZN1C1mEv) availability:available analyzed reachable
body externally_visible finalized
  called by: fn/1 (1.00 per call) 
  calls: 
  References:  var:d (read)
  Refering this function: 

it seems that m/0 lacks a resolution, the resolution file has

1
t.o 3
195 67dffb6b12d80baf PREVAILING_DEF_IRONLY _Z2fnv
200 67dffb6b12d80baf PREVAILING_DEF main
202 67dffb6b12d80baf PREVAILING_DEF_IRONLY _ZZN1C1mEvE1d

hm.  And the function decl for m looks like

 function_decl 0x75b60c00 m
type function_type 0x75b5f7e0
...
addressable used nothrow public static weak autoinline QI defer-output
...

and it is DECL_COMDAT, so we do not output it to the LTO IL symtab and
thus do not get a resolution for it from the first loop.  In the
2nd loop we do not output it because the node isn't DECL_EXTERNAL either.

Why do we never output comdat unsharable functions and thus do not get
a resolution (which would be valid even if we end up unsharing them)?

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
11:13:20 UTC ---
We can fix the resolution with

Index: gcc/lto-symtab.c
===
--- gcc/lto-symtab.c(revision 182652)
+++ gcc/lto-symtab.c(working copy)
@@ -715,6 +715,14 @@ lto_symtab_merge_cgraph_nodes_1 (void **
 {
   lto_symtab_entry_t e, prevailing = (lto_symtab_entry_t) *slot;

+  if (prevailing-guessed)
+{
+  if (prevailing-node)
+   prevailing-node-resolution = prevailing-resolution;
+  if (prevailing-vnode)
+   prevailing-vnode-resolution = prevailing-resolution;
+}
+
   if (!prevailing-next)
 return 1;

but still the local static is marked needed because of

  if (node-finalized)
varpool_mark_needed_node (node);

in input_varpool_node.  Not sure why we stream that flag at all?  Surely
whether to output sth is to be still decided?

I would say sth like

Index: gcc/lto-cgraph.c
===
--- gcc/lto-cgraph.c(revision 182652)
+++ gcc/lto-cgraph.c(working copy)
@@ -1080,6 +1080,8 @@ input_varpool_node (struct lto_file_decl
   DECL_EXTERNAL (node-decl) = 1;
   TREE_STATIC (node-decl) = 0;
 }
+  if (!flag_ltrans)
+node-finalized = 0;
   if (node-finalized)
 varpool_mark_needed_node (node);
   if (non_null_aliasof)

is in order, or a similar

Index: gcc/lto-cgraph.c
===
--- gcc/lto-cgraph.c(revision 182652)
+++ gcc/lto-cgraph.c(working copy)
@@ -565,7 +565,7 @@ lto_output_varpool_node (struct lto_simp
   bp = bitpack_create (ob-main_stream);
   bp_pack_value (bp, node-externally_visible, 1);
   bp_pack_value (bp, node-force_output, 1);
-  bp_pack_value (bp, node-finalized, 1);
+  bp_pack_value (bp, in_lto_p  node-finalized, 1);
   bp_pack_value (bp, node-alias, 1);
   bp_pack_value (bp, node-alias_of != NULL, 1);
   gcc_assert (node-finalized || !node-analyzed);

Honza?

[Bug lto/51663] New: LTO does not reclaim comdat-local statics

[rguenth at gcc dot gnu.org]

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

 Bug #: 51663
   Summary: LTO does not reclaim comdat-local statics
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org


struct T;
struct C
{
typedef ::T T;
virtual void E();
static T *m ()
  {
static T *d;
return d;
  }
};
int
fn ()
{
  C::m ();
}
int main() {}

The C++ frontend with -fwhole-program reclaims C::m::d, but LTO using
the linker plugin does not.  See PR51650 comment #15 and #16 for some
analysis.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
11:23:56 UTC ---
(In reply to comment #16)
 We can fix the resolution with
 
 Index: gcc/lto-symtab.c
 ===
 --- gcc/lto-symtab.c(revision 182652)
 +++ gcc/lto-symtab.c(working copy)
 @@ -715,6 +715,14 @@ lto_symtab_merge_cgraph_nodes_1 (void **
  {
lto_symtab_entry_t e, prevailing = (lto_symtab_entry_t) *slot;
 
 +  if (prevailing-guessed)
 +{
 +  if (prevailing-node)
 +   prevailing-node-resolution = prevailing-resolution;
 +  if (prevailing-vnode)
 +   prevailing-vnode-resolution = prevailing-resolution;
 +}
 +
if (!prevailing-next)
  return 1;
 
 but still the local static is marked needed because of
 
   if (node-finalized)
 varpool_mark_needed_node (node);
 
 in input_varpool_node.  Not sure why we stream that flag at all?  Surely
 whether to output sth is to be still decided?
 
 I would say sth like
 
 Index: gcc/lto-cgraph.c
 ===
 --- gcc/lto-cgraph.c(revision 182652)
 +++ gcc/lto-cgraph.c(working copy)
 @@ -1080,6 +1080,8 @@ input_varpool_node (struct lto_file_decl
DECL_EXTERNAL (node-decl) = 1;
TREE_STATIC (node-decl) = 0;
  }
 +  if (!flag_ltrans)
 +node-finalized = 0;
if (node-finalized)
  varpool_mark_needed_node (node);
if (non_null_aliasof)
 
 is in order, or a similar
 
 Index: gcc/lto-cgraph.c
 ===
 --- gcc/lto-cgraph.c(revision 182652)
 +++ gcc/lto-cgraph.c(working copy)
 @@ -565,7 +565,7 @@ lto_output_varpool_node (struct lto_simp
bp = bitpack_create (ob-main_stream);
bp_pack_value (bp, node-externally_visible, 1);
bp_pack_value (bp, node-force_output, 1);
 -  bp_pack_value (bp, node-finalized, 1);
 +  bp_pack_value (bp, in_lto_p  node-finalized, 1);
bp_pack_value (bp, node-alias, 1);
bp_pack_value (bp, node-alias_of != NULL, 1);
gcc_assert (node-finalized || !node-analyzed);
 
 Honza?

See PR51663 for this issue.

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
11:45:53 UTC ---
Even for

struct T;
struct C
{
typedef ::T T;
static T *m ()
  {
static T *d __attribute__((used));
return d;
  }
};
int
fn ()
{
  C::m ();
}
int main() {}

the C++ frontend works fine with -fwhole-program -g, outputting debug
information for C::m()::d (but in a way not accessible to gdb - huh):

16  int main() {}
(gdb) ptype 'C::m()::d' 
type = data variable, no debug info
(gdb) p 'C::m()::d' 
$1 = 0

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
11:51:41 UTC ---
A workaround for ICEs of this form is

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 182652)
+++ gcc/dwarf2out.c (working copy)
@@ -22496,15 +22496,23 @@ dwarf2out_finish (const char *filename)
  else if (TYPE_P (node-created_for))
context = TYPE_CONTEXT (node-created_for);

- gcc_assert (context
-  (TREE_CODE (context) == FUNCTION_DECL
- || TREE_CODE (context) == NAMESPACE_DECL));
+ if (!(context
+(TREE_CODE (context) == FUNCTION_DECL
+   || TREE_CODE (context) == NAMESPACE_DECL)))
+   {
+ if (!in_lto_p)
+   gcc_unreachable ();

- origin = lookup_decl_die (context);
- if (origin)
-   add_child_die (origin, die);
+ add_child_die (comp_unit_die (), die);
+   }
  else
-   add_child_die (comp_unit_die (), die);
+   {
+ origin = lookup_decl_die (context);
+ if (origin)
+   add_child_die (origin, die);
+ else
+   add_child_die (comp_unit_die (), die);
+   }
}
}
 }

just in case you want to look further ;)

[Bug c++/51664] New: comparison incorrectly treated as template instantiation

[timon.gehr at gmx dot ch]

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

 Bug #: 51664
   Summary: comparison incorrectly treated as template
instantiation
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: timon.g...@gmx.ch


The following valid C++ code is rejected by GCC 4.6.1:

---
templateclass T bool foo(T x){return x.foo1;}
---
$ g++ bug.cpp
---
bug.cpp: In function ‘bool foo(T)’:
bug.cpp:1:42: error: parse error in template argument list
---


(The following similar code compiles:

templateclass T bool bar(T x){return x.foo1;}

while the compilation of this code shows another instance of this broken
behavior:

templateclass T bool foo(T x){return x.qux1;}
templateclass T bool bar(T x){return x.foo1;} )



further details:

$ cat bug.cpp
templateclass T bool foo(T x){return x.foo1;}

$ g++ -save-temps bug.cpp
bug.cpp: In function ‘bool foo(T)’:
bug.cpp:1:42: error: parse error in template argument list
$ cat bug.ii
# 1 bug.cpp
# 1 built-in
# 1 command-line
# 1 bug.cpp
templateclass T bool foo(T x){return x.foo1;}
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

[Bug c++/51665] New: undefined reference when passing static const int member to template method

[gcc-bugzilla at bluespirit dot la]

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

 Bug #: 51665
   Summary: undefined reference when passing static const int
member to template method
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@bluespirit.la


Created attachment 26172
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26172
sources, save-temps, command line

Calling the template method qMax(T,T) with a constant (static const int) as
first parameter, I get an undefined reference. When saving this constant to a
local constant and using this for as template parameter, everything works fine.

Using Debian testing with Gcc 4.6.2-7 on Linux 3.1.0.1-686-pae.

Command line: g++ *.cpp

ld --version: GNU ld (GNU Binutils for Debian) 2.22
g++ --version: g++ (Debian 4.6.2-7) 4.6.2




template typename T
inline const T qMax(const T a, const T b) { if (a  b) return b; return a; }

class MyClass
{
public:
void doSomething();
private:
static const int M_SOME_CONSTANT = 24;
};


//
// NOT WORKING
//
void MyClass::doSomething()
{
int iValue = 77 + M_SOME_CONSTANT;
iValue += qMax( M_SOME_CONSTANT, 12 );
}

//
// WORKING
//
void MyClass::doSomething()
{
int iValue = 77 + M_SOME_CONSTANT;
const int iTmp = M_SOME_CONSTANT;
iValue += qMax( iTmp , 12 );
}

[Bug c++/51665] undefined reference when passing static const int member to template method

[gcc-bugzilla at bluespirit dot la]

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

--- Comment #1 from Karl Krach gcc-bugzilla at bluespirit dot la 2011-12-23 
13:38:22 UTC ---
g++ *.cpp --save-temps
MyClass.o:MyClass.cpp:function MyClass::doSomething(): error: undefined
reference to 'MyClass::M_SOME_CONSTANT'
collect2: ld returned 1 exit status

[Bug c++/51664] comparison incorrectly treated as template instantiation

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 
13:41:04 UTC ---
I don't think it's valid, Clang and EDG reject it too

[Bug c++/51665] undefined reference when passing static const int member to template method

[redi at gcc dot gnu.org]

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

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-23 
13:42:49 UTC ---
Not a bug

http://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

[Bug c++/51664] comparison incorrectly treated as template instantiation

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-23 
13:47:04 UTC ---
wasn't the template keyword meant to avoid this ambiguity?  Thus, if x.foo
is a template then you are required to write x.template foo because x is
template dependent?

[Bug debug/51650] [4.7 regression] LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul

[markus at trippelsdorf dot de]

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

--- Comment #20 from Markus Trippelsdorf markus at trippelsdorf dot de 
2011-12-23 13:56:55 UTC ---
(In reply to comment #19)
 A workaround for ICEs of this form is
 
 Index: gcc/dwarf2out.c
 ===
 --- gcc/dwarf2out.c (revision 182652)
 +++ gcc/dwarf2out.c (working copy)
 @@ -22496,15 +22496,23 @@ dwarf2out_finish (const char *filename)
   else if (TYPE_P (node-created_for))
 context = TYPE_CONTEXT (node-created_for);
 
 - gcc_assert (context
 -  (TREE_CODE (context) == FUNCTION_DECL
 - || TREE_CODE (context) == NAMESPACE_DECL));
 + if (!(context
 +(TREE_CODE (context) == FUNCTION_DECL
 +   || TREE_CODE (context) == NAMESPACE_DECL)))
 +   {
 + if (!in_lto_p)
 +   gcc_unreachable ();
 
 - origin = lookup_decl_die (context);
 - if (origin)
 -   add_child_die (origin, die);
 + add_child_die (comp_unit_die (), die);
 +   }
   else
 -   add_child_die (comp_unit_die (), die);
 +   {
 + origin = lookup_decl_die (context);
 + if (origin)
 +   add_child_die (origin, die);
 + else
 +   add_child_die (comp_unit_die (), die);
 +   }
 }
 }
  }
 
 just in case you want to look further ;)

Fortunately it seems that this bug was the last issue that needed to be fixed.
Firefox now builds fine with -lto and -g.

[Bug c++/51664] comparison incorrectly treated as template instantiation

[timon.gehr at gmx dot ch]

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

--- Comment #3 from Timon Gehr timon.gehr at gmx dot ch 2011-12-23 14:02:49 
UTC ---
(In reply to comment #1)
 I don't think it's valid, Clang and EDG reject it too

DMC accepts it.

[Bug c++/51666] New: NSDMI parse fails for template'd intializer

[miles at gnu dot org]

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

 Bug #: 51666
   Summary: NSDMI parse fails for template'd intializer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


The following code:

   templatetypename T, typename U
   struct tuple
   {
 tuple(T, U) { }
   };

   struct Y
   {
 tupleint, int tt = tupleint, int{1, 2};   // *error*
   };

Fails with a parse error in gcc 4.7 20111210:

   $ g++-snapshot -c -std=c++11 nsdmi3.cc
   nsdmi3.cc:9:36: error: expected unqualified-id before 'int'
   nsdmi3.cc:9:31: error: wrong number of template arguments (1, should be 2)
   nsdmi3.cc:2:9: error: provided for 'templateclass T, class U struct tuple'

   $ g++-snapshot --version
   g++ (Debian 20111210-1) 4.7.0 20111210 (experimental) [trunk revision
182188]

Thanks,

-miles

[Bug c++/51664] comparison incorrectly treated as template instantiation

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-23 
14:24:37 UTC ---
Let's ask Jason to help finishing the triage.

[Bug c++/51664] comparison incorrectly treated as template instantiation

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 
14:41:17 UTC ---
Richard: yes.

[temp.names] p3 says

-3- After name lookup (3.4) finds that a name is a template-name or that an
operator-function-id or a literal-operator-id refers to a set of overloaded
functions any member of which is a function template if this is followed by a
, the  is always taken as the delimiter of a template-argument-list and never
as the less-than operator. [...]

but then p4 should apply in this case:

-4- When the name of a member template specialization appears after . or - in
a postfix-expression or after a nested-name-specifier in a qualified-id, and the
object expression of the postfix-expression is type-dependent or the
nested-name-specifier in the qualified-id refers to a dependent type, but the
name is not a member of the current instantiation (14.6.2.1), the member
template name must be prefixed by the keyword template. Otherwise the name is
assumed to name a non-template.

Let's see what Jason says

[Bug libstdc++/49204] [C++0x] remaining issues in future

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 
16:10:58 UTC ---
Author: redi
Date: Fri Dec 23 16:10:48 2011
New Revision: 182658

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182658
Log:
PR libstdc++/49204
* include/std/future (future_errc): Implement LWG 2056.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/future

[Bug bootstrap/37079] cannot find -lgcc_s

[kai.extern at gmail dot com]

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

Kai Henningsen kai.extern at gmail dot com changed:

   What|Removed |Added

 CC||kai.extern at gmail dot com

--- Comment #9 from Kai Henningsen kai.extern at gmail dot com 2011-12-23 
16:12:17 UTC ---
I am seeing something very like this on x86_64-linux-gnu (native), gcc 4.6.2.
The compiler (with --disable-bootstrap) builds and installs into the prefix,
but then ld is unable to find libgcc_s, because the directory it is installed
in is not in the search path. It is installed into
$(prefix)/lib/gcc/$(target)/lib64.

Complete configure options (including some only relevant for different
packages; from config.log):

$(src)/gcc/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--prefix=$(prefix) --disable-bootstrap --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-multilib --disable-nls
--enable-cxx --enable-decimal-float=no --enable-maintainer-mode
--enable-optimization --enable-pch --enable-rpath
--enable-version-specific-runtime-libs --with-bits=gmp --with-gnu-as
--with-gnu-ld --with-ppl --enable-languages=c,c++ --with-gmp=$(prefix)
--with-mpfr=$(prefix) --with-mpc=$(prefix) --with-ppl=$(prefix)
--with-cloog=$(prefix) --target=x86_64-linux-gnu

Other coments: Ubuntu, I'm symlinking all system libs into
$(prefix)/$(target)/lib before I start.

The actual path searched is:

$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../../lib64/
/lib/../lib64/
/usr/lib/../lib64/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../../x86_64-linux-gnu/lib/
$(prefix)/lib/gcc/x86_64-linux-gnu/4.6.2/../../../
$(prefix)/x86_64-linux-gnu/lib64/
$(prefix)/lib64/
/usr/local/lib64/
/lib64/
/usr/lib64/
$(prefix)/x86_64-linux-gnu/lib/
$(prefix)/lib/
/usr/local/lib/
/lib/
/usr/lib/

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

[dominiq at lps dot ens.fr]

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

 Bug #: 51667
   Summary: [4.7 Regression] new FAIL: 27_io/basic_*stream/*
execution test with -m32
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hjl.to...@gmail.com, ia...@gcc.gnu.org,
r...@gcc.gnu.org, ubiz...@gmail.com
  Host: *86*-*-*
Target: *86*-*-*
 Build: *86*-*-*


Between revisions 182603 (OK) and 182605 the following tests have started to
fail on *86*-*-* in 32 bit mode:

Running target unix/-m32
FAIL: 27_io/basic_istream/extractors_arithmetic/char/dr696.cc execution test
FAIL: 27_io/basic_istream/extractors_arithmetic/wchar_t/dr696.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/char/7.cc execution test
FAIL: 27_io/basic_ostream/inserters_arithmetic/wchar_t/7.cc execution test

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

[dominiq at lps dot ens.fr]

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

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

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-23 
16:48:07 UTC ---
From http://gcc.gnu.org/ml/gcc-regression/2011-12/msg00543.html this pr has
been caused/exposed by revision 182605.

[Bug bootstrap/37079] cannot find -lgcc_s

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 
17:11:19 UTC ---
(In reply to comment #9)
 --enable-version-specific-runtime-libs

That's broken on x86_64 see bug 32415

[Bug debug/51668] New: class DW_AT_name does not match method's linkage name prefix (char)1 vs. '\001'

[jan.kratochvil at redhat dot com]

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

 Bug #: 51668
   Summary: class DW_AT_name does not match method's linkage name
prefix (char)1 vs. '\001'
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
CC: do...@gcc.gnu.org
Target: x86_64-unknown-linux-gnu


PASS: gcc (GCC) 4.6.3 20111222 (prerelease)
FAIL: gcc (GCC) 4.7.0 20111222 (experimental)

From the GDB point of view it is a regression because gcc-4.7 now provides the
non-matching DW_AT_linkage_name for ctors/dtors which GDB prefers over its
physname computed from class's DW_AT_name.

templatechar c
class C {
public:
  void m () {}
  ~C() {}
};
typedef C1 D;
D d;
int main () { d.m (); }

nm:
00400604 W _ZN1CILc1EED1Ev
00400604 W _ZN1CILc1EED2Ev
nm -C:
00400604 W C(char)1::~C()
00400604 W C(char)1::~C()
readelf -wi:
 13a: Abbrev Number: 3 (DW_TAG_class_type)
3b   DW_AT_name: (indirect string, offset: 0xac): C'\001'   

The gcc-4.6 - gcc-4.7 regression:

-PASS: gdb.cp/templates.exp: print destructor of template typedef
+FAIL: gdb.cp/templates.exp: print destructor of template typedef

(gdb) p D::~C
$1 = {void (C(char)'\001' * const)} 0x40056e C(char)'\001'::~C()
-
There is no field named ~C

[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

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org, tocarip.intel at
   ||gmail dot com
 Depends on||50038
   Target Milestone|--- |4.7.0

--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-12-23 18:05:07 
UTC ---
Something is wrong with new REE pass. CCs added.

[Bug c++/51669] New: ICE verify-gimple with openmp

[tprince at computer dot org]

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

 Bug #: 51669
   Summary: ICE verify-gimple with openmp
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tpri...@computer.org


Created attachment 26173
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26173
pre-processed C++ source

[tim@tim-knf1 gf]$ g++ -O1 -fopenmp -Drestrict=__restrict__ -v s451.i
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7-20111217/configure --enable-languages='c c++
fortran' --disable-multilib
Thread model: posix
gcc version 4.7.0 20111217 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-O1' '-fopenmp' '-D' 'restrict=__restrict__' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -fpreprocessed
s451.i -quiet -dumpbase s451.i -mtune=generic -march=x86-64 -auxbase s451 -O1
-version -fopenmp -o /tmp/ccVyBz2P.s
GNU C++ (GCC) version 4.7.0 20111217 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111217 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
warning: MPC header version 0.9 differs from library version 0.8.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20111217 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20111217 (experimental), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.9
warning: MPC header version 0.9 differs from library version 0.8.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 19c710f37412ac153ea3c68c9b7fb9cd
s451.cpp: In function ‘int s451_(integer*, integer*, integer*, real*, real*,
real*, real*, real*, real*, real*, real*, real*, real*)’:
s451.cpp:46:1: internal compiler error: in verify_gimple_stmt, at
tree-cfg.c:4244

[Bug c++/51664] comparison incorrectly treated as template instantiation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-23 
18:56:42 UTC ---
This is a dup of a much older bug, PR 10200.

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

[Bug c++/10200] Weird clash with same names in different scopes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||timon.gehr at gmx dot ch

--- Comment #19 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-23 
18:56:42 UTC ---
*** Bug 51664 has been marked as a duplicate of this bug. ***

[Bug other/51662] Temporary objects gets garbage collected in cc1

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-23 
19:02:55 UTC ---
Can you attach the testcase?

[Bug tree-optimization/48641] [4.7 Regression] ICE: verify_flow_info failed: Wrong frequency of block 77 -419530 with -O -fno-tree-ccp -fno-tree-copy-prop

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-23 
19:14:12 UTC ---
The frequencies are initially scaled to be in range 0...BB_FREQ_MAX, but
subsequent transformations may break the invariant (when two basic blocks are
unified). If it turns out to be neccessary we probably will add a capping.

Because the function is loopless, the frequencies should not get above sum of
all frequencies in the function no matter what threading does.  So it seems we
just propagate some misupdated profile?

Honza

[Bug rtl-optimization/51069] [4.7 Regression] ICE in verify_loop_structure, at cfgloop.c:1559

[hubicka at gcc dot gnu.org]

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

Jan Hubicka hubicka at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu.org

--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-23 
19:15:21 UTC ---
I am not terribly familiar with the logic here either, Zdenek?

[Bug tree-optimization/48641] [4.7 Regression] ICE: verify_flow_info failed: Wrong frequency of block 77 -419530 with -O -fno-tree-ccp -fno-tree-copy-prop

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-23 
21:47:08 UTC ---
OK, the problem is that profile is wrong and jump threading gets into
conflicting results and the results are propagated through the testcase because
of specific CFG.  I think all we can do is to add capping. I am testing
Index: tree-ssa-threadupdate.c
===
--- tree-ssa-threadupdate.c (revision 182657)
+++ tree-ssa-threadupdate.c (working copy)
@@ -513,7 +513,11 @@ redirect_edges (void **slot, void *data)
 e-src-index, e-dest-index, rd-dup_block-index);

  rd-dup_block-count += e-count;
- rd-dup_block-frequency += EDGE_FREQUENCY (e);
+
+ /* Excessive jump threading may make frequencies large enough so
+the computation overflows.  */
+ if (rd-dup_block-frequency  BB_FREQ_MAX * 2)
+   rd-dup_block-frequency += EDGE_FREQUENCY (e);
  EDGE_SUCC (rd-dup_block, 0)-count += e-count;
  /* Redirect the incoming edge to the appropriate duplicate
 block.  */

[Bug c++/51507] [C++0x] Function parameter pack doesn't use in template-argument-list

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-12-23 
22:00:21 UTC ---
Author: jason
Date: Fri Dec 23 22:00:13 2011
New Revision: 182668

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182668
Log:
PR c++/51507
* search.c (at_function_scope_p): Also check cfun.
* pt.c (tsubst_pack_expansion): Check it instead of
cp_unevaluated_operand.
(instantiate_template_1): Clear current_function_decl.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic121.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51504] Data race hunting instructions in manual do not work

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-23 
22:09:10 UTC ---
N.B. you don't have to rebuild the whole .so you can rebuild just thread.cc and
link thread.o into your program. The dynamic linker will do symbol
interposition and use the std::thread::_M_start_thread symbol from your program
instead of the one from libstdc++.so

[Bug c++/51507] [C++0x] Function parameter pack doesn't use in template-argument-list

[jason at gcc dot gnu.org]

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

Jason Merrill jason at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-12-23 
22:10:33 UTC ---
Fixed for 4.7.

[Bug ada/51114] Got compiler error when creating a private subtype

[frederic.praca at free dot fr]

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

--- Comment #1 from Frédéric Praca frederic.praca at free dot fr 2011-12-23 
23:02:36 UTC ---
In fact, the title is wrong as the problem occurs when declaring derived types,
not subtypes.

[Bug libstdc++/51504] Data race hunting instructions in manual do not work

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-23 
23:33:59 UTC ---
Nice tip.

[Bug preprocessor/51670] New: [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

 Bug #: 51670
   Summary: [4.7.0] conflicts with new declaration with 'C++'
linkage
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pashev.i...@gmail.com


Created attachment 26174
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26174
Build log

G++ 4.7.0 (trunk from 20111219) compiler doesn't work on Solaris
(x86_64-pc-solaris2.11).

But G++ 4.6.2 does.

Steps to reproduce:

# /usr/gcc/4.7/bin/g++ test.cpp -o test # FAIL
# /usr/gcc/4.6/bin/g++ -m64  test.cpp -o test # WIN

Build log is attached. Trivial test program and preprocessed files are below.

[Bug preprocessor/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

--- Comment #1 from Igor Pashev pashev.igor at gmail dot com 2011-12-23 
23:47:20 UTC ---
Created attachment 26175
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26175
Trivial test program

[Bug preprocessor/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

--- Comment #2 from Igor Pashev pashev.igor at gmail dot com 2011-12-23 
23:48:01 UTC ---
Created attachment 26176
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26176
/usr/gcc/4.6/bin/g++ -m64  -E test.cpp -o test.46

[Bug preprocessor/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

--- Comment #3 from Igor Pashev pashev.igor at gmail dot com 2011-12-23 
23:48:35 UTC ---
Created attachment 26177
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26177
/usr/gcc/4.7/bin/g++ -E test.cpp -o test.47

[Bug preprocessor/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

--- Comment #4 from Igor Pashev pashev.igor at gmail dot com 2011-12-23 
23:49:12 UTC ---
Created attachment 26178
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26178
Diff of test.46 and test.47

[Bug preprocessor/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

--- Comment #5 from Igor Pashev pashev.igor at gmail dot com 2011-12-23 
23:51:31 UTC ---
Sorry, GCC 4.7 is installed in /usr, not in /usr/gcc/4.7

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Target||x86_64-pc-solaris2.11
  Component|preprocessor|target

--- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-23 
23:53:05 UTC ---
This looks like a bug in Solaris's headers.

[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

--- Comment #7 from Igor Pashev pashev.igor at gmail dot com 2011-12-24 
00:27:10 UTC ---
Created attachment 26179
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26179
Diff of macros

[Bug tree-optimization/26656] Optimization flaw on conditional set of a bit.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-24
  Component|target  |tree-optimization
 Ever Confirmed|0   |1

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-24 
03:08:17 UTC ---
limittime ?:time ?: watime iftime if wa
1844354
2834444
3834464
4844403
5834463
6843544
7833534
8834534
9843534
10834584
11843554
12833524
13834523
14834464
15833473
16833454
17833434
18833383
19833403
20843373
21834263
22833294
23834214
24834214

This is at -O3.  So only flagIf is slower.
Without the vectorizer:
limittime ?:time ?: watime iftime if wa
1818124211
2817114511
3813124612
4816114811
5821115312
6815125012
7818115412
8817125511
9818125612
10818125811
11819125811
12816125512
13816125411
14816125411
15816115211
16819114912
17817124512
18815114311
19815123911
20813123711
21815123312
22814123012
23818112811
24815112611

[Bug tree-optimization/28134] optimize redundant memset + assignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-24
Version|unknown |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-24 
03:11:54 UTC ---
Confirmed:
bb 2:
  memset (bp_2(D), 0, 24576);

bb 3:
  # ivtmp.14_9 = PHI ivtmp.14_20(3), 0(2)
  MEM[base: bp_2(D), index: ivtmp.14_9, offset: 16B] = 0B;
  ivtmp.14_20 = ivtmp.14_9 + 24;
  if (ivtmp.14_20 != 24576)
goto bb 3;
  else
goto bb 4;

[Bug rtl-optimization/23811] returning 64-bit value turns off some 32-bit optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-24 
03:16:06 UTC ---
Fixed in 4.3.0 and above:
andl$16711935, %edx
andl$-16711936, %eax
orl%edx, %eax
xorl%edx, %edx
rorl$16, %eax
ret

[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-24 
06:46:16 UTC ---
Trying 9 - 10:
Failed to match this instruction:
(set (reg:DI 69 [ D.1710 ])
(sign_extend:DI (ctz:SI (reg:SI 67 [ x ]

Should be changed to zero_extend and then that could be matched really.