[Bug middle-end/51263] [4.7 regression] ICE in inline_small_functions when compiling scummvm with -O2 -flto

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #2 from Markus Trippelsdorf  
2011-11-22 07:10:38 UTC ---
dup of Bug 50823

[Bug c++/32039] Using declaration accepts non-visible members from base classes

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-22
 Ever Confirmed|0   |1

[Bug c++/51265] New: internal compiler error: in finish_decltype_type, at cp/semantics.c:5244

[i.nixman at gmail dot com]

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

 Bug #: 51265
   Summary: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5244
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com


When I try to compile following code, I get error:
test1.cpp: In instantiation of 'void xx(T*, A ...) [with X = int
(Funny::*)(int) const; X ff = &Funny::print3; R = int; T = Funny; A = {int}]':
test1.cpp:35:74:   required from here
test1.cpp:23:9: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5244

code:


#include 

struct Funny {
void print(int i) {
std::cout << "void (Funny::*)(int): " << i << std::endl;
}
int print2(int i) {
std::cout << "int (Funny::*)(int): " << i << std::endl;
return i;
}
int print3(int i)  const {
std::cout << "int (Funny::*)(int) const: " << i << std::endl;
return i;
}
};
template
void c(){ T abc; (abc.*ff)(123); }
template
void xx(T* _obj, A... args){
for (int i : {2,4}) std::cout << i << std::endl; // #3 int i is OK
{
/* 23 */ c(); // #1 summary error trigger here
}

std::cout << "xx()" << std::endl;
(_obj->*(ff))(args...);
// #2 can not define any object here, even int
// T abc; 
//(abc.*ff)(args...);
}
int main()
{
Funny abc;
/* 35 */ xx(&abc,
3);
return 0;
}


configured with:
C:\test>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrappe
r.exe
Target: i686-pc-mingw32
Configured with: ../../mingw-src/gcc-trunk/configure --host=i686-pc-mingw32
--bu
ild=i686-pc-mingw32 --target=i686-pc-mingw32 --prefix=/mingw-sjlj-x86
--with-arc
h=i686 --with-tune=generic --enable-languages=c,c++,lto,fortran,objc,obj-c++
--w
ith-host-libstdcxx=-lstdc++ --disable-shared --enable-static
--enable-cxx-flags=
'-fno-function-sections -fno-data-sections' --enable-libstdcxx-time=yes
--enable
-libgomp --enable-lto --enable-graphite --enable-cloog-backend=isl
--enable-chec
king=release --enable-fully-dynamic-string --enable-threads=posix
--disable-libs
tdcxx-pch --enable-libstdcxx-debug --enable-sjlj-exceptions --disable-debug
--di
sable-bootstrap --disable-multilib --disable-rpath --disable-win32-registry
--di
sable-nls --disable-werror --disable-symvers --with-gmp=/mingw-libs
--with-mpfr=
/mingw-libs --with-mpc=/mingw-libs --with-ppl=/mingw-libs
--with-cloog=/mingw-li
bs --with-libiconv-prefix=/mingw-libs --with-pkgversion='niXman build'
Thread model: posix

[Bug middle-end/51261] [4.7 Regression] -fcompare-debug with memset()

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2011-11-22 05:30:59 
UTC ---
Happens in r181597 as well.

$ diff testcase.*gkd
52c52
< (const_int 32675 [0x7fa3]))) testcase.C:3# {*cmpdi_1}
---
> (const_int 32551 [0x7f27]))) testcase.C:3# {*cmpdi_1}

[Bug middle-end/51200] Wrong code sequence to store restrict volatile bitfield

[joey.ye at arm dot com]

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

--- Comment #2 from Joey Ye  2011-11-22 03:58:29 UTC ---
Here is a test case fix.

With this patch, backend part of Bernd's original patch can be skipped. Thus
DJ's concern of unnecessary change can be addressed.

Also this test case intends to warn a situation that is incompatible to abi
version 1, -fstrict-volatile-bitfields happenly hides the incompatibility. IMHO
it is consultable to claim strict volatile bitfields violates version 1. So
fixing the test case and make it work as intended is more reasonable to me.


