[Bug c/52181] New: [4.7 Regression] merge_decls doesn't handle DECL_USER_ALIGN properly

[jakub at gcc dot gnu.org]

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

 Bug #: 52181
   Summary: [4.7 Regression] merge_decls doesn't handle
DECL_USER_ALIGN properly
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


extern const int v1[];
const int __attribute__((aligned(16))) v1[] = { 0 };
extern const int __attribute__((aligned(16))) v2[];
const int v2[] = { 0 };
extern const int __attribute__((aligned(16))) v3[];
const int __attribute__((aligned(16))) v3[] = { 0 };
const int __attribute__((aligned(16))) v4[] = { 0 };
int test[(__alignof__ (v4) != __alignof__ (v1)/* { dg-bogus "is negative" } */
 || __alignof__ (v4) != __alignof__ (v2)
 || __alignof__ (v4) != __alignof__ (v3)) ? -1 : 0];

fails with gcc 4.7, worked with 4.6, but it looks like the actual bug is of an
earlier date, when DECL_USER_ALIGN bit has been moved from tree_decl_common
etc.
down into tree_base.

[Bug c/52181] [4.7 Regression] merge_decls doesn't handle DECL_USER_ALIGN properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-09
  Known to work||4.6.3
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Known to fail||4.7.0

[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 #26 from Benjamin Kosnik  2012-02-09 
08:45:10 UTC ---
Created attachment 26620
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26620
complete transition to __atomic, modulo config


... and for config, plan would be to just remove check for atomic builtins and
resulting macros

[Bug c/52181] [4.7 Regression] merge_decls doesn't handle DECL_USER_ALIGN properly

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-02-09 
09:07:20 UTC ---
Created attachment 26621
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26621
gcc47-pr52181.patch

Untested fix.  The testcase shows that the C++ FE has a similar bug, but in the
other direction, when olddecl has aligned attribute and newdecl doesn't.

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

[redi at gcc dot gnu.org]

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

--- Comment #27 from Jonathan Wakely  2012-02-09 
09:16:11 UTC ---
Nice.  Now that we have an atomic load we can also do:

--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -193,7 +193,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   {
 // No memory barrier is used here so there is no synchronization
 // with other threads.
-return const_cast(_M_use_count);
+return __atomic_load_n(&_M_use_count, __ATOMIC_RELAXED);
   }

 private:

[Bug c/52182] New: unnamed structs/unions are supported by ISO C99

[jan.kratochvil at redhat dot com]

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

 Bug #: 52182
   Summary: unnamed structs/unions are supported by ISO C99
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com


http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields
says
"As permitted by ISO C11"

and also:
echo 'struct { int a; struct { int b; }; } s;'|gcc -c -x c - -Wall -std=c99
-pedantic
:1:34: warning: ISO C99 doesn’t support unnamed structs/unions
[-pedantic]
FAIL: gcc (GCC) 4.6.3 20120209 (prerelease)
FAIL: gcc (GCC) 4.7.0 20120209 (experimental)

plus
FAIL: gcc (GCC) 4.4.7 20120209 (prerelease)
FAIL: gcc (GCC) 4.5.4 20120209 (prerelease)
print
:1:34: warning: declaration does not declare anything

But ISO C99 says:
  A structure type describes a sequentially allocated nonempty set of member
  objects (and, in certain circumstances, an incomplete array), each of which
  has an optionally specified name and possibly distinct type.
 ^
  A union type describes an overlapping nonempty set of member objects, each of
  which has an optionally specified name and possibly distinct type.
   ^

(I agree ISO C90 spec still did not support unnamed fields.)

[Bug other/52168] fixinclude test failure for complex.h on netbsd

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2012-02-09 
09:20:21 UTC ---
This isn't the only issue we had with sed c command, see
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01110.html
And this is the only spot in fixincl that uses it.  Can't it be rewritten with
without sed somehow (c_test/c_fix* ?)?

[Bug middle-end/51867] GCC generates inconsistent code for same sources calling builtin calls, like sqrtf

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org 2012-02-09 09:37:43 UTC ---
Author: amker
Date: Thu Feb  9 09:37:37 2012
New Revision: 184037

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

PR target/51867
* builtins.c (expand_builtin): Don't check DECL_ASSEMBLER_NAME_SET_P.

PR target/51867
* testsuite/c-c++-common/dfp/signbit-2.c: Change '-O0' to '-O1'.
* testsuite/gcc.dg/pr51867.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr51867.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/dfp/signbit-2.c

[Bug c++/52183] New: Redeclaration of __this in lambda inside template member function when calling static class function

[stefan.bolus at gmx dot de]

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

 Bug #: 52183
   Summary: Redeclaration of __this in lambda inside template
member function when calling static class function
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stefan.bo...@gmx.de


When compiling

#include 

struct A
{
  template
  void f (T x) {
std::function aux;
aux = [&] () -> void{
  s();
  aux ();
};
  }

  static void s () { }
};

template void A::f (int);

code is rejected by the compiler by the error message below. Expected behavior
is compilation without an error.

stefan@bluebox:/tmp$ g++-svn -std=c++0x -v --save-temps foo.cpp
Using built-in specs.
COLLECT_GCC=g++-svn
COLLECT_LTO_WRAPPER=/home/stefan/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure --enable-languages=c,c++
--prefix=/home/stefan --program-suffix=-svn --disable-multilib
Thread model: posix
gcc version 4.7.0 20120126 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /home/stefan/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -E -quiet -v
-D_GNU_SOURCE foo.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess
-o foo.ii
ignoring nonexistent directory
"/home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0

/home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu

/home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
 /home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
 /usr/local/include
 /home/stefan/include
 /home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-save-temps' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /home/stefan/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -fpreprocessed
foo.ii -quiet -dumpbase foo.cpp -mtune=generic -march=x86-64 -auxbase foo
-std=c++11 -version -o foo.s
GNU C++ (GCC) version 4.7.0 20120126 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120126 (experimental), GMP version 5.0.1,
MPFR version 3.0.1-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.7.0 20120126 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0 20120126 (experimental), GMP version 5.0.1,
MPFR version 3.0.1-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 587bcf77b9db77a91e3cc4b379a04aff
foo.cpp: In instantiation of ‘A::f(T) [with T = int]::’:
foo.cpp:10:7:   required from ‘struct A::f(T) [with T = int]::’
foo.cpp:8:5:   required from ‘void A::f(T) [with T = int]’
foo.cpp:17:29:   required from here
foo.cpp:9:9: error: redeclaration of ‘A* const A::f(T) [with T =
int]__this’
foo.cpp:9:9: note: previous declaration ‘A* const A::f(T) [with T =
int]__this’
foo.cpp:9:9: error: redeclaration of ‘A* const this’
foo.cpp:9:9: error: ‘A* const this’ previously declared here
In file included from foo.cpp:1:0:
/home/stefan/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/functional:2172:2:
error: ‘typename std::enable_if<(! std::is_integral<_Functor>::value),
std::function<_Res(_ArgTypes ...)>&>::type std::function<_Res(_ArgTypes
...)>::operator=(_Functor&&) [with _Functor = A::f(T) [with T =
int]::; _Res = void; _ArgTypes = {}; typename std::enable_if<(!
std::is_integral<_Functor>::value), std::function<_Res(_ArgTypes ...)>&>::type
= std::function&]’, declared using local type ‘A::f(T) [with T =
int]::’, is used but never defined [-fpermissive]

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[abel at gcc dot gnu.org]

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

--- Comment #9 from Andrey Belevantsev  2012-02-09 
10:10:41 UTC ---
Author: abel
Date: Thu Feb  9 10:10:36 2012
New Revision: 184038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184038
Log:
2012-02-09  Andrey Belevantsev  

Backport from mainline
2012-01-20  Andrey Belevantsev  

PR target/51106
* function.c (instantiate_virtual_regs_in_insn): Use
delete_insn_and_edges when removing a wrong asm insn.

Backport from mainline
2012-01-20  Jakub Jelinek  

PR target/51106
* gcc.dg/torture/pr51106-1.c: New test.
* gcc.dg/torture/pr51106-2.c: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr51106-1.c
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr51106-2.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/function.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[abel at gcc dot gnu.org]

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

--- Comment #10 from Andrey Belevantsev  2012-02-09 
10:17:59 UTC ---
Author: abel
Date: Thu Feb  9 10:17:55 2012
New Revision: 184040

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184040
Log:
2012-02-09  Andrey Belevantsev  

Backport from mainline
2012-01-20  Andrey Belevantsev  

PR target/51106
* function.c (instantiate_virtual_regs_in_insn): Use
delete_insn_and_edges when removing a wrong asm insn.

Backport from mainline
2012-01-20  Jakub Jelinek  

PR target/51106
* gcc.dg/torture/pr51106-1.c: New test.
* gcc.dg/torture/pr51106-2.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr51106-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr51106-2.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/function.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Andrey Belevantsev  2012-02-09 
10:18:40 UTC ---
Tested ok, so committed to 4.5/4.6, fixed, closed.

[Bug c++/52183] Redeclaration of __this in lambda inside template member function when calling static class function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-09
 CC||paolo.carlini at oracle dot
   ||com
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-02-09 
11:25:54 UTC ---
Confirmed. I think this is closely related to PR51494, and indeed my draft
patch for the latter appears to fix this one too, you may want to give it a
try:

  http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01593.html

(by no means I consider my draft close to the final form, eg, likely we want to
leave maybe_dummy_object alone, but I believe it correctly pin points were the
problem is)

[Bug c++/48483] Construct from yourself w/o warning

[manu at gcc dot gnu.org]

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

--- Comment #17 from Manuel López-Ibáñez  2012-02-09 
11:35:27 UTC ---
Clang++ 3.0 warns with -Wuninitialized

/tmp/webcompile/_15338_0.cc:7:5: warning: variable 'a' is uninitialized when
used within its own initialization [-Wuninitialized]
A a(a.i);
  ~ ^
1 warning generated.


but it doesn't warn for the testcase in comment #2.

[Bug debug/52165] [4.7 Regression] ICE in add_var_loc_to_decl, at dwarf2out.c:5430 building libgo on s390/s390x

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-09 
11:41:29 UTC ---
Author: jakub
Date: Thu Feb  9 11:41:25 2012
New Revision: 184042

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184042
Log:
PR debug/52165
* var-tracking.c (emit_note_insn_var_location): If
EMIT_NOTE_BEFORE_INSN and insn is NOTE_INSN_CALL_ARG_LOCATION,
emit it before next non-NOTE_INSN_CALL_ARG_LOCATION
non-NOTE_DURING_CALL_P insn.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug fortran/32380] misaligned stores don't get vectorized

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-02-09 
12:13:25 UTC ---
Author: jakub
Date: Thu Feb  9 12:13:18 2012
New Revision: 184043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184043
Log:
PR fortran/32380
* gfortran.dg/vect/pr32380.f: Use dg-additional-options instead
of dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/vect/pr32380.f

