[Bug libfortran/51646] New: Make libgfortran compile on Android - without S_IREAD

[burnus at gcc dot gnu.org]

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

 Bug #: 51646
   Summary: Make libgfortran compile on Android - without S_IREAD
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: j...@gcc.gnu.org


Created attachment 26156
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26156
Draft patch

Janne: What do you think of the attached patch?

http://specificimpulses.blogspot.com/2011/01/my-android-speaks-fortran-yours-can-too.html
shows that gfortran can be build for on Android (= host + target).

However, Android's NDK does not support S_IREAD and S_IWRITE but only S_IRUSR
and S_IWUSR.

In the Linux man page I find:
   UNIX  V7 (and later systems) had S_IREAD, S_IWRITE, S_IEXEC, where POSIX
   prescribes the synonyms S_IRUSR, S_IWUSR, S_IXUSR.

While POSIX (IEEE Std 1003.1, 2003) just lists the latter:
   S_IRUSR
  Read permission, owner.
   S_IWUSR
  Write permission, owner.

Expected: If no S_IREAD/S_IWRITE is available, use S_IRUSR/S_IWUSR. (Or rather
the other way round, given that only the latter is standard.)

S_IREAD/S_IWRITE is
- checked for in LIBGFOR_CHECK_UNLINK_OPEN_FILE  (libgfortran/acinclude.m4)
- used in io/unix.c's id_from_fd

 * * *

In the blog, the existence of other issues is mentioned and it links to a hack:
http://aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch
(Google cache:
http://webcache.googleusercontent.com/search?q=cache:khmjfgpFiAIJ:aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch+aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch
)

However, the patch/hack does not tell me much: It disable configure checking
(as_fn_exit returns 0 ("echo $1") instead of "exit $1") and in
intrinsics/date_and_time.c the "#ifndef" has been changed into an "#ifdef" for
HAVE_LOCALTIME_R and for HAVE_GMTIME_R.

Without config.log, one can probably not deduce what went wrong.

[Bug c/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug rtl-optimization/42839] [4.5/4.6 Regression] gcc.target/mips/octeon-bbit-2.c failing for -mabi=64

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.5.4   |4.7.0

[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Guenther  2011-12-21 
09:23:03 UTC ---
Author: rguenth
Date: Wed Dec 21 09:22:58 2011
New Revision: 182570

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182570
Log:
2011-12-21  Richard Guenther  

PR lto/41159
* tree-outof-ssa.c (insert_value_copy_on_edge): Use the
mode of the pseudo as destination mode.  Only assert that
is equal to the promoted mode of the decl if it is a REG.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-outof-ssa.c

[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Known to work||4.7.0

--- Comment #24 from Richard Guenther  2011-12-21 
09:24:05 UTC ---
Fixed on trunk, probably worth backporting to the 4.6 branch at least (it
should be safe as it only really adjusts an assertion and code if the assert
previously hit).

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2011-12-21 
09:29:05 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > On Tue, 20 Dec 2011, Richard Guenther wrote:
> > > > This one is extremely slow. lto1 has already used 12min of CPU time when
> > > > linking libxul and is still running... (3min is normal)
> > > 
> > > That's odd - TREE_TYPE (f1) should already be registered - but I suppose
> > > that adjusting TYPE_NAME might break all the caching we do with the
> > > type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
> > > type we change that SCC by that adjustment - probably causing
> > > the hit rate of the type-pair compare cache to become absymal?
> > > Maybe you can check that theory (I have no other idea why the above
> > > should be slow).
> > 
> > Though we should be hitting the gimple_type_leader cache only ...
> > maybe it's too small though?
> 
> Increasing the cache 4-fold doesn't help. 
> I will look deeper tomorrow. In the meantime here is a disassembly of the
> hot-spot.
> 
> uniquify_nodes:
>  :  /* Second fixup all trees in the new cache entries.  */
>  :  for (i = len; i-- > from;)
> 0.00 :  49969f:   mov%ebp,%eax
> 0.00 :  4996a1:   jmpq   4994b0 
> 0.00 :  4996a6:   nopw   %cs:0x0(%rax,%rax,1)
>  :  tree t = VEC_index (tree, cache->nodes, i);
>  :  if (t == NULL_TREE)
>  :continue;
>  :
>  :  if (TREE_CODE (t) == VAR_DECL)
>  :lto_register_var_decl_in_symtab (data_in, t);
> 0.00 :  4996b0:   mov0x38(%rsp),%rdi
> 0.00 :  4996b5:   callq  499250
> 
> 0.00 :  4996ba:   jmpq   499520 
>  : variant list state before fixup is broken.  */
>  :  tree tem, mv;
>  :
>  :  /* Remove us from our main variant list if we are
> not the
>  : variant leader.  */
>  :  if (TYPE_MAIN_VARIANT (t) != t)
> 0.00 :  4996bf:   mov0x68(%r15),%rdi
> 0.00 :  4996c3:   cmp%rdi,%r15
> 0.00 :  4996c6:   je 499701 
>  :{
>  :  tem = TYPE_MAIN_VARIANT (t);
>  :  while (tem && TYPE_NEXT_VARIANT (tem) != t)
> 0.00 :  4996c8:   test   %rdi,%rdi
> 0.00 :  4996cb:   je 4996f9 
> 0.00 :  4996cd:   mov0x60(%rdi),%rax
> 0.00 :  4996d1:   cmp%rax,%r15
> 0.00 :  4996d4:   jne4996e3 
> 0.00 :  4996d6:   jmpq   4997d9 
> 0.00 :  4996db:   nopl   0x0(%rax,%rax,1)
> 0.50 :  4996e0:   mov%rcx,%rax
> 0.70 :  4996e3:   test   %rax,%rax
> 0.00 :  4996e6:   je 4996f9 
> 0.00 :  4996e8:   mov0x60(%rax),%rcx
>98.41 :  4996ec:   cmp%rcx,%r15
> 0.00 :  4996ef:   jne4996e0 
>  :tem = TYPE_NEXT_VARIANT (tem);
>  :  if (tem)
>  :TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT
> (t);
> 0.00 :  4996f1:   mov0x60(%r15),%rcx
> 0.00 :  4996f5:   mov%rcx,0x60(%rax)
>  :  TYPE_NEXT_VARIANT (t) = NULL_TREE;
> 0.00 :  4996f9:   movq   $0x0,0x60(%r15)
>  :}
>  :
>  :  /* Query our new main variant.  */
>  :  mv = gimple_register_type (TYPE_MAIN_VARIANT (t));
> 0.01 :  499701:   callq  5be860 
>  :
>  :  /* If we were the variant leader and we get
> replaced ourselves drop
>  : all variants from our list.  */
>  :  if (TYPE_MAIN_VARIANT (t) == t
> 0.00 :  499706:   mov0x30(%rsp),%rdx
> 0.00 :  49970b:   cmp0x68(%rdx),%rdx
> 0.00 :  49970f:   je 4997b7 
>  :}
>  :}
>  :
>  :  /* If we are not our own variant leader link us
> into our new leaders
>  : variant list.  */
>  :  if (mv != t)
> 0.00 :  499715:   cmp%rax,0x30(%rsp)
> 0.00 :  49971a:   je 49992d 
>  :{

That's weird.  Did the build eventually finish?  LTO bootstrap went fine
for me, but SPEC 2k6 483.xalancbmk build ran out of memory during LTRANs
(in theory we should end up using _less_ memory with the change ...)

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[markus at trippelsdorf dot de]

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

--- Comment #10 from Markus Trippelsdorf  
2011-12-21 09:37:38 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > On Tue, 20 Dec 2011, Richard Guenther wrote:
> That's weird.  Did the build eventually finish?  LTO bootstrap went fine
> for me, but SPEC 2k6 483.xalancbmk build ran out of memory during LTRANs
> (in theory we should end up using _less_ memory with the change ...)

Yes. It did "finish" after using ~17min of CPU-time, but only to hit the next
bug:

/var/tmp/mozilla-central/parser/htmlparser/src/nsScannerString.cpp:124:46:
internal compiler error: in force_type_die, at dwarf2out.c:19296

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-21
  Component|c   |middle-end
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-12-21 
09:48:11 UTC ---
We are gimplifying this to

a (int s)
{
  struct  args[1];

  try
{
  __builtin_va_start (&args, 0);
  b (s, &args);
  __builtin_va_end (&args);
}
  finally
{
  args = {CLOBBER};
}
}

So the cleanup returns normally when b throws.  The ehcleanup stuff does
not trigger at -O0.

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-12-21 
09:51:45 UTC ---
Caused by r181172 aka TREE_CLOBBER_P.  The problem is that we have before
*.cfg:
  __builtin_va_start (&args, 0);
  b (s, &args);
  __builtin_va_end (&args);
  finally_tmp.0 = 1;
  :
  args = {CLOBBER};
  switch (finally_tmp.0) , default: , case 1:
>
  :
  goto ;
  :
  return;
  :
  finally_tmp.0 = 0;
  goto ;
  :
  resx 1
and *.cfg pass obviously optimizes away anything after the noreturn call:
:
  __builtin_va_start (&args, 0);
  b (s, &args);
:
  return;
:
  finally_tmp.0 = 0;
  args = {CLOBBER};
  switch (finally_tmp.0) , case 1: >
:
  resx 1
but the warn_function_return pass is immediately after that (and, this is -O0
anyway), so nothing optimizes the switch away into simple fall through into the
resx 1 block.  At -O and above we don't warn, because the *.eh pass before
*.cfg pass optimizes this.

So, IMHO to fix this, we need to do 2 things:
1) in decide_copy_try_finally reconsider
 if (!optimize)
return ndests == 1;
   if finally contains only gimple_clobber_p stmts
2) estimate_num_insns should return 0 for gimple_clobber_p stmts

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||arm-eabi

