[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||krebbel at gcc dot gnu.org
 Resolution|FIXED   |

--- Comment #10 from Andreas Krebbel  2012-03-08 
07:56:14 UTC ---
(In reply to comment #8)
> Author: rguenth
> Date: Tue Mar  6 09:54:06 2012
> New Revision: 184981

This patch seems to have introduced the following testsuite fails on s390x:

=== gfortran tests ===


Running target unix
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link,
-O0 -flto -flto-partition=none  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o
execute -O0 -flto -flto-partition=none 
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link,
-O0 -flto -flto-partition=1to1  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o
execute -O0 -flto -flto-partition=1to1 
FAIL: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o link,
-O0 -flto  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586-2 f_lto_pr45586-2_0.o-f_lto_pr45586-2_0.o
execute -O0 -flto 
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0
-flto -flto-partition=none  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute
-O0 -flto -flto-partition=none 
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0
-flto -flto-partition=1to1  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute
-O0 -flto -flto-partition=1to1 
FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o link, -O0
-flto  (internal compiler error)
UNRESOLVED: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o-f_lto_pr45586_0.o execute
-O0 -flto

[Bug c++/52529] New: Compiler rejects template code inconsistently

[scovich at gmail dot com]

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

 Bug #: 52529
   Summary: Compiler rejects template code inconsistently
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: scov...@gmail.com


The following code does or does not compile (with varying errors) under
4.7.0-RC20120302 and 4.6.2 depending on the choice of FIRST..FOURTH; all four
variants compile under 4.5.3. 

I've narrowed down the test case as far as I could, but I don't really
understand what's going wrong. Does the code break some subtle lookup rule
which gcc recently became more strict about? There seem to be two issues,
because either A or foo() is enough to trigger an error; only A<1>::foo
compiles. 

=== bug.cpp ===
template  struct A {
template  long foo(typename T::X *x);
};

template  struct B {
typedef typename T::X X;
enum { M=1 };
static void bar(X *x);
};

struct C { struct X; };
int main() { B::bar(0); }

template  void B::bar(X *x) {
#if defined(FIRST)
A().foo(x);
#elif defined(SECOND)
A().foo(x);
#elif defined(THIRD)
A<1>().foo(x);
#elif defined(FOURTH)
A<1>().foo(x);
#endif
}
=== end bug.cpp ===


Sample error message from 4.7.0, since it has the clearest error messages
(4.6.2 gets confused by earlier errors when attempting to suggest a candidate):

 FIRST 
bug.cpp: In instantiation of ‘static void B::bar(B::X*) [with T = C;
B::X = C::X]’:
bug.cpp:12:20:   required from here
bug.cpp:16:5: error: no matching function for call to ‘A<1l>::foo(B::X*&)’
bug.cpp:16:5: note: candidate is:
bug.cpp:2:32: note: template long int A::foo(typename T::X*) [with T =
T; long int N = 1l]
bug.cpp:2:32: note:   template argument deduction/substitution failed:
bug.cpp:16:5: note:   couldn't deduce template parameter ‘T’

 SECOND 
bug.cpp: In static member function ‘static void B::bar(B::X*)’:
bug.cpp:18:17: error: expected primary-expression before ‘>’ token

 THIRD 
bug.cpp: In instantiation of ‘static void B::bar(B::X*) [with T = C;
B::X = C::X]’:
bug.cpp:12:20:   required from here
bug.cpp:20:5: error: no matching function for call to ‘A<1l>::foo(B::X*&)’
bug.cpp:20:5: note: candidate is:
bug.cpp:2:32: note: template long int A::foo(typename T::X*) [with T =
T; long int N = 1l]
bug.cpp:2:32: note:   template argument deduction/substitution failed:
bug.cpp:20:5: note:   couldn't deduce template parameter ‘T’

 FOURTH 
[successful compilation]

[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  2012-03-08 
07:19:51 UTC ---
(In reply to comment #14)
> Re-reading the standard, I think the non-BIND(C) version of TYPE(*) is
> currently mishandled. That should be only visible for "TYPE(*)" dummies which
> are INTENT(OUT) and where the actual argument is a derived type with default
> initialization or has allocatable components (possibly even with finalization
> subroutines).
> 
> See http://gcc.gnu.org/ml/fortran/2012-03/msg00037.html and
> http://j3-fortran.org/pipermail/j3/2012-March/005113.html

Some J3 members seem to agree that that's not a good idea. To add a link to a
thread in yet another mailing list:
  http://j3-fortran.org/pipermail/interop-tr/2012-March/001058.html

Thus, the current type(*) implementation seems to be okay.

[Bug rtl-optimization/52528] New: combine bug (powerpc testcase)

[cltang at gcc dot gnu.org]

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

 Bug #: 52528
   Summary: combine bug (powerpc testcase)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: clt...@gcc.gnu.org
Target: powerc-linux


The below testcase:
struct S {
  unsigned a : 30;
  unsigned b :  2;
};

int foo (int b)
{
  struct S s = {0};
  s.b = b;
  return bar (0x000b0010, 0x00040100ULL, *(unsigned long *)&s);
}

currently on trunk (target powerpc) compiles to:
foo:
lis 6,0x4
li 5,0
ori 6,6,256
li 7,0
crxor 6,6,6
b bar

Notice the incorrect code generated: no construction of the 1st arg (reg 3),
and
wrong code for the 3rd arg (reg 7)

I have diagnosed this as a problem in combine, and have a patch in testing.
Opening this issue for status tracking.

[Bug pch/52518] gcc fails to find pch files in subincludes

[casey at rodarmor dot com]

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

--- Comment #7 from casey at rodarmor dot com 2012-03-08 05:08:08 UTC ---
Not exactly what I was hoping for, but thanks for the speedy resolution :)

[Bug target/46942] x86_64 parameter passing unnecessary sign/zero extends

[meadori at gmail dot com]

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

Meador Inge  changed:

   What|Removed |Added

 CC||meadori at gmail dot com

--- Comment #9 from Meador Inge  2012-03-08 03:41:27 
UTC ---
What is the status of this issue?  Did the psABI ever get updated?  Is the
intent of this issue to modify GCC to remove the sign extension from the
callee?

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

--- Comment #23 from Oleg Endo  2012-03-08 
01:25:21 UTC ---
Created attachment 26853
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26853
Patch for the patch

The attached patch seems to fix the problem.
GCC (C,C++) and CSiBE set compiles with it.  Now doing the full testsuite...

Kaz, if you have some time, could you try it out in your setup, too please?

A thing that bugs me regarding the attached patch is the big/little endian
subreg copy pasta in the patterns *negnegt, *movtt, *movt_qi.  Isn't there a
way to avoid that?

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2012-03-08 
01:05:07 UTC ---
Author: redi
Date: Thu Mar  8 01:05:01 2012
New Revision: 185089

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185089
Log:
PR libstdc++/52433
* include/debug/safe_iterator.h (_Safe_iterator): Add debug checks
to move constructor and move assignment operator.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/safe_iterator.h

[Bug c++/52527] New: When using '-g', get an ICE: seg fault in add_name_attribute (called by modified_type_die)

[geir at cray dot com]

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

 Bug #: 52527
   Summary: When using '-g', get an ICE: seg fault in
add_name_attribute (called by modified_type_die)
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com


Compiling a program that uses the Boost libraries, I see an ICE when using '-g'
option.  Unfortunately (or fortunately) the problem does NOT occur when I
compile a preprocessed version of the code.

$ g++ --version
g++ (GCC) 4.6.2 20111026 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -dH -c -g -O3 -DNDEBUG -DCPU_FREQ=2.8e9 -DHAVE_U1 -DHAVE_TwoU1
-DDISABLE_MATRIX_ELEMENT_ITERATOR_WARNING -DUseTwoU1 -I. -I../../framework
-I../../../../boost_1_47_0 te_nn.cpp 
In file included from ../../framework/dmrg/mp_tensors/mps.hpp:14:0,
 from ../../framework/dmrg/mp_tensors/mps.h:94,
 from te_nn.cpp:28:
../../framework/dmrg/mp_tensors/contractions.h: In static member function
'static block_matrix
contraction::multiply_with_twosite(const block_matrix&,
const block_matrix&, const Index&, const
Index&, const Index&) [with Matrix =
maquis::types::dense_matrix >, SymmGroup = NU1<2>]':
../../framework/dmrg/mp_tensors/contractions.h:778:5: internal compiler error:
Segmentation fault
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$

   Here's the traceback:

(gdb) bt
#0  0x7f21a8ca3945 in raise () from /lib64/libc.so.6
#1  0x7f21a8ca4f21 in abort () from /lib64/libc.so.6
#2  0x0060cf95 in real_abort ()
at ../../xt-gcc-4.6.2/gcc/diagnostic.c:903
#3  diagnostic_action_after_output (context=0x1166d80, 
diagnostic=) at ../../xt-gcc-4.6.2/gcc/diagnostic.c:247
#4  0x0060d13f in diagnostic_report_diagnostic (context=0x1166d80, 
diagnostic=0x7fff3dff2480) at ../../xt-gcc-4.6.2/gcc/diagnostic.c:546
#5  0x0060e020 in internal_error (gmsgid=)
at ../../xt-gcc-4.6.2/gcc/diagnostic.c:839
#6  0x007bbbd0 in crash_signal (signo=11)
at ../../xt-gcc-4.6.2/gcc/toplev.c:359
#7  
#8  0x0062842e in add_name_attribute (die=0x7f218b75d8c0, 
name_string=0x13 )
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:17435
#9  0x006356c8 in modified_type_die (type=0x7f21a62a32a0, 
is_const_type=0, is_volatile_type=, 
context_die=0x7f21a8b97000) at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:13057
#10 0x00636070 in force_type_die (type=0x7f21a62a32a0)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20949
#11 0x00630541 in dwarf2out_imported_module_or_decl_1 (
---Type  to continue, or q  to quit---
decl=0x7f21a633b450, name=0x0, lexical_block=0x7f2195a60f78, 
lexical_block_die=0x7f218b75d870)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21307
#12 0x00630a98 in decls_for_scope (stmt=0x7f2195a60f78, 
context_die=0x7f218b75d870, depth=1)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20788
#13 0x0063b6eb in gen_lexical_block_die (depth=1, 
context_die=, stmt=0x7f2195a60f78)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:19886
#14 gen_block_die (stmt=0x7f2195a60f78, context_die=, depth=1)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20738
#15 0x00630af6 in decls_for_scope (stmt=0x7f2195a9d000, 
context_die=0x7f218b75d500, depth=0)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:20802
#16 0x00630d91 in gen_subprogram_die (decl=0x7f2197110e00, 
context_die=) at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:19494
#17 0x006335d8 in gen_decl_die (decl=0x7f2197110e00, 
origin=0x7f219a55f3f0, context_die=0x7f21a8b97000)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21152
#18 0x0063c239 in dwarf2out_function_decl (decl=)
at ../../xt-gcc-4.6.2/gcc/dwarf2out.c:21534
#19 0x0067150d in rest_of_handle_final ()
---Type  to continue, or q  to quit---
at ../../xt-gcc-4.6.2/gcc/final.c:4301
#20 0x0072c669 in execute_one_pass (pass=0x115c560)
at ../../xt-gcc-4.6.2/gcc/passes.c:1556
#21 0x0072c915 in execute_pass_list (pass=0x115c560)
at ../../xt-gcc-4.6.2/gcc/passes.c:1611
#22 0x0072c927 in execute_pass_list (pass=0x115ce40)
at ../../xt-gcc-4.6.2/gcc/passes.c:1612
#23 0x0072c927 in execute_pass_list (pass=0x115cea0)
at ../../xt-gcc-4.6.2/gcc/passes.c:1612
#24 0x007f9681 in tree_rest_of_compilation (fndecl=0x7f2197110e00)
at ../../xt-gcc-4.6.2/gcc/tree-optimize.c:422
#25 0x0093ab0f in cgraph_expand_function (node=0x7f2195a5cc60)
at ../../xt-gcc-4.6.2/gcc/cgraphunit.c:1576
#26 0x