[Bug other/52168] fixinclude test failure for complex.h on netbsd

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-02-09 
12:19:38 UTC ---
NetBSD PR http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45955

My analysis of the problem was incorrect and it looks as though a fix would be
to put an *unescaped* \n at the end of each -e script:

 /*
  *  Fix Command Arguments for Solaris_Complex_Cxx
  */
 static const char* apzSolaris_Complex_CxxPatch[] = { sed_cmd_z,
 "-e", "/#if[ \t]*!defined(__cplusplus)/c\\\n\
 #ifdef\t__cplusplus\\\n\
 extern \"C\" {\\\n\
-#endif",
+#endif\n",
 "-e", "/#endif[ \t]*\\/\\* !defined(__cplusplus) \\*\\//c\\\n\
 #ifdef\t__cplusplus\\\n\
 }\\\n\
-#endif",
+#endif\n",
 (char*)NULL };

POSIX requires that a newline in the replacement text be escaped with \ so an
unescaped newline is not part of the replacement text.  GNU and Solaris both
correctly ignore an unescaped newline at the end of the script, apparently
netbsd does too (but I can't test that until later today)

[Bug other/52168] fixinclude test failure for complex.h on netbsd

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-02-09 
12:24:14 UTC ---
(In reply to comment #4)
> netbsd does too (but I can't test that until later today)

or rather, it doesn't ignore the newline, but it does produce the expected
result

[Bug rtl-optimization/52175] [4.7 regression] ICE in maybe_record_trace_start after invalid dbr_schedule transformation

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Guenther  2012-02-09 
12:29:11 UTC ---
Confirmed.

[Bug debug/52165] [4.7 Regression] ICE in add_var_loc_to_decl, at dwarf2out.c:5430 building libgo on s390/s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2012-02-09 
12:35:44 UTC ---
Fixed.

[Bug middle-end/48814] [4.4/4.5/4.6/4.7 Regression] Incorrect scalar increment result

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-02-09 
13:03:25 UTC ---
For

extern void abort (void);
struct S { int i; };
struct S arr[32];
volatile int count = 0;

struct S __attribute__((noinline))
incr (void)
{
  ++count;
}

int main()
{
  arr[count++] = incr ();
  if (count != 2)
abort ();
  return 0;
}

we can only avoid reading 'count' too many times (once to get at the
index for the store and once for updating its value) if we can
insert a statement inbetween the call and the store to arr[].  Which
we can do only if we are introducing an aggregate temporary - which
might work in C, but does not work in C++ when we require
return-slot-optimization.  Thus, in the face of volatiles and required RSO
this is unfixable.

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  2012-02-09 
14:46:07 UTC ---
Author: bergner
Date: Thu Feb  9 14:46:02 2012
New Revision: 184045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184045
Log:
gcc/
PR middle-end/52140
* dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.

gcc/testsuite/
PR middle-end/52140
* gcc.dg/dfp/pr52140.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr52140.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dojump.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  2012-02-09 
14:56:03 UTC ---
Author: bergner
Date: Thu Feb  9 14:55:57 2012
New Revision: 184046

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184046
Log:
Backport from mainline 
2012-02-09  Peter Bergner  

gcc/
PR middle-end/52140
* dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.

gcc/testsuite/
PR middle-end/52140
* gcc.dg/dfp/pr52140.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/dfp/pr52140.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/dojump.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  2012-02-09 
14:59:51 UTC ---
Author: bergner
Date: Thu Feb  9 14:59:46 2012
New Revision: 184047

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184047
Log:
Backport from mainline 
2012-02-09  Peter Bergner  

gcc/
PR middle-end/52140
* dojump.c (do_compare_rtx_and_jump): Use SCALAR_FLOAT_MODE_P.

gcc/testsuite/
PR middle-end/52140
* gcc.dg/dfp/pr52140.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/dfp/pr52140.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dojump.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Peter Bergner  2012-02-09 
15:05:08 UTC ---
Fixed on trunk and the 4.6 and 4.5 branches.

[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 #6 from Jack Howarth  2012-02-09 
15:05:50 UTC ---
All of these crashes appear in the section in the GC_mark_from subroutine of
mark.c commented as...

   /* Try to prefetch the next pointer to be examined asap.*/
/* Empirically, this also seems to help slightly without*/
/* prefetches, at least on linux/X86.  Presumably this loop */
/* ends up with less register pressure, and gcc thus ends up*/
/* generating slightly better code.  Overall gcc code quality   */
/* for this loop is still not great.*/

GC_mark_from itself is commented as...

/*
 * Mark objects pointed to by the regions described by
 * mark stack entries between GC_mark_stack and GC_mark_stack_top,
 * inclusive.  Assumes the upper limit of a mark stack entry
 * is never 0.  A mark stack entry never has size 0.
 * We try to traverse on the order of a hblk of memory before we return.
 * Caller is responsible for calling this until the mark stack is empty.
 * Note that this is the most performance critical routine in the
 * collector.  Hence it contains all sorts of ugly hacks to speed
 * things up.  In particular, we avoid procedure calls on the common
 * path, we take advantage of peculiarities of the mark descriptor
 * encoding, we optionally maintain a cache for the block address to
 * header mapping, we prefetch when an object is "grayed", etc.
 */

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #10 from Peter Bergner  2012-02-09 
15:08:03 UTC ---
Closing as fixed

[Bug middle-end/51752] trans-mem: publication safety violated

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  2012-02-09 
16:23:57 UTC ---
Created attachment 26622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26622
proposed (untested) patch

This is a first stab at the problem.  It is untested, and there are definitely
other places that will be perform loads behind our back, but this seems to work
for the test at hand.

The main gist is saving all blocks that appear in a transaction so later we can
know if the load being hoisted is inside a transaction.  Then we use ANTIC sets
to determine if all paths out of the loop header perform the load.  If so, the
load is permitted.

Again, untested WIP, but hopefully on the right track.

[Bug c++/52184] New: Wrong object initialization in

[kamil.holubicki at gmail dot com]

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

 Bug #: 52184
   Summary: Wrong object initialization in
Classification: Unclassified
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kamil.holubi...@gmail.com

[Bug c++/52185] New: Const member function may change the object for which the function is called.

[lsoltysiak at gmail dot com]

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

 Bug #: 52185
   Summary: Const member function may change the object for which
the function is called.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lsoltys...@gmail.com


According to paper www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3242.pdf (
class.this point 2), a const member function shall not modify the object for
which the function is called.

With basic cases it is true, so for below class g++ returns error ('error:
increment of member ‘A::a’ in read-only object').

class A {
int a;
public: int fun() const { a++; }
};

Problems start when class contains references. In below example, const member
function allows to change internal state of class A instances. This shouldn't
be allowed. In my opinion compilation should failed, but g++ 4.7.0 doesn't
report any problem.

class A {
int   a1;
int & a2;
  public: 
A() : a2(a1) { }
int fun() const { a2++; }
};

[Bug c++/52184] Wrong object initialization in

[kamil.holubicki at gmail dot com]

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

--- Comment #1 from Kamil  2012-02-09 
16:44:01 UTC ---
Created attachment 26623
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26623
Short example demonstrating problem

[Bug middle-end/51752] trans-mem: publication safety violated

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-02-09 
16:43:40 UTC ---
But isn't with

  __transaction_atomic
{
  for (i = 0; i < 10; i++)
if (x[i])
  x[i] += data;
}

and

  __transaction_atomic { x[9] = 1; }

occuring concurrently the loop transaction terminated?  Thus,

  __transaction_atomic
{
  tem = data;
  for (i = 0; i < 10; i++)
if (x[i])
  x[i] += tem;
}

equivalent?  We don't hoist out of the transaction region (well, as far
as I can see - the transaction region seems to be specified in a very
weak way, without virtual operands or any IL barrier or such).

:
  # .MEM_2 = VDEF <.MEM_1(D)>
  data = 23;
  __transaction_atomic  // SUBCODE=[ GTMA_HAVE_STORE ]

:
  # .MEM_3 = VDEF <.MEM_2>
  x[9] = 1;
  # .MEM_4 = VDEF <.MEM_3>
  __builtin__ITM_commitTransaction ();

:
  # VUSE <.MEM_4>
  return;

the __transaction_atomic  // SUBCODE=[ GTMA_HAVE_STORE ] statement
looks like an overly optimistic way to start a transaction in my quick view.

[Bug c++/52185] Const member function may change the object for which the function is called.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-02-09 
16:44:20 UTC ---
Comeau C++ does not error out either.

[Bug c++/52184] Wrong object initialization in

[kamil.holubicki at gmail dot com]

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

--- Comment #2 from Kamil  2012-02-09 
16:46:55 UTC ---
Base virtual class object is corrupted when explicitly called auto generated
constructor from derived class inititalization list. 
Attached file demonstrates problem.

The only difference between constructors of Derived class is that first one
explicitly states which Base1 constructor should be called. I would expect that
both cout in main() print 8. Unfortunately the first one prints 0.

f I enable explicit definition of Base1 constructor it fixes the problem. If I
remove virtual inheritance in Derived class definition (class Derived: public
A1, public A2) it works as well.

Tested also on 4.6.1 version - issue still exist. Does not exist on 3.4.4.

[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

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2012-02-09 
16:51:25 UTC ---
The first testcase IMNSHO isn't a regression, because it ICEs since the
ipa-cp-eval-threshold param has been added.  The other testcase is a
regression, started ICEing with the same commit:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176424

[Bug c++/52184] Wrong object initialization in

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-02-09 
16:55:12 UTC ---
4.7 prints 8, agreeing with other compilers

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

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  2012-02-09 16:55:28 
UTC ---
Yes, I marked this PR as a regression after adding the second testcase, along
with modifying the summary.
The way it behaves in 4.6 is described in the "Tested revisions" paragraph, but
yes, I should have been more clear, sorry.

[Bug c++/48483] Construct from yourself w/o warning

[lisp2d at lisp2d dot net]

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

--- Comment #18 from Lisp2D  2012-02-09 16:59:19 UTC 
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483#c2
  shows that function calling of object before constructor is bad idea and must
be strongly forbidden.

[Bug c++/52185] Const member function may change the object for which the function is called.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  2012-02-09 
17:00:32 UTC ---
G++ is correct. 
In A::fun() 'this' is 'const A*' but you can still change A::a1 through a
reference.

Compare:

int* p;

struct A {
int   a1;
A() : a1(-1) { }
int fun() const { return ++*p; }
};

int main()
{
A a;
p = &a.a1;
return a.fun();
}

[Bug fortran/52176] Valgrind complains about some realloc on assignment to unallocated LHS

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-02-09 
17:02:36 UTC ---
gfortran generates the following code (original dump). I think, it's 

if ((real(kind=4)[0:] * restrict) __result->data == 0B) goto L.17;
L.17:;
D.2061 = __result->dim[0].ubound - __result->dim[0].lbound >= 0
   ? (__result->dim[0].ubound - __result->dim[0].lbound) + 1 : 0;
D.2062 = D.2061 != 2;
if ((real(kind=4)[0:] * restrict) __result->data == 0B)
  ...
else
if (D.2062)

where those equations are not used in an "if", if result->data == NULL.
However, in the optimized dump, one finds:

  [air.F90 : 82:0] prephitmp.78_7 = [air.F90 : 82] __result_6(D)->data;
  [air.F90 : 82:0] if (prephitmp.78_7 == 0B)
goto ;
:
  prephitmp.77_85 = __result_6(D)->dim[0].ubound;
  [air.F90 : 82:0] D.2085_25 = prephitmp.77_79 - D.2057_9;
  [air.F90 : 82:0] if (D.2085_25 >= 0)
...
  [air.F90 : 82:0] if (prephitmp.78_7 == 0B)
goto ;
  else
goto ;

Thus, the bounds are always accessed in the "if", even if the result->data ==
NULL. However, in terms of the result, it does not seem to matter as far as I
could see.


However, I think the issue above is not related to the warning I see. valgrind
can only track uninitialized variables which have been allocated ("malloc") but
in this case "result" is a local variable, which should be stack allocated.
>From the callee (state_vector, atmosphere.F90:187):
real ,dimension(:) ,allocatable :: x
x = this%air_puppet%coordinate()

I think one should see such a valgrind error for allocatable components of
allocatable/pointer derived types as then also ".dim" is malloc'ed.

If my analysis is correct, I do not see why valgrind warns. Nor do I understand
the reordering of the middle end. But at least the case above looks as if it's
not a wrong-code issue.

[Bug c++/48483] Construct from yourself w/o warning

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  2012-02-09 
17:04:06 UTC ---
Everyone knows it's a bad idea, and everyone agrees there should be a warning.
Stop going on about it.

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

[alex at aivor dot com]

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

 Bug #: 52186
   Summary: array out of bounds error when accessing last byte of
a struct via char ptr
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@aivor.com


Created attachment 26624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26624
source code

In some cases, casting a struct to an unsigned char and indexing the last byte
causes an array out of bounds error.  To illustrate:

 struct foobar foobar;
 unsigned char *k = (unsigned char*)foobar;
 if ( k[sizeof(struct foobar)-1] ) /* out of bounds? */
   return;

The above snippet is only to describe the problem.  See the attached file
"test.c" for an real example.  When test.c is compiled with -O2 it gives the
following error:

 test.c:21:11: error: array subscript is above array bounds

Small changes to the code such as changing a struct member type from 'unsigned
char' to 'char' avoid the error.  Other changes that avoid the error are
described in comments in test.c.

The error is flagged with and without '-fno-strict-aliasing'.

The file test.c is as simple as I could make it -- no external includes, etc.

Attached files:

 test.c -- source code

 test.* -- files created by '-save-temps'

 log -- stdout and stderr of the compile command

Compile command:

 gcc -v -save-temps -c test.c -Wall -Werror  -O2 -fno-strict-aliasing

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

[alex at aivor dot com]

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

--- Comment #1 from Alex Tomlinson  2012-02-09 17:10:31 
UTC ---
Created attachment 26625
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26625
output of -save-temps

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

[alex at aivor dot com]

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

--- Comment #2 from Alex Tomlinson  2012-02-09 17:11:03 
UTC ---
Created attachment 26626
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26626
output of -save-temps

[Bug c++/52185] Const member function may change the object for which the function is called.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-02-09 
17:11:40 UTC ---
[class.this] says, "In a const member function, the object for which the
function is called is accessed through a const access path;"

That doesn't mean the object is immutable.

In the member function you can't change A::a (but you couldn't do that anyway
because it's a reference) but you can change the thing it is bound to, because
it's a non-const reference, and it could point to a non-member just as easily
as to a member e.g.

int i = 0;

struct A {
  int a1;
  int a2;
  A(bool b) : a1(1), a2(b ? a1 : i) { }
  void f() const { ++a2; }
};

Should this fail to compile?
What if you only ever call the constructor with a 'false' argument?

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

[alex at aivor dot com]

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

--- Comment #3 from Alex Tomlinson  2012-02-09 17:12:39 
UTC ---
Created attachment 26627
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26627
stdout/stderr of gcc with -v -save-temps

[Bug c/51360] [4.6 Regression] spurious unused-but-set-variable warning for var used in OpenMP pragma

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-02-09 
17:15:39 UTC ---
Author: jakub
Date: Thu Feb  9 17:15:29 2012
New Revision: 184049

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184049
Log:
Backported from mainline
2011-12-15  Jakub Jelinek  

PR c/51360
* c-parser.c (c_parser_omp_clause_num_threads,
c_parser_omp_clause_schedule): Call mark_exp_read.

* semantics.c (finish_omp_clauses): For OMP_CLAUSE_NUM_THREADS_EXPR
and OMP_CLAUSE_SCHEDULE_CHUNK_EXPR call mark_rvalue_use.

* gcc.dg/gomp/pr51360.c: New test.
* g++.dg/gomp/pr51360.C: New test.
* g++.dg/gomp/pr51360-2.C: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gomp/pr51360-2.C
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gomp/pr51360.C
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/gomp/pr51360.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/c-parser.c
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/semantics.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug driver/48306] [4.4/4.5/4.6 Regression] presence of gcc subdir with . in PATH causes breakdown

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-02-09 
17:16:27 UTC ---
Author: jakub
Date: Thu Feb  9 17:16:19 2012
New Revision: 184050

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184050
Log:
Backported from mainline
2012-01-26  Jakub Jelinek  

* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
about using preprocessor directives inside of macro arguments.

2012-01-02  Jakub Jelinek  

* make-relative-prefix.c (make_relative_prefix_1): Avoid
stack overflow if PATH contains just a single entry and
HOST_EXECUTABLE_SUFFIX needs to be used.

PR driver/48306
* make-relative-prefix.c: Include sys/stat.h.
(make_relative_prefix_1): If access succeeds, check also stat
if nstore is a regular file.

Modified:
branches/gcc-4_6-branch/libiberty/ChangeLog
branches/gcc-4_6-branch/libiberty/make-relative-prefix.c

[Bug c++/51669] [4.7 Regression] ICE verify-gimple with openmp

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-02-09 
17:17:48 UTC ---
Author: jakub
Date: Thu Feb  9 17:17:36 2012
New Revision: 184051

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184051
Log:
Backported from mainline
2012-01-03  Jakub Jelinek  

PR c++/51669
* semantics.c (finish_omp_clauses): Call fold_build_cleanup_point_expr
on OMP_CLAUSE_{IF,NUM_THREADS,SCHEDULE_CHUNK}_EXPR.

* g++.dg/gomp/pr51669.C: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gomp/pr51669.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/semantics.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/51695] NOTE_INSN_VAR_LOCATION notes are sometimes too large

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2012-02-09 
17:18:51 UTC ---
Author: jakub
Date: Thu Feb  9 17:18:42 2012
New Revision: 184052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184052
Log:
Backported from mainline
2012-01-04  Jakub Jelinek  

PR debug/51695
* dwarf2out.c (output_loc_list): For now drop >= 64KB expressions
in .debug_loc on the floor.

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

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr51695.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/dwarf2out.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-02-09 
17:17:03 UTC ---
a = b

The problem is that the LHS is REAL(4) while the RHS is REAL(8). Thus, the
expression is not  =  but
   = __convert_i8_i4 ()


But trans-array's gfc_trans_assignment_1 contains:

  if (gfc_is_reallocatable_lhs (expr1)
&& !(expr2->expr_type == EXPR_FUNCTION
 && expr2->value.function.isym != NULL))
lss->is_alloc_lhs = 1;

As expr2->value.function.isym is set (expr2->value.function.isym->id ==
GFC_ISYM_CONVERSION), the is_alloc_lhs is not set. Hence, the bound checking
code is inserted.

[Bug middle-end/44777] [4.4/4.5/4.6 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2012-02-09 
17:20:31 UTC ---
Author: jakub
Date: Thu Feb  9 17:20:09 2012
New Revision: 184053

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184053
Log:
Backported from mainline
2012-01-05  Jakub Jelinek  

PR middle-end/44777
* profile.c (branch_prob): Split bbs that have exit edge
and need a fake entry edge too.

* gcc.dg/tree-prof/pr44777.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/tree-prof/pr44777.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/profile.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug debug/51517] [4.5/4.6 Regression] Wrong debug information for pointers with negative strides.

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-02-09 
17:13:57 UTC ---
Author: jakub
Date: Thu Feb  9 17:13:50 2012
New Revision: 184048

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184048
Log:
Backported from mainline
2011-12-15  Jakub Jelinek  

PR debug/51517
* tree-ssa-coalesce.c (coalesce_ssa_name): For !optimize, test
!DECL_IGNORED_P instead of !DECL_ARTIFICIAL.

* trans-decl.c (gfc_get_symbol_decl): Don't set DECL_INITAL on span.
(gfc_trans_deferred_vars): Instead add its runtime initialization
here.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/trans-decl.c
branches/gcc-4_6-branch/gcc/tree-ssa-coalesce.c

[Bug middle-end/51768] [4.5/4.6 Regression] ICE with invalid asm goto

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-09 
17:21:45 UTC ---
Author: jakub
Date: Thu Feb  9 17:21:15 2012
New Revision: 184054

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184054
Log:
Backported from mainline
2012-01-05  Jakub Jelinek  

PR middle-end/51768
* stmt.c (check_unique_operand_names): Don't ICE during error
reporting if i is from labels chain.

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

Added:
branches/gcc-4_6-branch/gcc/testsuite/c-c++-common/pr51768.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/stmt.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51767] [4.5/4.6 Regression] ICE with degenerated asm goto

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-09 
17:23:23 UTC ---
Author: jakub
Date: Thu Feb  9 17:23:13 2012
New Revision: 184055

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184055
Log:
Backported from mainline
2012-01-05  Jakub Jelinek  

PR rtl-optimization/51767
* cfgrtl.c (force_nonfallthru_and_redirect): Force addition
of jump_block and add an extra edge for degenerated asm gotos.

* gcc.c-torture/compile/pr51767.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr51767.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cfgrtl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

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

[alex at aivor dot com]

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

--- Comment #4 from Alex Tomlinson  2012-02-09 17:23:37 
UTC ---
Reported to work with gcc 4.6.1:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-4)

[Bug c/52182] unnamed structs/unions are supported by ISO C99

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2012-02-09 17:23:59 UTC ---
On Thu, 9 Feb 2012, jan.kratochvil at redhat dot com wrote:

> But ISO C99 says:
>   A structure type describes a sequentially allocated nonempty set of member
>   objects (and, in certain circumstances, an incomplete array), each of which
>   has an optionally specified name and possibly distinct type.
>  ^

The name is only optional for bit-fields.  See the syntax for 
struct-declaration and struct-declarator.  The difference in C11 is that a 
struct-declarator-list is optional in a struct-declaration.

[Bug libmudflap/40778] [4.5/4.6 Regression] Mudflap instrumentation missing in cloned function.

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2012-02-09 
17:24:57 UTC ---
Author: jakub
Date: Thu Feb  9 17:24:47 2012
New Revision: 184056

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184056
Log:
Backported from mainline
2012-01-19  Jakub Jelinek  

PR libmudflap/40778
* tree-mudflap.c (mf_artificial): New function.
(execute_mudflap_function_ops, execute_mudflap_function_decls,
mx_register_decls, mudflap_enqueue_decl): Use it.

* testsuite/libmudflap.c/fail68-frag.c: New test.

Added:
branches/gcc-4_6-branch/libmudflap/testsuite/libmudflap.c/fail68-frag.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-mudflap.c
branches/gcc-4_6-branch/libmudflap/ChangeLog

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-02-09 
17:27:26 UTC ---
(In reply to comment #1)
> As expr2->value.function.isym is set (expr2->value.function.isym->id ==
> GFC_ISYM_CONVERSION), the is_alloc_lhs is not set. Hence, the bound checking
> code is inserted.

All intrinsics, which do not call libgfortran, should be affected. For
instance:
  B = tan(A)

[Bug target/52129] wrong code to pass parameters to tail call function

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-02-09 
17:27:34 UTC ---
Author: jakub
Date: Thu Feb  9 17:27:25 2012
New Revision: 184059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184059
Log:
Backported from mainline
2012-02-06  Jakub Jelinek  

PR target/52129
* calls.c (mem_overlaps_already_clobbered_arg_p): If val is
CONST_INT_P, subtract resp. add crtl->args.pretend_args_size to it.

* gcc.c-torture/execute/pr52129.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr52129.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/calls.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/52006] [4.7 Regression] ARM ICE with incorrectly peepholed tls_load_dot_plus_eight

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-09 
17:26:01 UTC ---
Author: jakub
Date: Thu Feb  9 17:25:47 2012
New Revision: 184057

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184057
Log:
Backported from mainline
2012-01-28  Jakub Jelinek  

PR target/52006
* config/arm/arm.md (pic_add_dot_plus_eight peephole2): Use
arm_general_register_operand predicate for operand 2 instead of
register_operand.

* gcc.target/arm/pr52006.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr52006.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/48071] [4.6 Regression] Blank line after 'all warnings being treated as errors'

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-09 
17:26:41 UTC ---
Author: jakub
Date: Thu Feb  9 17:26:29 2012
New Revision: 184058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184058
Log:
Backported from mainline
2012-02-02  Jakub Jelinek  