--- Comment #7 from Richard Guenther  2011-12-21 
09:53:24 UTC ---
Technically this bug is invalid (undefined is undefined, not consistent).  ARM
maintainers may want to disallow tail/sibling calls to possibly weak targets.

The ABI is inconsistent itself, btw, as

 weak_fn ();

beahaves different than

 *(&weak_fn) ();

as I presume the linker cannot do anything for indirect calls to weak
functions.

[Bug lto/51642] Weak variable reference triggers ICE with -flto option

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto

--- Comment #1 from Richard Guenther  2011-12-21 
09:54:16 UTC ---
Please try a recent trunk snapshot.

[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #1 from Janne Blomqvist  2011-12-21 10:10:10 
UTC ---
(In reply to comment #0)
> Created attachment 26156 [details]
> Draft patch
> 
> Janne: What do you think of the attached patch?
> 
> http://specificimpulses.blogspot.com/2011/01/my-android-speaks-fortran-yours-can-too.html
> shows that gfortran can be build for on Android (= host + target).
> 
> However, Android's NDK does not support S_IREAD and S_IWRITE but only S_IRUSR
> and S_IWUSR.
> 
> In the Linux man page I find:
>UNIX  V7 (and later systems) had S_IREAD, S_IWRITE, S_IEXEC, where 
> POSIX
>prescribes the synonyms S_IRUSR, S_IWUSR, S_IXUSR.
> 
> While POSIX (IEEE Std 1003.1, 2003) just lists the latter:
>S_IRUSR
>   Read permission, owner.
>S_IWUSR
>   Write permission, owner.
> 
> Expected: If no S_IREAD/S_IWRITE is available, use S_IRUSR/S_IWUSR. (Or rather
> the other way round, given that only the latter is standard.)
> 
> S_IREAD/S_IWRITE is
> - checked for in LIBGFOR_CHECK_UNLINK_OPEN_FILE  (libgfortran/acinclude.m4)
> - used in io/unix.c's id_from_fd
> 
>  * * *

Good catch! I suppose it's possible that all targets we support have the POSIX
flags, but since we're in stage 3 I think it's fine to play it safe and do the
ifdef dance.

So your patch per se is OK, however you have manage to introduce quite a few
typos ;-)

Since I copy-paste the patch here, I'll put my comments within "<<<>>>" 
blocks:

Index: acinclude.m4
===
--- acinclude.m4(revision 182565)
+++ acinclude.m4(working copy)
@@ -115,11 +115,19 @@ AC_DEFUN([LIBGFOR_CHECK_UNLINK_OPEN_FILE], [
 #include 
 #include 

+#if !defined(S_IRUSR) && defined(S_IREAD)
+#define S_IRUSR S_IREAD
+#endif
+
+#if !defined(S_IWUSR) && defined(S_IWRITE)
+#define S_IWGRP S_IWRITE

<<< Should be S_IWUSR >>>

+#endif
+
 int main ()
 {
   int fd;

-  fd = open ("testfile", O_RDWR | O_CREAT, S_IWRITE | S_IREAD);
+  fd = open ("testfile", O_RDWR | O_CREAT, S_IWUSR | S_IRUSR);
   if (fd <= 0)
 return 0;
   if (unlink ("testfile") == -1)
@@ -127,7 +135,7 @@ int main ()
   write (fd, "This is a test\n", 15);
   close (fd);

-  if (open ("testfile", O_RDONLY, S_IWRITE | S_IREAD) == -1 && errno ==
ENOENT)
+  if (open ("testfile", O_RDONLY, S_IUSR | S_IUSR) == -1 && errno == ENOENT)

<<<
There's two bugs here:

1. You have S_IUSR twice, presumably you mean S_IRUSR | S_IWUSR.

2. The mode argument is ignored if O_CREAT is not or'ed into the flags
argument, so the open call could just as well be open ("testfile", O_RDONLY)
>>>

 return 0;
   else
 return 1;
Index: io/unix.c
===
--- io/unix.c(revision 182565)
+++ io/unix.c(working copy)
@@ -113,6 +113,14 @@ id_from_fd (const int fd)
 #define PATH_MAX 1024
 #endif

+#if !defined(S_IRUSR) && defined(S_IREAD)
+#define S_IRUSR S_IREAD
+#endif
+
+#if !defined(S_IWUSR) && defined(S_IWRITE)
+#define S_IWGRP S_IWRITE

<<< Same here, should be S_IWUSR. >>>

+#endif
+
 /* These flags aren't defined on all targets (mingw32), so provide them
here.  */
 #ifndef S_IRGRP
@@ -1112,9 +1120,9 @@ tempfile (st_parameter_open *opp)

 #if defined(HAVE_CRLF) && defined(O_BINARY)
   fd = open (template, O_RDWR | O_CREAT | O_EXCL | O_BINARY,
- S_IREAD | S_IWRITE);
+ S_IUSR | S_IWUSR);

<<< Should be S_IRUSR | S_IWUSR  (R is missing) >>>

 #else
-  fd = open (template, O_RDWR | O_CREAT | O_EXCL, S_IREAD | S_IWRITE);
+  fd = open (template, O_RDWR | O_CREAT | O_EXCL, S_IUSR | S_IWUSR);

<<< Should be S_IRUSR | S_IWUSR  (R is missing) >>>

 #endif
 }
   while (fd == -1 && errno == EEXIST);




> In the blog, the existence of other issues is mentioned and it links to a 
> hack:
> http://aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch
> (Google cache:
> http://webcache.googleusercontent.com/search?q=cache:khmjfgpFiAIJ:aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch+aeromonkey.homeip.net/public/ugly_gfortran_hacks.patch
> )
> 
> However, the patch/hack does not tell me much: It disable configure checking
> (as_fn_exit returns 0 ("echo $1") instead of "exit $1") and in
> intrinsics/date_and_time.c the "#ifndef" has been changed into an "#ifdef" for
> HAVE_LOCALTIME_R and for HAVE_GMTIME_R.
> 
> Without config.log, one can probably not deduce what went wrong.

Agreed, that patch is hacky to the point of being useless for us. Lets not
worry about that.

[Bug tree-optimization/51600] [4.7 Regression] ice in estimate_local_effects

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-12/msg01508.htm
   ||l

--- Comment #4 from Martin Jambor  2011-12-21 
10:21:28 UTC ---
A workaround patch posted to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01508.html

[Bug libfortran/51646] Make libgfortran compile on Android - without S_IREAD

[jb at gcc dot gnu.org]

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

--- Comment #2 from Janne Blomqvist  2011-12-21 10:21:32 
UTC ---
(In reply to comment #1)
> Good catch! I suppose it's possible that all targets we support have the POSIX
> flags, but since we're in stage 3 I think it's fine to play it safe and do the
> ifdef dance.

Actually, in unix.c:1243 we unconditionally use S_IRUSR and S_IRGRP, which
means that all targets we support do have those flags. So on second thought I
think the ifdef dance is not necessary.

[Bug middle-end/51647] New: [4.7 Regression] Bogus "control reaches end of non-void function [-Wreturn-type]"

[burnus at gcc dot gnu.org]

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

 Bug #: 51647
   Summary: [4.7 Regression] Bogus "control reaches end of
non-void function [-Wreturn-type]"
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu


Created attachment 26157
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26157
test case

With the current trunk, I get:

$ g++ -S -Wall bogus_warn.cc
bogus_warn.cc: In function ‘int nsp::test(nsp::LookupResult*)’:
bogus_warn.cc:44:1: warning: control reaches end of non-void function
[-Wreturn-type

While using g++ 4.6, no warning is shown.

Looking at my builds (no warranty):
No warning with: 2011-11-06 (Rev. 181031)
   Warning with: 2011-11-11 (Rev. 181283)

[Bug bootstrap/51648] New: [4.7 Regression]

[jakub at gcc dot gnu.org]

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

 Bug #: 51648
   Summary: [4.7 Regression]
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: x86_64-linux

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|[4.7 Regression]|[4.7 Regression]
   ||Profiledbootstrap failure
   ||on x86_64-linux

--- Comment #1 from Jakub Jelinek  2011-12-21 
10:32:29 UTC ---
CFLAGS='-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mtune=generic' CXXFLAGS='-O2 -g -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mtune=generic' \
../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-checking=release \
--disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu \
--enable-languages=c,c++,lto --enable-plugin --with-ppl --with-cloog
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
make -j8 'BOOT_CFLAGS=-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mtune=generic' profiledbootstrap
fails on current trunk, reproduceably (3 times already) with:
../../gcc/gcc.c:8278:1: error: corrupted profile info: profile data is not
flow-consistent
../../gcc/gcc.c:8278:1: error: corrupted profile info: number of executions for
edge 262-263 thought to be -24
../../gcc/gcc.c:8278:1: error: corrupted profile info: number of executions for
edge 262-1 thought to be 24

I had to workaround two (bogus) uninitialized warnings first, will post a patch
for that.

[Bug c/51622] GCC generates bad code that generate big executable sizes when using _Decimal*

[mingodad at gmail dot com]

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

--- Comment #10 from Domingo Alvarez  2011-12-21 
10:36:45 UTC ---
Now looking on the net I found that libbid history and could see that the
actual one monolithic bid_decimalbinary file is a recent creation before it was
splited over several files, I don't think that this is a good move, it's hard
to edit, it links unnecessary code to all applications that do no use all
_Decimal sizes, ...

[Bug middle-end/51647] [4.7 Regression] Bogus "control reaches end of non-void function [-Wreturn-type]"

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2011-12-21 
10:56:01 UTC ---
One issue we still hit is that we for example merge in
stl_iterator_base_types.h

  template
struct iterator_traits
{ 
  typedef typename _Iterator::iterator_category iterator_category;
  typedef typename _Iterator::value_typevalue_type;
  typedef typename _Iterator::difference_type   difference_type;
  typedef typename _Iterator::pointer   pointer;
  typedef typename _Iterator::reference reference;
};

and

  template  
struct iterator_traits
{ 
  typedef random_access_iterator_tag iterator_category;
  typedef _Tp value_type;
  typedef ptrdiff_t   difference_type;
  typedef const _Tp*  pointer;
  typedef const _Tp&  reference;
};

and so end up attaching the same TYPE_DECL to both iterator_category typedefs.
An extreme idea was to only merge if the TYPE_DECLs source location was the
same (but not sure if that works reliably without expensive location
expansion).

The above merging causes us to infinitely recurse in modified_type_die
through DECL_ORIGINAL_TYPE which forms a typedef cycle.  You probably
hit a similar bug.

A non-optimial patch for the above is (non-optimal because it does not
include hashing)

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 182525)
+++ gcc/gimple.c(working copy)
@@ -3318,28 +3318,35 @@ compare_type_names_p (tree t1, tree t2)
   tree name1 = TYPE_NAME (t1);
   tree name2 = TYPE_NAME (t2);

+  if (name1 == name2)
+return true;
+
   if ((name1 != NULL_TREE) != (name2 != NULL_TREE))
 return false;

-  if (name1 == NULL_TREE)
-return true;
-
   /* Either both should be a TYPE_DECL or both an IDENTIFIER_NODE.  */
   if (TREE_CODE (name1) != TREE_CODE (name2))
 return false;

   if (TREE_CODE (name1) == TYPE_DECL)
-name1 = DECL_NAME (name1);
-  gcc_checking_assert (!name1 || TREE_CODE (name1) == IDENTIFIER_NODE);
+{
+  expanded_location loc1, loc2;

-  if (TREE_CODE (name2) == TYPE_DECL)
-name2 = DECL_NAME (name2);
-  gcc_checking_assert (!name2 || TREE_CODE (name2) == IDENTIFIER_NODE);
+  if (DECL_NAME (name1) != DECL_NAME (name2))
+   return false;

-  /* Identifiers can be compared with pointer equality rather
- than a string comparison.  */
-  if (name1 == name2)
-return true;
+  if (DECL_SOURCE_LOCATION (name1) == DECL_SOURCE_LOCATION (name2))
+   return true;
+
+  loc1 = expand_location (DECL_SOURCE_LOCATION (name1));
+  loc2 = expand_location (DECL_SOURCE_LOCATION (name2));
+  if (loc1.line != loc2.line
+ || loc1.column != loc2.column
+ || strcmp (loc1.file, loc2.file) != 0)
+   return false;
+
+  return true;
+}

   return false;
 }

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2011-12-21 
11:03:46 UTC ---
Created attachment 26158
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26158
patch candidate to speed up uniquify nodes

I was also experimenting with the attached patch - it should be enough to
call gimple_register_types (in uniquify_nodes and lto_fixup_types and friends)
for types in the current set of trees we process, and for those that do not
prevail.

[asserting that does not work though, for unknown reasons - known partially
at least for pre-loaded types which we shouldn't really merge anyway]

[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-12-21 
11:17:10 UTC ---
Insane, this doesn't happen for an initializer list of 1, 2, 4, or 5 elements.
Happens with std::vector too, however. Should be rather easy to construct a
reduced testcase including only .

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-12-21 
11:38:39 UTC ---
Created attachment 26159
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26159
gcc47-pr51644.patch

Fix I'm going to bootstrap/regtest.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-12-21 
11:41:04 UTC ---
Why -fexceptions?  Don't we explicitely _disable_ exceptions?

[Bug middle-end/51647] [4.7 Regression] Bogus "control reaches end of non-void function [-Wreturn-type]"

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-12-21 
11:42:16 UTC ---
Dup of PR51644 I think.

[Bug libstdc++/51649] New: pretty printers don't handle std::__7:: namespace

[pluto at agmk dot net]

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

 Bug #: 51649
   Summary: pretty printers don't handle std::__7:: namespace
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


the libstdc++ pretty printers don't work for gcc configured
with --enable-symvers=gnu-versioned-namespace.

e.g. it prints std::string as:

(gdb) p s
$1 = {
  static npos = 18446744073709551615,
  _M_dataplus = {
> = {
  <__gnu_cxx::__7::__mt_alloc >> = {
<__gnu_cxx::__7::__mt_alloc_base> = {}, }, },
members of std::__7::basic_string,
std::__7::allocator >::_Alloc_hider:
_M_p = 0x4d7220 "foo bar"
  }
}

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-12-21 
11:52:55 UTC ---
-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4 -mtune=generic
are our standard distro flags.  The intent is that e.g. C code that uses
pthread_cleanup_{push,pop} will be more efficient (use cleanup attribute) if we
do that.  Packages that for some reason want to build with -fno-exceptions
should IMHO put that -fno-exceptions after user supplied flags to override it.
If I understand right our gcc/Makefile.in we do that, $(NOEXCEPT_FLAGS) is put
after TCFLAGS etc. in AM_CXXFLAGS, so it overrides it right.
In this case (C build instead of C++, when there are still no advantages of
using C++ in GCC, I thought it doesn't hurt to configure that way) -fno-rtti
-fno-exceptions isn't considered to be a valid option during configure (well,
-fno-exceptions is, but -fno-rtti is not for C and both are tried at the same
time), so we build with -fexceptions.  That shouldn't make a significant
difference for C though, unless the cleanup attribute is used somewhere.

Anyway, the reason why I'm filing this is because this looks very much like
lots of the issues that were not really reproduceable during profiledbootstrap
in the past, now it seems to be reproduceable.

[Bug target/50038] redundant zero extensions

[kyukhin at gcc dot gnu.org]

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

--- Comment #8 from Kirill Yukhin  2011-12-21 
11:52:32 UTC ---
Author: kyukhin
Date: Wed Dec 21 11:52:27 2011
New Revision: 182574

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

2011-12-21  Enkovich Ilya  

PR target/50038
* implicit-zee.c: Delete.
* ree.c: New file.
* Makefile.in: Replace implicit-zee.c with ree.c.
* config/i386/i386.c (ix86_option_override_internal): Rename
flag_zee to flag_ree.
* common.opt (fzee): Ignored.
(free): New.
* passes.c (init_optimization_passes): Replace pass_implicit_zee
with pass_ree.
* tree-pass.h (pass_implicit_zee): Delete.
(pass_ree): New.
* timevar.def (TV_ZEE): Delete.
(TV_REE): New.
* doc/invoke.texi: Add -free description.

gcc/testsuite/

2011-12-21  Enkovich Ilya  

PR target/50038


Added:
trunk/gcc/ree.c
trunk/gcc/testsuite/gcc.dg/pr50038.c
Removed:
trunk/gcc/implicit-zee.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/common.opt
trunk/gcc/config/i386/i386.c
trunk/gcc/doc/invoke.texi
trunk/gcc/passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/timevar.def
trunk/gcc/tree-pass.h

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[pluto at agmk dot net]

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

--- Comment #1 from Pawel Sikora  2011-12-21 11:53:23 
UTC ---
adding '(__7::)?' to regex patterns should be ok.

[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #3 from Paolo Carlini  2011-12-21 
12:20:43 UTC ---
This is enough:

namespace std
{
  template
class initializer_list;

  template
struct set
{
  void insert(const _Key&);
};

  struct string
  {
string(const string&, __SIZE_TYPE__, __SIZE_TYPE__ = -1);
string(const char*);
string(initializer_list);
  };
}

int main()
{
  std::set s;
  s.insert( { "abc", "def", "hij"} );
}

[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225

[uros at gcc dot gnu.org]

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

--- Comment #25 from uros at gcc dot gnu.org 2011-12-21 12:26:17 UTC ---
Author: uros
Date: Wed Dec 21 12:26:04 2011
New Revision: 182580

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182580
Log:
Backport from mainline
2011-12-21  Richard Guenther  

PR lto/41159
* tree-outof-ssa.c (insert_value_copy_on_edge): Use the
mode of the pseudo as destination mode.  Only assert that
is equal to the promoted mode of the decl if it is a REG.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-outof-ssa.c

[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-12-21 
12:43:38 UTC ---
This is a more correct testcase, which also preserves the property of OT that
-pedantic works around the issue. Note: removing the string constructor taking
an initializer_list also works around the problem:

///

#include 

namespace std
{
  template
struct set
{
  void insert(const _Key&);
  void insert(initializer_list<_Key>);
};

  struct string
  {
string(const string&, __SIZE_TYPE__, __SIZE_TYPE__ = -1);
string(const char*);
string(initializer_list);
  };
}

int main()
{
  std::set s;
  s.insert( { "abc", "def", "hij"} );
}

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[markus at trippelsdorf dot de]

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

--- Comment #13 from Markus Trippelsdorf  
2011-12-21 12:55:21 UTC ---
(In reply to comment #11)
> One issue we still hit is that we for example merge in
> stl_iterator_base_types.h
> 
>   template
> struct iterator_traits
> { 
>   typedef typename _Iterator::iterator_category iterator_category;
>   typedef typename _Iterator::value_typevalue_type;
>   typedef typename _Iterator::difference_type   difference_type;
>   typedef typename _Iterator::pointer   pointer;
>   typedef typename _Iterator::reference reference;
> };
> 
> and
> 
>   template  
> struct iterator_traits
> { 
>   typedef random_access_iterator_tag iterator_category;
>   typedef _Tp value_type;
>   typedef ptrdiff_t   difference_type;
>   typedef const _Tp*  pointer;
>   typedef const _Tp&  reference;
> };
> 
> and so end up attaching the same TYPE_DECL to both iterator_category typedefs.
> An extreme idea was to only merge if the TYPE_DECLs source location was the
> same (but not sure if that works reliably without expensive location
> expansion).
> 
> The above merging causes us to infinitely recurse in modified_type_die
> through DECL_ORIGINAL_TYPE which forms a typedef cycle.  You probably
> hit a similar bug.
> 
> A non-optimial patch for the above is (non-optimal because it does not
> include hashing)
> 
> Index: gcc/gimple.c
> ===
> --- gcc/gimple.c(revision 182525)
> +++ gcc/gimple.c(working copy)
> @@ -3318,28 +3318,35 @@ compare_type_names_p (tree t1, tree t2)
>tree name1 = TYPE_NAME (t1);
>tree name2 = TYPE_NAME (t2);
> 
> +  if (name1 == name2)
> +return true;
> +
>if ((name1 != NULL_TREE) != (name2 != NULL_TREE))
>  return false;
> 
> -  if (name1 == NULL_TREE)
> -return true;
> -
>/* Either both should be a TYPE_DECL or both an IDENTIFIER_NODE.  */
>if (TREE_CODE (name1) != TREE_CODE (name2))
>  return false;
> 
>if (TREE_CODE (name1) == TYPE_DECL)
> -name1 = DECL_NAME (name1);
> -  gcc_checking_assert (!name1 || TREE_CODE (name1) == IDENTIFIER_NODE);
> +{
> +  expanded_location loc1, loc2;
> 
> -  if (TREE_CODE (name2) == TYPE_DECL)
> -name2 = DECL_NAME (name2);
> -  gcc_checking_assert (!name2 || TREE_CODE (name2) == IDENTIFIER_NODE);
> +  if (DECL_NAME (name1) != DECL_NAME (name2))
> +   return false;
> 
> -  /* Identifiers can be compared with pointer equality rather
> - than a string comparison.  */
> -  if (name1 == name2)
> -return true;
> +  if (DECL_SOURCE_LOCATION (name1) == DECL_SOURCE_LOCATION (name2))
> +   return true;
> +
> +  loc1 = expand_location (DECL_SOURCE_LOCATION (name1));
> +  loc2 = expand_location (DECL_SOURCE_LOCATION (name2));
> +  if (loc1.line != loc2.line
> + || loc1.column != loc2.column
> + || strcmp (loc1.file, loc2.file) != 0)
> +   return false;
> +
> +  return true;
> +}
> 
>return false;
>  }

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 30844]
strcmp () at ../sysdeps/x86_64/strcmp.S:214
214 movlpd  (%rsi), %xmm2
(gdb) bt
#0  strcmp () at ../sysdeps/x86_64/strcmp.S:214
#1  0x005bff0f in compare_type_names_p (t1=,
t2=) at ../../gcc/gcc/gimple.c:3345
#2  gimple_types_compatible_p_1 (t1=0x76feb000, t2=0x7728f690,
p=0x10ea9dc, sccstack=0x7ffee068, sccstate=0x1118380, 
sccstate_obstack=0x7ffee070) at ../../gcc/gcc/gimple.c:3554
#3  0x005bea20 in gimple_types_compatible_p (t2=0x7728f690,
t1=0x76feb000) at ../../gcc/gcc/gimple.c:3943
#4  gimple_type_eq (p1=0x76feb000, p2=0x7728f690) at
../../gcc/gcc/gimple.c:4438
#5  0x00b6f064 in htab_find_slot_with_hash (htab=0x7727db60,
element=0x7728f690, hash=1226149484, insert=INSERT)
at ../../gcc/libiberty/hashtab.c:668
#6  0x005b87d1 in gimple_register_type_1 (t=0x7728f690,
registering_mv=) at ../../gcc/gcc/gimple.c:4473
#7  0x005b8803 in gimple_register_type_1 (t=0x76fc1540,
registering_mv=) at ../../gcc/gcc/gimple.c:4470
#8  0x004996d4 in uniquify_nodes (data_in=0x10bb2b0, from=236) at
../../gcc/gcc/lto/lto.c:742
#9  0x00499b13 in lto_read_decls (decl_data=0x773bf000,
data=0x7718e020, resolutions=) at
../../gcc/gcc/lto/lto.c:933
#10 0x0049ab80 in lto_file_finalize (file_data=0x773bf000,
file=) at ../../gcc/gcc/lto/lto.c:1173
#11 lto_create_files_from_ids (count=,
file_data=0x773bf000, file=0x1028eb0) at ../../gcc/gcc/lto/lto.c:1183
#12 lto_file_read (count=, resolution_file=0x10b70b0,
file=0x1028eb0) at ../../gcc/gcc/lto/lto.c:1223
#13 read_cgraph_and_symbols (fnames=0x103ac10, nfiles=110) at
../../gcc/gcc/lto/lto.c:2624
#14 lto_main (

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Guenther  2011-12-21 
12:57:58 UTC ---
Created attachment 26160
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26160
patch comparing DECL_SOURCE_LOCATION