[Bug tree-optimization/52523] Missing "uninitialized" warning in simple code

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-08
 CC||manu at gcc dot gnu.org
 Blocks||24639
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2012-03-08 
00:05:22 UTC ---
The SSA dump is a bit obscure to me:

int main() ()
{
  int x;
  int D.21721;
  int x.0;

:
  [pr52523.cc : 5:17] x.0_1 = x;
  [pr52523.cc : 5:17] std::basic_ostream::operator<< ([pr52523.cc : 5]
&cout, x.0_1);

:
  [pr52523.cc : 6:16] std::basic_istream::operator>> ([pr52523.cc : 6]
&cin, &x);

:
  x ={v} {CLOBBER};
  [pr52523.cc : 7:1] D.21721_2 = 0;

:
  [pr52523.cc : 7:1] return D.21721_2;

:
  x ={v} {CLOBBER};
  resx 1

}

but I guess that 'std::cin >> x' creates a VOP, and the warning machinery does
not work well with VOPs. See PR19430.

[Bug libitm/52526] New: libitm: stuck in futex_wait

[patrick.marlier at gmail dot com]

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

 Bug #: 52526
   Summary: libitm: stuck in futex_wait
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: torv...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu


libitm (default configuration/4.8.0 20120307) is stuck in futex_wait with STAMP
kmeans with low contention and 8 threads.

(gdb) info threads 
  Id   Target Id Frame 
  8Thread 0x7322b700 (LWP 24011) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
  7Thread 0x73a2c700 (LWP 24010) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
  6Thread 0x7422d700 (LWP 24009) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
  5Thread 0x74a2e700 (LWP 24008) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
* 4Thread 0x7522f700 (LWP 24007) "kmeans" GTM::futex_wait
(addr=0x77fdfbb8, val=1)
at ../../../gcc-trunk/libitm/config/linux/futex.cc:49
  3Thread 0x75a30700 (LWP 24006) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
  2Thread 0x76231700 (LWP 24005) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
  1Thread 0x773aa720 (LWP 24002) "kmeans" 0x003ecb40c14c in
pthread_barrier_wait () from /lib64/libpthread.so.0
(gdb) thread 5
[Switching to thread 5 (Thread 0x74a2e700 (LWP 24008))]
#0  0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0
(gdb) bt
#0  0x003ecb40c14c in pthread_barrier_wait () from /lib64/libpthread.so.0
#1  0x00403099 in threadWait ()
#2  0x003ecb407b41 in start_thread () from /lib64/libpthread.so.0
#3  0x003eca8df49d in clone () from /lib64/libc.so.6
(gdb) thread 4
[Switching to thread 4 (Thread 0x7522f700 (LWP 24007))]
#0  GTM::futex_wait (addr=0x77fdfbb8, val=1) at
../../../gcc-trunk/libitm/config/linux/futex.cc:49
49if (__builtin_expect (res == -ENOSYS, 0))
(gdb) bt
#0  GTM::futex_wait (addr=0x77fdfbb8, val=1) at
../../../gcc-trunk/libitm/config/linux/futex.cc:49
#1  0x775cd1a4 in GTM::gtm_rwlock::read_lock (this=0x77fdfbb0,
tx=0x7fffd40008c0)
at ../../../gcc-trunk/libitm/config/linux/rwlock.cc:76
#2  0x775ccbfa in GTM::gtm_thread::decide_begin_dispatch
(this=0x7fffd40008c0, prop=)
at ../../../gcc-trunk/libitm/retry.cc:182
#3  0x775cc16b in GTM_begin_transaction (prop=41, jb=0x7522edb0) at
../../../gcc-trunk/libitm/beginend.cc:235
#4  0x775cd853 in _ITM_beginTransaction () at
../../../gcc-trunk/libitm/config/x86/sjlj.S:74
#5  0x004021ab in work ()
#6  0x0040308d in threadWait ()
#7  0x003ecb407b41 in start_thread () from /lib64/libpthread.so.0
#8  0x003eca8df49d in clone () from /lib64/libc.so.6