--- a/gcc/testsuite/g++.dg/abi/bitfield12.C
+++ b/gcc/testsuite/g++.dg/abi/bitfield12.C
@@ -1,4 +1,4 @@
-// { dg-options "-Wabi -fabi-version=1" }
+// { dg-options "-Wabi -fabi-version=1 -fno-strict-volatile-bitfields" }

 struct S { // { dg-warning "ABI" }
   char c : 1024; // { dg-warning "width" }

 struct S { // { dg-warning "ABI" }
   char c : 1024; // { dg-warning

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2011-11-22 
03:44:39 UTC ---
Created attachment 25877
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25877
Patch which improves the use of clobbers for toplevel BIND expressions.

Though at -O0 we should not emit the clobbers at all.  That can be cured by
adding !optimize to the condition which includes !top_level.

[Bug target/51134] [4.7 Regression] x86 memset/memcpy expansion is broken

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2011-11-22 03:30:54 
UTC ---
On Linux/x86-64, configured with

--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared
--prefix=/usr/gcc-4.7.0 --with-local-prefix=/usr/local -with-arch=core2
--with-cpu=atom --with-fpmath=sse

revision 181584 result is at

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02226.html

revision 181584 + the old memset/memcpy expansion result us at

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02225.html

Regressions caused by the new memset/memcpy expansion are

FAIL: 27_io/basic_filebuf/seekoff/wchar_t/1.cc execution test
FAIL: 27_io/basic_filebuf/seekpos/wchar_t/9874.cc execution test
FAIL: 27_io/manipulators/basefield/char/1.cc execution test
FAIL: 27_io/manipulators/basefield/wchar_t/1.cc execution test
FAIL: 27_io/objects/wchar_t/12.cc execution test
FAIL: 27_io/objects/wchar_t/13.cc execution test
FAIL: events run
FAIL: gcc.target/i386/cleanup-1.c execution test
FAIL: gcc.target/i386/cleanup-2.c execution test
FAIL: gcc.target/i386/pr34077.c (internal compiler error)
FAIL: gcc.target/i386/pr34077.c (internal compiler error)
FAIL: gcc.target/i386/pr34077.c (test for excess errors)
FAIL: gcc.target/i386/pr34077.c (test for excess errors)
FAIL: gfortran.fortran-torture/execute/arrayarg.f90 execution,  -O2
-fomit-frame-pointer -finline-functions -funroll-loops

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2011-11-22 
03:03:37 UTC ---
Hmm, I don't think we need a clobber for the outer most scope of the function
really.  Though that might only allow us to get the bootstrap to work better
and might improve code generation.

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org 2011-11-22 02:57:45 UTC ---
Difference in dumps just before error in r181172, at tree.cc.014t.cfg:
...
r181171  |  r181172
unsigned int iterative_hash_expr(un unsigned int iterative_hash_expr(un
{   {
 >int finally_tmp.0;
  int code;   int code;
  unsigned int D.2185;unsigned int D.2185;

: :
  iterative_hash (&code); iterative_hash (&code);
  D.2185 = 0; D.2185 = 0;
 >finally_tmp.0 = 0;
 >code = {CLOBBER};
 >switch (finally_tmp.0)
 >  ,
 >   case 1: >

:|  :
 >return;
 >
 >  :
  return D.2185;  return D.2185;

}   }
...

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org 2011-11-22 02:52:20 UTC ---
dumps start diverging at tree.cc.004t.gimple: 
...
r181171  |  r181172
unsigned int iterative_hash_expr(un unsigned int iterative_hash_expr(un
{   {
  unsigned int D.2185;unsigned int D.2185;
  int code;   int code;

  switch (val) >   |try
  :  |  {
  iterative_hash (&code);|switch (val) :
  return D.2185; |iterative_hash (&code);
  goto ; |D.2185 = 0;
  :  |return D.2185;
 >goto ;
 >:
 >  }
 >finally
 >  {
 >code = {CLOBBER};
 >  }
}   }
...

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||matz at suse dot de

--- Comment #3 from vries at gcc dot gnu.org 2011-11-22 02:38:30 UTC ---
Triggered/caused by r181172:
...
r181172 | matz | 2011-11-08 17:47:16 +0100 (Tue, 08 Nov 2011) | 44 lines

* gengtype.c (write_field_root): Avoid out-of-scope access of newv.

* tree-stdarg.c (execute_optimize_stdarg): Accept clobbers.

* tree.h (TREE_CLOBBER_P): New macro.
* gimple.h (gimple_clobber_p): New inline function.
* gimplify.c (gimplify_bind_expr): Add clobbers for all variables
that go out of scope and live in memory.
* tree-ssa-operands.c (get_expr_operands): Transfer volatility also
for constructors.
* cfgexpand.c (decl_to_stack_part): New static variable.
(add_stack_var): Allocate it, and remember mapping.
(fini_vars_expansion): Deallocate it.
(stack_var_conflict_p): Add early outs.
(visit_op, visit_conflict, add_scope_conflicts_1,
add_scope_conflicts): New static functions.
(expand_used_vars_for_block): Don't call add_stack_var_conflict, tidy.
(expand_used_vars): Add scope conflicts.
(expand_gimple_stmt_1): Expand clobbers to nothing.
(expand_debug_expr): Ditto.

* tree-pretty-print.c (dump_generic_node): Dump clobbers nicely.
* tree-ssa-live.c (remove_unused_locals): Remove clobbers that
refer to otherwise unused locals.
* tree-sra.c (build_accesses_from_assign): Ignore clobbers.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Clobbers of
SSA names aren't necessary.
(propagate_necessity): Accept and ignore constructors on the rhs,
tidy.
* gimple.c (walk_gimple_op): Accept constructors like mem_rhs.
* tree-ssa-structalias.c (find_func_aliases): Clobbers don't store
any known value.
* tree-ssa-sccvn.c (vn_reference_lookup_3): Ditto, in particular they
don't zero-initialize something.
* tree-ssa-phiopt.c (cond_if_else_store_replacement_1): Ignore
clobber RHS, we don't want PHI nodes with those.
...

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-11-22 
01:47:58 UTC ---
(In reply to comment #0)
> This might be a duplicate of PR20681, but I'm filing it just in case it's not.


It is.  I had some patches which improve the situation here but I lost them
over the years.  Though I think I might have posted some of them already.

[Bug c++/51264] O0 Bootstrap failure: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org 2011-11-22 01:38:07 UTC ---
Minimal example tree.cc:
...
extern void iterative_hash (const int *);

unsigned int
iterative_hash_expr (unsigned int val)
{
  int code;
  switch (val)
{
default:
  iterative_hash (&code);
  return 0;
  break;
}
}
...

to reproduce:
...
gcc -Werror -Wreturn-type -O0 tree.cc -S -fno-exceptions
...

[Bug c++/51264] New: O0 Bootstrap failure: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

 Bug #: 51264
   Summary: O0 Bootstrap failure: control reaches end of non-void
function
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org


This might be a duplicate of PR20681, but I'm filing it just in case it's not.

During a x86-64 -O0 bootstrap, the 3rd stage fails with:
...
In function 'hashval_t iterative_hash_expr(const_tree, hashval_t)':
/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/tree.c:6999:1:
error: control reaches end of non-void function [-Werror=return-type]
cc1plus: all warnings being treated as errors
...

full command line:
...
/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/./prev-gcc/g++
-B/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/./prev-gcc/
-B/opt/codesourcery/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/libstdc++-v3/libsupc++
-L/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O0 -gtoggle -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I.
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/.
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/../include
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/../libcpp/include
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr/include
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr/include
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr/include

-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/../libdecnumber
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/../libdecnumber/bid
-I../libdecnumber
-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr/include

-I/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr/include
 /scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/tree.c -o
tree.o/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/tree.c: In
function 'hashval_t iterative_hash_expr(const_tree, hashval_t)':
/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/gcc/tree.c:6999:1:
error: control reaches end of non-void function [-Werror=return-type]
cc1plus: all warnings being treated as errors
...

configure line:
...
Configured with:
/scratch/vries/b2/ref-x86_64-ml-11-11-21/src/gcc-mainline/configure
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu --enable-threads --disable-libmudflap
--disable-libssp --disable-libstdcxx-pch --enable-checking=yes,rtl
--disable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--enable-shared --enable-lto --disable-nls --prefix=/opt/codesourcery
--with-gmp=/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr
--with-mpfr=/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr
--with-mpc=/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/usr
--with-ppl=/scratch/vries/b2/ref-x86_64-ml-11-11-21/obj/host-libs-m

[Bug tree-optimization/51074] No constant folding performed for VEC_PERM_EXPR, VEC_INTERLEAVE*EXPR, VEC_EXTRACT*EXPR

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #6 from Pat Haugen  2011-11-21 
23:57:29 UTC ---
cpu2000 benchmark 176.gcc started failing on PPC with this patch (miscompare of
results). Appears to be due to result from VEC_INTERLEAVE_[LOW|HIGH]_EXPR when
folding.  Following is simple testcase to demonstrate results.

temp/gcc> cat junk.c
#include 

#define NUM 8
struct hard_reg_n_uses { int regno; int uses; };
struct hard_reg_n_uses hard_reg_n_uses[NUM];

void main() {
  int i;

  for (i = 0; i < NUM; i++)
{
  hard_reg_n_uses[i].uses = 0;
  hard_reg_n_uses[i].regno = i;
}

  for (i = 0; i < NUM; i++)
printf("i = %d  regno = %d\n",i,hard_reg_n_uses[i].regno);

}


When compiled with revisions prior to r181297 with -O3 -mcpu=power7 I get the
following results:

temp/gcc> a.out
i = 0   regno = 0
i = 1   regno = 1
i = 2   regno = 2
i = 3   regno = 3
i = 4   regno = 4
i = 5   regno = 5
i = 6   regno = 6
i = 7   regno = 7


revision 181297 (and later) give:

temp/gcc> a.out
i = 0   regno = 2
i = 1   regno = 3
i = 2   regno = 0
i = 3   regno = 1
i = 4   regno = 6
i = 5   regno = 7
i = 6   regno = 4
i = 7   regno = 5


Comparing the tree dumps of r181296 and r181297, diff comes in at 127t.dom2
dump.


36,38c36,38
<   vect_inter_high.15_17 = VEC_INTERLEAVE_HIGH_EXPR <{ 0, 1, 2, 3 }, { 0, 0,
0, 0 }>;
<   vect_inter_low.16_37 = VEC_INTERLEAVE_LOW_EXPR <{ 0, 1, 2, 3 }, { 0, 0, 0,
0 }>;
<   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses] = vect_inter_high.15_17;
---
>   vect_inter_high.15_17 = { 2, 0, 3, 0 };
>   vect_inter_low.16_37 = { 0, 0, 1, 0 };
>   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses] = { 2, 0, 3, 0 };
40c40
<   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 16B] =
vect_inter_low.16_37;
---
>   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 16B] = { 0, 0, 1, 0 };
47,49c47,49
<   vect_inter_high.15_28 = VEC_INTERLEAVE_HIGH_EXPR <{ 4, 5, 6, 7 }, { 0, 0,
0, 0 }>;
<   vect_inter_low.16_29 = VEC_INTERLEAVE_LOW_EXPR <{ 4, 5, 6, 7 }, { 0, 0, 0,
0 }>;
<   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 32B] =
vect_inter_high.15_28;
---
>   vect_inter_high.15_28 = { 6, 0, 7, 0 };
>   vect_inter_low.16_29 = { 4, 0, 5, 0 };
>   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 32B] = { 6, 0, 7, 0 };
51c51
<   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 48B] =
vect_inter_low.16_29;
---
>   MEM[(struct hard_reg_n_uses[8] *)&hard_reg_n_uses + 48B] = { 4, 0, 5, 0 };