Fixed patch, also with hashing adjustments.

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Attachment #26158|0   |1
is obsolete||

--- Comment #15 from Richard Guenther  2011-12-21 
12:58:54 UTC ---
Created attachment 26161
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26161
patch speeding up uniquify_nodes

Patch to speedup uniquify_nodes

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther  2011-12-21 
13:00:37 UTC ---
Created attachment 26162
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26162
patch for this bug

And finally the patch for this particular bug, to be applied ontop of the
previous two.

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[markus at trippelsdorf dot de]

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

--- Comment #17 from Markus Trippelsdorf  
2011-12-21 13:47:16 UTC ---
It's a little bit faster now. But it still takes 9 CPU-minutes
to output all ltrans files. And then the following happens:

At top level:
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [/tmp/ccQIIdf5.ltrans7.ltrans.o] Error 1
make[6]: *** Waiting for unfinished jobs
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [/tmp/ccQIIdf5.ltrans8.ltrans.o] Error 1
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [/tmp/ccQIIdf5.ltrans10.ltrans.o] Error 1

:-(

During the 9 minutes the following happens:

+  27.72%lto1-wpa  lto1   [.] htab_expand
+  12.88%lto1-wpa  lto1   [.] lto_read_decls
+  12.04%lto1-wpa  lto1   [.] linemap_lookup
+   8.31%lto1-wpa  lto1   [.]
htab_find_slot_with_hash 
+   6.71%lto1-wpa  lto1   [.]
iterative_hash_hashval_t
+   6.51%lto1-wpa  lto1   [.] gimple_type_eq
+   3.74%lto1-wpa  lto1   [.] gimple_type_hash
+   2.60%lto1-wpa  libc-2.14.90.so[.] _int_malloc
+   2.01%lto1-wpa  libc-2.14.90.so[.] memset
+   1.46%lto1-wpa  lto1   [.] gtc_visit
+   1.23%lto1-wpa  lto1   [.]
lookup_type_pair.isra.108
+   1.11%lto1-wpa  libc-2.14.90.so[.] _int_free
+   1.04% swapper  [kernel.kallsyms]  [k] default_idle

Zoom into htab_expand:

 :static inline hashval_t
 :htab_mod_m2 (hashval_t hash, htab_t htab)
 :{
 :  const struct prime_ent *p =
&prime_tab[htab->size_prime_index];
 :  return 1 + htab_mod_1 (hash, p->prime - 2, p->inv_m2,
p->shift);
0.00 :  b6e9a4:   sub%eax,%r9d
0.00 :  b6e9a7:   jmpb6e9ba 
0.00 :  b6e9a9:   nopl   0x0(%rax)
 :index -= size;
 :
 :  slot = htab->entries + index;
 :  if (*slot == HTAB_EMPTY_ENTRY)
 :return slot;
 :  else if (*slot == HTAB_DELETED_ENTRY)
5.04 :  b6e9b0:   cmp$0x1,%rax
6.16 :  b6e9b4:   je b6ea8b 
 :abort ();
 :
 :  hash2 = htab_mod_m2 (hash, htab);
 :  for (;;)
 :{
 :  index += hash2;
0.00 :  b6e9ba:   add%r9d,%edx
 :  if (index >= size)
   15.48 :  b6e9bd:   mov%edx,%eax
   22.35 :  b6e9bf:   cmp%rax,%rsi
0.00 :  b6e9c2:   ja b6e9c8 
 :index -= size;
0.63 :  b6e9c4:   sub%esi,%edx
   12.78 :  b6e9c6:   mov%edx,%eax
 :
 :  slot = htab->entries + index;
0.70 :  b6e9c8:   lea(%r10,%rax,8),%r8
 :  if (*slot == HTAB_EMPTY_ENTRY)
   12.99 :  b6e9cc:   mov(%r8),%rax
0.63 :  b6e9cf:   test   %rax,%rax
1.96 :  b6e9d2:   jneb6e9b0 
 :  PTR *q = find_empty_slot_for_expand (htab,
(*htab->hash_f) (x));
 :
 :  *q = x;
 :}
 :
 :  p++;
0.00 :  b6e9d4:   add$0x8,%r13
 :
 :  if (x != HTAB_EMPTY_ENTRY && x != HTAB_DELETED_ENTRY)
 :{
 :  PTR *q = find_empty_slot_for_expand (htab,
(*htab->hash_f) (x));
 :
 :  *q = x;
9.74 :  b6e9d8:   mov%r14,(%r8)
 :}
 :
 :  p++;
 :

[Bug middle-end/51291] ICE: SIGSEGV in ix86_init_builtins (i386.c:27691) with -fgnu-tm and any fortran code

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  2011-12-21 
14:00:36 UTC ---
fixed

[Bug middle-end/51273] ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  2011-12-21 
14:02:24 UTC ---
fixed

[Bug middle-end/51291] ICE: SIGSEGV in ix86_init_builtins (i386.c:27691) with -fgnu-tm and any fortran code

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Aldy Hernandez  2011-12-21 
14:03:25 UTC ---
now fixed and closed for real :)

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  
2011-12-21 14:05:42 UTC ---
On Wed, 21 Dec 2011, markus at trippelsdorf dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> 
> --- Comment #17 from Markus Trippelsdorf  
> 2011-12-21 13:47:16 UTC ---
> It's a little bit faster now. But it still takes 9 CPU-minutes
> to output all ltrans files. And then the following happens:
> 
> At top level:
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans7.ltrans.o] Error 1
> make[6]: *** Waiting for unfinished jobs
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans8.ltrans.o] Error 1
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans10.ltrans.o] Error 1
> 
> :-(

*sigh*

> During the 9 minutes the following happens:
> 
> +  27.72%lto1-wpa  lto1   [.] htab_expand
> +  12.88%lto1-wpa  lto1   [.] lto_read_decls
> +  12.04%lto1-wpa  lto1   [.] linemap_lookup
> +   8.31%lto1-wpa  lto1   [.]
> htab_find_slot_with_hash 
> +   6.71%lto1-wpa  lto1   [.]
> iterative_hash_hashval_t
> +   6.51%lto1-wpa  lto1   [.] gimple_type_eq
> +   3.74%lto1-wpa  lto1   [.] gimple_type_hash
> +   2.60%lto1-wpa  libc-2.14.90.so[.] _int_malloc
> +   2.01%lto1-wpa  libc-2.14.90.so[.] memset
> +   1.46%lto1-wpa  lto1   [.] gtc_visit
> +   1.23%lto1-wpa  lto1   [.]
> lookup_type_pair.isra.108
> +   1.11%lto1-wpa  libc-2.14.90.so[.] _int_free
> +   1.04% swapper  [kernel.kallsyms]  [k] default_idle
> 
> Zoom into htab_expand:
> 
>  :static inline hashval_t
>  :htab_mod_m2 (hashval_t hash, htab_t htab)
>  :{
>  :  const struct prime_ent *p =
> &prime_tab[htab->size_prime_index];
>  :  return 1 + htab_mod_1 (hash, p->prime - 2, p->inv_m2,
> p->shift);
> 0.00 :  b6e9a4:   sub%eax,%r9d
> 0.00 :  b6e9a7:   jmpb6e9ba 
> 0.00 :  b6e9a9:   nopl   0x0(%rax)
>  :index -= size;
>  :
>  :  slot = htab->entries + index;
>  :  if (*slot == HTAB_EMPTY_ENTRY)
>  :return slot;
>  :  else if (*slot == HTAB_DELETED_ENTRY)
> 5.04 :  b6e9b0:   cmp$0x1,%rax
> 6.16 :  b6e9b4:   je b6ea8b 
>  :abort ();
>  :
>  :  hash2 = htab_mod_m2 (hash, htab);
>  :  for (;;)
>  :{
>  :  index += hash2;
> 0.00 :  b6e9ba:   add%r9d,%edx
>  :  if (index >= size)
>15.48 :  b6e9bd:   mov%edx,%eax
>22.35 :  b6e9bf:   cmp%rax,%rsi
> 0.00 :  b6e9c2:   ja b6e9c8 
>  :index -= size;
> 0.63 :  b6e9c4:   sub%esi,%edx
>12.78 :  b6e9c6:   mov%edx,%eax
>  :
>  :  slot = htab->entries + index;
> 0.70 :  b6e9c8:   lea(%r10,%rax,8),%r8
>  :  if (*slot == HTAB_EMPTY_ENTRY)
>12.99 :  b6e9cc:   mov(%r8),%rax
> 0.63 :  b6e9cf:   test   %rax,%rax
> 1.96 :  b6e9d2:   jneb6e9b0 
>  :  PTR *q = find_empty_slot_for_expand (htab,
> (*htab->hash_f) (x));
>  :
>  :  *q = x;
>  :}
>  :
>  :  p++;
> 0.00 :  b6e9d4:   add$0x8,%r13
>  :
>  :  if (x != HTAB_EMPTY_ENTRY && x != HTAB_DELETED_ENTRY)
>  :{
>  :  PTR *q = find_empty_slot_for_expand (htab,
> (*htab->hash_f) (x));
>  :
>  :  *q = x;
> 9.74 :  b6e9d8:   mov%r14,(%r8)
>  :}
>  :
>  :  p++;
>  :

I can imagine this being triggered by the

@@ -845,6 +855,14 @@ uniquify_nodes 

[Bug other/51174] AIX unexpected error_mark node in new TM tests

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Aldy Hernandez  2011-12-21 
14:07:40 UTC ---
fixed on trunk

[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez  2011-12-21 
14:30:20 UTC ---
Author: aldyh
Date: Wed Dec 21 14:30:07 2011
New Revision: 182588

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182588
Log:
PR middle-end/51472
* trans-mem.c (tm_log_add): Use create_tmp_var_reg.


Added:
trunk/gcc/testsuite/gcc.dg/tm/pr51472.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/trans-mem.c

[Bug middle-end/51472] ICE: verify_gimple failed: invalid rhs for gimple memory store with -fgnu-tm --param tm-max-aggregate-size=32

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Aldy Hernandez  2011-12-21 
14:31:26 UTC ---
fixed

[Bug middle-end/51647] [4.7 Regression] Bogus "control reaches end of non-void function [-Wreturn-type]"

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-12-21 
14:51:34 UTC ---
Author: jakub
Date: Wed Dec 21 14:51:19 2011
New Revision: 182589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182589
Log:
PR middle-end/51644
PR middle-end/51647
* tree-eh.c (decide_copy_try_finally): At -O0, return true
even when ndests is not 1, if there are only gimple_clobber_p
(or debug) stmts in the finally sequence.
* tree-inline.c (estimate_num_insns): Return 0 for gimple_clobber_p
stmts.

* gcc.dg/pr51644.c: New test.
* g++.dg/warn/Wreturn-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wreturn-4.C
trunk/gcc/testsuite/gcc.dg/pr51644.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-inline.c

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-12-21 
14:51:38 UTC ---
Author: jakub
Date: Wed Dec 21 14:51:19 2011
New Revision: 182589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182589
Log:
PR middle-end/51644
PR middle-end/51647
* tree-eh.c (decide_copy_try_finally): At -O0, return true
even when ndests is not 1, if there are only gimple_clobber_p
(or debug) stmts in the finally sequence.
* tree-inline.c (estimate_num_insns): Return 0 for gimple_clobber_p
stmts.

* gcc.dg/pr51644.c: New test.
* g++.dg/warn/Wreturn-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wreturn-4.C
trunk/gcc/testsuite/gcc.dg/pr51644.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-inline.c

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2011-12-21 
15:00:21 UTC ---
Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
LTO testcases is going to be disrupted by source line changes.  So for it
to be effective one would need to preserve #include directives and reduce
headers together with sources (ugh).

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther  2011-12-21 
15:06:35 UTC ---
(In reply to comment #19)
> Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> LTO testcases is going to be disrupted by source line changes.  So for it
> to be effective one would need to preserve #include directives and reduce
> headers together with sources (ugh).

Which means - can you check (on the original sources) whether just
using the patch comparing DECL_SOURCE_LOCATION fixes the bug
(yeah, and runs into the new bug...)

Btw, my fear of crossing SCCs should not really happen unless we have such
bogus merging like outlined in comment #11.

[Bug testsuite/51645] FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak  2011-12-21 15:10:48 
UTC ---
(In reply to comment #0)

> FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for excess errors)
> 
> Needs:
> 
> /* { dg-skip-if "No stabs" { mmix-*-* *-*-aix* alpha*-*-* hppa*64*-*-* 
> ia64-*-*
> *-*-vxworks* } { "*" } { "" } } */
> 
> as in gcc.dg/20040813-1.c.

I'd say that this change certainly qualifies as obvious.

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-12-21 
15:18:57 UTC ---
Created attachment 26163
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26163
gcc.i

/some/path/gcc/cc1 -fpreprocessed -quiet -quiet -dumpbase gcc.c -mtune=generic
-march=x86-64 -g -O2 -fexceptions -fstack-protector -fprofile-use --param
ssp-buffer-size=4 /tmp/gcc.i -o /tmp/gcc.s
reproduces this with the attached gcc.i and gcc.gcda.  Of course the problem
might be already at the -fprofile-generate phase or at runtime when generating
the gcc.gcda file.

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-12-21 
15:20:05 UTC ---
Created attachment 26164
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26164
gcc.gcda

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

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-12-21 
15:23:57 UTC ---
BTW, it can be also reproduced without that -j8 make option, i.e. it is not any
kind of race condition or similar.

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-12-21 
15:31:54 UTC ---
Fixed.

[Bug middle-end/51644] [4.7 Regression] va_list vs. warning: ‘noreturn’ function does return is not fixable

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-12-21 
15:32:11 UTC ---
*** Bug 51647 has been marked as a duplicate of this bug. ***

[Bug middle-end/51647] [4.7 Regression] Bogus "control reaches end of non-void function [-Wreturn-type]"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2011-12-21 
15:32:10 UTC ---
Fixed.

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

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[markus at trippelsdorf dot de]

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

--- Comment #21 from Markus Trippelsdorf  
2011-12-21 15:47:01 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> > LTO testcases is going to be disrupted by source line changes.  So for it
> > to be effective one would need to preserve #include directives and reduce
> > headers together with sources (ugh).
> 
> Which means - can you check (on the original sources) whether just
> using the patch comparing DECL_SOURCE_LOCATION fixes the bug
> (yeah, and runs into the new bug...)


Yes, this patch alone fixes this bug. (and runs into the new one 
from Comment 17)

(3.5 minutes CPU-time, 5GB RAM used, 3.1GB ltrans files written out)

BTW a quick debugging question:
Is it possible to tell lto1 to use partitions even when called 
directly in a delta check script? (I have only 8GB of RAM  
and calling lto1 directly uses ~15GB. (I've used a big swapfile
on my SSD when reduceing this bug))

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  
2011-12-21 15:51:16 UTC ---
On Wed, 21 Dec 2011, markus at trippelsdorf dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> 
> --- Comment #21 from Markus Trippelsdorf  
> 2011-12-21 15:47:01 UTC ---
> (In reply to comment #20)
> > (In reply to comment #19)
> > > Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> > > LTO testcases is going to be disrupted by source line changes.  So for it
> > > to be effective one would need to preserve #include directives and reduce
> > > headers together with sources (ugh).
> > 
> > Which means - can you check (on the original sources) whether just
> > using the patch comparing DECL_SOURCE_LOCATION fixes the bug
> > (yeah, and runs into the new bug...)
> 
> 
> Yes, this patch alone fixes this bug. (and runs into the new one 
> from Comment 17)

Thanks.  New testcase appreciated ;)

> (3.5 minutes CPU-time, 5GB RAM used, 3.1GB ltrans files written out)
> 
> BTW a quick debugging question:
> Is it possible to tell lto1 to use partitions even when called 
> directly in a delta check script? (I have only 8GB of RAM  
> and calling lto1 directly uses ~15GB. (I've used a big swapfile
> on my SSD when reduceing this bug))

Hmm, I always use the xgcc or g++ drivers for reducing LTO bugs.
To use partitions more "manually" you'd have to invoke lto-wrapper
(or emulate what it does).

Richard.

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Guenther  2011-12-21 
16:01:30 UTC ---
Another fun (well ...) patch that is worth trying is

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 182590)
+++ gcc/gimple.c(working copy)
@@ -4488,16 +4488,7 @@ gimple_register_type_1 (tree t, bool reg
 tree
 gimple_register_type (tree t)
 {
-  gcc_assert (TYPE_P (t));
-
-  if (!gimple_type_leader)
-gimple_type_leader = ggc_alloc_cleared_vec_gimple_type_leader_entry_s
-   (GIMPLE_TYPE_LEADER_SIZE);
-
-  if (gimple_types == NULL)
-gimple_types = htab_create_ggc (16381, gimple_type_hash, gimple_type_eq,
0);
-
-  return gimple_register_type_1 (t, false);
+  return t;
 }

 /* The TYPE_CANONICAL merging machinery.  It should closely resemble

where you need to configure with --disable-werror (because of now unused
functions in gimple.c).  The above will simply disable all type merging
and thus may in theory increase memory usage a lot (I think so more for
ltrans stage than wpa stage, it also may increase ltrans file size a lot).
It also probably increases the size of the emitted debug information.

[Bug c++/51630] failure to detect missing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|CLOSED  |RESOLVED
 Resolution|WONTFIX |INVALID

--- Comment #8 from Jonathan Wakely  2011-12-21 
16:08:15 UTC ---
(Setting status back to RESOLVED+INVALID, we don't use CLOSED in GCC's
bugzilla, and WONTFIX is not appropriate because no G++ dev has agreed there is
a bug here and said it won't be fixed.)

(In reply to comment #0)
> 
> template
> const T & max(const T & x, const T & y){
> return (x < y) ? y : x;
> }

This template has valid syntax. It follows the rules of the C++ grammar.
Whether it can be compiled depends on the template arguments.

> struct name {};
> 
> void test3(){
> name x, y, z;
> z = max(x, y); // error name doesn't have < operator

That function call also has valid syntax. It follows the rules of the C++
grammar.

> This looks like a bug to me.  For what it's worth, this second example fails 
> to
> compile with MSVC 9.0 pointing to an error for lack of operator < as one would
> expect.

It fails to *compile* with G++ too, but using -fsyntax-only doesn't do
compilation.



(In reply to comment #7)
> what I expected was that -fsyntax-only would run the normal process but skip
> the code generation.  I don't think that's an unreasonable expectation from 
> the
> name of the option and the simple description of it.
> 
> Also I wouldn't characterize the program as not having any syntax errors.  The
> first example
> 
> name test2(){
> name x, y;
> return (x < y) ? y : x;
> }
> 
> generates an compile time error as one would expect.  If the same code were
> placed inside a macro, it would also provoke an error.  Then you move it into
> at template - and voila - no syntax error.

Templates are not just fancy macros, you know C++ well enough to know that.


>  This is not regular or intuitive
> behavior.  When you tested it you also expected to see an error - to the 
> extent
> you tried on several versions of gcc.

When I tested it I *did* see an error. I tested several versions because I was
trying to reproduce your reported lack of an error, because I missed you were
using -fsyntax-only


> If your asking me what I want, I would respond that the current behavior of 
> the
> -fsyntax-only is inconsistent and confusing and has room for improvement.  
> It's
> not much of an answer to say "don't do that".  Taken to it's logical
> conclusion, you might just skip emission of compile time errors all together
> and replace them with the admonition - don't write incorrect code !

That's not the logical conclusion, it's a strawman.  If a user complains that
omitting the -g flag causes there to be no debug symbols in their objects,
they've apparently misunderstood the purpose of the option and "don't do that"
is a reasonable answer.

[Bug c++/51630] failure to detect missing

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-12-21 
16:14:39 UTC ---
Feel free to open an enhancement request in bugzilla for -fsyntax-only to
instantiate templates, or for a new option that does so

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-12-21 
16:20:15 UTC ---
It might be better to provide a separate python/libstdcxx/v7/printers.py file
and install that when configured with versioned namespaces.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-12-21 16:20:12 UTC ---
With the exception of the unrelated Ada bootstrap failure (PR
ada/51624), your patch allowed a mips-sgi-irix6.5 bootstrap to succeed
(for the first time in almost 3 months :-).  AFAICS, there are no
unexpected testsuite failures, so from an IRIX perspective the patch is
good to go.

Thanks a lot.

Rainer

[Bug middle-end/51212] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |aldyh at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Aldy Hernandez  2011-12-21 
16:28:12 UTC ---
The problem here is that with -fnon-call-exceptions, the load from *p may trap,
but when we instrument the store, we have lost the landing pad information.

We can save and attach the exception information to the instrumented load
(_ITM_RU*), but currently all the TM load/store builtins are marked as
no-throw.  Perhaps we can get rid of the no-throw bit when
-fnon-call-exceptions is enabled.

Maybe something like this:

1. Get rid of the NOTHROW bits from the TM load/store builtins.
2. Attach the EH information to the TM load/store calls.
3. Split the BB accordingly when the TM load/store calls are not the last in
the BB (because we have added a cast after the instrumentation).

How does this sound Richard?

[Bug c++/51305] [C++11][constexpr] noexcept-specifier overconstraints constexpr functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2011-12-21 
16:29:20 UTC ---
Fixed.

[Bug c++/51305] [C++11][constexpr] noexcept-specifier overconstraints constexpr functions

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-12-21 16:28:19 UTC ---
Author: paolo
Date: Wed Dec 21 16:28:08 2011
New Revision: 182594

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182594
Log:
/cp
2011-12-21  Paolo Carlini  

PR c++/51305
* semantics.c (massage_constexpr_body): Reorder conditionals, make
sure a BIND_EXPR embedded in a MUST_NOT_THROW_EXPR is handled.

/testsuite
2011-12-21  Paolo Carlini  

PR c++/51305
* g++.dg/cpp0x/constexpr-noexcept6.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/48660] [4.5/4.6/4.7 Regression] ARM ICE in expand_expr_real_1

[rsandifo at gcc dot gnu.org]

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

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

   What|Removed |Added

  Known to work||4.7.0
  Known to fail|4.7.0   |

--- Comment #7 from rsandifo at gcc dot gnu.org  
2011-12-21 16:36:37 UTC ---
Fixed on trunk.  I'll ask about backporting.

[Bug middle-end/48660] [4.5/4.6/4.7 Regression] ARM ICE in expand_expr_real_1

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
2011-12-21 16:34:49 UTC ---
Author: rsandifo
Date: Wed Dec 21 16:34:41 2011
New Revision: 182595

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182595
Log:
Add reference to PR middle-end/48660

Modified:
trunk/gcc/ChangeLog

[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #24 from Michael Matz  2011-12-21 16:39:32 
UTC ---
(just FYI: my later LTO patches do merge some decls, amongst them TYPE_DECLs)

[Bug target/43052] [4.7 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

[fabio.ped at libero dot it]

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

Fabio  changed:

   What|Removed |Added

 CC||fabio.ped at libero dot it

--- Comment #19 from Fabio  2011-12-21 16:35:41 UTC 
---
Just FYI: mesa is now defaulting to -fno-builtin-memcmp to workaround this
problem:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=983fa4ad523535debf2e94cf6ac1fd4c5630c0d2
http://cgit.freedesktop.org/mesa/mesa/commit/?id=1448bdf1c0995e3ac2e0f97c51e5e2d73eded8e0

[Bug middle-end/51212] ICE: verify_flow_info failed: BB 3 can not throw but has an EH edge with -fgnu-tm -fnon-call-exceptions and transaction_callable

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  2011-12-21 
17:18:11 UTC ---
As far as the compiler goes that all sounds plausible.

The main problem is that we would have to make libitm exception safe.
I'm 100% sure that won't work at the moment.  I'm also sure that it
would be exceedingly awkward to take an exception in the middle of
the actual transaction.

Unless Torvald has a brilliant idea there, I'm inclined to simply
emit a sorry for combining -fgnu-tm and -fnon-call-exceptions.

Unless we redefine that combination such that we only support the
exception case for NULL, but non-null faulting memory references
just crash.  In that case we can simply test for NULL at the start
of the accessors and explicitly throw the exception.

[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225

[uros at gcc dot gnu.org]

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

--- Comment #26 from uros at gcc dot gnu.org 2011-12-21 17:23:44 UTC ---
Author: uros
Date: Wed Dec 21 17:23:33 2011
New Revision: 182597

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182597
Log:
Backport from mainline
2011-12-21  Richard Guenther  

PR lto/41159
* tree-outof-ssa.c (insert_value_copy_on_edge): Use the
mode of the pseudo as destination mode.  Only assert that
is equal to the promoted mode of the decl if it is a REG.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/tree-outof-ssa.c

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  2011-12-21 
17:26:36 UTC ---
Tom, I assume the plan for the libstdc++ python printers is to have a
python/libstdcxx/v7/printers.py for the libstdc++.so.7 library, right?

As we have that version today when using versioned namespaces (see PR 48698) do
you think we should have that v7 file today?  Or while the only difference
between v6 and v7 is the nested inline namespace do you think just adding
(__7::)? to the regexes for the v6 printers is better (at least for now)?

[Bug target/51552] bfin generates bad assembly

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #3 from Richard Henderson  2011-12-21 
17:51:30 UTC ---
Well, honestly the largest problem is that the bfin backend is
emitting bundles in a way that can't be split, but in separate insns.

The ia64 backend handles this case by supporting "debug labels"
in the assembler, which are understood not to break the bundle.

As far as the middle-end is concerned, it's doing absolutely nothing
wrong. I'll see what I can do to restore the kinda-sorta working state
that we had before, but you really ought to fix the backend to not
lie to the middle-end.

Consider implementing debug labels in the assembler.  Or failing
that, pack your insn bundles into sequences, or something.

[Bug target/51552] bfin generates bad assembly

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Henderson  2011-12-21 
18:12:39 UTC ---
Mine.  The only thing I'll concede is that this is a debug size
regression from 4.6, as there's an unnecessary advance between
the two cfi opcodes.

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

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-12-21 
18:15:23 UTC ---
Ok, so when the -fprofile-generate compiled xgcc is linked, it is enough
to (assuming gcc.i from the attachment here is in /tmp/):
$ rm gcc.gcda; ./xgcc -qversion
$ cp -a gcc.gcda /tmp/
$ cd /tmp
$ /usr/src/gcc/obj8/gcc/cc1 -fpreprocessed -quiet -quiet -dumpbase gcc.c \
-mtune=generic -march=x86-64 -g -O2 -fexceptions -fstack-protector
-fprofile-use \
--param ssp-buffer-size=4 /tmp/gcc.i -o /tmp/gcc.s
../../gcc/gcc.c: In function ‘main’:
../../gcc/gcc.c:8278:1: error: corrupted profile info: profile data is not
flow-consistent
../../gcc/gcc.c:8278:1: error: corrupted profile info: number of executions for
edge 262-263 thought to be -1
../../gcc/gcc.c:8278:1: error: corrupted profile info: number of executions for
edge 262-1 thought to be 1

[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-12/msg01504.htm
   ||l
  Known to work|4.7.0   |
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #27 from Uros Bizjak  2011-12-21 18:28:38 
UTC ---
Fixed everywhere.

[Bug c++/51216] [4.6 Regression] ICE with statement expression

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  2011-12-21 
18:29:44 UTC ---
Fixed for 4.7.0.

[Bug libstdc++/51649] pretty printers don't handle std::__7:: namespace

[tromey at gcc dot gnu.org]

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

--- Comment #4 from Tom Tromey  2011-12-21 18:34:47 
UTC ---
(In reply to comment #3)
> Tom, I assume the plan for the libstdc++ python printers is to have a
> python/libstdcxx/v7/printers.py for the libstdc++.so.7 library, right?
> 
> As we have that version today when using versioned namespaces (see PR 48698) 
> do
> you think we should have that v7 file today?  Or while the only difference
> between v6 and v7 is the nested inline namespace do you think just adding
> (__7::)? to the regexes for the v6 printers is better (at least for now)?

I didn't know about --enable-symvers=gnu.

The reason I put things into a v6 namespace is just to give us options
for the future.  If a v7 libstdc++ is different enough to need different
printers, this approach would let us do that -- while also letting us
have gdb sessions where different inferiors use different versions of
libstdc++.

The two sets of printers can still share code.  For example, we could move
most of the code to libstdcxx/printers.py and have the v6 and v7 variants
import that.

I am not sure what the best approach is for the current situation.
What is the purpose of --enable-symvers=gnu?  How different is the v7 library?
Are there other possible configurations (configure- or user-compile-time)
that affect printers that we haven't already accounted for?

[Bug libstdc++/51626] [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-12-21 
18:35:48 UTC ---
Author: redi
Date: Wed Dec 21 18:35:40 2011
New Revision: 182600

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182600
Log:
PR libstdc++/51626
* include/bits/stl_uninitialized.h (_Construct_default_a_impl): Define
overloaded functions to conditionally use allocator::construct.
(_Construct_default_a): Define to dispatch to appropriate
_Construct_default_a_impl overload.
(__uninitialized_default_a, __uninitialized_default_n_a): Use
_Construct_default_a.
* testsuite/20_util/allocator/51626.cc: New.

Added:
branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/allocator/51626.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_uninitialized.h

[Bug libstdc++/51626] [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jonathan Wakely  2011-12-21 
18:37:23 UTC ---
fixed for 4.6.3

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-12-21 
19:01:22 UTC ---
So, shorter/faster reproducer, using a snapshot from ~ today (tried with
r182599)
on x86_64-linux:
../configure --enable-languages=c --disable-bootstrap \
  --disable-libitm
make -j8
cd gcc
./cc1 -fpreprocessed -quiet -quiet -dumpbase gcc.c \
  -g -O2 -fexceptions -fprofile-generate /tmp/gcc.i -o /tmp/gcc.s
gcc -c -o gcc.o /tmp/gcc.s
gcc   -g -pedantic -fno-common -o xgccmy gccmy.o ggc-none.o \
  gccspec.o driver-i386.o libcommon-target.a libcommon.a \
  ../libcpp/libcpp.a   ../libiberty/libiberty.a \
  ../libdecnumber/libdecnumber.a libgcov.a
rm -f gcc.gcda
./xgccmy -qversion
./cc1 -fpreprocessed -quiet -quiet -dumpbase gcc.c \
  -g -O2 -fexceptions -fprofile-use /tmp/gcc.i -o /tmp/gcc.s

The steps before cd gcc could be left out if you have the tree built with other
options already, all it matters is if more-less similar *.o/*.a listed on the
command line are built, including libgcov.a.  /tmp/gcc.i contains the copy of
the first attachment here.

[Bug c++/51611] [c++0x] ICE with non-static data member initializer and virtual base class

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-12-21 
19:19:52 UTC ---
Author: jason
Date: Wed Dec 21 19:19:47 2011
New Revision: 182602

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182602
Log:
PR c++/51611
* cp-tree.h (CONVERT_EXPR_VBASE_PATH): New.
* class.c (build_base_path): Defer vbase conversion in an NSDMI.
* tree.c (bot_replace): Expand it here.
* cp-gimplify.c (cp_genericize_r): Make sure deferred conversion
doesn't leak into GENERIC.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-virtual1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51611] [c++0x] ICE with non-static data member initializer and virtual base class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  2011-12-21 
19:20:30 UTC ---
Fixed.

[Bug target/51552] bfin generates bad assembly

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  2011-12-21 
20:21:14 UTC ---
Author: rth
Date: Wed Dec 21 20:21:00 2011
New Revision: 182604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182604
Log:
PR target/51552
* dwarf2cfi.c (dwarf2out_frame_debug): Move any_cfis_emitted code...
(scan_trace): ... here.

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

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

[markus at trippelsdorf dot de]

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

 Bug #: 51650
   Summary: [4.7 regression] ICE in dwarf2out_finish, at
dwarf2out.c:22501 while building libxul
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


After applying the patch that fixes Bug 51635 I've hit new bug
while building Firefox's libxul.

 % cat test.ii
extern "C" typedef int PRUint32;
typedef PRUint32 nsresult;
class nsQueryFrame
{
};
extern "C" struct PLDHashEntryHdr
{
};

template < class > class nsPtrHashKey:PLDHashEntryHdr
{
};

class nsIFrame;
namespace mozilla
{
  struct FramePropertyDescriptor
  {
  };
  class FramePropertyTable
  {
  public:FramePropertyTable ():mLastFrame (), mLastEntry ()
{
}
void *Get (nsIFrame *, FramePropertyDescriptor *, bool *);
class Entry:nsPtrHashKey < nsIFrame >
{
};
nsIFrame *mLastFrame;
Entry *mLastEntry;
  };
  class FrameProperties
  {
  public:FrameProperties ():mTable (), mFrame ()
{
}
void *Get (FramePropertyDescriptor * aProperty)
{
  mTable->Get (0, aProperty, 0);
}
FramePropertyTable *mTable;
nsIFrame *mFrame;
  };
}

extern "C" class nsIFrame:nsQueryFrame
{
public:typedef mozilla::FramePropertyDescriptor FramePropertyDescriptor;
  typedef mozilla::FrameProperties FrameProperties;
  FrameProperties Properties ()
  {
  }
  static FramePropertyDescriptor *EmbeddingLevelProperty ()
  {
static FramePropertyDescriptor descriptor;

return &descriptor;
  }
};
nsresult
nsCaretGetCaretFrameForNodeOffset ()
{
  nsIFrame *theFrame;

  theFrame->Properties ().Get (nsIFrame::EmbeddingLevelProperty ());
}

 % g++ -flto -g -w test.ii
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
Please submit a full bug report,
with preprocessed source if appropriate.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, lto
  Component|lto |debug
   Target Milestone|--- |4.7.0
Summary|[4.7 regression] ICE in |[4.7 regression] LTO ICE in
   |dwarf2out_finish, at|dwarf2out_finish, at
   |dwarf2out.c:22501 while |dwarf2out.c:22501 while
   |building libxul |building libxul

[Bug target/51552] bfin generates bad assembly

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Henderson  2011-12-21 
20:35:52 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01577.html

[Bug lto/51642] Weak variable reference triggers ICE with -flto option

[sipych at gmail dot com]

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

Alexander Osipenko  changed:

   What|Removed |Added

  Known to work||4.7.0

--- Comment #2 from Alexander Osipenko  2011-12-21 
20:44:35 UTC ---
No ICE in the recent snapshot:

svn://gcc.gnu.org/svn/gcc/trunk
Revision: 182598

$ /opt/arm/gnuarm-4.7.0/bin/arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gnuarm-4.7.0/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.7.0/libexec/gcc/arm-eabi/4.7.0/lto-wrapper
Target: arm-eabi
Configured with: ../../src/gcc-4.7.0/configure --target=arm-eabi
--prefix=/opt/arm/gnuarm-4.7.0 --enable-multilib --enable-interwork
--enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as
--disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp
--with-float=softfp --with-abi=aapcs-linux --enable-lto
--enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog
--enable-gmp --enable-mpfr --enable-lto
-with-headers=/opt/arm/gnuarm-4.7.0/arm-eabi/include
Thread model: single
gcc version 4.7.0 20111221 (experimental) (GCC)

[Bug tree-optimization/40711] verify_ssa failed with -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Andrew Pinski  2011-12-21 
20:49:23 UTC ---
Yes this is a dup of bug 40676 and has been fixed for a while now.

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

[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #12 from Andrew Pinski  2011-12-21 
20:49:23 UTC ---
*** Bug 40711 has been marked as a duplicate of this bug. ***

[Bug middle-end/39852] GCC 4.4.0 builds a broken glibc 2.8

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #9 from Andrew Pinski  2011-12-21 
21:18:38 UTC ---
Not a gcc bug so closing as such.

[Bug target/40782] Code works with optimization disabled.. but not with 02 for when used as cross compiler for ARM 11 MP

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-12-21 
23:47:49 UTC ---
NO feedback in over two years.

[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||denisc at gcc dot gnu.org

--- Comment #18 from Georg-Johann Lay  2011-12-22 
00:03:08 UTC ---
>From what you wrote the internals documentation need to be fixed, i.e. there
should be a disclaimer in expand_prologue documentation that SP=FP is an
illegal configuration that breaks GCC.

Moreover there is:

> FIND_BASE_TERM (x): It is always safe for this macro to not be defined.

Which is obviously wrong.

I don't know enough of alias internals,  but I get more and more the impression
that implementing FIND_BASE_TERM is just working around problem in generic code
and instead of backend hacking around it the generic code should be made
robust.

At the moment I tend to deactivate malicous pass(es) in the backend until they
use robust approach and don't value performance higher than correctness.

[Bug libstdc++/51651] New: istream::ignore returns eof too early

[claytongdavis at gmail dot com]

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

 Bug #: 51651
   Summary: istream::ignore returns eof too early
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: claytongda...@gmail.com


Created attachment 26165
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26165
Test program displaying the bug.  Output should be false for both methods of
reading the stream.

This bug was initially reported on the stack overflow forum.  Since it seems
never to have been reported, I am doing so now.

When istream::ignore is used to ignore the last character of a stream, it sets
the eof flag as though it had read past the end of the file.  Thus,
istream::read and istream::ignore show different behavior.

[Bug target/20102] Incorrect floating point code generated when assigning to "packed" structure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #9 from Andrew Pinski  2011-12-22 
00:45:57 UTC ---
AS mentioned, GCC for powerpc defaults to non-strict alignment which means you
need to supply -mstrict-align to get the strict alignment requirements.

[Bug libstdc++/42857] std::istream::ignore(std::streamsize n) calls unnecessary underflow

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||claytongdavis at gmail dot
   ||com

--- Comment #3 from Paolo Carlini  2011-12-22 
00:55:04 UTC ---
*** Bug 51651 has been marked as a duplicate of this bug. ***

[Bug libstdc++/51651] istream::ignore returns eof too early

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||DUPLICATE
   Severity|major   |normal

--- Comment #1 from Paolo Carlini  2011-12-22 
00:55:04 UTC ---
.

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

[Bug middle-end/24539] inconsistent handling of null-valued language hooks in GCC

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.5.0

--- Comment #5 from Andrew Pinski  2011-12-22 
01:13:10 UTC ---
2007-09-12  Jan Hubicka  

* c-objc-common.h (LANG_HOOKS_CALLGRAPH_EXPAND_FUNCTION): Kill.
2007-09-11  Jan Hubicka 

* toplev.c (process_options): all frontends now do unit-at-a-time.
* cgraphunit.c: update comments.
(cgraph_expand_function): call passmanager dirrectly; emit thunks.
* c-decl.c (finish_function): use cgraph_add_new_function.
* function.c (expand_function_end): We are always unit-at-a-time.

[Bug c/51085] "volatile const" structures (in C) go in the .data section, not .rodata as expected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2011-12-22 
01:15:48 UTC ---
Dup of an older bug.

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