[Bug rtl-optimization/52524] Segfault compiling libgcov.c

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from vries at gcc dot gnu.org 2012-03-07 22:11:15 UTC ---
> I think this has already been fixed.

Yep, in r185028.

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

[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c, x86_64-unknown-linux-gnu in bid_binarydecimal.c

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #7 from vries at gcc dot gnu.org 2012-03-07 22:11:15 UTC ---
*** Bug 52524 has been marked as a duplicate of this bug. ***

[Bug target/52503] sh-wrs-vxworks: too many target masks

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  2012-03-07 
22:06:28 UTC ---
Author: kkojima
Date: Wed Mar  7 22:06:25 2012
New Revision: 185081

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185081
Log:
PR target/52503
* config/sh/sh.opt (msoft-atomic): Use Var instead of Mask.
* config/sh/linux.h (TARGET_DEFAULT): Remove MASK_SOFT_ATOMIC.
(SUBTARGET_OVERRIDE_OPTIONS): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/linux.h
trunk/gcc/config/sh/sh.opt

[Bug middle-end/52525] compiler segmentation fault when building OpenMP code with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
  Known to work||4.5.5, 4.6.0
   Severity|major   |normal

[Bug c/52525] compiler segmentation fault when building OpenMP code with -O3

[sin.pecado at gmail dot com]

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

--- Comment #1 from Szilárd Páll  2012-03-07 
21:36:17 UTC ---
Created attachment 26852
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26852
preprocessed source file for reproducing bug

[Bug c/52525] New: compiler segmentation fault when building OpenMP code with -O3

[sin.pecado at gmail dot com]

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

 Bug #: 52525
   Summary: compiler segmentation fault when building OpenMP code
with -O3
Classification: Unclassified
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sin.pec...@gmail.com


An -O3 optimization seems to make gcc 4.4.x choke with a segfault while
compiling some OpenMP code. The same code compiles with -O2. Strangely enough,
it also compiles with -O2 + the additional -O3 flags listed in the 4.4.6 docs
(-finline-functions, -funswitch-loops, -fpredictive-commoning,
-fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone).

The bug is not present neither in 4.3 nor 4.5, 4.6.

Marked with major severity as this code will be part of the next version of
GROMACS, the OSS HPC molecular simulation package shipped by several distros
and running on lots of machines from desktops to the largest clusters.


Tested with: 
Ubuntu 10.04 x86_64, gcc-4.4 (Ubuntu 4.4.6-3lucid2) 4.4.6
Ubuntu 11.10 x86_64, gcc-4.4 (Ubuntu/Linaro 4.4.6-11ubuntu2) 4.4.6
RHEL 6.0 x86_64, gcc (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13)

Attached is the input that reproduces the segfault by running:

$ gcc-4.4 -fopenmp -O3 force.i 
/home/pszilard/projects/gmx/gromacs-gpu/src/mdlib/force.c: In function
‘do_force_lowlevel.omp_fn.0’:
/home/pszilard/projects/gmx/gromacs-gpu/src/mdlib/force.c:448: internal
compiler error: Segmentation fault

[Bug rtl-optimization/52524] Segfault compiling libgcov.c

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-03-07 
20:35:46 UTC ---
I think this has already been fixed.

[Bug c++/52510] [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-03-07 20:34:57 UTC ---
A reghunt revealed that this patch (r184876) is indeed the culprit:

2012-03-03  Jason Merrill  

   Core 1270
   * call.c (build_aggr_conv): Call reshape_init.
   (convert_like_real): Likewise.
   * typeck2.c (process_init_constructor): Clear TREE_CONSTANT if
   not all constant.

Jason, could you please have a look?

Thanks.
Rainer

[Bug rtl-optimization/52524] New: Segfault compiling libgcov.c

[vries at gcc dot gnu.org]

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

 Bug #: 52524
   Summary: Segfault compiling libgcov.c
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vr...@gcc.gnu.org


with revision r185025, I ran into this build breaker:
...
/home/vries/gcc_versions/devel/lean/build/./gcc/xgcc
-B/home/vries/gcc_versions/devel/lean/build/./gcc/
-B/home/vries/gcc_versions/devel/lean/install/x86_64-unknown-linux-gnu/bin/
-B/home/vries/gcc_versions/devel/lean/install/x86_64-unknown-linux-gnu/lib/
-isystem
/home/vries/gcc_versions/devel/lean/install/x86_64-unknown-linux-gnu/include
-isystem
/home/vries/gcc_versions/devel/lean/install/x86_64-unknown-linux-gnu/sys-include
   -g -O2 -m32 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-fpic -I. -I. -I../../.././gcc -I/home/vries/gcc_versions/devel/src/libgcc
-I/home/vries/gcc_versions/devel/src/libgcc/.
-I/home/vries/gcc_versions/devel/src/libgcc/../gcc
-I/home/vries/gcc_versions/devel/src/libgcc/../include
-I/home/vries/gcc_versions/devel/src/libgcc/config/libbid
-DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS  -DUSE_TLS -o _gcov.o -MT _gcov.o -MD
-MP -MF _gcov.dep -DL_gcov -c
/home/vries/gcc_versions/devel/src/libgcc/libgcov.c
/home/vries/gcc_versions/devel/src/libgcc/libgcov.c: In function
‘free_fn_data’:
/home/vries/gcc_versions/devel/src/libgcc/libgcov.c:158:1: internal compiler
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
...

backtrace:
...
Program received signal SIGSEGV, Segmentation fault.
0x00c2a3a8 in for_each_rtx_1 (exp=0x755270b8, n=0, f=0xa701a6
, data=0x0) at
/home/vries/gcc_versions/devel/src/gcc/rtlanal.c:2837
2837  for (; format[n] != '\0'; n++)
(gdb) bt
#0  0x00c2a3a8 in for_each_rtx_1 (exp=0x755270b8, n=0, f=0xa701a6
, data=0x0) at
/home/vries/gcc_versions/devel/src/gcc/rtlanal.c:2837
#1  0x00c29fce in for_each_rtx_1 (exp=0x75360ba0, n=0, f=0xa701a6
, data=0x0) at
/home/vries/gcc_versions/devel/src/gcc/rtlanal.c:2859
#2  0x00c2a45b in for_each_rtx (x=0x757021b8, f=0xa701a6
, data=0x0) at
/home/vries/gcc_versions/devel/src/gcc/rtlanal.c:2940
#3  0x00a7034a in returnjump_p (insn=0x75702190) at
/home/vries/gcc_versions/devel/src/gcc/jump.c:935
#4  0x0069efc9 in patch_jump_insn (insn=0x75702190,
old_label=0x753c7870, new_bb=0x75411820) at
/home/vries/gcc_versions/devel/src/gcc/cfgrtl.c:1036
#5  0x0069f231 in redirect_branch_edge (e=0x75227880,
target=0x75411820) at /home/vries/gcc_versions/devel/src/gcc/cfgrtl.c:1083
#6  0x0069f510 in rtl_redirect_edge_and_branch (e=0x75227880,
target=0x75411820) at /home/vries/gcc_versions/devel/src/gcc/cfgrtl.c:1125
#7  0x0067f506 in redirect_edge_and_branch (e=0x75227880,
dest=0x75411820) at /home/vries/gcc_versions/devel/src/gcc/cfghooks.c:323
#8  0x006a0f46 in rtl_split_edge (edge_in=0x75227880) at
/home/vries/gcc_versions/devel/src/gcc/cfgrtl.c:1483
#9  0x0067fc9f in split_edge (e=0x75227880) at
/home/vries/gcc_versions/devel/src/gcc/cfghooks.c:551
#10 0x006a1665 in commit_one_edge_insertion (e=0x75227880) at
/home/vries/gcc_versions/devel/src/gcc/cfgrtl.c:1590
#11 0x0067dd21 in gimple_expand_cfg () at
/home/vries/gcc_versions/devel/src/gcc/cfgexpand.c:4576
#12 0x00b08863 in execute_one_pass (pass=0x25f5240) at
/home/vries/gcc_versions/devel/src/gcc/passes.c:2084
#13 0x00b08a51 in execute_pass_list (pass=0x25f5240) at
/home/vries/gcc_versions/devel/src/gcc/passes.c:2139
#14 0x00dc2282 in tree_rest_of_compilation (fndecl=0x751a1a00) at
/home/vries/gcc_versions/devel/src/gcc/tree-optimize.c:422
#15 0x006c15d5 in cgraph_expand_function (node=0x751a2ea0) at
/home/vries/gcc_versions/devel/src/gcc/cgraphunit.c:1837
#16 0x006c17a0 in cgraph_expand_all_functions () at
/home/vries/gcc_versions/devel/src/gcc/cgraphunit.c:1904
#17 0x006c22e6 in cgraph_optimize () at
/home/vries/gcc_versions/devel/src/gcc/cgraphunit.c:2218
#18 0x006bf322 in cgraph_finalize_compilation_unit () at
/home/vries/gcc_versions/devel/src/gcc/cgraphunit.c:1344
#19 0x004be2d4 in c_write_global_declarations () at
/home/vries/gcc_versions/devel/src/gcc/c-decl.c:10032
#20 0x00d0efeb in compile_file () at
/home/vries/gcc_versions/devel/src/gcc/toplev.c:573
#21 0x00d112b3 in do_compile () at
/home/vries/gcc_versions/devel/src/gcc/toplev.c:1937
#22 0x00d1142a in toplev_main (argc=78, argv=0x7fffd618) 