[Bug middle-end/51263] New: ICE in inline_small_functions when compiling scummvm with -O2 -flto

[matt at use dot net]

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

 Bug #: 51263
   Summary: ICE in inline_small_functions when compiling scummvm
with -O2 -flto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


With current trunk, compiling scummvm 1.4.0
(http://prdownloads.sourceforge.net/scummvm/scummvm-1.4.0.tar.bz2?download):

$ CXXFLAGS="-O2 -flto" CFLAGS="-O2 -flto" ./configure --enable-all-engines

Running ScummVM configure...
[...]

$ make

[...]

engines/parallaction/balloons.cpp:756:1: internal compiler error: in
inline_small_functions, at ipa-inline.c:1421

with -j7, this one happens first, but is likely the same root issue:

In file included from video/smk_decoder.cpp:37:0:
./audio/audiostream.h:303:7: internal compiler error: in
inline_small_functions, at ipa-inline.c:1421

I tried reproducing with just -O1 -finline-small-functions, but that didn't
trip the issue.

Pre-processed source file attached, reproduce by:
bunzip2 balloons.i.bz2
g++ -O2 balloons.i

[Bug middle-end/51263] ICE in inline_small_functions when compiling scummvm with -O2 -flto

[matt at use dot net]

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

--- Comment #1 from Matt Hargett  2011-11-21 23:58:48 UTC 
---
Created attachment 25876
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25876
pre-processed source of the file that triggers the ICE

[Bug testsuite/51251] conflicting -mcpu switches during testing

[joel at gcc dot gnu.org]

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

--- Comment #10 from Joel Sherrill  2011-11-21 
23:08:20 UTC ---
(In reply to comment #9)
> In addition to the comments so far about what the testsuite framework
> should be doing, I also think the sparc option processing is currently
> doing the right thing given the input seen here.
> 
> If you say "-mcpu=cypress -mvis" which is what the command line amounts
> to, it meant to enable VIS and that requires turning on V9 also which is
> what the option processing in the sparc backend does.

Doesn't the order of the conflicting options have an impact? The cypress flag
is last.

Conflicting cpu feature flags is bad anyway and even though many flags can be
alternated like optimzation flags with the last one winning, this situation
likely has no easy general solution which is predictable.

The best solution in this particular case is to disable all tests V9+, VIS, etc
which are
not V7/V8 since that what this target is for.

[Bug debug/51262] New: [4.7 Regression] ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g

[zsojka at seznam dot cz]

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

 Bug #: 51262
   Summary: [4.7 Regression] ICE: SIGSEGV in
primary_template_instantiation_p (pt.c:2874) with
-flto -g
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -flto -fcompare-debug testcase.C
==20321== Invalid read of size 2
==20321==at 0x5C0904: primary_template_instantiation_p(tree_node const*)
(pt.c:2874)
==20321==by 0x5C118D: get_primary_template_innermost_parameters(tree_node
const*) (pt.c:2902)
==20321==by 0x899E19: gen_tagged_type_die(tree_node*, die_struct*,
debug_info_usage) (dwarf2out.c:20045)
==20321==by 0x886C5F: gen_type_die_with_usage(tree_node*, die_struct*,
debug_info_usage) (dwarf2out.c:18952)
==20321==by 0x89C8A6: gen_decl_die(tree_node*, tree_node*, die_struct*)
(dwarf2out.c:19512)
==20321==by 0x8A1C2F: decls_for_scope(tree_node*, die_struct*, int)
(dwarf2out.c:19125)
==20321==by 0x8A2043: gen_block_die(tree_node*, die_struct*, int)
(dwarf2out.c:18111)
==20321==by 0x8A1CD5: decls_for_scope(tree_node*, die_struct*, int)
(dwarf2out.c:19139)
==20321==by 0x89DB1E: gen_subprogram_die(tree_node*, die_struct*)
(dwarf2out.c:17555)
==20321==by 0x89C214: gen_decl_die(tree_node*, tree_node*, die_struct*)
(dwarf2out.c:19489)
==20321==by 0x8A5818: dwarf2out_function_decl(tree_node*)
(dwarf2out.c:19871)
==20321==by 0x8FEF14: rest_of_handle_final() (final.c:4349)
==20321==by 0xA6ED94: execute_one_pass(opt_pass*) (passes.c:2074)
==20321==by 0xA6F134: execute_pass_list(opt_pass*) (passes.c:2129)
==20321==by 0xA6F146: execute_pass_list(opt_pass*) (passes.c:2130)
==20321==by 0xA6F146: execute_pass_list(opt_pass*) (passes.c:2130)
==20321==by 0xBD0CED: tree_rest_of_compilation(tree_node*)
(tree-optimize.c:420)
==20321==by 0x8249C9: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1819)
==20321==by 0x826B05: cgraph_optimize() (cgraphunit.c:1984)
==20321==by 0x826ED9: cgraph_finalize_compilation_unit()
(cgraphunit.c:1327)
==20321==by 0x64880A: cp_write_global_declarations() (decl2.c:4050)
==20321==by 0xB64033: toplev_main(int, char**) (toplev.c:581)
==20321==by 0x674ED2C: (below main) (in /lib64/libc-2.12.2.so)
==20321==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20321== 
testcase.C: In function 'bar(int*)void*':
testcase.C:11:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gcc: error: during -fcompare-debug recompilation
gcc: error: testcase.C: -fcompare-debug failure (length)

Tested revisions:
r181550 - crash
r181532 - crash
r181508 - crash
r181442 - OK

[Bug c++/47747] [trans-mem] unsafe virtual function not properly displayed

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution||FIXED

--- Comment #1 from torvald at gcc dot gnu.org 2011-11-21 22:31:14 UTC ---
This got fixed in r181602 on trunk.

[Bug libgomp/51249] semaphore implemetation for linux leaves threads blocked

[amodra at gmail dot com]

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

--- Comment #3 from Alan Modra  2011-11-21 22:21:13 
UTC ---
Sorry, I misread the code.  Indeed, the mutex will be left at 2.

I'm chasing a frustratingly elusive locking bug.  Symptoms are that one or two
libgomp tests fail each gcc testsuite run, not always the same test.  log shows
a timeout, but I'm fairly certain it isn't a real timeout but one of the
threads blocking.  This used to happen before rth's recent locking changes. 
The difficulty is that I can't seem to reproduce the failure when running tests
by hand.

I have a rewrite of sem.c,h which adds a "wait" field to the struct and uses
atomics, and have rewritten a number of other files to use atomics rather than
the old __sync functions.  I just haven't been game to post my changes until I
track down the problem.

[Bug c++/11750] class scope using-declaration lookup not implemented

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-18 20:22:49 |2011-11-21 20:22:49

[Bug c++/51239] ICE with variadic template alias

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-21
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug middle-end/51261] New: [4.7 Regression] -fcompare-debug with memset()

[zsojka at seznam dot cz]

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

 Bug #: 51261
   Summary: [4.7 Regression] -fcompare-debug with memset()
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

There have been many -fcompare-debug failures in the last testsuite run.

Compiler output:
$ gcc -fcompare-debug testcase.C 
gcc: error: testcase.C: -fcompare-debug failure

Tested revisions:
r181550 - fail
r181508 - fail
r181442 - OK

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[davem at gcc dot gnu.org]

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