PR middle-end/48071
* diagnostic.c (diagnostic_finish): Remove trailing newlines.

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

[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2012-02-09 
17:29:52 UTC ---
Author: jakub
Date: Thu Feb  9 17:29:38 2012
New Revision: 184061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184061
Log:
Backported from mainline
2012-02-07  Jakub Jelinek  

PR rtl-optimization/52060
* combine.c (try_combine): Add i0src_copy and i0src_copy2 variables,
copy i1src to i1src_copy whenever added_sets_2 && i1_feeds_i2_n already
before i1dest -> i1src substitution in newpat, copy i0src to i0src_copy
and/or i0src_copy2 when needed.

* gcc.dg/torture/pr52060.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr52060.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/combine.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/52074] ICE: RTL flag check: MEM_VOLATILE_P used with unexpected rtx code 'plus' in extract_fixed_bit_field, at expmed.c:1734

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-02-09 
17:28:30 UTC ---
Author: jakub
Date: Thu Feb  9 17:28:22 2012
New Revision: 184060

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184060
Log:
Backported from mainline
2012-02-07  Jakub Jelinek  

PR middle-end/52074
* expr.c (expand_expr_addr_expr_1): For CONSTANT_CLASS_P or CONST_DECL
if modifier < EXPAND_SUM call force_operand on the result.