[Bug tree-optimization/52523] New: Missing "uninitialized" warning in simple code

[andreac at unstable dot it]

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

 Bug #: 52523
   Summary: Missing "uninitialized" warning in simple code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andr...@unstable.it


Compiling this code:

#include 
int main()
{
  int x;
  std::cout << x;
  std::cin >> x;
}

with g++ -Wall uninitialized.cc
give no warning.

But compiling this code:

#include 
int main()
{
  int x;
  std::cout << x;
}

with g++ -Wall uninitialized.cc
gives:
uninitialized.cc: In function ‘int main()’:
uninitialized.cc:6:17: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized

Tested also on version 4.6.1 and 4.6.2

[Bug c++/52521] [C++11] user defined literals and order of declaration

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2012-03-07 
20:20:09 UTC ---
Author: jason
Date: Wed Mar  7 20:20:00 2012
New Revision: 185079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185079
Log:
PR c++/52521
* mangle.c (write_literal_operator_name): The length comes after the
operator prefix.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-mangle.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/52521] [C++11] user defined literals and order of declaration

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2012-03-07 
20:16:48 UTC ---
Author: jason
Date: Wed Mar  7 20:16:16 2012
New Revision: 185077

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185077
Log:
PR c++/52521
* mangle.c (write_literal_operator_name): The length comes after the
operator prefix.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/udlit-mangle.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/mangle.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/52521] [C++11] user defined literals and order of declaration

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/52522] Overloaded functions called with initializer lists considered ambiguous

[dgsteffen at numerica dot us]

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