--- Comment #21 from davem at gcc dot gnu.org 2011-11-21 21:50:46 UTC ---
Author: davem
Date: Mon Nov 21 21:50:41 2011
New Revision: 181598

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181598
Log:
Revert regression causing changes to store_bit_field_1.

Revert
2011-11-16  Andreas Krebbel  

PR middle-end/50325
* expmed.c (store_bit_field_1): Use extract_bit_field on big
endian targets if the source cannot be exactly covered by word
mode chunks.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c

[Bug fortran/51260] New: PARAMETER array with constructor initializer: Compile-time simplify single element access

[burnus at gcc dot gnu.org]

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

 Bug #: 51260
   Summary: PARAMETER array with constructor initializer:
Compile-time simplify single element access
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Missed optimization in several ways for:
integer, parameter:: is(1)=(/(i,i=1,1)/)
print *,is(1)
end

The main issue is that "is(1)" is not simplified into the constant "1".

Expected:

* The front end should already optimize is(1) to "1" and should not generate
the variable to store the parameter.

* One should somehow tell the middle end that only a single element is needed
for I/O. One currently has:
  _gfortran_transfer_integer_write (&dt_parm.0, &is[0], 4);
which requires the whole object though only the first 4 bytes are needed (=
&"1").

* The constructor should not be fully expanded, if one only needs a single
element, i.e. using
   integer, parameter:: is(*)=(/(i,i=1,1000)/)
should be quick if one only needs the first element. In any case, no parameter
array should be written if one can simplify it at front-end compilation time.

[Bug preprocessor/51259] New: no escape on control characters on linemarker lines

[pertusus at free dot fr]

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

 Bug #: 51259
   Summary: no escape on control characters on linemarker lines
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pertu...@free.fr


In the cpp manual, node 'Preprocessor Output' it is told about linemarker lines

  They mean that the following line originated in file filename at line
linenum. filename will never contain any non-printing characters; they are
replaced with octal escape sequences. 

This is not what the following test shows (\x01 is also often denoted as C^A):

echo "int main() { }" > aa`printf '\x01'`bb.h
echo '#include "aa'`printf '\x01'`'bb.h"' > inc.c

And look at
cpp inc.c

or
gcc -E inc.c

gcc compiles the file inc.c fine.

I have no idea whether cpp should conform to the documentation or whether the
documentation should be changed...


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-4'
--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 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-4)

[Bug debug/50827] [4.7 Regression] ICE: RTL check: expected elt 0 type 'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-11-21 
21:07:23 UTC ---
Author: jakub
Date: Mon Nov 21 21:07:19 2011
New Revision: 181597

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181597
Log:
PR debug/50827
* var-tracking.c (loc_cmp): For ENTRY_VALUEs use ENTRY_VALUE_EXP
macro instead of XEXP.

* gcc.dg/pr50827.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr50827.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/var-tracking.c

[Bug fortran/51218] [4.6/4.7 Regression] Potential optimization bug due to implicit_pure?

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |4.6.3