* gcc.c-torture/compile/pr52074.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/pr52074.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/52139] [4.5/4.6 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-02-09 
17:30:51 UTC ---
Author: jakub
Date: Thu Feb  9 17:30:39 2012
New Revision: 184062

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184062
Log:
Backported from mainline
2012-02-08  Jakub Jelinek  

PR rtl-optimization/52139
* cfgrtl.c (cfg_layout_merge_blocks): If BB_END
is a BARRIER after emit_insn_after_noloc, move BB_END
to the last non-BARRIER insn before it.

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

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr52139.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/cfgrtl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/51752] trans-mem: publication safety violated

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  2012-02-09 
17:39:51 UTC ---
(In reply to comment #4)
> But isn't with
> 
>   __transaction_atomic
> {
>   for (i = 0; i < 10; i++)
> if (x[i])
>   x[i] += data;
> }
> 
> and
> 
>   __transaction_atomic { x[9] = 1; }
> 
> occuring concurrently the loop transaction terminated?

The problem we want to fix is not wrt x[], but data.

Consider x[0..10] == 0, and another thread with

  while (1)
__transaction_atomic { data += 1; }

If we hoist data in the first transaction, then we're very
likely to restart the transaction based on stale contents
of data, even when we ought not have touched data at all.

I.e. we can wind up looping even when we ought to be making
forward progress.

> We don't hoist out of the transaction region (well, as far
> as I can see - the transaction region seems to be specified in a very
> weak way, without virtual operands or any IL barrier or such).

