[Bug middle-end/52209] [4.7 Regression] wrong code at -O0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  2012-02-11 
05:11:20 UTC ---
Caused by:
r176398 | rguenth | 2011-07-18 06:39:28 -0700 (Mon, 18 Jul 2011) | 7 lines

2011-07-18  Richard Guenther  

* expr.c (expand_expr_real_2): Properly truncate the BIT_NOT_EXPR
expansion result to bitfield precision if required.

* gcc.dg/torture/20110718-1.c: New testcase.

Looks like a missing REDUCE_BIT_FIELD.

[Bug middle-end/52209] [4.7 Regression] wrong code at -O0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.4.5, 4.6.0
   Target Milestone|--- |4.7.0
Summary|wrong code at -O0   |[4.7 Regression] wrong code
   ||at -O0
  Known to fail||4.7.0

--- Comment #2 from Andrew Pinski  2012-02-11 
05:05:17 UTC ---
Looks like we forgot to reduce the "bitfield" for expansion of ~.

[Bug middle-end/52209] wrong code at -O0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-11
  Component|c   |middle-end
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-02-11 
05:02:22 UTC ---
;; D.1714_2 = ~D.1713_1;

(insn 10 9 0 (parallel [
(set (reg:QI 60 [ D.1714 ])
(xor:QI (reg:QI 59 [ D.1713 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) t77.c:14 -1
 (nil))

;; b.0_3 = (int) D.1714_2;

(insn 11 10 0 (set (reg:SI 61 [ b.0 ])
(sign_extend:SI (reg:QI 60 [ D.1714 ]))) t77.c:14 -1
 (nil))


Confirmed, this is an expand issue, the ~ is being expanded incorrectly.
Here is a testcase for all optimizations level (except whole program):
struct S0
{
  int f2:1;
};

struct S0 c;

int b;

int main (void)
{
  b = -1 ^ c.f2;
  if (b != -1)
__builtin_abort();
  return 0;
}

[Bug rtl-optimization/52208] [4.7 Regression] Useless store

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
   Target Milestone|--- |4.7.0

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from H.J. Lu  2012-02-11 04:21:21 
UTC ---
Fixed on trunk, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32.

[Bug c/52209] New: wrong code at -O0

[regehr at cs dot utah.edu]

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

 Bug #: 52209
   Summary: wrong code at -O0
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu


[regehr@gamow 2]$ icc -Wall small.c
[regehr@gamow 2]$ ./a.out 
-1
[regehr@gamow 2]$ clang -Wall small.c
[regehr@gamow 2]$ ./a.out 
-1
[regehr@gamow 2]$ current-gcc -O0 small.c
[regehr@gamow 2]$ ./a.out 
1
[regehr@gamow 2]$ current-gcc -O1 small.c
[regehr@gamow 2]$ ./a.out 
-1
[regehr@gamow 2]$ cat small.c
int printf (const char *, ...);

struct S0
{
  int f2:1;
};

static struct S0 c;

int b;

int main (void)
{
  b = -1 ^ c.f2;
  printf ("%d\n", b);
  return 0;
}
[regehr@gamow 2]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r184082-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r184082-install
--program-prefix=r184082- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20120210 (experimental) (GCC)

[Bug rtl-optimization/52208] [4.7 Regression] Useless store

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||law at redhat dot com
  Component|target  |rtl-optimization

--- Comment #1 from H.J. Lu  2012-02-11 03:39:51 
UTC ---
It is caused by revision 17:

http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00533.html

[Bug target/52208] New: [4.7 Regression] Useless store

[hjl.tools at gmail dot com]

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

 Bug #: 52208
   Summary: [4.7 Regression] Useless store
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86_64


[hjl@gnu-6 pr52146]$ cat a.i
int test5() {
  int* apic_tpr_addr = (int *)0xfee00080;
  return *apic_tpr_addr + 5;
}
[hjl@gnu-6 pr52146]$ gcc -S -O a.i
[hjl@gnu-6 pr52146]$ cat a.s
.file"a.i"
.text
.globltest5
.typetest5, @function
test5:
.LFB0:
.cfi_startproc
movabsl4276093056, %eax
addl$5, %eax
ret
.cfi_endproc
.LFE0:
.sizetest5, .-test5
.ident"GCC: (GNU) 4.6.1 20110908 (Red Hat 4.6.1-9)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52146]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S  -O   a.i  
[hjl@gnu-6 pr52146]$ cat a.s
.file"a.i"
.text
.globltest5
.typetest5, @function
test5:
.LFB0:
.cfi_startproc
movabsl4276093056, %eax
movl%eax, -4(%rsp)
addl$5, %eax
ret
.cfi_endproc
.LFE0:
.sizetest5, .-test5
.ident"GCC: (GNU) 4.7.0 20120209 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52146]$ 

GCC 4.7 generates extra store:

movl%eax, -4(%rsp)

[Bug boehm-gc/52179] boehm-gc incompatible with aslr on darwin11

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2012-02-11 
01:10:48 UTC ---
Interestingly, aslr randomizes the gdb crash log. For instance...

# gdb ./gctest

(gdb) break mark.c:361
Breakpoint 1 at 0x20c49ba5e20a81: file
../../../gcc-4.7-20120209/boehm-gc/mark.c, line 361.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/gctest
 
Reading symbols for shared libraries + done
Reading symbols for shared libraries  done

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff6624b64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361MARK_FROM_MARK_STACK();
(gdb) c 106
Will ignore next 105 crossings of breakpoint 1.  Continuing.

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff6624b64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361MARK_FROM_MARK_STACK();
(gdb) break mark.c:759
Breakpoint 2 at 0x1066722ac: file ../../../gcc-4.7-20120209/boehm-gc/mark.c,
line 759.
(gdb) c 3000
Will ignore next 2999 crossings of breakpoint 1.  Continuing.

Breakpoint 2, GC_mark_from (mark_stack_top=0x106716000, mark_stack=0x106716000,
mark_stack_limit=0x106726000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759  deferred = *limit;
(gdb) c 1000
Will ignore next 999 crossings of breakpoint 2.  Continuing.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x7fff662d03d8
GC_mark_from (mark_stack_top=0x106716000, mark_stack=0x106716000,
mark_stack_limit=0x106726000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759  deferred = *limit;

vs

# gdb ./gctest
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov  3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries  done

(gdb) set disable-aslr off
(gdb) break mark.c:361
Breakpoint 1 at 0x20c49ba5e20a81: file
../../../gcc-4.7-20120209/boehm-gc/mark.c, line 361.
(gdb) r
Starting program:
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/x86_64-apple-darwin11.3.0/boehm-gc/testsuite/.libs/gctest
 
Reading symbols for shared libraries + done
Reading symbols for shared libraries  done

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff605eb64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361MARK_FROM_MARK_STACK();
(gdb) c 106
Will ignore next 105 crossings of breakpoint 1.  Continuing.

Breakpoint 1, GC_mark_some (cold_gc_frame=0x7fff605eb64c "\001") at
../../../gcc-4.7-20120209/boehm-gc/mark.c:361
361MARK_FROM_MARK_STACK();
(gdb) break mark.c:759
Breakpoint 2 at 0x100a112ac: file ../../../gcc-4.7-20120209/boehm-gc/mark.c,
line 759.
(gdb) c 4000
Will ignore next 3999 crossings of breakpoint 1.  Continuing.

Breakpoint 2, GC_mark_from (mark_stack_top=0x100abb000, mark_stack=0x100abb000,
mark_stack_limit=0x100acb000) at ../../../gcc-4.7-20120209/boehm-gc/mark.c:759
759  deferred = *limit;
(gdb) 

where the second attempt crosses the same number of breakpoints on mark.c:759
without crashing as in the first try.

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor  2012-02-11 00:10:13 
UTC ---
Note that the C++ example must be compiled -fnon-call-exceptions.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Depends on||52205

--- Comment #5 from Ian Lance Taylor  2012-02-11 00:07:07 
UTC ---
I just committed a patch to fix the channel endian problem, but forgot to put
the PR note in the commit message.

http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00533.html
http://gcc.gnu.org/ml/gcc-cvs/2012-02/msg00335.html

On x86 and x86_64 Solaris 2.11, all tests now pass for me.

On SPARC Solaris 2.11, there are still some failures.  At least some are due to
PR 52205.

No idea about Irix.

[Bug other/52207] License on gcc/doc/include/gcc-common.texi screws up the licenses of many other documents.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|blocker |normal

--- Comment #1 from Andrew Pinski  2012-02-10 
23:45:58 UTC ---
IIRC this was done on purpose.

[Bug target/52206] Strange %P in stack_tls_protect_set_ and movabs patterns

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from H.J. Lu  2012-02-10 23:42:21 
UTC ---
Close it.

[Bug target/52206] Strange %P in stack_tls_protect_set_ and movabs patterns

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-02-10 23:41:50 
UTC ---
I think it is used to avoid '$" in operand.

[Bug other/52207] New: License on gcc/doc/include/gcc-common.texi screws up the licenses of many other documents.

[naesten at gmail dot com]

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

 Bug #: 52207
   Summary: License on gcc/doc/include/gcc-common.texi screws up
the licenses of many other documents.
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: naes...@gmail.com


gcc/doc/include/gcc-common.texi says:

@c Copyright (C) 2001, 2002, 2003, 2004, 2005,
@c 2007 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.

gcc/doc/gcc.texi says:

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``Funding Free Software'', the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
``GNU Free Documentation License''.

(a) The FSF's Front-Cover Text is:

 A GNU Manual

(b) The FSF's Back-Cover Text is:

 You have freedom to copy and modify this GNU Manual, like GNU
 software.  Copies published by the Free Software Foundation raise
 funds for GNU development.

But there are a lot of other documents that include this file, most of which do
not include the "Funding Free Software" section (and have "@copying" blocks
different from the above):

find . -type f -print0 | "xargs" -0 -e grep -nH -e '@include.*gcc-common'
./gcc/ada/gnat-style.texi:30:@include gcc-common.texi
./gcc/ada/gnat_rm.texi:37:@include gcc-common.texi
./gcc/ada/gnat_ugn.texi:124:@include gcc-common.texi
./gcc/doc/cpp.texi:9:@include gcc-common.texi
./gcc/doc/gcc.texi:25:@include gcc-common.texi
./gcc/doc/cppinternals.texi:5:@include gcc-common.texi
./gcc/doc/gccint.texi:11:@include gcc-common.texi
./gcc/doc/install.texi:10:@include gcc-common.texi
./gcc/fortran/gfc-internals.texi:6:@include gcc-common.texi
./gcc/fortran/gfortran.texi:6:@include gcc-common.texi
./gcc/java/gcj.texi:12:@include gcc-common.texi
./gcc/go/gccgo.texi:12:@include gcc-common.texi

find . -type f -print0 | "xargs" -0 -e grep -nH -e '@include.*funding'
./gcc/doc/gcc.texi:173:@include funding.texi
./gcc/doc/gccint.texi:164:@include funding.texi
./gcc/fortran/gfortran.texi:3033:@include funding.texi

and which it is therefore probably illegal for anyone but the FSF to distribute
in built form.

[Bug target/52206] New: Strange %P in stack_tls_protect_set_ and movabs patterns

[hjl.tools at gmail dot com]

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

 Bug #: 52206
   Summary: Strange %P in stack_tls_protect_set_ and movabs
patterns
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86_64


i386.md has

(define_insn "stack_tls_protect_set_"
  [(set (match_operand:P 0 "memory_operand" "=m") 
(unspec:P [(match_operand:P 1 "const_int_operand" "i")] 
  UNSPEC_SP_TLS_SET))
   (set (match_scratch:P 2 "=&r") (const_int 0))
   (clobber (reg:CC FLAGS_REG))]
  ""
  "mov{}\t{%@:%P1, %2|%2,  PTR
%@:%P1}\;mov{}\t{%2, %0|%0, %2}\;xor{l}\t%k2, %k2"
  [(set_attr "type" "multi")])

Operand 1 is always a constant generated by

 operands[1] = GEN_INT (TARGET_THREAD_SSP_OFFSET);
  insn = (TARGET_LP64
  ? gen_stack_tls_protect_set_di
  : gen_stack_tls_protect_set_si);

(define_insn "*movabs_1"
  [(set (mem:SWI1248x (match_operand:DI 0 "x86_64_movabs_operand" "i,r"))
(match_operand:SWI1248x 1 "nonmemory_operand" "a,er"))]
  "TARGET_64BIT && ix86_check_movabs (insn, 0)"
  "@
   movabs{}\t{%1, %P0|%P0, %1}
   mov{}\t{%1, %a0|%a0, %1}"
  [(set_attr "type" "imov")
   (set_attr "modrm" "0,*")
   (set_attr "length_address" "8,0")
   (set_attr "length_immediate" "0,*")
   (set_attr "memory" "store")
   (set_attr "mode" "")])

(define_insn "*movabs_2"
  [(set (match_operand:SWI1248x 0 "register_operand" "=a,r")
(mem:SWI1248x (match_operand:DI 1 "x86_64_movabs_operand" "i,r")))]
  "TARGET_64BIT && ix86_check_movabs (insn, 1)"
  "@
   movabs{}\t{%P1, %0|%0, %P1}
   mov{}\t{%a1, %0|%0, %a1}"
  [(set_attr "type" "imov")
   (set_attr "modrm" "0,*")
   (set_attr "length_address" "8,0")
   (set_attr "length_immediate" "0")
   (set_attr "memory" "load")
   (set_attr "mode" "")])

The P code is only used on symbol for

P -- if PIC, print an @PLT suffix.

Why do we need it on immediate operand?

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  2012-02-10 
23:35:15 UTC ---
Here is a C++ example (which comes from PR 52205 which I marked as a dup of
this bug):
#include 
#include 
#include 
#include 

void
die(const char* msg)
{
  perror(msg);
  exit(EXIT_FAILURE);
}

void
handler(int signo, siginfo_t* info, void *context)
{
  printf("in handler signal %d\n", signo);
  throw signo;
}

int
main(int, const char**)
{
  struct sigaction act;
  memset(&act, 0, sizeof act);
  act.sa_sigaction = handler;
  sigfillset(&act.sa_mask);
  act.sa_flags = SA_SIGINFO;
  if (sigaction(SIGSEGV, &act, NULL) != 0)
die("sigaction");

  try
{
  *reinterpret_cast(0) = 1;
}
  catch (int signo)
{
  printf("caught signal %d\n", signo);
  exit(EXIT_SUCCESS);
}

  printf("did not catch\n");
  exit(EXIT_FAILURE);
}

[Bug target/52205] SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2012-02-10 
23:34:28 UTC ---
This is a dup of bug 51921.

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

[Bug target/51921] [4.6/4.7 regression] EH unwinding support is broken

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #9 from Andrew Pinski  2012-02-10 
23:34:28 UTC ---
*** Bug 52205 has been marked as a duplicate of this bug. ***

[Bug target/52205] New: SPARC Solaris 2.11 unwind through signal handler fails with -fnon-call-exceptions

[ian at airs dot com]

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

 Bug #: 52205
   Summary: SPARC Solaris 2.11 unwind through signal handler fails
with -fnon-call-exceptions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com
CC: r...@gcc.gnu.org


Compile this C++ program with -fnon-call-exceptions:

#include 
#include 
#include 
#include 

void
die(const char* msg)
{
  perror(msg);
  exit(EXIT_FAILURE);
}

void
handler(int signo, siginfo_t* info, void *context)
{
  printf("in handler signal %d\n", signo);
  throw signo;
}

int
main(int, const char**)
{
  struct sigaction act;
  memset(&act, 0, sizeof act);
  act.sa_sigaction = handler;
  sigfillset(&act.sa_mask);
  act.sa_flags = SA_SIGINFO;
  if (sigaction(SIGSEGV, &act, NULL) != 0)
die("sigaction");

  try
{
  *reinterpret_cast(0) = 1;
}
  catch (int signo)
{
  printf("caught signal %d\n", signo);
  exit(EXIT_SUCCESS);
}

  printf("did not catch\n");
  exit(EXIT_FAILURE);
}

When this program is run, it should print something like

in handler signal 11
caught signal 11

This works fine on GNU/Linux and on x86 and x86_64 Solaris 2.11.  When run on
SPARC Solaris 2.11, however, it prints

in handler signal 11
Segmentation Fault

I see this in both 32-bit and 64-bit mode.  If I tweak
libgcc/config/sparc/sol2-unwind.h so that sparc_is_sighandler sets *nframes to
3 rather than 2, then the test passes (I only tried this in 32-bit mode, not in
64-bit mode).  The cuh_pattern test in sparc_is_sighandler does not match, so
presumably it needs to be adjusted for Solaris 2.11.  However, I'm not sure how
to properly and safely correct it.

[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net 2012-02-10 22:44:17 UTC ---
On 2/10/2012 5:41 PM, John David Anglin wrote:
> There is only only one atomic instruction (ldcw). 
Actually, loads and stores are also atomic and strongly ordered.  But 
that's it.

[Bug rtl-optimization/52203] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-10
 CC||abel at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug other/52204] New: libiberty/at-file.texi has no copyright or license statement whatsoever

[naesten at gmail dot com]

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

 Bug #: 52204
   Summary: libiberty/at-file.texi has no copyright or license
statement whatsoever
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: naes...@gmail.com


Here is the entirety of the file:

>8
@c This file is designed to be included in manuals that use
@c expandargv.

@item @@@var{file}
Read command-line options from @var{file}.  The options read are
inserted in place of the original @@@var{file} option.  If @var{file}
does not exist, or cannot be read, then the option will be treated
literally, and not removed.

Options in @var{file} are separated by whitespace.  A whitespace
character may be included in an option by surrounding the entire
option in either single or double quotes.  Any character (including a
backslash) may be included by prefixing the character to be included
with a backslash.  The @var{file} may itself contain additional
@@@var{file} options; any such options will be processed recursively.
>8

And all relevant ChangeLog entries:

2005-10-07  Mark Mitchell  

* at-file.texi: Fix typo.

2005-10-03  Mark Mitchell  

* at-file.texi: New file.

[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net 2012-02-10 22:41:42 UTC ---
On 2/10/2012 5:26 PM, amacleod at redhat dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52201
>
> Andrew Macleod  changed:
>
> What|Removed |Added
> 
>   CC||amacleod at redhat dot com
>
> --- Comment #1 from Andrew Macleod  2012-02-10 
> 22:26:59 UTC ---
> Does this target support atomics and multi-threaded at all?
>
> do any tests in gcc/gcc.dg/atomic* run or are they all unsupported?
>
The target doesn't support atomics.  There is only only one atomic 
instruction (ldcw).

There is pthread and semaphore support.

gcc.dg/atomic-flag.c, gcc.dg/atomic-generic.c, gcc.dg/atomic-lockfree.c, 
gcc.dg/atomic-noinline-aux.c,
gcc.dg/atomic-noinline.c pass.  The remainder are unsupported

Dave

[Bug middle-end/52201] FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)

[amacleod at redhat dot com]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  2012-02-10 
22:26:59 UTC ---
Does this target support atomics and multi-threaded at all?

do any tests in gcc/gcc.dg/atomic* run or are they all unsupported?

[Bug rtl-optimization/52203] New: ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7136 with -fsel-sched-pipelining -fselective-scheduling2 and other custom flags

[zsojka at seznam dot cz]

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

 Bug #: 52203
   Summary: ICE: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7136 with -fsel-sched-pipelining
-fselective-scheduling2 and other custom flags
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

After a long time, there comes one sel-sched ICE.

Compiler output:
$ gcc -O -fPIC -fno-dce -fgcse -fschedule-insns2 -fsel-sched-pipelining
-fselective-scheduling2 -ftree-vectorize -funroll-loops -fno-web
-mno-avx256-split-unaligned-store -mfma --param=max-pending-list-length=0
--param=selsched-insns-to-rename=70 testcase.c 
testcase.c: In function 'foo':
testcase.c:9:1: internal compiler error: in reset_sched_cycles_in_current_ebb,
at sel-sched.c:7136
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x129c408 "/mnt/svn/gcc-trunk/gcc/sel-sched.c",
line=7136, function=0x129dce0 "reset_sched_cycles_in_current_ebb")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1  0x009a919d in reset_sched_cycles_in_current_ebb () at
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7136
#2  0x009bea53 in sel_region_target_finish (reset_sched_cycles_p=true)
at /mnt/svn/gcc-trunk/gcc/sel-sched.c:7209
#3  sel_region_finish (reset_sched_cycles_p=) at
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7266
#4  sel_sched_region (rgn=) at
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7622
#5  0x009bf23a in run_selective_scheduling () at
/mnt/svn/gcc-trunk/gcc/sel-sched.c:7693
#6  0x0098c076 in rest_of_handle_sched2 () at
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3515
#7  0x008fbd85 in execute_one_pass (pass=0x17ca8e0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2081
#8  0x008fc145 in execute_pass_list (pass=0x17ca8e0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2136
#9  0x008fc157 in execute_pass_list (pass=0x17c9ee0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2137
#10 0x008fc157 in execute_pass_list (pass=0x17c9f40) at
/mnt/svn/gcc-trunk/gcc/passes.c:2137
#11 0x00a5e3ee in tree_rest_of_compilation (fndecl=0x75bd2700) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#12 0x006b006a in cgraph_expand_function (node=0x75a976c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1829
#13 0x006b1f5c in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1896
#14 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2210
#15 0x006b25aa in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1338
#16 0x0058ecb0 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:10030
#17 0x009f0b9c in compile_file () at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#18 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938
#19 toplev_main (argc=28, argv=0x7fffd658) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2014
#20 0x761cc09d in __libc_start_main () from /lib64/libc.so.6
#21 0x005723b1 in _start ()

Tested revisions:
r184068 - crash
4.6 r180325 - OK

[Bug web/52200] Archives of some old versions of gcc are corrupted

[maisqual.project at gmail dot com]

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

--- Comment #3 from Boris Baldassari  
2012-02-10 21:44:13 UTC ---
Confirmed, has twice download problems. Third was right. 

Thank you!

[Bug web/52200] Archives of some old versions of gcc are corrupted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||WORKSFORME

--- Comment #2 from Jakub Jelinek  2012-02-10 
21:30:57 UTC ---
Yes, the problem must be on your side, bzip2 -tv gcc-4.6.1.tar.bz2 verifies
just fine here.

[Bug c++/52202] New: [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type

[jason at gcc dot gnu.org]

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

 Bug #: 52202
   Summary: [C++11][DR 1376] Should not extend lifetime of
temporary wrapped in static_cast to reference type
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


// Core 1376
// { dg-options -std=c++0x }

extern "C" void abort();
bool x;
struct T { ~T() { if (x) abort (); } };
int main()
{
  T&& r = static_cast(T());
  x = true;
}

[Bug middle-end/52201] New: FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

 Bug #: 52201
   Summary: FAIL: 29_atomics/atomic/operators/51811.cc (test for
excess errors)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa*-*-hpux11.11
Target: hppa*-*-hpux11.11
 Build: hppa*-*-hpux11.11


Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpu
x11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include
-isystem
 /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/h
ppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT
-fmessage-l
ength=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="."
-nostd
inc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-
hpux11.11 -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/tes
t/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/ba
ckward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc
++-v3/testsuite/29_atomics/atomic/operators/51811.cc   -std=gnu++0x
./libtestc++
.a   -lm   -o ./51811.exe(timeout = 600)
spawn /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gcc
 -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/test
/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/gnu64/gcc/gcc-
4.7/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/lib/
-
isystem /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/g
cc/gcc-4.7/hppa64-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa64-hp-hpux
11.11/./libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0
-ffun
ction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++
-I/test
/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/29_atomics/atomic/operators/51811.cc
-std=gnu++0x ./libtestc++.a -lm -o ./51811.exe
ld: Unsatisfied symbol "__atomic_fetch_add_8" in file /var/tmp//ccfj44l2.o
ld: Unsatisfied symbol "__atomic_fetch_sub_8" in file /var/tmp//ccfj44l2.o
2 errors.
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: Unsatisfied symbol "__atomic_fetch_add_8" in file /var/tmp//ccfj44l2.o
ld: Unsatisfied symbol "__atomic_fetch_sub_8" in file /var/tmp//ccfj44l2.o
2 errors.
collect2: error: ld returned 1 exit status

FAIL: 29_atomics/atomic/operators/51811.cc (test for excess errors)

Similar fail:

FAIL: 29_atomics/atomic/operators/pointer_partial_void.cc (test for excess
errors)

Tests fail on both 32 and 64-bit targets.

[Bug web/52200] Archives of some old versions of gcc are corrupted

[maisqual.project at gmail dot com]

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

--- Comment #1 from Boris Baldassari  
2012-02-10 21:18:59 UTC ---
Well.. Actually I was NOT able to get them right with bzip2recover.

The gcc-4.6.2.tar.bz2 is corrupted as well. (other not-mentioned releases were
ok).

More information:

 * Download the build : 

-8<
boris@server:gcc$ wget http://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-4.6.2.tar.bz2
--2012-02-10 21:29:10--  http://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-4.6.2.tar.bz2
Resolving ftp.gnu.org... 140.186.70.20
Connecting to ftp.gnu.org|140.186.70.20|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 71995338 (69M) [application/x-bzip2]
Saving to: `gcc-4.6.2.tar.bz2'

100%[===>]
71,995,338   132K/s   in 7m 0s

2012-02-10 21:36:11 (167 KB/s) - `gcc-4.6.2.tar.bz2' saved [71995338/71995338]
-8<

 * Untar the file:

-8<
boris@server:gcc$ wget
http://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-4.6.2.tar.bz2.sig
boris@server:gcc$ tar xjf ../../applis/src/gcc/gcc-4.6.1.tar.bz2

bzip2: Compressed file ends unexpectedly;
perhaps it is corrupted?  *Possible* reason follows.
bzip2: Inappropriate ioctl for device
Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
-8<

I verified the signature of the build..

-8<
boris@server:gcc$ gpg --verify gcc-4.6.2.tar.bz2.sig
gpg: Signature made Wed 26 Oct 2011 14:56:46 CEST using DSA key ID C3C45C06
gpg: Good signature from "Jakub Jelinek "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29  3709 A328 C3A2 C3C4 5C06
-8<

Could it come from my setup?

Thanks,

[Bug web/52200] New: Archives of some old versions of gcc are corrupted

[maisqual.project at gmail dot com]

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

 Bug #: 52200
   Summary: Archives of some old versions of gcc are corrupted
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maisqual.proj...@gmail.com


I had to download old versions of gcc for research purpose, and found some
releases to be corrupted. Namely:
 * gcc-4.3.0.tar.bz2
 * gcc-4.3.4.tar.bz2
 * gcc-4.4.3.tar.bz2
 * gcc-4.4.5.tar.bz2
 * gcc-4.5.3.tar.bz2
 * gcc-4.6.0.tar.bz2
 * gcc-4.6.1.tar.bz2

I was able to get them right with the bzip2recover utility, but this would be a
plus to have them clean on the download site.

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Severity|critical|normal

--- Comment #10 from kargl at gcc dot gnu.org 2012-02-10 20:44:47 UTC ---
(In reply to comment #9)
> Tobias
> 
> We have a problem in v4.6.2 with the following (using the std=f95 flag):
>  There seems to have been a limitation in past versions of gfortran with
> allocatable components inside derived types.  It was supposed to have been
> fixed, and should be no more a compiler bug.  It is valid (language-legal)
> fortran 95 and 2003, so must be a compiler limitation or compiler bug.
> 
> Other compiles are fine as well (g95, ifort, etc.).
> 
> Do you know if this has indeed been fixed?

The audit trail for this PR is quite confusing, and the above
is too vague to even guess at what your problem is.

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

[hjl at gcc dot gnu.org]

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

--- Comment #15 from hjl at gcc dot gnu.org  2012-02-10 
20:03:11 UTC ---
Author: hjl
Date: Fri Feb 10 20:03:08 2012
New Revision: 184113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184113
Log:
Add the testcase for PR 52146

Added:
trunk/gcc/testsuite/gcc.target/i386/pr52146.c

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[sphirshman at yahoo dot com]

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

--- Comment #9 from steven hirshman  2012-02-10 
20:00:47 UTC ---
Tobias

We have a problem in v4.6.2 with the following (using the std=f95 flag):
 There seems to have been a limitation in past versions of gfortran with
allocatable components inside derived types.  It was supposed to have been
fixed, and should be no more a compiler bug.  It is valid (language-legal)
fortran 95 and 2003, so must be a compiler limitation or compiler bug.

Other compiles are fine as well (g95, ifort, etc.).

Do you know if this has indeed been fixed?






From: burnus at gcc dot gnu.org 
To: sphirsh...@yahoo.com 
Sent: Friday, February 3, 2012 3:41 PM
Subject: [Bug fortran/52117] allocated arrays give incorrect results when used
with RESHAPE in gcc v4.6.2

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

Tobias Burnus  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Tobias Burnus  2012-02-03
20:41:32 UTC ---
Work around: -fno-realloc-lhs

Or add "(:)"
  B(:) = RESHAPE(A, SHAPE(B))

Solution: Update - it has just been fixed in the last days.

Thanks for the report!

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

[Bug libgcj/50057] [4.7 regression] misalignment of java_exception_header resulted in throwable to be null

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-10
 Ever Confirmed|0   |1

[Bug libgcj/50057] [4.7 regression] misalignment of java_exception_header resulted in throwable to be null

[ktietz at gcc dot gnu.org]

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

--- Comment #5 from Kai Tietz  2012-02-10 19:19:56 
UTC ---
Hmm, I assume issue is related to using of -mms-bitfields for 4.7 for
windows-targets.

Does the following patch fix the issue?

Index: exception.cc
===
--- exception.cc(revision 184105)
+++ exception.cc(working copy)
@@ -33,12 +33,18 @@
 }
 #include "unwind.h"

+#ifdef __MINGW32__
+__attribute__ ((gcc_struct))
+#endif
 struct alignment_test_struct
 {
   char space;
   char end[0] __attribute__((aligned));
 };

+#ifdef __MINGW32__
+__attribute__ ((gcc_struct))
+#endif
 struct java_exception_header
 {
   /* Cache handler details between Phase 1 and Phase 2.  */

[Bug target/52187] armeb-unknown-eabi not recognized as big-endian

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Target||arm
   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #3 from Richard Earnshaw  2012-02-10 
19:01:41 UTC ---
Not as important as linux because you can always enable the big-endian
multilibs.  Autodetection of the native target doesn't apply to cross building.

[Bug target/52199] V2DI vec_duplicate ICE on valid code

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc64-linux
 AssignedTo|unassigned at gcc dot   |meissner at gcc dot gnu.org
   |gnu.org |

--- Comment #1 from Peter Bergner  2012-02-10 
18:58:39 UTC ---
Mike said he would look into this one.

[Bug target/52199] New: V2DI vec_duplicate ICE on valid code

[bergner at gcc dot gnu.org]

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

 Bug #: 52199
   Summary: V2DI vec_duplicate ICE on valid code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: berg...@gcc.gnu.org


GCC ICEs on the reduced test case below:

bergner@igoo:~> cat v2di-ice.i 
struct locale_time_t
{
  const char *abday[7];
  const unsigned int *wabday[7];
};

static const unsigned int empty_wstr[1] = { 0 };

void
time_read (struct locale_time_t *time)
{
  int cnt;

  for (cnt=0; cnt < 7; cnt++)
{
  time->abday[cnt] = "";
  time->wabday[cnt] = empty_wstr;
}
}

bergner@igoo:~> /home/bergner/gcc/build/gcc-mainline/gcc/xgcc
-B/home/bergner/gcc/build/gcc-mainline/gcc -O3 -fmerge-all-constants
-mcpu=power7 -S v2di-ice.i 
v2di-ice.i: In function ‘time_read’:
v2di-ice.i:19:1: error: unrecognizable insn:
(insn 116 115 117 7 (set (reg:V2DI 234)
(vec_duplicate:V2DI (symbol_ref:DI ("empty_wstr") [flags 0x82]
))) v2di-ice.i:17 -1
 (nil))
v2di-ice.i:19:1: internal compiler error: in extract_insn, at recog.c:2123
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod  2012-02-10 
18:37:22 UTC ---
Author: amacleod
Date: Fri Feb 10 18:37:18 2012
New Revision: 184112

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

2012-02-10  Andrew MacLeod  

PR c/52190
* doc/extend.texi : Update comments for __atomic_compare_exchange and
__atomic_{is,always}_lock_free.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug testsuite/50722] FAIL: gcc.dg/pr49994-3.c (test for excess errors)

[janis at gcc dot gnu.org]

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

Janis Johnson  changed:

   What|Removed |Added

 CC||janis at gcc dot gnu.org

--- Comment #8 from Janis Johnson  2012-02-10 
18:36:37 UTC ---
Since the test only needs to compile and there are other targets (at least
arm-none-eabi) that warn, a cleaner fix would be to add "-w" to the options to
avoid the warnings.

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

[hjl at gcc dot gnu.org]

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

--- Comment #14 from hjl at gcc dot gnu.org  2012-02-10 
18:23:16 UTC ---
Author: hjl
Date: Fri Feb 10 18:23:12 2012
New Revision: 184111

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184111
Log:
Disallow negative constant address for x32

gcc/

2012-02-10  Uros Bizjak  

PR target/52146
* config/i386/i386.c (ix86_legitimate_address_p): Disallow
negative constant address for x32.

gcc/testsuite/

2012-02-10  H.J. Lu  

PR target/52146
* gcc.target/i386/pr52146.c: New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[bkoz at gcc dot gnu.org]

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

--- Comment #30 from Benjamin Kosnik  2012-02-10 
18:20:50 UTC ---
Author: bkoz
Date: Fri Feb 10 18:20:43 2012
New Revision: 184110

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184110
Log:
2012-02-10  Benjamin Kosnik  
Jonathan Wakely  

PR libstdc++/51798 continued.
* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Use __atomic_*
builtins instead of __sync_* builtins for atomic functionality.
* include/bits/shared_ptr_base.h: Same.
* include/parallel/compatibility.h: Same.
* include/profile/impl/profiler_state.h: Same.
* include/tr1/shared_ptr.h: Same.
* libsupc++/eh_ptr.cc: Same.
* libsupc++/eh_throw.cc: Same.
* libsupc++/eh_tm.cc: Same.
* libsupc++/guard.cc: Same.
* configure: Regenerated.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust line numbers.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
trunk/libstdc++-v3/include/parallel/compatibility.h
trunk/libstdc++-v3/include/profile/impl/profiler_state.h
trunk/libstdc++-v3/include/tr1/shared_ptr.h
trunk/libstdc++-v3/libsupc++/eh_ptr.cc
trunk/libstdc++-v3/libsupc++/eh_throw.cc
trunk/libstdc++-v3/libsupc++/eh_tm.cc
trunk/libstdc++-v3/libsupc++/guard.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-02/msg00499.htm
   ||l
 Resolution||FIXED

--- Comment #40 from Rainer Orth  2012-02-10 18:13:25 
UTC ---
Fixed for 4.7.0.

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[ro at gcc dot gnu.org]

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

--- Comment #39 from Rainer Orth  2012-02-10 18:10:19 
UTC ---
Author: ro
Date: Fri Feb 10 18:10:12 2012
New Revision: 184108

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184108
Log:
Use __GTHREAD_MUTEX_INIT_FUNCTION on Tru64 UNIX (PR libstdc++/51296)

PR libstdc++/51296
* config/os/osf/ctype_base.h,
config/os/osf/ctype_configure_char.cc,
config/os/osf/ctype_inline.h, config/os/osf/error_constants.h:
Copy from config/os/generic.
* config/os/osf/os_defines.h: Likewise.
(_GTHREAD_USE_MUTEX_INIT_FUNC, _GTHREAD_USE_COND_INIT_FUNC):
Define.
* configure.host : Use os/osf for os_include_dir.

Added:
trunk/libstdc++-v3/config/os/osf/
trunk/libstdc++-v3/config/os/osf/ctype_base.h
  - copied, changed from r184107,
trunk/libstdc++-v3/config/os/generic/ctype_base.h
trunk/libstdc++-v3/config/os/osf/ctype_configure_char.cc
  - copied, changed from r184107,
trunk/libstdc++-v3/config/os/generic/ctype_configure_char.cc
trunk/libstdc++-v3/config/os/osf/ctype_inline.h
  - copied, changed from r184107,
trunk/libstdc++-v3/config/os/generic/ctype_inline.h
trunk/libstdc++-v3/config/os/osf/error_constants.h
  - copied, changed from r184107,
trunk/libstdc++-v3/config/os/generic/error_constants.h
trunk/libstdc++-v3/config/os/osf/os_defines.h
  - copied, changed from r184107,
trunk/libstdc++-v3/config/os/generic/os_defines.h
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/configure.host

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

[ubizjak at gmail dot com]

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

--- Comment #13 from Uros Bizjak  2012-02-10 18:01:29 
UTC ---
(In reply to comment #12)
> What if the CONST_INT is from DImode expansion instead of SImode?
> val_signbit_known_set_p would handle that, INTVAL () < 0 not.

I have tested this case, and was not able to pass any constant that didn't fit
SImode to legitimate_address_p.

[Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  2012-02-10 
17:51:19 UTC ---
> I don't understand this sentence completely - if the types have been merged
> then the COMPONENT_REFs should have been updated, too (do they only have
> "weak" matched types at the point of LTO streaming?  Thus, do they maybe
> depend on the frontend TYPE_CANONICAL setting?)

The Ada front-end doesn't touch TYPE_CANONICAL at all.  It's the same type, but
instantiated from different units.  What I don't understand is when type
merging is supposed to be done: WPA, LTRANS, or both?

> Unless the COMPONENT_REF in question comes from constant folding from
> a global variable initializer for example (which is what the ??? is about)?

No, it's in a simple assignment statement.

> So - at which point during the compilation does the verification issue
> happen?

See the opening message, it's LTRANS.  The type mismatch is already present
when the assignment statement is streamed in at the beginning of LTRANS, as the
streamed in FIELD_DECL isn't the original FIELD_DECL that was streamed out.

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

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2012-02-10 
17:48:42 UTC ---
What if the CONST_INT is from DImode expansion instead of SImode?
val_signbit_known_set_p would handle that, INTVAL () < 0 not.

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

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak  2012-02-10 17:42:30 
UTC ---
(In reply to comment #9)
> HJ, Steffen, can you please test following patch instead:

val_signbit_known_set_p is a bit overkill, following patch works as well:

--cut here--
Index: i386.c
===
--- i386.c  (revision 184096)
+++ i386.c  (working copy)
@@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
   rtx base, index, disp;
   HOST_WIDE_INT scale;

+  /* Since constant address in x32 is signed extended to 64bit,
+ we have to prevent addresses from 0x8000 to 0x.  */
+  if (TARGET_X32
+  && CONST_INT_P (addr)
+  && INTVAL (addr) < 0)
+return false;
+
   if (ix86_decompose_address (addr, &parts) <= 0)
 /* Decomposition failed.  */
 return false;
--cut here--

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

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2012-02-10 17:28:54 
UTC ---
(In reply to comment #9)
> HJ, Steffen, can you please test following patch instead:
> 
> --cut here--
> Index: i386/i386.c
> ===
> --- i386/i386.c (revision 184096)
> +++ i386/i386.c (working copy)
> @@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
>rtx base, index, disp;
>HOST_WIDE_INT scale;
> 
> +  /* Since constant address in x32 is signed extended to 64bit,
> + we have to prevent addresses from 0x8000 to 0x.  */
> +  if (TARGET_X32
> +  && CONST_INT_P (addr)
> +  && val_signbit_known_set_p (SImode, INTVAL (addr)))
> +return false;
> +
>if (ix86_decompose_address (addr, &parts) <= 0)
>  /* Decomposition failed.  */
>  return false;
> --cut here--

It works.

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

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak  2012-02-10 17:05:47 
UTC ---
HJ, Steffen, can you please test following patch instead:

--cut here--
Index: i386/i386.c
===
--- i386/i386.c (revision 184096)
+++ i386/i386.c (working copy)
@@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
   rtx base, index, disp;
   HOST_WIDE_INT scale;

+  /* Since constant address in x32 is signed extended to 64bit,
+ we have to prevent addresses from 0x8000 to 0x.  */
+  if (TARGET_X32
+  && CONST_INT_P (addr)
+  && val_signbit_known_set_p (SImode, INTVAL (addr)))
+return false;
+
   if (ix86_decompose_address (addr, &parts) <= 0)
 /* Decomposition failed.  */
 return false;
--cut here--

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-02-10 17:01:39 UTC ---
> --- Comment #37 from Jonathan Wakely  2012-02-07 
> 09:22:29 UTC ---
> Rainer, you should now be able to define _GTHREAD_USE_MUTEX_INIT_FUNC and
> _GTHREAD_USE_COND_INIT_FUNC (either in gthr-posix.h or os_defines.h or 
> wherever
> you see fit) and then the tests should pass.

I've already posted a patch that does this:

http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00499.html

Rainer

[Bug tree-optimization/50031] Sphinx3 has a 10% regression going from GCC 4.5 to GCC 4.6 on powerpc

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from William J. Schmidt  2012-02-10 
16:38:44 UTC ---
Author: wschmidt
Date: Fri Feb 10 16:38:37 2012
New Revision: 184102

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184102
Log:
2012-02-10  Bill Schmidt  
Ira Rosen  

PR tree-optimization/50031
* targhooks.c (default_builtin_vectorization_cost): Handle
vec_promote_demote.
* target.h (enum vect_cost_for_stmt): Add vec_promote_demote.
* tree-vect-loop.c (vect_get_single_scalar_iteraion_cost): Handle
all types of reduction and pattern statements.
(vect_estimate_min_profitable_iters): Likewise.
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): New function.
(vect_get_load_cost): Use vec_perm for permutations; add dump logic
for explicit realigns.
(vectorizable_conversion): Call vect_model_promotion_demotion_cost.
* config/spu/spu.c (spu_builtin_vectorization_cost): Handle
vec_promote_demote.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Likewise.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Update
vec_perm for VSX and handle vec_promote_demote.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/spu/spu.c
trunk/gcc/target.h
trunk/gcc/targhooks.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-stmts.c

[Bug boehm-gc/48514] [4.6] boehm gc incorrectly compile using __declspec(dllexport) on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Kai Tietz  2012-02-10 16:33:48 
UTC ---
Fixed.

[Bug boehm-gc/48514] [4.6] boehm gc incorrectly compile using __declspec(dllexport) on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

--- Comment #4 from Kai Tietz  2012-02-10 16:32:44 
UTC ---
Author: ktietz
Date: Fri Feb 10 16:32:36 2012
New Revision: 184101

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184101
Log:
PR boehm-gc/48514
* include/gc_config_macros.h (GC_DLL): Define it for mingw-targets
only, if we are actual in boehm-gc's build and DLL_EXPORT
is defined.

Modified:
branches/gcc-4_6-branch/boehm-gc/ChangeLog
branches/gcc-4_6-branch/boehm-gc/include/gc_config_macros.h

[Bug boehm-gc/48514] [4.6] boehm gc incorrectly compile using __declspec(dllexport) on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  2012-02-10 16:30:59 
UTC ---
Author: ktietz
Date: Fri Feb 10 16:30:47 2012
New Revision: 184100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184100
Log:
PR boehm-gc/48514
* include/gc_config_macros.h (GC_DLL): Define it for mingw-targets
only, if we are actual in boehm-gc's build and DLL_EXPORT
is defined.

Modified:
trunk/boehm-gc/ChangeLog
trunk/boehm-gc/include/gc_config_macros.h

[Bug middle-end/52177] ICE: verify_gimple failed: non-trivial conversion at assignment with __atomic_is_lock_free()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-02-10 
15:47:22 UTC ---
Fixed.

[Bug middle-end/52177] ICE: verify_gimple failed: non-trivial conversion at assignment with __atomic_is_lock_free()

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-02-10 
15:31:23 UTC ---
Author: jakub
Date: Fri Feb 10 15:31:18 2012
New Revision: 184096

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184096
Log:
PR middle-end/52177
* builtins.c (fold_builtin_atomic_always_lock_free,
expand_builtin_atomic_always_lock_free,
fold_builtin_atomic_is_lock_free,
expand_builtin_atomic_is_lock_free): Return and/or test
boolean_true_node/boolean_false_node instead of
integer_one_node/integer_zero_node.

* c-c++-common/pr52177.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/pr52177.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug target/51753] Many gcc.dg/simultate-thread tests fail on Solaris 10+/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-02-10 15:28:17 UTC ---
> With this fixed, all but the
>
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c  -O0 -g  thread simulation
> test
>
> failures (at all optimization levels) were gone.  I didn't have the
> Linux/x86_64 gcc.log available for comparison, so I still have to
> investigate that one.

With the recent timeout changes, even those failures are gone, so
Solaris/x86 results are clean.

> I'm still seeing a large number of failures both on IRIX 6.5 and Tru64
> UNIX V5.1B (both with gdb 7.4), but I suppose those are better filed as
> separate PRs.  I certainly cannot compare gcc.log/g++.log output from
> other OSes since have no machines running e.g. Linux for comparison.

I'll check those with a massively increased timeout to see if that makes
a difference.  I wonder if it wouldn't be better to handle those other
platforms in a different PR.

Rainer

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-02-10 15:22:41 UTC ---
> --- Comment #13 from Jonathan Wakely  2012-02-06 
> 21:37:09 UTC ---
> please let me know what issues remain on Solaris after r183920

Solaris 8/9 works again, but the go1 runtime failure on Solaris 10/11
with gld remains.  But while this is triggered by your patch, it's
ultimately a gld bug.  I've filed

PR ld/13671
gld creates i386 relocations not supported by Solaris ld.so.1

for that, while at the same time checking with the Solaris linker
maintainers if it's possible to support the missing relocs directly.

Rainer

[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  2012-02-10 
15:21:27 UTC ---
Fixed.

[Bug bootstrap/52172] [4.7 Regression] stage 3 Bootstrap comparison failure on FreeBSD ia64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-02-10 
15:10:54 UTC ---
So, can you from your build log paste the command to compile var-tracking.c
with the stage2 gcc and rerun it in the gcc subdir with additional
-fcompare-debug option?  It might be a -fcompare-debug issue (in that case
rerun with -save-temps option and attach var-tracking.i together with the exact
command line option used to compile it, or stage1 or stage2 cc1/cc1plus might
be miscompiled.

[Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2012-02-10 
15:09:38 UTC ---
(In reply to comment #0)
> The problem has been present for months despite the various LTO changes.
> 
> The typical error message issued during LTRANS is:
> 
> /home/eric/svn/gcc/gcc/ada/lib-load.adb: In function 'lib__load__load_unit':
> /home/eric/svn/gcc/gcc/ada/lib-load.adb:344:0: error: type mismatch in
> component reference
> atree__atree_private_part__node_record___is_extension___XVN
> 
> atree__atree_private_part__node_record___is_extension___XVN
> 
> # VUSE <.MEM_328>
> T142b_492 =
> *atree__atree_private_part__nodes__table.19_489[D.105830_491].is_extension___XVN.S0.sloc;
> 
> It's a type mismatch between a COMPONENT_REF and the FIELD_DECL (operand #1).
> Everything is OK during compilation and the problem is apparently already 
> there
> when LTRANS kicks in, so the problem is probably in WPA.  As far as I can see,
> it merges 2 equivalent types and then updates the cache (uniquify_nodes):
> 
> /* If we're going to replace an element which we'd
>still visit in the next iterations, we wouldn't
>handle it, so do it here.  We do have to handle it
>even though the field_decl itself will be removed,
>as it could refer to e.g. integer_cst which we
>wouldn't reach via any other way, hence they
>(and their type) would stay uncollected.  */
> /* ???  We should rather make sure to replace all
>references to f2 with f1.  That means handling
>COMPONENT_REFs and CONSTRUCTOR elements in
>lto_fixup_types and special-case the field-decl
>operand handling.  */
> if (ix < i)
>   lto_fixup_types (f2);
> streamer_tree_cache_insert_at (cache, f1, ix);
> 
> But, while the types of the old set and the new set of fields are compatible 
> in
> GIMPLE, there is at least one field for which the type isn't compatible in the
> middle-end sense, and the type verifier chokes.

I don't understand this sentence completely - if the types have been merged
then the COMPONENT_REFs should have been updated, too (do they only have
"weak" matched types at the point of LTO streaming?  Thus, do they maybe
depend on the frontend TYPE_CANONICAL setting?)

> I'm a little at a loss as to how this is supposed to work: should the type of
> the COMPONENT_REF be updated too, i.e is that the ??? above?  Should this be
> handled via TYPE_CANONICAL, i.e the old and new type must have the same?  Or
> should this be patched up in input_gimple_stmt, similarly to what is already
> done:
>   /* Fixup FIELD_DECLs in COMPONENT_REFs, they are not handled
>  by decl merging.  */
>   if (TREE_CODE (op) == ADDR_EXPR)
> op = TREE_OPERAND (op, 0);
>   while (handled_component_p (op))
> 
> Any hint is welcome!

The code is mostly to paper over invalid-code issues and to give some
sensible warning to users if they declare decls with mismatching types.
But the code should also silence all tree checking errors that are
remaining (but issue a warning, so with -Werror it would not help you).
Unless the COMPONENT_REF in question comes from constant folding from
a global variable initializer for example (which is what the ??? is about)?
So - at which point during the compilation does the verification issue
happen?

[Bug tree-optimization/52186] array out of bounds error when accessing last byte of a struct via char ptr

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Guenther  2012-02-10 
14:54:16 UTC ---
Fixed in 4.6.

[Bug tree-optimization/52198] New: SLP vectorization does not consider swapped operands consistently

[rguenth at gcc dot gnu.org]

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

 Bug #: 52198
   Summary: SLP vectorization does not consider swapped operands
consistently
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


While vect_get_and_check_slp_defs swaps operands of binary operations in some
cases it does not do so when vect_build_slp_tree would reject the tree because
the operands have different operations in def stmts, for example with

  D.1751_23 = s_3(D) * D.1737_13;
  D.1753_25 = s_3(D) * D.1734_16;
  D.1755_27 = s_3(D) * D.1731_19;
  D.1757_29 = s_3(D) * D.1728_22;
  D.1777_7 = MEM[(const struct LorentzVector &)res_4(D)].theT;
  D.1775_31 = D.1777_7 + D.1751_23;
  D.1774_32 = MEM[(const struct LorentzVector &)res_4(D)].theZ;
  D.1772_34 = D.1753_25 + D.1774_32;
  D.1771_35 = MEM[(const struct LorentzVector &)res_4(D)].theY;
  D.1769_37 = D.1755_27 + D.1771_35;
  D.1768_38 = MEM[(const struct LorentzVector &)res_4(D)].theX;
  D.1766_40 = D.1757_29 + D.1768_38;
  res_4(D)->theX = D.1766_40;
  res_4(D)->theY = D.1769_37;
  res_4(D)->theZ = D.1772_34;
  res_4(D)->theT = D.1775_31;

where you can see that the first addition stmt has its operands swapped
(because of SSA name numbering contributing to canonicalization here).

This issue triggers in g++.dg/vect/slp-pr50819.cc if you install a patch
to properly release virtual operands of the call stmt during inlining
which frees up that SSA name for re-use:

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 184088)
+++ gcc/tree-inline.c   (working copy)
@@ -4002,6 +4002,9 @@ expand_call_inline (basic_block bb, gimp

   /* Unlink the calls virtual operands before replacing it.  */
   unlink_stmt_vdef (stmt);
+  if (gimple_vdef (stmt)
+  && TREE_CODE (gimple_vdef (stmt)) == SSA_NAME)
+release_ssa_name (gimple_vdef (stmt));

   /* If the inlined function returns a result that we care about,
  substitute the GIMPLE_CALL with an assignment of the return

[Bug bootstrap/52172] [4.7 Regression] stage 3 Bootstrap comparison failure on FreeBSD ia64

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  2012-02-10 
14:47:40 UTC ---
> Same for gcc-4.7-20120204.
> Is this snapshot after r183751?

According to http://gcc.gnu.org/ml/gcc/2012-02/msg00111.html it is revision
183896, so yes it is after r183751 (4.7.0.20120107 was r182982 and
4.7.0.20120128 r183669).

[Bug bootstrap/52172] [4.7 Regression] stage 3 Bootstrap comparison failure on FreeBSD ia64

[mexas at bristol dot ac.uk]

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

--- Comment #5 from Anton Shterenlikht  2012-02-10 
14:35:12 UTC ---
Same for gcc-4.7-20120204.
Is this snapshot after r183751?

gmake[3]: Leaving directory `/usr/ports/lang/gcc47/work/build'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/var-tracking.o differs
gmake[2]: *** [compare] Error 1
gmake[2]: Leaving directory `/usr/ports/lang/gcc47/work/build'
gmake[1]: *** [stage3-bubble] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/gcc47/work/build'
gmake: *** [bootstrap-lean] Error 2
*** Error code 1

Stop in /usr/ports/lang/gcc47.
*** Error code 1

[Bug other/52192] GCC_CHECK_TLS doesn't detect native TLS on Solaris 8/9

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-02-10 13:59:12 UTC ---
> --- Comment #1 from Jonathan Wakely  2012-02-09 
> 20:01:41 UTC ---
> (In reply to comment #0)
>> needs to link with -lthread for __tls_get_addr.  -pthread knows about this
>> and the necessary contortions, and I do have a patch to try the test with 
>> -pthread if it fails without, and adds it to LDFLAGS if that works.
>
> Will that be Solaris only? Because I'm seeing many failures on NetBSD due to
> undefined refs to __tls_get_addr, which I haven't investigated yet.

No, the patch just tries the TLS test first without and then with
-pthread to check if it makes a difference.

Rainer

[Bug libitm/52197] New: library cannot be rebuilt by make all-target

[ebotcazou at gcc dot gnu.org]

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

 Bug #: 52197
   Summary: library cannot be rebuilt by make all-target
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org


This is a little annoying for development: you cannot rebuild libitm by the
usual make all-target-libitm or make all-target.  Do a rm -rf $(target)libitm
and then issue one of the former two commands, you get:

/bin/sh ./libtool --tag=CXX   --mode=compile 
-B/home/eric/install/gcc/i586-suse-linux/bin/
-B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem
/home/eric/install/gcc/i586-suse-linux/include -isystem
/home/eric/install/gcc/i586-suse-linux/sys-include-DHAVE_CONFIG_H -I.
-I/home/eric/svn/gcc/libitm  -I/home/eric/svn/gcc/libitm/config/linux/x86
-I/home/eric/svn/gcc/libitm/config/linux -I/home/eric/svn/gcc/libitm/config/x86
-I/home/eric/svn/gcc/libitm/config/posix
-I/home/eric/svn/gcc/libitm/config/generic -I/home/eric/svn/gcc/libitm 
-march=i486 -mtune=i586 -fomit-frame-pointer -Wall -Werror  -Wc,-pthread
-std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2
-D_GNU_SOURCE -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c -o aatree.lo
/home/eric/svn/gcc/libitm/aatree.cc
libtool: compile: unrecognized option
`-B/home/eric/install/gcc/i586-suse-linux/bin/'
libtool: compile: Try `libtool --help' for more information.
make[3]: *** [aatree.lo] Error 1

You need to do a make all to rebuild the library.

[Bug middle-end/49536] latent bug with creation of vector of arrays

[baldrick at gcc dot gnu.org]

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

--- Comment #8 from Duncan Sands  2012-02-10 
12:34:21 UTC ---
Author: baldrick
Date: Fri Feb 10 12:34:17 2012
New Revision: 184090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184090
Log:
Backport the fix for PR tree-optimization/49536 from mainline.
Patch by Jack Howarth, approved by Richard Guenther.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-vect-stmts.c

[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  2012-02-10 
12:31:24 UTC ---
Yes, it looks OK to me.  Thanks!
Perhaps we will eventually need to give up on this sanity check as the
transformations we do to callgraph gets more general...

Honza

[Bug tree-optimization/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2012-02-10 
12:30:39 UTC ---
The bug was that the gnu.ver wildcards were too generic and thus matched even
something that wasn't intended to be exported and just happened to be exported
as an implementation detail.
This caused a problem on Linux several years ago (I think in 2005), and since
then these are forcefully exported from compatibility.cc:
/* gcc-3.4.4
_ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv
_ZNSt19istreambuf_iteratorIwSt11char_traitsIwEEppEv
 */

namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION

  template
istreambuf_iterator&
istreambuf_iterator::operator++();

#ifdef _GLIBCXX_USE_WCHAR_T
  template
istreambuf_iterator&
istreambuf_iterator::operator++();
#endif

_GLIBCXX_END_NAMESPACE_VERSION
} // namespace

but not on Solaris, because it either doesn't support GNU symver, or doesn't
have corresponding runtime support.
I think the bug is not on the optimization side, it is fine if the
optimizations change stuff that are implementation details, C++ isn't a very
good language for ABI stability and just requires lots of work on the libstdc++
side to preserve at least some.

So, I'd say it is time to preprocess the *.ver files and tweak them based on
target OS or its version, and additionally you'll want (for Solaris) enable the
above hunk (sans the following stuff), to make sure it doesn't go again when
the optimizers change.

[Bug middle-end/48600] [4.7 Regression] ICE when using cold attribute

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|[4.6/4.7 Regression] ICE|[4.7 Regression] ICE when
   |when using cold attribute   |using cold attribute

--- Comment #17 from Jan Hubicka  2012-02-10 
12:22:50 UTC ---
Fixed in 4.7. Backport to 4.6 should be easy.

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

[steffen-schmidt at siemens dot com]

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

--- Comment #8 from Steffen Schmidt  
2012-02-10 12:23:00 UTC ---
(In reply to comment #5)
> Created attachment 26636 [details]
> A patch

I've tried the patch, it applied cleanly, but unfortunately it had no effect on
the generated code.
The gcc built is based on latest of branch hjl/x32/gcc-4_6-branch+mx32, should
I switch to another gcc branch?

[Bug middle-end/48600] [4.6/4.7 Regression] ICE when using cold attribute

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  2012-02-10 
12:21:24 UTC ---
Author: hubicka
Date: Fri Feb 10 12:21:16 2012
New Revision: 184089

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184089
Log:
PR middle-end/48600
* predict.c (predict_paths_for_bb): Prevent looping.
(predict_paths_leading_to_edge, predict_paths_leading_to): Update.
* g++.dg/torture/pr48600.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr48600.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  2012-02-10 
11:49:18 UTC ---
Created attachment 26638
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26638
gcc47-pr51929.patch

Actually, it is handled afterwards using the former_clone_of check.
If that one is adjusted too, this compiles fine.  Does this look correct?

[Bug tree-optimization/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-10
 Ever Confirmed|0   |1

--- Comment #6 from Richard Guenther  2012-02-10 
11:31:00 UTC ---
So, if we'd want to be really consistent with symbols remaining in the
libstdc++ object files at different optimization levels (I guess if you
build libstdc++ with -O3 things might be different again) then we need
to avoid removing unused instantiated templates as part of the optimization
process.  Not sure on what basis we choose to be exported symbols right now.

[Bug libstdc++/52189] [4.7 regression] Relaxed gthreads check breaks Solaris 8/9 symbol versioning

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-02-10 
11:31:22 UTC ---
i.e #undef _GLIBCXX_HAS_GTHREADS

[Bug libstdc++/52189] [4.7 regression] Relaxed gthreads check breaks Solaris 8/9 symbol versioning

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-02-10 
11:29:09 UTC ---
(In reply to comment #0)
> * Default to --disable-threads on Solaris 8/9 to avoid breaking symbol
>   versioning.  That's my current preference, but certainly requires
> documentation
>   explaining the choice, since it's obviously a pity.

Or override the autoconf check which decides to enable C++11 thread support,
which would only disable std::thread, std::future etc. (the source of the
problem symbols) rather than disabling all thread support.

[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-02-10 
11:27:39 UTC ---
What happens is that cgraph_materialize_clone on the _ZN1BIcEC2E1Ai.constprop.1
clone performs:
2451  if (!node->clone_of->analyzed && !node->clone_of->clones)
2452{
2453  cgraph_release_function_body (node->clone_of);
2454  cgraph_node_remove_callees (node->clone_of);
2455  ipa_remove_all_references (&node->clone_of->ref_list);
2456}
2457  node->clone_of = NULL;
where node->clone_of is _ZN1BIcEC2E1Ai, i.e. the __base_ctor and so the
verification fails.
Even before this cgraph_remove_unreachable_nodes marks the _ZN1BIcEC1E1Ai (i.e.
__comp_ctor to which the call_stmts still refer) as unreachable and calls
ipa_remove_all_references on it, which means I don't see a way how we could get
from the _ZN1BIcEC2E1Ai to _ZN1BIcEC1E1Ai node anymore.

Honza?

[Bug libstdc++/52189] [4.7 regression] Relaxed gthreads check breaks Solaris 8/9 symbol versioning

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-02-10 
11:25:35 UTC ---
This change:

--- baseline_symbols.txt2012-01-23 19:01:03.590486000 +0100
+++ baseline_symbols.txt.s8g2012-01-23 19:03:38.063402000 +0100
@@ -2176,0 +2177 @@
+FUNC:_ZSt16__get_once_mutexv@@GLIBCXX_3.4.12
@@ -2209,0 +2211 @@
+FUNC:_ZSt23__get_once_functor_lockv@@GLIBCXX_3.4.11
@@ -2212,0 +2215 @@
+FUNC:_ZSt27__set_once_functor_lock_ptrPSt11unique_lockISt5mutexE@@GLIBCXX_3.4.12
@@ -2649,0 +2653 @@
+OBJECT:16:_ZSt14__once_functor@@GLIBCXX_3.4.11
@@ -2715,2 +2718,0 @@
-OBJECT:16:__emutls_v._ZSt11__once_call@@GLIBCXX_3.4.15
-OBJECT:16:__emutls_v._ZSt15__once_callable@@GLIBCXX_3.4.15

indicates that it was previously using TLS and now isn't (as discussed in PR
52104) so that's what should be fixed to bring the __once_call* symbols back

[Bug tree-optimization/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-02-10 
11:23:49 UTC ---
Then simply don't export it?  It's a template instantiation after all.

[Bug libstdc++/52189] [4.7 regression] Relaxed gthreads check breaks Solaris 8/9 symbol versioning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ABI
   Target Milestone|--- |4.7.0

--- Comment #1 from Richard Guenther  2012-02-10 
11:20:33 UTC ---
4) Don't export them (thus, eventually live with undefined symbols?)

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-10
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-02-10 
11:14:02 UTC ---
Confirmed thus.

[Bug libstdc++/52191] abi_check should flag additions to released versions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-10
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Richard Guenther  2012-02-10 
11:12:54 UTC ---
Confirmed.  That would be indeed very nice to have.

[Bug translation/52193] Bad translatable string: failed to reclaim unneeded functionin same comdat group

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Richard Guenther  2012-02-10 
11:10:27 UTC ---
Fixed.

[Bug translation/52193] Bad translatable string: failed to reclaim unneeded functionin same comdat group

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-02-10 
11:10:12 UTC ---
Author: rguenth
Date: Fri Feb 10 11:10:04 2012
New Revision: 184086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184086
Log:
2012-02-10  Richard Guenther  

PR translation/52193
* cgraphunit.c (cgraph_mark_functions_to_output): Fix typo.

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

[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-10 
10:33:33 UTC ---
This is related to same body aliases.  The verification fails because IPA-CP
decides to cgraph_redirect_edge_callee a call_stmt that calls a same_body_alias
of B::B(A, int) (__comp_ctor) to a clone of not that node (i.e. not the
same_body_alias), but of its ->thunk.alias (i.e. the alias with the actual body
of the ctor, __base_ctor).  I don't find anything wrong on that, so I've tried
to adjust just the verification:
- function.  This ping-pong has to go, eventaully.  */
+ function.  This ping-pong has to go, eventually.  */
   && (node != cgraph_function_or_thunk_node (e->callee, NULL))
-  && !clone_of_p (node, e->callee))
+  && !clone_of_p (node, e->callee)
+  /* If decl is a same body alias of some other decl, allow e->callee to
be
+ a clone of a clone of that other decl too.  */
+  && (!node->same_body_alias
+  || !clone_of_p (cgraph_get_node (node->thunk.alias), e->callee)))

but unfortunately it just cures one of the two error: edge points to wrong
declaration: errors.

[Bug tree-optimization/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-02-10 10:24:36 UTC ---
> caused libstdc++.so symbol versioning to be broken on Solaris.  Before the
> patch,
> when compiling locale-const.cc only contains references and definitions of
>
> _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv.constprop.36
>
> After the patch, the same source has references to
>
> _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv

The change isn't Solaris-specific, btw.  I've just compiled the same
preprocessed file (with -fpermissive added to avoid

/vol/gcc/src/hg/trunk/reghunt/libstdc++-v3/libsupc++/new:93:54: error:
'operator new' takes type 'size_t' ('long unsigned int') as first parameter
[-fpermissive]

) on x86_64-unknown-linux-gnu: with gcc 4.6 off the top of the 4.6
branch, the symbol doesn't occur in the output at all, with mainline, it
does.

Rainer

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

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-02-10 10:14:36 
UTC ---
(In reply to comment #5)
> Created attachment 26636 [details]
> A patch

This should be implemented in constant_address_p.

[Bug middle-end/52177] ICE: verify_gimple failed: non-trivial conversion at assignment with __atomic_is_lock_free()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2012-02-10 
08:52:25 UTC ---
Created attachment 26637
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26637
gcc47-pr52177.patch

Untested fix.  These two builtins return bool, so can't fold into
integer_one_node or integer_zero_node.

[Bug fortran/52196] New: Add -Wrealloc-lhs

[burnus at gcc dot gnu.org]

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

 Bug #: 52196
   Summary: Add -Wrealloc-lhs
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org


While (re)allocation of the LHS with intrinsic assignment is a great feature,
for hot loops it can cause in some cases a severe slow down. Analyzing a
program to find the places where reallocation happens, can be rather difficult.
Thus, it would be useful if the compiler could assist by providing the
following warnings:

(Suggested wording, should be refined.)

-Wrealloc-lhs
Warn when the compiler inserts code to for allocation or reallocation of an
allocatable array variable of intrinsic type in intrinsic assignments. In hot
loops, the Fortran 2003 reallocation feature may reduce the performance. If the
array is already allocated with the correct shape, consider using a whole-array
array-spec (e.g. "(:,:,:)") for the variable on the left-hand side to prevent
the reallocation check. See also -frealloc-lhs.

-Wrealloc-lhs-all
Warn when the compiler inserts code to for allocation or reallocation of an
allocatable variable; this includes scalars and derived types.


The reason I suggest two flags:

The first one is probably the more useful one: intrinsic variables are
typically used in hot loops, for arrays the effect is more severe and in many
program - even those which use reallocate on assignment - the array
realloc-on-assignment for an intrinsic type is rarely used. Additionally, by
adding an array section, which encompasses the whole array, reallocation can be
prevented without causing further problems.

By contrast, for scalars intrinsic types are typically either not allocatable
or - as with deferred-length characters - the reallocation is usually intended
and not used in hot loops. Similarly for derived types: Assignments are
typically not done in hot loops, otherwise, they are either simple scalars
(which shouldn't be allocatables) or not used in hot loops. If they have
allocatable components, the reallocation is already heavy.

Thus, in many cases, -Wrealloc-lhs will show potential hotspots without too
many false positives, while the extra warnings of -Wrealloc-lhs-all might be
sometimes helpful but should also contain many false positives.

[Bug libstdc++/52195] doesn't put stdio, stderr and stdin in the std namespace

[nospam.kotarou.dono at gmail dot com]

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

--- Comment #3 from nospam.kotarou.dono at gmail dot com 2012-02-10 08:21:40 
UTC ---
Oh, because simply doing:
namespace std
{
using ::stdout;
using ::stderr;
using ::stdin;
}
seemed to work fine for me on both linux and windows so I thought they wouldn't
be macros. I'm not too good at checking standards though :p