--- Comment #19 from Tobias Burnus  2011-11-21 
20:36:03 UTC ---
(In reply to comment #18)
> > @@ -3257,6 +3255,7 @@ pure_subroutine (gfc_code *c, gfc_symbol *sym)
> > +  gfc_current_ns->proc_name->attr.implicit_pure = 0;
> 
> Harald's example has function calls not subroutines.  I would
> expect that you need to set this in pure_function as well.

Hmm, I had the feeling that such a check is already there, but I have not
really audited resolve.c

> Also, does this type of change inhibit reason why 
> implicit_pure was added in the first place?

One probably should add a check whether the called procedure has
attr.implicit_pure has set - and only is not mark the current namespace as
impure. Then, I don't think it will inhibit the reason for the initial change.
And even if it does, having correct code is more important. We might be able to
mark more code as implicit none - but first we need to make sure that code
which is effectively not pure is also not marked as implicit_pure.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #18 from Steve Kargl  
2011-11-21 20:21:01 UTC ---
On Mon, Nov 21, 2011 at 08:02:20PM +, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
> 
> --- Comment #17 from Tobias Burnus  2011-11-21 
> 20:02:20 UTC ---
> (In reply to comment #16)
> > One thing it relies on is that the compiler recognizes
> > that the bad function are not pure, as they have a
> > side effect (e.g. accessing module variable call_level).
> > If a side effect is able to disable critical optimizations,
> > then I'm optimistic that the code will work on most platforms.
> > 
> > Now as promised, here's the reduced example:
> 
> Thanks for the example!
> 
> Untested patch:
> 
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -3257,6 +3255,7 @@ pure_subroutine (gfc_code *c, gfc_symbol *sym)
>else if (gfc_pure (NULL))
>  gfc_error ("Subroutine call to '%s' at %L is not PURE", sym->name,
>&c->loc);
> +  gfc_current_ns->proc_name->attr.implicit_pure = 0;
>  }

Harald's example has function calls not subroutines.  I would
expect that you need to set this in pure_function as well.

Also, does this type of change inhibit reason why 
implicit_pure was added in the first place?

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus  2011-11-21 
20:02:20 UTC ---
(In reply to comment #16)
> One thing it relies on is that the compiler recognizes
> that the bad function are not pure, as they have a
> side effect (e.g. accessing module variable call_level).
> If a side effect is able to disable critical optimizations,
> then I'm optimistic that the code will work on most platforms.
> 
> Now as promised, here's the reduced example:

Thanks for the example!

Untested patch:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -3257,6 +3255,7 @@ pure_subroutine (gfc_code *c, gfc_symbol *sym)
   else if (gfc_pure (NULL))
 gfc_error ("Subroutine call to '%s' at %L is not PURE", sym->name,
   &c->loc);
+  gfc_current_ns->proc_name->attr.implicit_pure = 0;
 }

[Bug c++/50958] [C++0x] raw literal operator provides incorrect string for integer literal '0'

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Jason Merrill  2011-11-21 
19:48:07 UTC ---
Fixed.

[Bug middle-end/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  2011-11-21 
19:41:16 UTC ---
The quoted test ought to have worked for i386-solaris.
If one of those predicates is wrong (e.g. is-effective-target ia32)
then there are other tests in the testsuite that are going to be
failing unnecessarily.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[anlauf at gmx dot de]

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

--- Comment #16 from Harald Anlauf  2011-11-21 19:31:13 
UTC ---
(In reply to comment #15)
> Because it generates "wrong-code" and I wasn't completely convinced that there
> is no bug lurking in implicit_pure. Thus, for me the status is an 
> "unconfirmed"
> bug which would be - if confirmed - a wrong-code 4.7 regression.

I found a shorter code which shows that functions with
side-effects are erroneously treated as pure, see below.

>  * * *
> 
> (In reply to comment #11)
> > The code does memory management similar to that required by
> > TR15581 for allocatable DT components and allocatable function
> > results, but it also has to work for compilers that do not
> > support TR15581.  It does so by overloading everything needed.
> 
> I think that by now most compilers support TR 15581, thus, you could consider
> to solve the issue by changing the code to TR 15581.

Well, most /= all.

At work I (have to) use a compiler which does not support TR 15581.
The (hard-/software) vendor (non-European, non-US) has been successfully
declining user demands to support F2003.

> At the moment you have code which might work by chance with some compilers but
> fail with others since it is invalid.

Well, I understand that the code does bad thing.
One thing it relies on is that the compiler recognizes
that the bad function are not pure, as they have a
side effect (e.g. accessing module variable call_level).
If a side effect is able to disable critical optimizations,
then I'm optimistic that the code will work on most platforms.

Now as promised, here's the reduced example:


module a
  implicit none
  integer :: neval = 0
! integer, volatile :: neval = 0   ! Won't change anything...
contains
  subroutine inc_eval
neval = neval + 1
  end subroutine inc_eval
end module a

module b
  use a
  implicit none
contains
  function f(x)
real :: f
real, intent(in) :: x
f = x
  end function f

! impure &   ! This won't help...
  function g(x)
real :: g
real, intent(in) :: x
! g is not pure, it has a side-effect!
call inc_eval
!   print *, "In g!"
g = x
  end function g
end module b

program gfcbug114a
  use a
  use b
  implicit none
  real :: x = 1, y = 1, t, u, v, w
  print *, (neval == 0) ! 0 initially
  t = f(x)*f(y)
  print *, (neval == 0)
  u = f(x)*f(y) + f(x)*f(y)
  print *, (neval == 0)
  v = g(x)*g(y)
  print *, (neval == 2)
  w = g(x)*g(y) + g(x)*g(y)
  print *, (neval == 6)
  print *, neval ! 6???
  print *, t, u, v, w
end program gfcbug114a


Running without optimization, I get:

 T
 T
 T
 T
 T
   6
   1.   2.   1.   2.

With optimization, the result is:

 T
 T
 T
 T
 F
   4
   1.   2.   1.   2.


Thus the number of function evaluations of the non-pure
function g deepends on the optimization.

Enabling the commented out print in g(),
I get the expected result.

Setting g as impure, as well as making neval volatile
does not help.  I do think that this qualifies as a bug.

[Bug c++/50958] [C++0x] raw literal operator provides incorrect string for integer literal '0'

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-11-21 
19:27:35 UTC ---
Author: jason
Date: Mon Nov 21 19:27:30 2011
New Revision: 181595

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181595
Log:
PR c++/50958
gcc/cp/
* parser.c (lookup_literal_operator): New.
(cp_parser_userdef_char_literal): Use it.
(cp_parser_userdef_numeric_literal): Use it.
(cp_parser_userdef_string_literal): Use lookup_name.
libcpp/
* expr.c (cpp_userdef_char_remove_type): Fix typo.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-implicit-conv-neg.C
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-raw-length.C
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-resolve.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/dfp/pr33466.c
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-declare-neg.C
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-member-neg.C
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-raw-op-string-neg.C
trunk/libcpp/ChangeLog
trunk/libcpp/expr.c

[Bug middle-end/51258] 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86

[amacleod at redhat dot com]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  2011-11-21 
19:21:30 UTC ---
32 bit targets don't usually support 128 bit atomic operations natively, and
leave calls to be resolved by an external atomic library.   There was some
issue with X32 support where 32 bit could support it under some circumstances.

Now gcc/testsuite/lib/target-supports.exp defines the testsuite check for
whether 128 bit is supported as:

proc check_effective_target_sync_int_128 { } {
if { ([istarget x86_64-*-*] || [istarget i?86-*-*])
 && ![is-effective-target ia32] } {
return 1
} else {
return 0
}
}

I presume if 32 bit solaris isn't supporting 128 bit operations then this needs
to be tweaked...

[Bug testsuite/51251] conflicting -mcpu switches during testing

[davem at gcc dot gnu.org]

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

--- Comment #9 from davem at gcc dot gnu.org 2011-11-21 19:11:56 UTC ---
In addition to the comments so far about what the testsuite framework
should be doing, I also think the sparc option processing is currently
doing the right thing given the input seen here.

If you say "-mcpu=cypress -mvis" which is what the command line amounts
to, it meant to enable VIS and that requires turning on V9 also which is
what the option processing in the sparc backend does.

[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc

[aph at gcc dot gnu.org]

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

--- Comment #6 from Andrew Haley  2011-11-21 18:02:29 
UTC ---
I suppose I don't really object to a workaround in libjava, but surely the
sensible thing to do is fix isspace() not to throw.  It can't, anyway: that
would be in breach of its spec.

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-21 17:30:21 UTC ---
> --- Comment #5 from Paolo Bonzini  2011-11-21 
> 17:25:20 UTC ---
> What's exactly the problem with gdb that requires disabling largefiles?

gdb (and only gdb AFAIK) uses procfs, and Solaris procfs doesn't support
a largefile environment, no idea why?

 has

#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error  "Cannot use procfs in the large file compilation environment"
#endif

Rainer

[Bug middle-end/51258] New: 64-bit gcc.dg/atomic-compare-exchange-5.c link failure on 32-bit Solaris/x86

[ro at gcc dot gnu.org]

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

 Bug #: 51258
   Summary: 64-bit gcc.dg/atomic-compare-exchange-5.c link failure
on 32-bit Solaris/x86
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: r...@gcc.gnu.org
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]


Several 64-bit atomic-* tests fail to link with a 32-bit Solaris/x86 gcc:

Running target unix/-m64
FAIL: gcc.dg/atomic-compare-exchange-5.c (test for excess errors)
WARNING: gcc.dg/atomic-compare-exchange-5.c compilation failed to produce
executable
FAIL: gcc.dg/atomic-exchange-5.c (test for excess errors)
WARNING: gcc.dg/atomic-exchange-5.c compilation failed to produce executable
FAIL: gcc.dg/atomic-load-5.c execution test
FAIL: gcc.dg/atomic-op-5.c (test for excess errors)
WARNING: gcc.dg/atomic-op-5.c compilation failed to produce executable
FAIL: gcc.dg/atomic-store-5.c (test for excess errors)
WARNING: gcc.dg/atomic-store-5.c compilation failed to produce executable

E.g. 

FAIL: gcc.dg/atomic-compare-exchange-5.c (test for excess errors)
Excess errors:
Undefinedfirst referenced
 symbol  in file
__atomic_compare_exchange_16/var/tmp//ccSEaa.G.o

FAIL: gcc.dg/atomic-exchange-5.c (test for excess errors)
Excess errors:
Undefinedfirst referenced
 symbol  in file
__atomic_exchange_16/var/tmp//cci5aWbI.o

FAIL: gcc.dg/atomic-op-5.c (test for excess errors)
Excess errors:
Undefinedfirst referenced
 symbol  in file
__atomic_fetch_nand_16  /var/tmp//ccnFaOtM.o
__atomic_fetch_or_16/var/tmp//ccnFaOtM.o
__atomic_fetch_add_16   /var/tmp//ccnFaOtM.o
__atomic_fetch_and_16   /var/tmp//ccnFaOtM.o
__atomic_fetch_xor_16   /var/tmp//ccnFaOtM.o
__atomic_fetch_sub_16   /var/tmp//ccnFaOtM.o

FAIL: gcc.dg/atomic-store-5.c (test for excess errors)
Excess errors:
Undefinedfirst referenced
 symbol  in file
__atomic_store_16   /var/tmp//ccV8ayIN.o

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[bonzini at gnu dot org]

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

--- Comment #5 from Paolo Bonzini  2011-11-21 17:25:20 
UTC ---
What's exactly the problem with gdb that requires disabling largefiles?

[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2011-11-21 
17:04:47 UTC ---
Created attachment 25873
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25873
Sanity checked on x86_64-linux and lightly tested arm-none-eabi

In practice, this works for me. Maybe Greta can test it more carefully.

[Bug middle-end/50283] [4.7 Regression] FAIL: g++.dg/eh/simd-1.C execution test

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2011-11-21 
17:04:20 UTC ---
Regarding label placement of frame related insns, we have the following
rtl for f2:

(insn 14 2 15 (sequence [
(call_insn 5 2 11 (parallel [
(call (mem:SI (symbol_ref/v:SI ("@_Z2f3v") [flags
0x203]  ) [0 f3 S4 A32])
(const_int 16 [0x10]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0]))
]) /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/simd-1.C:30
199 {call_symref}
 (expr_list:REG_NORETURN (const_int 0 [0])
(nil))
(nil))
(insn/f 11 5 15 (set (reg/f:SI 30 %r30)
(plus:SI (reg/f:SI 30 %r30)
(const_int 64 [0x40]))) 111 {addsi3}
 (nil))
]) /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/simd-1.C:30 -1
 (nil))

The assembler for f2 is:

.SPACE $TEXT$
.NSUBSPA $CODE$
.align 4
.EXPORT _Z2f2v,ENTRY,PRIV_LEV=3
L$FB0002:
_Z2f2v:
.PROC
.CALLINFO FRAME=64,CALLS,SAVE_RP
.ENTRY
stw %r2,-20(%r30)
L$CFI0001:
.CALL 
bl _Z2f3v,%r2
ldo 64(%r30),%r30
L$CFI0002:
nop
.EXIT
.PROCEND
L$FE0002:

L$CFI0002 is now after the call sequence whereas it used to be
before the sequence.

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-21 16:50:54 UTC ---
I forgot: while one could use ACX_LARGEFILE everywhere in GCC (and I
tried that using --disable-largefile when configuring gcc works with a
default-configured gld), I'd rather not cripple all of gcc for the
benefit of the lto-plugin.

Using the macro in lto-plugin alone doesn't work either: the plugin is
linked with libiberty, and gld SEGVs all over the place if libiberty
isn't built with largefile support.  Since libiberty is also linked into
all the compiler executables, we're effectively back to using
ACX_LARGEFILE/--disable-largefile everywhere.

Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
   Target Milestone|--- |4.7.0

--- Comment #3 from Rainer Orth  2011-11-21 16:41:54 UTC 
---
It took me a while, but the issue turned out to be different:

* Toplevel config/largefile.m4 disables largefile support for 32-bit Solaris,
  and both bfd and ld use ACX_LARGEFILE.

* On the other hand, gcc enables largefile support by default, thus the
lto-plugin
  is built with it.

* The resulting ld often fails in strange ways, as expected.

* If I build binutils with --enable-largefile, the vast majority of slim LTO
  tests suddenly pass, even when binutils ar, nm, and ranlib are nowhere in
  PATH, and are not plugin-enabled by default.

I'm undecided how to deal with this: the largefile disabling in largefile.m4 is
only for the benefit of procfs (thus gdb), but bfd/ld cannot know if they are
built in a combined tree.  ld cannot easily check if a plugin is largefile
enabled (this would probably be highly system-dependent), and there is no
guarantee that a plugin uses I/O functions at all.  Maybe the lto-plugin could
perform some check with dlsym (for open64?)?

Alternatiely, one could simply document the problem in install.texi and be done
with it.

Thoughts?
  Rainer

[Bug c++/47611] [trans-mem] memory allocated by default new/new_vec operator can be considered as transaction local

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution||INVALID

--- Comment #2 from torvald at gcc dot gnu.org 2011-11-21 16:39:40 UTC ---
If the alias oracle considers the memory region returned from new/delete to be
potentially escaping to code outside of the transaction, then I think we need
to respect this.  If you think this should not be possible, please file another
bug against the alias oracle.

[Bug driver/28718] Call to -lgcc added prior to user libraries

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #10 from Georg-Johann Lay  2011-11-21 
16:20:39 UTC ---
Jörg, could you prepare a list of functions that shall be excluded from libgcc?
You can also answer to my mail "PR28718 Infos?" from 2011-11-10.

[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #11 from Michael Matz  2011-11-21 16:23:00 
UTC ---
That sched2 moves frame related instructions into paths that didn't have
them before seems dubious.  The assert is correct in sofar as triggering
implies generating wrong unwind info:  Depending on if bb5 (the abort) would
be placed after or before bb 3, it would have wrong unwind info for the
path 2->5 (CFA would be r10, but it wouldn't be set up) or 3->5 (CFA would
be r6, but due to the push at the wrong offset).

I think the dead-label moving just exposes the bug in sched2.

[Bug middle-end/51130] ICE: in create_tmp_var, at gimplify.c:468 with -fgnu-tm and __transaction_atomic

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||matz at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #2 from Michael Matz  2011-11-21 16:25:34 
UTC ---
Yes, definitely a dup (tried testcase with my potential patch).

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

[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #7 from Michael Matz  2011-11-21 16:25:34 
UTC ---
*** Bug 51130 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/50827] [4.7 Regression] ICE: RTL check: expected elt 0 type 'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2011-11-21 
16:19:09 UTC ---
Created attachment 25872
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25872
gcc47-pr50827.patch

Untested fix.

[Bug other/51022] powerpc libgcc static-object.mk error

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg02109.htm
   ||l
   Last reconfirmed||2011-11-21
 CC||ro at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #5 from Rainer Orth  2011-11-21 16:13:50 UTC 
---
Mine, patch posted.

[Bug c++/51196] FAIL: g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|Greta.Yorsh at arm dot com  |

--- Comment #4 from Paolo Carlini  2011-11-21 
15:53:55 UTC ---
Unexpectedly ;) I'm making progress debugging this: what happens is that, for
arm, in cp_build_binary_op, case EQ_EXPR (this is for 'if (pmf == 0)') here:

  if (TARGET_PTRMEMFUNC_VBIT_LOCATION
  == ptrmemfunc_vbit_in_delta)
{
  tree pfn0 = pfn_from_ptrmemfunc (op0);
  tree delta0 = delta_from_ptrmemfunc (op0);
  tree e1 = cp_build_binary_op (location,
EQ_EXPR,
  pfn0,
  build_zero_cst (TREE_TYPE (pfn0)),
complain);
  tree e2 = cp_build_binary_op (location,
BIT_AND_EXPR, 
delta0,
integer_one_node,
complain);
  e2 = cp_build_binary_op (location,
   EQ_EXPR, e2, integer_zero_node,
   complain);
  op0 = cp_build_binary_op (location,
TRUTH_ANDIF_EXPR, e1, e2,
complain);
  op1 = cp_convert (TREE_TYPE (op0), integer_one_node); 
}
   else 
{
  op0 = build_ptrmemfunc_access_expr (op0, pfn_identifier);
  op1 = cp_convert (TREE_TYPE (op0), op1);
}

the condition is true, thus we don't call cp_convert with op1, which is
integer_zero_node here, instead we pass integer_one_node to cp_convert and the
warning down in cp_convert_to_pointer cannot possibly trigger (actually, for
arm we don't even reach cp_convert_to_pointer)

Thus, an idea for fixing the problem would be just warn right here for arm and
similar targets, because here we know that op1 is indeed integer_zero_node (and
that TYPE_PTRMEMFUNC_P (type0) is true of course)

Jason, can you imagine something neater?

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P4

--- Comment #4 from Georg-Johann Lay  2011-11-21 
15:50:11 UTC ---
(In reply to comment #0)

> Class test
> {
> virtual void example();
> };

Would you please post some real code that shows the problem and actually
*compiles* with, e.g.

avr-g++ -c vtable.cpp

instead of the lines above that trigger syntax error?

[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Aldy Hernandez  2011-11-21 
15:22:02 UTC ---
Thanks Patrick.

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[dave.anglin at bell dot net]

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

--- Comment #18 from dave.anglin at bell dot net 2011-11-21 14:59:53 UTC ---
On 11/18/2011 9:05 PM, amylaar at gcc dot gnu.org wrote:
> Could you test if this also fixes your regressions?
It does.

Thanks,
Dave

[Bug c++/51143] [C++11][DR 1159] Alias template allows class definition

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-21
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug libgomp/51249] semaphore implemetation for linux leaves threads blocked

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-11-21 
14:52:58 UTC ---
Can you please clarify why do you think mutex is problematic too?
When you do futex_wake in gomp_mutex_unlock_slow, you wake up one of the
threads that are already blocked (i.e. have called futex_wait in
gomp_mutex_lock_slow).
But once it calls futex_wait, it breaks the first loop and keeps setting the
mutex value to 2 rather than just 1.

As for gomp_sem_{wait,post}, I guess libgomp's sem.[ch] has been written based
on glibc before
http://sources.redhat.com/git/?p=glibc.git;a=patch;h=3d2dd6ca71fa9933e3413625d606f4b486661409
changes (we always want private in libgomp, so those parts are non-issue, but
the nwaiters maybe is).  I'll need to think about this more when I'm not so
sleepy.

[Bug c++/50852] [4.6/4.7 Regression] ICE: internal compiler error: in tsubst, at cp/pt.c:11030

[dodji at seketeli dot org]

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

--- Comment #3 from dodji at seketeli dot org  
2011-11-21 14:43:25 UTC ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01859.html for this.

[Bug testsuite/51251] conflicting -mcpu switches during testing

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill  2011-11-21 14:06:27 
UTC ---
(In reply to comment #7)

> > The issue is that when running on real hardware, you can't use arbitrary cpu
> > flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
> > because they could work on another board running rtems. Just not this one.
> 
> ...yes, that's why we have the dg-require-effective-target framework now.

I am thinking this may be a broader case than just that the CPU model on the
target doesn't have a particular feature.  sparc-rtems is different from
sparc64-rtems.  sparc-rtems is ONLY 32-bit v7 and v8.  

What's the simplest way to indicate that no 64-bit, VIS, etc tests are
applicable?

[Bug c++/51231] g++ remove placement new with -O1

[dushistov at mail dot ru]

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

Evgeniy Dushistov  changed:

   What|Removed |Added

  Known to work||4.4.5
  Known to fail||4.5.3, 4.6.2
   Severity|normal  |major

[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC

[krebbel at gcc dot gnu.org]

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

--- Comment #13 from Andreas Krebbel  2011-11-21 
13:31:16 UTC ---
This fixes the testcase on s390x. Tested with r181554.

Thanks!

[Bug c/48023] [trans-mem] no-builtin flag and TM builtin like memset

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution||FIXED

--- Comment #1 from torvald at gcc dot gnu.org 2011-11-21 13:27:11 UTC ---
This works for current trunk (both for memset and the memcpy in your test
case).

[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C

[matz at gcc dot gnu.org]

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

--- Comment #6 from Michael Matz  2011-11-21 13:28:08 
UTC ---
Yes, the patch submission to the mailing list was incorrect and contained a
non-intended change.  The patch as committed and ChangeLogged is correct.
Aldy: yes, I'm taking a peek.

[Bug testsuite/51251] conflicting -mcpu switches during testing

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|target  |testsuite
Summary|SPARC _64 instructions in   |conflicting -mcpu switches
   |V7 executables  |during testing

--- Comment #7 from Eric Botcazou  2011-11-21 
12:43:45 UTC ---
> The board in question is really a V7 and that is the proper cpu selection. It
> is added by the test framework in a dejagnu board file.

OK, but adding it like so is wrong.  Suppose that a SPARC-specific test checks
that some feature available only in V8 works; by adding -mcpu=cypress without
further ado, you'll most likely make the test fail.

Overriding compiler switches in tests is a no-no and...

> The issue is that when running on real hardware, you can't use arbitrary cpu
> flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
> because they could work on another board running rtems. Just not this one.

...yes, that's why we have the dg-require-effective-target framework now.

[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #25473|0   |1
is obsolete||

--- Comment #20 from Rainer Orth  2011-11-21 12:21:35 
UTC ---
Created attachment 25871
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25871
reduced testcase

I've now been able to reproduce the ICE with a 32-bit i386-pc-solaris2.11 x
mips-sgi-irix6.5 cross compiler, at the same time massively reducing the
testcase:

$ ./cc1plus -fpreprocessed pr50686.ii -quiet -g -O2
pr50686.ii: In function 'int maybe_adjust_start_pc(JCF*, int, int, int)':
pr50686.ii:68:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2244

I haven't been able to investigate further since I've been busy with several
other breakages this weekend, so I'd appreciate if you could have a look
yourself.

Thanks.
  Rainer

[Bug target/51251] SPARC _64 instructions in V7 executables

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill  2011-11-21 12:21:26 
UTC ---
(In reply to comment #5)
> > Hmmm... because of the way the test is compiled and the target flags are 
> > added,
> > there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> > "-mcpu=cypress".  I wonder what that results in other than a mess.
> 
> Whoever automatically adds -mcpu=cypress without checking whether there isn't
> already a -mcpu switch specified by the user is the culprit.

The board in question is really a V7 and that is the proper cpu selection. It
is added by the test framework in a dejagnu board file.

We have seen this before on arm and powerpc targets. In those cases, the tests
or scripts had something added to them. Janice Johnson tinkered with the
testsuite to address a similar failure on PowerPC. I found this message in the
thread.

 http://lists.gnu.org/archive/html/dejagnu/2008-12/msg00012.html

The issue is that when running on real hardware, you can't use arbitrary cpu
flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
because they could work on another board running rtems. Just not this one.

[Bug target/51251] SPARC _64 instructions in V7 executables

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-21
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #5 from Eric Botcazou  2011-11-21 
11:46:13 UTC ---
> Hmmm... because of the way the test is compiled and the target flags are 
> added,
> there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> "-mcpu=cypress".  I wonder what that results in other than a mess.

Whoever automatically adds -mcpu=cypress without checking whether there isn't
already a -mcpu switch specified by the user is the culprit.

[Bug libstdc++/51185] [C++0x] false-positive results of std::is_constructible

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0
   Severity|minor   |normal

--- Comment #5 from Paolo Carlini  2011-11-21 
11:24:27 UTC ---
Fixed.

[Bug libstdc++/51185] [C++0x] false-positive results of std::is_constructible

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2011-11-21 11:21:20 UTC ---
Author: paolo
Date: Mon Nov 21 11:21:13 2011
New Revision: 181557

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181557
Log:
2011-11-21  Daniel Krugler  

PR libstdc++/51185
* include/std/type_traits (__is_base_to_derived_ref,
__is_lvalue_to_rvalue_ref): Fix.
* testsuite/20_util/is_constructible/51185.cc: New.
* testsuite/20_util/is_constructible/value-2.cc: Extend.

Added:
trunk/libstdc++-v3/testsuite/20_util/is_constructible/51185.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
trunk/libstdc++-v3/testsuite/20_util/is_constructible/value-2.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug middle-end/51144] r181279 possibly miscompilation of genmddeps

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  2011-11-21 
10:10:31 UTC ---
(In reply to comment #5)
> PR middle-end/51144
> * output.h (fprint_w): Remove.
> * final.c (fprint_w): Remove.
> (output_addr_const): Change fprint_w back to fprintf.


This also fixed the s390 bootstrap problem:
http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg01784.html

Thanks!

[Bug objc++/51159] build failure with --enable-build-with-cxx in "gcc-4.6.2/gcc/objc/objc-next-runtime-abi-02.c"

[sebastian.heg...@tu-dresden.de]

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

--- Comment #5 from sebastian.heg...@tu-dresden.de 2011-11-21 09:43:23 UTC ---
Any chance of seeing the fix backported to 4.6, though?

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #41 from Mikael Pettersson  2011-11-21 
09:25:27 UTC ---
(In reply to comment #25)
> The first 4.6.1 bootstrap attempt failed at the very first Ada compilation 
> step
> in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads.  This was
> with a straight forward-port of the working 4.5.3 patch.  I'll keep digging...

GNAT/m68k worked on 4.6 branch, with a few unrelated interruptions, up to
r161654.  Starting with r161655 (Richard Guenther's big MEM_REF merge):
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
it fails as follows:

/tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/
-B/tmp/install46/m68k-unknown-linux-gnu/bin/
-B/tmp/install46/m68k-unknown-linux-gnu/lib/ -isystem
/tmp/install46/m68k-unknown-linux-gnu/include -isystem
/tmp/install46/m68k-unknown-linux-gnu/sys-include-c -g -O2   -W -Wall
-gnatpg   s-fatllf.ads -o s-fatllf.o
+===GNAT BUG DETECTED==+
| 4.6.0 20100703 (experimental) (m68k-unknown-linux-gnu) GCC error:|
| in gen_rtx_SUBREG, at emit-rtl.c:803 |
| Error detected around s-fatgen.adb:857:50|

This continues until r162897 (jiez's tree-sra tweak for PR45144):
http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00108.html
after which it fails a bit earlier as follows:

/tmp/objdir/./prev-gcc/xgcc -B/tmp/objdir/./prev-gcc/
-B/tmp/install46/m68k-unknown-linux-gnu/bin/
-B/tmp/install46/m68k-unknown-linux-gnu/bin/
-B/tmp/install46/m68k-unknown-linux-gnu/lib/ -isystem
/tmp/install46/m68k-unknown-linux-gnu/include -isystem
/tmp/install46/m68k-unknown-linux-gnu/sys-include-c -g -O2  -gnatpg -gnata
-nostdinc -I- -I. -Iada -I/tmp/gcc-4.6-r162898/gcc/ada
-I/tmp/gcc-4.6-r162898/gcc/ada/gcc-interface
/tmp/gcc-4.6-r162898/gcc/ada/a-charac.ads -o ada/a-charac.o
xgcc: internal compiler error: Segmentation fault (program gnat1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [ada/a-charac.o] Error 4
make[3]: Leaving directory `/tmp/objdir/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/tmp/objdir'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/tmp/objdir'
make: *** [bootstrap] Error 2

which is the failure seen originally with gcc-4.6.1.  a-charac.ads was compiled
ok earlier by the stage 1 (?) compiler, so this smells like a miscompilation of
stage 3.

I'll continue to bisect and test with r162897 reverted.

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #60 from Eric Botcazou  2011-11-21 
09:14:56 UTC ---
> I am marking this as 'waiting' - since it's probably better to get some
> feedback on the radar before cooking up a more complex fix.

Let's use SUSPENDED for that.

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #59 from Iain Sandoe  2011-11-21 09:05:55 
UTC ---
I am marking this as 'waiting' - since it's probably better to get some
feedback on the radar before cooking up a more complex fix.

[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #58 from Iain Sandoe  2011-11-21 09:04:14 
UTC ---
Author: iains
Date: Mon Nov 21 09:04:08 2011
New Revision: 181553

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

gcc/ada:

Backport from mainline r181474
PR target/50678
* init.c (__gnat_error_handler) [Darwin]: Move work-around to the
bug filed as radar #10302855 from __gnat_error_handler ...
... to (__gnat_adjust_context_for_raise) [Darwin]: New.
(HAVE_GNAT_ADJUST_CONTEXT_FOR_RAISE) [Darwin]: Define.
(__gnat_error_handler) [Darwin]: Use __gnat_adjust_context_for_raise.


Modified:
branches/gcc-4_6-branch/gcc/ada/ChangeLog
branches/gcc-4_6-branch/gcc/ada/init.c

[Bug target/49313] Inefficient libgcc implementations for avr

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  2011-11-21 
08:56:51 UTC ---
Author: gjl
Date: Mon Nov 21 08:56:44 2011
New Revision: 181551

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181551
Log:
PR target/49313
* config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add _moddi3, _umoddi3.
(LIB1ASMFUNCS): Add _divdi3, _udivdi3, _udivmod64, _negdi2.
* config/avr/lib1funcs.S (wmov): New assembler macro.
(__umoddi3, __udivdi3, __udivdi3_umoddi3): New functions.
(__moddi3, __divdi3, __divdi3_moddi3): New functions.
(__udivmod64): New function.
(__negdi2): New function.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S
trunk/libgcc/config/avr/t-avr

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  2011-11-21 
08:41:21 UTC ---
(In reply to comment #14)
> Tobias, Why did you mark this PR with the "wrong-code" keyword?

Because it generates "wrong-code" and I wasn't completely convinced that there
is no bug lurking in implicit_pure. Thus, for me the status is an "unconfirmed"
bug which would be - if confirmed - a wrong-code 4.7 regression.

However, it looks as if the code is invalid and so far I didn't come up with
something valid which gets wrongly treated.

 * * *

(In reply to comment #11)
> The code does memory management similar to that required by
> TR15581 for allocatable DT components and allocatable function
> results, but it also has to work for compilers that do not
> support TR15581.  It does so by overloading everything needed.

I think that by now most compilers support TR 15581, thus, you could consider
to solve the issue by changing the code to TR 15581.

At the moment you have code which might work by chance with some compilers but
fail with others since it is invalid.


> > I would advise you to fix your code to
> > be standard-conforming.
> 
> Do you have a suggestion without introducing a memory leak?

Unfortunately not. The mix of having to use INTENT(IN) because of OPERATOR(...)
combined with the need to modify the argument looks extremely fragile and - as
this issue shows - also breaks in practice. In principle, using TARGET, you
could allow the variable to alias - but only if you do not use INTENT(IN) ...

I think there is no simple way out, if (and only if) you need to be compatible
to pre-TR15581 compilers. One other suggestion would be to compile the code
with -O0.

For gfortran, I do not see any possibility to "fix" is, which doesn't cause
severe performance regressions. The problem is not just the implicit_pure
attribute or the front-end optimization. The Fortran front end also passes the
INTENT(IN) to the middle end, which allows also the middle end to certain
optimizations. And, here, the user has explicitly entered the INTENT(IN)
himself.

Alias issues are one of the most important problems which hamper optimization.
Thus, compilers try to make use of anything in the standard which rules out
aliasing. If they can't, temporary arrays have to be introduced, code may not
be optimized away, loop vectorization might be impossible etc. I think one of
the strengths of gfortran is that it makes a lot of effort to avoid array
temporaries and similar alias related issues.

Thus, unless a practical suggestion how gfortran should be changed comes up -
or a scenario is found where gfortran generates invalid code for a valid
program, I am inclined to close the bug as INVALID, which would be in line of
the comments of Thomas and Steve.

[Bug c++/51257] New: Template changes scope of friend functions

[pubby.8 at gmail dot com]

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

 Bug #: 51257
   Summary: Template changes scope of friend functions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pubb...@gmail.com


gcc version 4.7.0 2012 (experimental) (GCC) 

Unsure about this:

struct foo {
  friend void f1() { }

  template 
  friend void f2() { }
};

int main(){
  f1(); // doesn't compile
  f2(); // compiles, seems like it shouldn't
}

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe  2011-11-21 08:08:18 
UTC ---
(In reply to comment #18)
> Patch also break mips-linux-gnu.  See:
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html

I applied this on top of r181530 and reg-strapped on powerpc-darwin9.  
The 22_locale tests pass without regression in the struct-layout-1 series.

[Bug target/51251] SPARC _64 instructions in V7 executables

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-11-21 
08:07:29 UTC ---
(In reply to comment #1)
> Hmmm... because of the way the test is compiled and the target flags are 
> added,
> there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> "-mcpu=cypress".


It gets added via  gcc/testsuite/lib/target-supports.exp's
check_vect_support_and_set_flags:

} elseif [istarget sparc*-*-*] {
lappend DEFAULT_VECTCFLAGS "-mcpu=ultrasparc" "-mvis"

Hence, it should also affect also C/C++'s vect/ tests ...