It was supposed to have virtual operands.  It really did at one
time, but that seems to have gotten lost.  I noticed this with
another PR a week or so ago, but havn't gotten around to fixing it.

[Bug c/51360] [4.6 Regression] spurious unused-but-set-variable warning for var used in OpenMP pragma

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2012-02-09 
17:39:48 UTC ---
Fixed.

[Bug c/52182] unnamed structs/unions are supported by ISO C99

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jan Kratochvil  
2012-02-09 17:42:30 UTC ---
That there can be struct { int:10; }, OK.  Thanks for the explanation.

[Bug target/52129] wrong code to pass parameters to tail call function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2012-02-09 
17:48:15 UTC ---
Hopefully fixed now.

[Bug middle-end/48071] [4.6 Regression] Blank line after 'all warnings being treated as errors'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-02-09 
17:49:06 UTC ---
Fixed.

[Bug rtl-optimization/52060] [4.6 Regression] Invalid constant simplification in combine with parallel result

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Jakub Jelinek  2012-02-09 
17:49:36 UTC ---
Fixed.

[Bug fortran/43366] [OOP][F2008] Intrinsic assign to polymorphic variable

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  2012-02-09 
17:48:11 UTC ---
Created attachment 26628
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26628
Small patch for the resolve.c. It misses all the real work (trans*.c).