--- Comment #4 from Dave Steffen  2012-03-07 
19:06:56 UTC ---
(In reply to comment #2)
> The cause for this problem is the currently unconstrained constructor
> 
> template
> vector(InputIter, InputIter);
> 
> but I need to investigate whether this is a language or compiler problem. In
> this case the problem should be fixed, once this constructor becomes
> constrained (There is work on this in progress, but I have not the bug id 
> right
> at my hands).

Ahhh gotcha.  Thanks.  Either way (language or compiler problem) I know how
to fix our code.  Looks like an explicit qualification, e.g.

vector{a,b}

makes things happy.


Thanks very much for the fast response time -- you guys are great.

[Bug c++/52522] Overloaded functions called with initializer lists considered ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jonathan Wakely  2012-03-07 
18:44:07 UTC ---
PR 43813

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

[Bug libstdc++/43813] [DR1234] vector(3, NULL) fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dgsteffen at numerica dot
   ||us

--- Comment #20 from Jonathan Wakely  2012-03-07 
18:44:07 UTC ---
*** Bug 52522 has been marked as a duplicate of this bug. ***

[Bug c++/52522] Overloaded functions called with initializer lists considered ambiguous

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #2 from Daniel Krügler  
2012-03-07 18:41:21 UTC ---
The cause for this problem is the currently unconstrained constructor

template
vector(InputIter, InputIter);

but I need to investigate whether this is a language or compiler problem. In
this case the problem should be fixed, once this constructor becomes
constrained (There is work on this in progress, but I have not the bug id right
at my hands).

[Bug c++/52522] Overloaded functions called with initializer lists considered ambiguous

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-03-07 
18:32:56 UTC ---
Clang gives a very similar result, so I'm not convinced it's a bug:

t.cc:12:2: error: call to 'horizontalConcat' is ambiguous
 horizontalConcat({a,b});
 ^~~~
t.cc:6:8: note: candidate function
Matrix horizontalConcat(const std::vector& vectors);
   ^
t.cc:7:8: note: candidate function
Matrix horizontalConcat(const std::vector& matrices);
   ^

[Bug c++/52510] [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2012-03-07 17:49:20 UTC 
---
Nothing Solaris-specific here, fails in the same way on
x86_64-unknown-linux-gnu
as of r185060.

  Rainer

[Bug c++/52522] New: Overloaded functions called with initializer lists considered ambiguous

[dgsteffen at numerica dot us]

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

 Bug #: 52522
   Summary: Overloaded functions called with initializer lists
considered ambiguous
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dgstef...@numerica.us


Consider:

#include 
using std::vector;
class Matrix{};
class Vector{};

Matrix horizontalConcat(const std::vector& vectors);
Matrix horizontalConcat(const std::vector& matrices);

int main()
{
 Matrix a,b;
 horizontalConcat({a,b});
}

GCC 4.4 and 4.5 in C++0X mode (E.G., g++ testA.cpp -c -ansi -std=c++0x ) accept
this code and do the right thing.  However, 4.6.3 produces:

/usr/local/compilers/4.6/bin/g++ testA.cpp -c -ansi -std=c++0x 

estA.cpp: In function ‘int main()’:
testA.cpp:25:24: error: call of overloaded ‘horizontalConcat()’ is ambiguous
testA.cpp:25:24: note: candidates are:
testA.cpp:12:8: note: Matrix horizontalConcat(const std::vector&)
testA.cpp:13:8: note: Matrix horizontalConcat(const std::vector&)

However, sending an initializer list containing 3 or more Matrices works fine. 
Also, removing the vector overloaded function removes the warning.

In principle there could be some ambiguity, when using an initializer list of
two elements, between calling vector's initializer list ctor or calling one of
its other ctors, but here I don't see that either, since vector doesn't
have a ctor that takes two matrices.

At any rate, either GCC 4.6 is incorrectly concluding that the function call is
ambiguous, or it's producing a very confusing error message.

Thanks very much.

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[Bernhard.Rosenkranzer at linaro dot org]

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

Bernhard Rosenkränzer  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #6 from Bernhard Rosenkränzer  2012-03-07 16:57:55 UTC ---
Confirmed fixed in current trunk

[Bug middle-end/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  2012-03-07 
16:09:12 UTC ---
(In reply to comment #5)
> Can't reproduce this though.

Strange. I still see the ICE with current trunk. It's a 32 bit build and host;
might this have an impact?

[Bug c++/52521] [C++11] user defined literals and order of declaration

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-07
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-03-07 
14:58:21 UTC ---
The only mail I found about the mangling was
http://communities.mentor.com/community/cs/archives/cxx-abi-dev/msg02351.html
but the ABI document at least on the web hasn't been updated.
If li is the operator name, then I'd think instead of
_Z4li_wPKc
we should mangle it as
_Zli2_wPKc
- i.e. "li" followed by  pair would be  (and have
support for this in the demangler).
Jason, can this be resolved on cxx-abi-dev and for 4.7.0-RC2?  Sounds like a
blocker to me for 4.7.0, releasing udlit support which is mangled incorrectly
would be very bad, especially when it clashes with user function.s

[Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member

[scovich at gmail dot com]

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

--- Comment #8 from Ryan Johnson  2012-03-07 14:28:29 
UTC ---
(In reply to comment #7)
> On Wed, 7 Mar 2012, scovich at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > 
> > --- Comment #6 from Ryan Johnson  2012-03-07 
> > 13:31:19 UTC ---
> > (In reply to comment #5)
> > > On Wed, 12 Oct 2011, scovich at gmail dot com wrote:
> > > 
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > > > 
> > > > --- Comment #4 from Ryan Johnson  2011-10-12 
> > > > 12:40:25 UTC ---
> > > > (In reply to comment #3)
> > > > > Well, it's a tree optimization issue.  It's simple - the local 
> > > > > aggregate f
> > > > > escapes the function via the member function call to baz:
> > > > > 
> > > > > :
> > > > >   foo::baz (&f);
> > > > > 
> > > > > and as our points-to analysis is not flow-sensitive for memory/calls 
> > > > > this
> > > > > causes f to be clobbered by the call to bar
> > > > 
> > > > Is flow-sensitive analysis within single functions prohibitively 
> > > > expensive? All
> > > > the papers I can find talk about whole-program analysis, where it's very
> > > > expensive in both time and space; the best I could find (CGO'11 best 
> > > > paper)
> > > > gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. 
> > > 
> > > It would need a complete rewrite, it isn't integratable into the current
> > > solver (which happens to be shared between IPA and non-IPA modes).
> > That makes sense...
> > 
> > Wild idea: would it be possible to annotate references as "escaped" or "not
> > escaped yet" ? Anything global or passed into the function would be marked 
> > as
> > escaped, while anything allocated locally would start out as not escaped;
> > assigning to an escaped location or passing to a function would mark it as
> > escaped if it wasn't already. The status could be determined in linear time
> > using local information only (= scalable), and would benefit strongly as
> > inlining (IPA or not) eliminates escape points.
> 
> Well, you can compute the clobber/use sets of individual function calls,
> IPA PTA computes a simple mod-ref analysis this way.  You can also
> annotate functions whether they make arguments escape or whether it
> reads from them or clobbers them.
> 
> The plan is to do some simple analysis and propagate that up the
> callgraph, similar to pure-const analysis.  The escape part could
> be integrated there.

That sounds really slick to have in general... but would it actually catch the
test case above? What you describe seems to depend on test() having information
about foo::baz() -- which it does not -- while analyzing the body of test()
could at least identify the part of f's lifetime where it cannot possibly have
escaped.

Or does the local analysis come "for free" once those IPA changes are in place?

[Bug c++/52521] New: [C++11] user defined literals and order of declaration

[marc.glisse at normalesup dot org]

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

 Bug #: 52521
   Summary: [C++11] user defined literals and order of declaration
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


#include 
int operator "" _w(const char*);
int operator "" _w(const char*, std::size_t);
int main() {
  123_w;
}

a.cc: In function 'int main()':
a.cc:5:3: error: unable to find numeric literal operator 'operator"" _w'

The problem disappears if I switch the 2 declarations...

Btw, mangling these operators like functions called li_w taking the same
arguments is strange, I could have such a function in my code.

[Bug target/52484] [avr]: Missing __memx insn because of wrong register footprint

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2012-03-07 
13:52:37 UTC ---
Author: gjl
Date: Wed Mar  7 13:52:30 2012
New Revision: 185043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185043
Log:
PR target/52484
* config/avr/avr.md (xload_A): Add R22... to register footprint.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md

[Bug target/52484] [avr]: Missing __memx insn because of wrong register footprint

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-07
  Component|rtl-optimization|target
 AssignedTo|unassigned at gcc dot   |gjl at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.1
Summary|Wrong code from ce3 pass|[avr]: Missing __memx insn
   |(deletes insn)  |because of wrong register
   ||footprint
 Ever Confirmed|0   |1

--- Comment #4 from Georg-Johann Lay  2012-03-07 
13:46:47 UTC ---
ce3 is correct in deleting the insn.

The bug is that "xload_A" insn needs a clobber of r22 to represent the
register footprint of the libcall generated in split1.

[Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  
2012-03-07 13:39:19 UTC ---
On Wed, 7 Mar 2012, scovich at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> 
> --- Comment #6 from Ryan Johnson  2012-03-07 
> 13:31:19 UTC ---
> (In reply to comment #5)
> > On Wed, 12 Oct 2011, scovich at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > > 
> > > --- Comment #4 from Ryan Johnson  2011-10-12 
> > > 12:40:25 UTC ---
> > > (In reply to comment #3)
> > > > Well, it's a tree optimization issue.  It's simple - the local 
> > > > aggregate f
> > > > escapes the function via the member function call to baz:
> > > > 
> > > > :
> > > >   foo::baz (&f);
> > > > 
> > > > and as our points-to analysis is not flow-sensitive for memory/calls 
> > > > this
> > > > causes f to be clobbered by the call to bar
> > > 
> > > Is flow-sensitive analysis within single functions prohibitively 
> > > expensive? All
> > > the papers I can find talk about whole-program analysis, where it's very
> > > expensive in both time and space; the best I could find (CGO'11 best 
> > > paper)
> > > gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. 
> > 
> > It would need a complete rewrite, it isn't integratable into the current
> > solver (which happens to be shared between IPA and non-IPA modes).
> That makes sense...
> 
> Wild idea: would it be possible to annotate references as "escaped" or "not
> escaped yet" ? Anything global or passed into the function would be marked as
> escaped, while anything allocated locally would start out as not escaped;
> assigning to an escaped location or passing to a function would mark it as
> escaped if it wasn't already. The status could be determined in linear time
> using local information only (= scalable), and would benefit strongly as
> inlining (IPA or not) eliminates escape points.

Well, you can compute the clobber/use sets of individual function calls,
IPA PTA computes a simple mod-ref analysis this way.  You can also
annotate functions whether they make arguments escape or whether it
reads from them or clobbers them.

The plan is to do some simple analysis and propagate that up the
callgraph, similar to pure-const analysis.  The escape part could
be integrated there.

Richard.

[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX

--- Comment #3 from Dave Korn  2012-03-07 13:36:52 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > 4.6 should be broken as well for you?
> Oops. I reported wrong in my OP. I've actually been using a home-built 4.6.2
> for some time now... and it is the host compiler for this build:

  I had no problems building the RC using:

binutils 2.22.51-1
cygwin   1.7.9-1
gcc4 4.5.3-3
gmp  4.3.2-1
make 3.82.90-1
mpfr 3.0.1-1


> > Can you check why configure thinks spawnve is available in process.h
> > (contrary to the warning we see in your snippet)?
> Sorry, I may not have been clear on this. Google reported that spawnve lives 
> in
> process.h. A quick search on my filesystem shows that spawnve actually lives 
> in
> , not  as expected by pex-unix.c.

> Perhaps the file moved recently (since 1.7.9 or 10)? I've sent mail to the
> cygwin list to see if anybody there knows. Meanwhile, soft-linking process.h 
> to
> where gcc expects it lets the compile continue. 

  Right, I think this is a cygwin bug.  The /usr/include/cygwin dir is private,
you're not supposed to #include files from there directly, they should be
indirectly included from within other system header files.  If process.h is a
public header, it shouldn't have been moved there.

  Ah.  In fact, I see from the reply to your email there that it is indeed an
acknowledged error in 1.7.10 and fixed already in 1.7.11.  Since the .10
release was buggy in several other important ways, I don't think it's important
to support it, we'll just tell people they need to upgrade.  Closing as
WONTFIX.

[Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member

[scovich at gmail dot com]

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

--- Comment #6 from Ryan Johnson  2012-03-07 13:31:19 
UTC ---
(In reply to comment #5)
> On Wed, 12 Oct 2011, scovich at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > 
> > --- Comment #4 from Ryan Johnson  2011-10-12 
> > 12:40:25 UTC ---
> > (In reply to comment #3)
> > > Well, it's a tree optimization issue.  It's simple - the local aggregate f
> > > escapes the function via the member function call to baz:
> > > 
> > > :
> > >   foo::baz (&f);
> > > 
> > > and as our points-to analysis is not flow-sensitive for memory/calls this
> > > causes f to be clobbered by the call to bar
> > 
> > Is flow-sensitive analysis within single functions prohibitively expensive? 
> > All
> > the papers I can find talk about whole-program analysis, where it's very
> > expensive in both time and space; the best I could find (CGO'11 best paper)
> > gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. 
> 
> It would need a complete rewrite, it isn't integratable into the current
> solver (which happens to be shared between IPA and non-IPA modes).
That makes sense...

Wild idea: would it be possible to annotate references as "escaped" or "not
escaped yet" ? Anything global or passed into the function would be marked as
escaped, while anything allocated locally would start out as not escaped;
assigning to an escaped location or passing to a function would mark it as
escaped if it wasn't already. The status could be determined in linear time
using local information only (= scalable), and would benefit strongly as
inlining (IPA or not) eliminates escape points.

Alternatively (or maybe it's really the same thing?), I could imagine an SSA
"operation" which "moves" the non-escaped variable into an escaped one (which
happens to live at the same address) just before it escapes? That might give
the same effect with no changes to the current flow-insensitive algorithm, as
long as the optimizer knew how to adjust things to account for inlining.

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[steven at gcc dot gnu.org]

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

--- Comment #5 from Steven Bosscher  2012-03-07 
13:07:24 UTC ---
May be fixed by r185028. Please update and try again.

[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin

[scovich at gmail dot com]

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

--- Comment #2 from Ryan Johnson  2012-03-07 13:02:50 
UTC ---
(In reply to comment #1)
> 4.6 should be broken as well for you?
Oops. I reported wrong in my OP. I've actually been using a home-built 4.6.2
for some time now... and it is the host compiler for this build:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/Ryan/apps/gcc-4.6.2/libexec/gcc/i686-pc-cygwin/4.6.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ../gcc-4.6.2-src/configure --prefix=/home/Ryan/apps/gcc-4.6.2
Thread model: single
gcc version 4.6.2 (GCC)


> 
> Can you check why configure thinks spawnve is available in process.h
> (contrary to the warning we see in your snippet)?
Sorry, I may not have been clear on this. Google reported that spawnve lives in
process.h. A quick search on my filesystem shows that spawnve actually lives in
, not  as expected by pex-unix.c. Configure
probably only tested linker status for the function and therefore wouldn't have
noticed. 

Perhaps the file moved recently (since 1.7.9 or 10)? I've sent mail to the
cygwin list to see if anybody there knows. Meanwhile, soft-linking process.h to
where gcc expects it lets the compile continue. I'll report back if any further
issues arise.

> What Windows version are you using?
W7-x64

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-07
 Ever Confirmed|0   |1

--- Comment #8 from Georg-Johann Lay  2012-03-07 
12:35:17 UTC ---
(In reply to comment #7)
> nice!
> i willl build it and publish it on avrfreaks soon, so Markus can try it out

Stefan, please noteice other PRs that won't get into 4.7.0 and fix problems
with new features: PR52496, PR52505,  PR52506,  PR52507,  PR52508.

Backporting to 4.7 will happen if 4.7-branch is open for bugfixing which will
be in about 3 weeks after 4.7.0 release.

[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2012-03-07 
12:31:13 UTC ---
Fixed.

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[Bernhard.Rosenkranzer at linaro dot org]

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

--- Comment #4 from Bernhard Rosenkränzer  2012-03-07 12:27:06 UTC ---
This is rev. 185024

Configured with:
/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/../build/../gcc/gcc-4.8/configure
--prefix=/tmp/android-toolchain-eabi --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--with-gmp=/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/temp-install
--with-mpfr=/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/temp-install
--with-mpc=/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/temp-install
--with-cloog=/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/temp-install
--with-ppl=/home/bero/repos/linaro-android/toolchain-trunk-test/objdir/temp-install
--disable-libssp --disable-nls --disable-libmudflap --disable-shared
--disable-sjlj-exceptions --disable-libquadmath --disable-libitm
--with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-target-optspace
--prefix=/tmp/android-toolchain-eabi --disable-docs --disable-nls
--target=arm-linux-androideabi --enable-threads --enable-tls --disable-libgomp
--disable-libstdc__-v3 --disable-libitm
Thread model: posix
gcc version 4.8.0 20120307 (experimental) (GCC) 

gmp 5.0.4
mpfr 3.1.0
mpc 0.9

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[Bernhard.Rosenkranzer at linaro dot org]

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

--- Comment #3 from Bernhard Rosenkränzer  2012-03-07 12:23:54 UTC ---
Created attachment 26851
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26851
slightly reduced test case

I'm familiar with delta, but it's not very useful in this particular case.
The attached file is the result of running multidelta and doing some manual
work (e.g. eliminating useless typedefs).

[Bug fortran/52512] Cannot match namelist object name

[marco at hulten dot org]

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

--- Comment #3 from Marco van Hulten  2012-03-07 
12:15:36 UTC ---
This work-around of changing all entries to tracer(N:N) indeed works, in both
the test case as for my original code where I found the problem.  That is the
NEMO 3.1 ocean model, with namelist_top containing 26 tracer entries of a
larger structure, but similar to the test case.

[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

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

  Known to work||4.8.0

--- Comment #10 from Andrey Belevantsev  2012-03-07 
12:02:28 UTC ---
Fixed on trunk, will be ported for 4.7.1.

[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

[abel at gcc dot gnu.org]

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

--- Comment #9 from Andrey Belevantsev  2012-03-07 
12:00:42 UTC ---
Author: abel
Date: Wed Mar  7 12:00:37 2012
New Revision: 185036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185036
Log:
PR rtl-optimization/52203
* sel-sched.c (estimate_insn_cost): New parameter pempty.  Adjust
all callers to pass NULL except ...
(reset_sched_cycles_in_current_ebb): ... here, save the value
in new variable 'empty'.  Increase issue_rate only for
non-empty insns.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched.c

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Steven Bosscher  2012-03-07 
11:57:23 UTC ---
Works for me at trunk r185035, configure options:
../trunk/configure --with-mpfr=/opt/cfarm/mpfr-2.3.1
--with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpc=/opt/cfarm/mpc-0.8
--enable-languages=c --disable-libmudflap --disable-libssp --disable-libitm
--disable-lto --target=arm-linux-androideabi

Can you please show your configuration and the trunk revision you are using?

[Bug middle-end/52520] trunk: internal compiler error: in predict_insn, at predict.c:477

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-07
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Steven Bosscher  2012-03-07 
11:41:58 UTC ---
I'll have a look...
Reduced test case much appreciated (you know about the "delta" tool?).

[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names

[corsepiu at gcc dot gnu.org]

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

--- Comment #7 from Ralf Corsepius  2012-03-07 
11:39:29 UTC ---
Author: corsepiu
Date: Wed Mar  7 11:39:25 2012
New Revision: 185035

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185035
Log:
2012-03-05  Ralf Corsépius  

PR target/51417
* Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext),
gcc-nm$(exeext), gcc-ranlib$(exeext).
Don't double canonicalize if cross-compiling.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

[Bug middle-end/52520] New: trunk: internal compiler error: in predict_insn, at predict.c:477

[Bernhard.Rosenkranzer at linaro dot org]

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

 Bug #: 52520
   Summary: trunk: internal compiler error: in predict_insn, at
predict.c:477
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bernhard.rosenkran...@linaro.org


Created attachment 26850
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26850
Preprocessed source (not yet reduced)

Trying to build bionic with current trunk (but not 4.6 or 4.7) at -O2 or higher
results in:

[bero@localhost android]$
/tmp/android-toolchain-eabi/bin/arm-linux-androideabi-gcc -o
out/target/product/pandaboard/obj/SHARED_LIBRARIES/libc_intermediates/bionic/dlmalloc.o
-c dlmalloc.i -O2
bionic/libc/bionic/dlmalloc.c: In function 'sys_trim.constprop.6':
bionic/libc/bionic/dlmalloc.c:3830:1: internal compiler error: in
commit_one_edge_insertion, at cfgrtl.c:1631
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[fbi.sr at gmx dot de]

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

--- Comment #7 from Stefan Reichardt  2012-03-07 11:07:33 
UTC ---
nice!
i willl build it and publish it on avrfreaks soon, so Markus can try it out

[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names

[corsepiu at gcc dot gnu.org]

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

--- Comment #6 from Ralf Corsepius  2012-03-07 
10:59:59 UTC ---
Author: corsepiu
Date: Wed Mar  7 10:59:56 2012
New Revision: 185034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185034
Log:
2012-03-05  Ralf Corsépius  

PR target/51417
* Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext),
gcc-nm$(exeext), gcc-ranlib$(exeext).
Don't double canonicalize if cross-compiling.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/Makefile.in

[Bug target/52507] [avr]: movmem loop for __memx address space uses wrong loop label

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-07 
10:39:45 UTC ---
Author: gjl
Date: Wed Mar  7 10:39:42 2012
New Revision: 185033

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185033
Log:
PR target/52507
* config/avr/lib1funcs.S (__movmemx_hi): Fix loop label in RAM-part.


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

[Bug target/52506] [avr]: XMEGA: Wrong order of save/restore of RAMPX/Y/Z/D SFRs in ISR pro-/epilogue

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-07 
10:38:28 UTC ---
Author: gjl
Date: Wed Mar  7 10:38:25 2012
New Revision: 185032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185032
Log:
PR target/52506
* gcc/config/avr/avr.c (expand_epilogue): Fix order of restoration
to: RAMPZ, RAMPY, RAMPX, RAMPD.
(expand_prologue): Only clear RAMPZ if it has effect on RAM-read.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c

[Bug target/52505] [avr]: __memx address space reading unintentionally from RAM

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-07 
10:36:34 UTC ---
Author: gjl
Date: Wed Mar  7 10:36:30 2012
New Revision: 185031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185031
Log:
libgcc/
PR target/52505
* config/avr/lib1funcs.S (__xload_1): Don't read unintentionally
from RAM.

gcc/
PR target/52505
* config/avr/avr.c (avr_out_xload): Don't read unintentionally
from RAM.
* config/avr/avr.md (xload_8): Adjust insn length.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S

[Bug target/52508] [avr]: HAVE_RAMPZ as condition to set RAMPZ prior to flash-read is no more appropriate

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-07 
10:33:24 UTC ---
Author: gjl
Date: Wed Mar  7 10:33:19 2012
New Revision: 185030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185030
Log:
libgcc/
PR target/52461
PR target/52508
* config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.
(__tablejump_elpm__): Ditto.
(.xload): Ditto.
(__movmemx_hi): Ditto.
(__do_global_ctors): Right condition for RAMPZ usage is "have ELPM".
(__do_global_dtors): Ditto.
(__xload_1, __xload_2, __xload_3, __xload_4): Ditto.
(__movmemx_hi): Ditto.
gcc/
PR target/52461
* gcc/config/avr/avr.c (avr_out_lpm): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  2012-03-07 
10:33:24 UTC ---
Author: gjl
Date: Wed Mar  7 10:33:19 2012
New Revision: 185030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185030
Log:
libgcc/
PR target/52461
PR target/52508
* config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.
(__tablejump_elpm__): Ditto.
(.xload): Ditto.
(__movmemx_hi): Ditto.
(__do_global_ctors): Right condition for RAMPZ usage is "have ELPM".
(__do_global_dtors): Ditto.
(__xload_1, __xload_2, __xload_3, __xload_4): Ditto.
(__movmemx_hi): Ditto.
gcc/
PR target/52461
* gcc/config/avr/avr.c (avr_out_lpm): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/libgcc/ChangeLog
trunk/libgcc/config/avr/lib1funcs.S

[Bug target/52461] [avr] XMEGA+EBI: RAMPZ clobbered while reading from flash

[saturn at quantentunnel dot de]

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

--- Comment #5 from Markus Faust  2012-03-07 
10:12:41 UTC ---
(In reply to comment #4)
> This bug tracker if for the official GCC hosted by FSF, not for private ports.
Sorry about that.

Yesterday I found Stefan's binaries (Thanks, Stefan):
gcc version 4.7.0 20120217 - by SRMeister (GCC)

It seems to show the same behaviour.
ELPM is used in the __do_copy_data section (the only ELPM in my whole object
code, btw.).

(In reply to comment #1)
> Can the EBI be switched off, so that RAMPZ affects ELPM but not LD?

Actually, the EBI is switched off by default (and I'm not using it), but
obviously RAMPZ does still affect the adressing of the data space (LD/ST with
Z). I think switching EBI on/off only affects the function of the corresponding
port pins.

Further more, I didn't find any documentation if RAMPZ affects addressing of
data space on devices without EBI, but it is documented that (for LD/ST with
increment)
> The RAMPZ Register in the I/O area is updated in parts with more than 64K 
> bytes data space or more than 64K bytes Program memory, [...].
(AVR Instruction Set, doc0856i)

[Bug middle-end/52519] [4.8 Regression]

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug preprocessor/38987] Including a precompiled header from another header causes invalid assembly to be generated

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2012-03-07 
09:55:32 UTC ---
Author: rguenth
Date: Wed Mar  7 09:55:26 2012
New Revision: 185029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185029
Log:
2012-03-07  Richard Guenther  

PR pch/52518
PR pch/38987
* doc/invoke.texi (Precompiled Headers): Remove sentence that
suggests you can include PCHs from inside another header.

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

[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c, x86_64-unknown-linux-gnu in bid_binarydecimal.c

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from rsandifo at gcc dot gnu.org  
2012-03-07 09:54:54 UTC ---
Fixed.

[Bug pch/52518] gcc fails to find pch files in subincludes

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2012-03-07 
09:56:15 UTC ---
Fixed.  See PR38987.

[Bug pch/52518] gcc fails to find pch files in subincludes

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-03-07 
09:55:31 UTC ---
Author: rguenth
Date: Wed Mar  7 09:55:26 2012
New Revision: 185029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185029
Log:
2012-03-07  Richard Guenther  

PR pch/52518
PR pch/38987
* doc/invoke.texi (Precompiled Headers): Remove sentence that
suggests you can include PCHs from inside another header.

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

[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c, x86_64-unknown-linux-gnu in bid_binarydecimal.c

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
2012-03-07 09:50:41 UTC ---
Author: rsandifo
Date: Wed Mar  7 09:50:36 2012
New Revision: 185028

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185028
Log:
gcc/
PR middle-end/52515
* rtl.h (pc_rtx, cc0_rtx, ret_rtx, simple_return_rtx): Add GTY markers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/rtl.h

[Bug pch/52518] gcc fails to find pch files in subincludes

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-07
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from Richard Guenther  2012-03-07 
09:51:55 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > This is expected as the token is #include .
> 
> The documentation suggests that that shouldn't be a problem:
> "you can even include a precompiled header from inside another header"

No, that never worked ok, and it was changed to error (instead of crash ;))
by intent.

The documentation wasn't updated for that fact, I'll do that now.

[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
Version|4.6.0   |4.8.0
 Resolution|FIXED   |
   Target Milestone|4.6.2   |4.8.0
Summary|[4.6/4.7 Regression] ICE|[4.8 Regression] ICE
   |non-trivial conversion at   |non-trivial conversion at
   |assignment  |assignment

--- Comment #66 from Richard Guenther  2012-03-07 
09:48:12 UTC ---
Now exposed again.

[Bug lto/52516] FAIL: gfortran.dg/lto/pr45586* f_lto_pr45586*_0.o-f_lto_pr45586_0.o link, -O0 -flto (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2012-03-07 
09:47:15 UTC ---
That's expected.  See the audit trail of PR45586, that bug wasn't really fixed.
Marking as dup and re-opening.

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

[Bug fortran/45586] [4.6/4.7 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #65 from Richard Guenther  2012-03-07 
09:47:16 UTC ---
*** Bug 52516 has been marked as a duplicate of this bug. ***

[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||i686-pc-cygwin
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-07
 CC||davek at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
   Host||i686-pc-cygwin
 Ever Confirmed|0   |1
  Build||i686-pc-cygwin

--- Comment #1 from Richard Guenther  2012-03-07 
09:44:34 UTC ---
Probably caused by

2010-11-04  Richard Henderson  

* configure.ac (AC_CHECK_HEADERS): Add process.h.
(checkfuncs): Add dup3, spawnve, spawnvpe; sort the list.
(AC_CHECK_FUNCS): Add dup3, spawnve, spawnvpe.
* configure, config.in: Rebuild.
* pex-unix.c [HAVE_SPAWNVE] (pex_unix_exec_child): New function.
[HAVE_SPAWNVE] (save_and_install_fd, restore_fd): New functions.

thus 4.6 should be broken as well for you?

Can you check why configure thinks spawnve is available in process.h
(contrary to the warning we see in your snippet)?

What Windows version are you using?

[Bug c++/52510] [4.8 regression] libitm/config/posix/rwlock.cc doesn't compile

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Version|4.7.0   |4.8.0
   Target Milestone|--- |4.8.0

[Bug middle-end/52515] [4.8 Regression]: build fails on cris-elf in unwind-dw2.c, x86_64-unknown-linux-gnu in bid_binarydecimal.c

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
2012-03-07 09:35:50 UTC ---
Oops.

[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus  2012-03-07 
09:26:13 UTC ---
Re-reading the standard, I think the non-BIND(C) version of TYPE(*) is
currently mishandled. That should be only visible for "TYPE(*)" dummies which
are INTENT(OUT) and where the actual argument is a derived type with default
initialization or has allocatable components (possibly even with finalization
subroutines).

See http://gcc.gnu.org/ml/fortran/2012-03/msg00037.html and
http://j3-fortran.org/pipermail/j3/2012-March/005113.html

[Bug middle-end/52519] [4.8 Regression]

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-03-07 
08:54:23 UTC ---
might be the same as PR 52515

[Bug c++/49976] Cross (Linux->AIX) GCC crashes with Segmentation fault

[basil at list dot ru]

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

Vasily Sukhanov  changed:

   What|Removed |Added

 Target|powerpc-ibm-aix5.2.0.0  |powerpc-ibm-aix5.3.0.0
Version|4.6.1   |4.6.3

--- Comment #6 from Vasily Sukhanov  2012-03-07 08:34:38 
UTC ---
Bug is still in 4.6 branch:

* Command line **
/emc/sukhav/cross/aix53/gcc463/bin/powerpc-ibm-aix5.3.0.0-g++ -pthread -W -Wall
-DACE_AIX_VERS=503 -maix32 -O2 -g -O2 -DACE_HAS_CUSTOM_EXPORT_MACROS=0
-I/emc/sukhav/cross/aix53/gcc463/ACE580/ACE_wrappers -DACE_HAS_EXCEPTIONS
-D__ACE_INLINE__ -I.. -DACE_BUILD_DLL -c -o .shobj/Log_Msg.o Log_Msg.cpp
-save-temps -v
Using built-in specs.
COLLECT_GCC=/emc/sukhav/cross/aix53/gcc463/bin/powerpc-ibm-aix5.3.0.0-g++
COLLECT_LTO_WRAPPER=/home/sukhav/cross/aix53/gcc463/bin/../libexec/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/lto-wrapper
Target: powerpc-ibm-aix5.3.0.0
Configured with: /emc/sukhav/cross/gcc-4.6.3/configure
--prefix=/emc/sukhav/cross/aix53/gcc463
--with-sysroot=/emc/sukhav/cross/aix53/sysroot --target=powerpc-ibm-aix5.3.0.0
--with-gnu-ld --with-gnu-as --enable-languages=c,c++
Thread model: aix
gcc version 4.6.3 (GCC)
COLLECT_GCC_OPTIONS='-pthread' '-Wextra' '-Wall' '-D' 'ACE_AIX_VERS=503'
'-maix32' '-O2' '-g' '-O2' '-D' 'ACE_HAS_CUSTOM_EXPORT_MACROS=0' '-I'
'/emc/sukhav/cross/aix53/gcc463/ACE580/ACE_wrappers' '-D' 'ACE_HAS_EXCEPTIONS'
'-D' '__ACE_INLINE__' '-I' '..' '-D' 'ACE_BUILD_DLL' '-c' '-o'
'.shobj/Log_Msg.o' '-save-temps' '-v' '-shared-libgcc'

/home/sukhav/cross/aix53/gcc463/bin/../libexec/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/cc1plus
-E -quiet -v -I /emc/sukhav/cross/aix53/gcc463/ACE580/ACE_wrappers -I ..
-imultilib pthread -iprefix
/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/
-D_ALL_SOURCE -D_THREAD_SAFE -D ACE_AIX_VERS=503 -D
ACE_HAS_CUSTOM_EXPORT_MACROS=0 -D ACE_HAS_EXCEPTIONS -D __ACE_INLINE__ -D
ACE_BUILD_DLL Log_Msg.cpp -maix32 -Wextra -Wall -g -fworking-directory -O2 -O2
-fpch-preprocess -o Log_Msg.ii
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3"
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3/powerpc-ibm-aix5.3.0.0/pthread"
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3/backward"
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/include"
ignoring nonexistent directory
"/emc/sukhav/cross/aix53/sysroot/usr/local/include"
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/include-fixed"
ignoring duplicate directory
"/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/../../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include"
ignoring duplicate directory ".."
#include "..." search starts here:
#include <...> search starts here:
 /emc/sukhav/cross/aix53/gcc463/ACE580/ACE_wrappers

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3/powerpc-ibm-aix5.3.0.0/pthread

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include/c++/4.6.3/backward

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/include

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/include-fixed

/home/sukhav/cross/aix53/gcc463/bin/../lib/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/../../../../powerpc-ibm-aix5.3.0.0/include
 /emc/sukhav/cross/aix53/sysroot/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-pthread' '-Wextra' '-Wall' '-D' 'ACE_AIX_VERS=503'
'-maix32' '-O2' '-g' '-O2' '-D' 'ACE_HAS_CUSTOM_EXPORT_MACROS=0' '-I'
'/emc/sukhav/cross/aix53/gcc463/ACE580/ACE_wrappers' '-D' 'ACE_HAS_EXCEPTIONS'
'-D' '__ACE_INLINE__' '-I' '..' '-D' 'ACE_BUILD_DLL' '-c' '-o'
'.shobj/Log_Msg.o' '-save-temps' '-v' '-shared-libgcc'

/home/sukhav/cross/aix53/gcc463/bin/../libexec/gcc/powerpc-ibm-aix5.3.0.0/4.6.3/cc1plus
-fpreprocessed Log_Msg.ii -quiet -dumpbase Log_Msg.cpp -maix32 -auxbase-strip
.shobj/Log_Msg.o -g -O2 -O2 -Wextra -Wall -version -o Log_Msg.s
GNU C++ (GCC) version 4.6.3 (powerpc-ibm-aix5.3.0.0)
compiled by GNU C version 4.3.2, GMP version 5.0.2, MPFR version 3.0.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.6.3 (powerpc-ibm-aix5.3.0.0)
  

[Bug c++/49976] Cross (Linux->AIX) GCC crashes with Segmentation fault

[basil at list dot ru]

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

Vasily Sukhanov  changed:

   What|Removed |Added

  Attachment #24915|0   |1
is obsolete||

--- Comment #5 from Vasily Sukhanov  2012-03-07 08:28:03 
UTC ---
Created attachment 26849
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26849
new preprocessed file