[Bug other/52187] New: armeb-unknown-eabi not recognized as big-endian

[egnor at ofb dot net]

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

 Bug #: 52187
   Summary: armeb-unknown-eabi not recognized as big-endian
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eg...@ofb.net


In gcc/config.gcc, the stanza for Linux recognizes arm*b-* and treats it as
big-endian:

arm*-*-linux*)  # ARM GNU/Linux with ELF
tm_file="dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h arm/elf.h arm/linux-gas.h arm/linux-elf.h"
case $target in
arm*b-*)
tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
;;
esac

However, the similar stanza for other arm targets does not.  In my case I am
using armeb-unknown-eabi (for a bare metal project), which means the
arm*-*-eabi* stanza takes place.  This ignores the "eb" suffix and builds a
compiler which defaults to little endian.  (Worse, libgcc is built in
little-endian mode, causing subtle bugs even with code compiled with
-mbig-endian.)

Copying the Linux arm*b-* section to the other stanza helps my case, but I'm
not sure it's a general solution.

Bug 16350 may be related -- possibly even a dupe -- though I'm not sure the
scope is the same.  Good code _is_ generated with -mbig-endian, it just needs
to be recognized as the default for appropriate targets.

[Bug target/16350] gcc only understands little endian ARM systems

[egnor at ofb dot net]

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

Dan Egnor  changed:

   What|Removed |Added

 CC||egnor at ofb dot net

--- Comment #27 from Dan Egnor  2012-02-09 17:53:24 UTC 
---
The precise scope of this bug is unclear to me.

Big endian Linux targets _do_ seem to work now, and -mbig-endian generates
correct code regardless; however, non-Linux big-endian targets do not seem to
be recognized as big-endian by default (which means libgcc is built in little
endian mode, etc.).

See bug 52187 (which may be a dupe of this one, depending on how you interpret
the scope of this bug).

[Bug c++/52184] Wrong object initialization in virtual inhreitance

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  2012-02-09 
18:00:42 UTC ---
(In reply to comment #3)
> 4.7 prints 8, agreeing with other compilers

It was either PR 51331 or PR 50618 so closing as fixed.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |target

--- Comment #1 from Andrew Pinski  2012-02-09 
18:04:09 UTC ---
I think this is really a dup of bug 49448 or at least related to it.

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

[egnor at ofb dot net]

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

--- Comment #2 from Dan Egnor  2012-02-09 18:06:36 UTC ---
This is sort of the opposite of 49448.

In 49448, the _Linux_ rule is recognizing a _little endian_ target as _big
endian_ because its big-endian glob is too generous.

In this bug, a _non-Linux_ rule is recognizing a _big endian_ target as _little
endian_, because there's no big-endian glob at all.

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

[ro at gcc dot gnu.org]

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

 Bug #: 52188
   Summary: [4.7 regression] IPA-CP change broke libstdc++ symbol
versioning on Solaris
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: jamb...@gcc.gnu.org, paolo.carl...@oracle.com
  Host: *-*-solaris2*
Target: *-*-solaris2.*
 Build: *-*-solaris2.*


As already discussed to some length in

  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html

the following patch

2011-07-18  Martin Jambor  

* ipa-prop.h: Include alloc-pool.h, all sorts of updates to general
comments.
(ipcp_values_pool): Declare.
(ipcp_sources_pool): Likewise.
[...]

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 latter is matched by the linker map and exported at version GLIBCXX_3.4.15,
which is effectively closed with the release of gcc 4.6 where the symbol wasn't
present.

To avoid breaking symbol versioning on Solaris, the question is what to do
here:
we obviously cannot export it at 3.4.15, but could instead export it at
3.4.17 *on Solaris* instead.  Before going that route, I need to make certain
that this isn't just a code generation accident and the symbol can vanish again
later: the exported interface of a shared object *must not* depend on the 
vagaries of code generation changes.

Martin?

[Bug c++/52185] Const member function may change the object for which the function is called.

[lsoltysiak at gmail dot com]

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

--- Comment #4 from xfg  2012-02-09 18:30:34 UTC 
---
Ok, I understood. Pointers are also quite good examples, to explain that. 

Thanks Jonathan.

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

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2012-02-09 18:31:18 UTC 
---
Created attachment 26629
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26629
preprocesed source

compile with

cc1plus -fpreprocessed locale-inst.ii -quiet -O2 -fPIC -o locale-inst.s

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.7.0
   Severity|normal  |major

[Bug c/52181] [4.7 Regression] merge_decls doesn't handle DECL_USER_ALIGN properly

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #2 from Ulrich Weigand  2012-02-09 
18:33:12 UTC ---
The regression is present on tip of 4.6 branch as well, exposed by recent
backports from mainline.

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

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2012-02-09 18:33:54 UTC 
---
Created attachment 26631
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26631
assembler output after patch

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

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2012-02-09 18:33:03 UTC 
---
Created attachment 26630
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26630
asembler output before patch

[Bug middle-end/51752] trans-mem: publication safety violated

[torvald at gcc dot gnu.org]

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

--- Comment #6 from torvald at gcc dot gnu.org 2012-02-09 18:40:49 UTC ---
(In reply to comment #4)
> But isn't with
> 
>   __transaction_atomic
> {
>   for (i = 0; i < 10; i++)
> if (x[i])
>   x[i] += data;
> }
> 
> and
> 

prepend with the following for thread B:

  data = 123;

>   __transaction_atomic { x[9] = 1; }
> 
> occuring concurrently the loop transaction terminated?  Thus,
> 
>   __transaction_atomic
> {
>   tem = data;
>   for (i = 0; i < 10; i++)
> if (x[i])
>   x[i] += tem;
> }
> 
> equivalent?

No.  It might be for typical HTMs, but we can't expect this in the general
case.  The interleaving that can then happen is (with A and B being the two
concurrent threads):

  B: tem = data;  // reads initial value of zero
  A: data = 123;
  A: __transaction_atomic { x[9] = 1; }
  B: if (x[i])
  B:   x[i] += tem;  // adds zero, not 123.

The problem here is that B's store to data is nontransactional, and we cannot
add synchronization code for those (it might be library code, for example).

We could add a partial workaround to libitm that would reduce this case here to
"just" a racing load.  However, that would kill performance because basically,
B's transaction would have to wait for all earlier-started transactions before
it can start executing.  The racing load can still be a problem if we hoist
dereferencing a pointer.

We don't see this example with other concurrent code because there, the load of
x[] would have to be a synchronizing operation, and we don't hoist across
these.

[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 #5 from Jakub Jelinek  2012-02-09 
18:43:01 UTC ---
Reduced testcase:

// { dg-do compile }
// { dg-options "-O -fno-guess-branch-probability -fipa-cp -fipa-cp-clone
--param=max-inline-insns-single=25" }

struct A
{
  A (A, unsigned);
  A (const char *);
  ~A () { a1 (a4 ()); }
  void a1 (int);
  unsigned a2 ();
  char *a3 ();
  int a4 ();
};

template 
struct B
{
  A b;
  B (A x, int y = 1) : b (x.a3 (), x.a2 ()) { if (y & 1) b.a2 (); }
};

extern template struct B ;
A a1 ("foo"), a2 ("bar");
B b1 (a1), b2 (a2, 8);

void
foo ()
{
  A a3 ("baz");
  B b3 (a1), b4 (a3);
}

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

[ro at gcc dot gnu.org]

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

 Bug #: 52189
   Summary: [4.7 regression] Relaxed gthreads check breaks Solaris
8/9 symbol versioning
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: paolo.carl...@oracle.com
  Host: *-*-solaris2.[89]
Target: *-*-solaris2.[89]
 Build: *-*-solaris2.[89]


As already discussed in

  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html

the relaxed gthreads check in 4.7 breaks libstdc++ symbol versioning on
Solaris 8 and 9 by exposing a considerable set of thread-dependent symbols
at the closed version GLIBCXX_3.4.11.

I think there are several options to fix this:

* 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.

* Export them at GLIBCXX_3.4.17 instead *on Solaris*.  This has the serious
  disadvantage that such a Solaris 8/9 binary cannot run on Solaris 10+
  which has those symbols at 3.4.11, and Solaris ld.so.1 doesn't support
  the symbol renaming/aliasing to also export them at 3.4.17, too, even if gld
  is in use.

* Do nothing and let the breakage happen ;-(

  Rainer

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

[mib.bugzilla at gmail dot com]

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

 Bug #: 52190
   Summary: question about atomic intrinsics -- test and
documentation vary -- please clarify
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com


This url http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

shows these 2 intrinsics declared like this:
Built-in Function: bool __atomic_always_lock_free (size_t size)
Built-in Function: bool __atomic_is_lock_free (size_t size)

But there are test cases for these 2 functions that have 2nd argument
(memmodel) e.g. atomic-lockfree.c lines 23 and 24

r1 = __atomic_always_lock_free (sizeof(char), 0); 
r2 = __atomic_is_lock_free (sizeof(char), 0);

Please clarify, thanks!

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

[ro at gcc dot gnu.org]

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

 Bug #: 52191
   Summary: abi_check should flag additions to released versions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: b...@gcc.gnu.org


When regenerating the Solaris libstdc++ baselines, I noticed that there were
several additions to already release/closed symbol versions:

  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html

Provided that the baselines for the various targets are updated immediately
before
releases, abi_check should be able to flag such additions since they are
obviously
not supposed to happen.  This is certainly far better than noticing the problem
only by accident/manual inspection or, even worse, only after another major
release has happened.

Ben, do you think this is feasible?

Thanks.
  Rainer

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

[ro at gcc dot gnu.org]

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

 Bug #: 52192
   Summary: GCC_CHECK_TLS doesn't detect native TLS on Solaris 8/9
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: bonz...@gnu.org
  Host: *-*-solaris2.[89]
Target: *-*-solaris2.[89]
 Build: *-*-solaris2.[89]


As discovered while investigating PR libstdc++/52104, config/tls.m4
(GCC_CHECK_TLS)
tails to detect native TLS support on Solaris 8 and 9 since that platform
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.

Unfortunately, when trying a bootstrap, I found two issues that most likely
require the patch to be postponed for 4.8:

* libstdc++.so still had an unresolved reference to __tls_get_addr; I suspect
  that we need -Wc,-pthread to get it through libtool.

* Same when linking go1, which uses -static-libstdc++, so a fix for the last
  won't help.  Most likely, the knowledge will have to be added to gcc/go
  directly.

  Rainer

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

[redi at gcc dot gnu.org]

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

--- 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.

[Bug ada/50942] Bootstrap failure on mingw32

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||charlet at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Arnaud Charlet  2012-02-09 
20:02:07 UTC ---
You didn't provide sufficient info.
The error looks like an error with your environment (e.g. bad behavior of
make),
and GCC builds on mingw32 for other people.

[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

Benjamin Kosnik  changed:

   What|Removed |Added

  Attachment #26620|0   |1
is obsolete||

--- Comment #28 from Benjamin Kosnik  2012-02-09 
20:07:29 UTC ---
Created attachment 26632
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26632
try two, check cleanups + jonathan's addition

[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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  2012-02-09 
20:40:05 UTC ---
Its a discrepancy due to vagueness :-)

The extra parameter is for an optional pointer to the object to allow the
alignment to be examined.

The standard was unclear about alignment issues, and when the atomics were
being designed and implemented, it was still unclear what direction things were
going.  

The routines were designed so that an aligned object could be lock free and an
unaligned object may be locked.  The last set of discussions I had indicate
that it is undesirable for 2 objects of the same size not to both be lock-free
or locked.  (ie, all objects of a given size must be the same).   We'll
finalize it all in gcc 4.8, but I think going forward we are probably only
going to support aligned atomic operations...

Anyway, thats why the extra parameter is there.  a 0 passed in instead of a
pointer means "use standard alignment for an object of this size".

I will change the documentation to match reality.

Andrew

[Bug other/52168] fixinclude test failure for complex.h on netbsd

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-02-09 
21:31:48 UTC ---
Created attachment 26633
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26633
replace 'c' command with 'i' and 'd'

this passes the tests on gnu/linux and netbsd

[Bug driver/48306] [4.4/4.5 Regression] presence of gcc subdir with . in PATH causes breakdown

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2012-02-09 
21:33:15 UTC ---
Author: jakub
Date: Thu Feb  9 21:33:11 2012
New Revision: 184069

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184069
Log:
Backported from mainline
2012-01-26  Jakub Jelinek  

* make-relative-prefix.c (make_relative_prefix_1): Avoid warning
about using preprocessor directives inside of macro arguments.

2012-01-02  Jakub Jelinek  

* make-relative-prefix.c (make_relative_prefix_1): Avoid
stack overflow if PATH contains just a single entry and
HOST_EXECUTABLE_SUFFIX needs to be used.

PR driver/48306
* make-relative-prefix.c: Include sys/stat.h.
(make_relative_prefix_1): If access succeeds, check also stat
if nstore is a regular file.

Modified:
branches/gcc-4_5-branch/libiberty/ChangeLog
branches/gcc-4_5-branch/libiberty/make-relative-prefix.c

[Bug middle-end/44777] [4.4/4.5 Regression] ICE: SIGSEGV with -fprofile-use in gcc.c-torture/execute/comp-goto-2.c

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2012-02-09 
21:34:25 UTC ---
Author: jakub
Date: Thu Feb  9 21:34:21 2012
New Revision: 184070

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184070
Log:
Backported from mainline
2012-01-05  Jakub Jelinek  

PR middle-end/44777
* profile.c (branch_prob): Split bbs that have exit edge
and need a fake entry edge too.

* gcc.dg/tree-prof/pr44777.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-prof/pr44777.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/profile.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/51768] [4.5 Regression] ICE with invalid asm goto

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-02-09 
21:35:40 UTC ---
Author: jakub
Date: Thu Feb  9 21:35:36 2012
New Revision: 184071

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184071
Log:
Backported from mainline
2012-01-05  Jakub Jelinek  

PR middle-end/51768
* stmt.c (check_unique_operand_names): Don't ICE during error
reporting if i is from labels chain.

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

Added:
branches/gcc-4_5-branch/gcc/testsuite/c-c++-common/pr51768.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/stmt.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog