[Bug libstdc++/54185] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-06
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-08-06 
07:41:14 UTC ---
please provide a proper testcase, not snippets of code

[Bug c++/54170] Call to lambda elided

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jason at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  2012-08-06 
07:51:48 UTC ---
hmm, it still fails on trunk.

Jason, the fix for PR 52988 seems to be incomplete.

[Bug libstdc++/53901] [C++11] [DR 2165] std::atomic fails for type without no-throw default constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2012-08-06
Summary|[C++11] std::atomic  |[C++11] [DR 2165]
   |fails for type without  |std::atomic fails for
   |no-throw default|type without no-throw
   |constructor |default constructor
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-08-06 
07:55:13 UTC ---
http://cplusplus.github.com/LWG/lwg-active.html#2165

[Bug libstdc++/54186] New: PowerPC: Double free, same malloc address for two pointers after free

[poyo_vl at yahoo dot com]

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

 Bug #: 54186
   Summary: PowerPC: Double free, same malloc address for two
pointers after free
Classification: Unclassified
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: poyo...@yahoo.com


Hi,

This is first bug I post here, I'm not sure if it is a bug or not, but this is
how it looks like.

GCC version: gcc-4.2.187-eglibc-2.5.187

I compile something for PowerPC (32) and I have a class with:
- a constructor where there are 2 pointer malloc() allocations
- possible realloc() during class ussage
- a destructor where there are 2 free() for that pointers

During program execution I receive SIGSEGV (strace):

*** glibc detected *** /path/my_tool: double free or corruption (!prev):
0x100f6130 ***

[pid 24045] tgkill(23758, 24045, SIGABRT) = 0
[pid 24045] --- SIGABRT (Aborted) @ 0 (0) ---
[pid 24045] --- SIGSEGV (Segmentation fault) @ 0 (0) ---

Also, something strange, the process is not terminated, it looks like it is
locked in a futex. I killed it with SIGKILL.

[pid 23758] futex(0xf9b5ae8, FUTEX_WAIT, 2, NULL) = ? ERESTARTSYS (To be
restarted)
[pid 23758] --- SIGTERM (Terminated) @ 0 (0) ---
[pid 23758] futex(0xf9b5060, FUTEX_WAIT, 2, NULL 
[pid 24045] +++ killed by SIGKILL +++
PANIC: handle_group_exit: 24045 leader 23758
+++ killed by SIGKILL +++

Following the backtrace, it looks like the problem is a double free in my
destructor. 

The example of the problem:

Creating a object, I get for my pointers:
- pointer 1: 0x100ee780
- pointer 2: 0x100f0228

And for this object, the destructor works ok.

However, creating a NEW object, I get SAME VALUES for newly malloc()ated
pointers (but I think "reversed"):
- pointer 1: 0x100f0228
- pointer 2: 0x100ee780

The 0x100ee780 pointer gets "relloc"ated, but the result is the same address:
0x100ee780

And in the destructor, when I try to free() those pointers I get the SIGSEGV...

Do you think this is a glibc problem? 

Also, this may be related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839

I hope I posted ok.

Thank you,
Ionut

[Bug c++/54170] Call to lambda elided

[bekenn at yopmail dot com]

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

--- Comment #8 from bekenn at yopmail dot com 2012-08-06 08:11:38 UTC ---
(In reply to comment #4)
> If submitter can try current 4_7-branch or mainline, it would be easy for him
> to double check.

I installed mint in a virtual machine to test those, but I couldn't get either
trunk or gcc-4_7 to build; I got these errors, which I haven't bothered to
investigate:

build/gengtype.o: In function `create_optional_field_':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:853: undefined
reference to `lexer_line'
build/gengtype.o: In function `adjust_field_rtx_def':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:989: undefined
reference to `lexer_line'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:1045:
undefined reference to `lexer_line'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:1055:
undefined reference to `lexer_line'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:1121:
undefined reference to `lexer_line'
build/gengtype.o:/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype.c:1160:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `token':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:53:
undefined reference to `yylex'
build/gengtype-parse.o: In function `parse_error':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:142:
undefined reference to `lexer_line'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:142:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `struct_field_seq':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:692:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `type':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:726:
undefined reference to `lexer_line'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:758:
undefined reference to `lexer_line'
build/gengtype-parse.o:/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:758:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `parse_file':
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:951:
undefined reference to `yybegin'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:986:
undefined reference to `lexer_toplevel_done'
/home/bekenn/Projects/gcc-build/gcc/../../gcc-4_7/gcc/gengtype-parse.c:991:
undefined reference to `yyend'
collect2: ld returned 1 exit status

[Bug lto/54187] New: liblto_plugin.so broken with -fvisibility=hidden

[wbrana at gmail dot com]

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

 Bug #: 54187
   Summary: liblto_plugin.so broken with -fvisibility=hidden
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wbr...@gmail.com


liblto_plugin.so is broken if BOOT_CFLAGS includes -fvisibility=hidden
build system should add -fvisibility=normal for building liblto_plugin.so to
fix it

[Bug ada/54125] [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on multiple platforms

[charlet at gcc dot gnu.org]

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

--- Comment #4 from Arnaud Charlet  2012-08-06 
08:12:18 UTC ---
Author: charlet
Date: Mon Aug  6 08:12:10 2012
New Revision: 190163

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190163
Log:
2012-08-06  Vincent Pucci  

PR ada/54125
* exp_attr.adb (Expand_N_Attribute_Reference): Expand new
Atomic_Always_Lock_Free attribute.
* sem_attr.adb (Analyze_Attribute): Analyze new
Atomic_Always_Lock_Free attribute.
(Eval_Attribute): Nothing to do with new Atomic_Always_Lock_Free
attribute.
* sem_ch9.adb (Allows_Lock_Free_Implementation):
Support_Atomic_Primitives check replaces previous erroneous
size check.
* sem_util.adb, sem_util.ads (Support_Atomic_Primitives):
New routine.
* snames.ads-tmpl: New name Name_Atomic_Always_Lock_Free and
new attribute Attribute_Atomic_Always_Lock_Free defined.
* s-atopri.adb: Support_Atomic_Primitives checks replaced by
Atomic_Always_Lock_Free queries.
* system-aix64.ads, system-aix.ads, system-darwin-ppc.ads,
system-hpux.ads, system-linux-alpha.ads, system-linux-hppa.ads,
system-linux-ppc.ads, system-linux-s390.ads,
system-linux-s390x.ads, system-linux-sh4.ads,
system-linux-sparc.ads, system-lynxos178-ppc.ads,
system-lynxos-ppc.ads, system-mingw.ads,
system-vxworks-arm.ads, system-solaris-sparc.ads,
system-solaris-sparcv9.ads, system-vms_64.ads,
system-vxworks-m68k.ads, system-vxworks-mips.ads,
system-vxworks-ppc.ads, system-vxworks-sparcv9.ads: Flag
Support_Atomic_Primitives removed.


Modified:
trunk/gcc/ada/exp_attr.adb
trunk/gcc/ada/s-atopri.adb
trunk/gcc/ada/sem_attr.adb
trunk/gcc/ada/sem_ch9.adb
trunk/gcc/ada/sem_util.adb
trunk/gcc/ada/sem_util.ads
trunk/gcc/ada/snames.ads-tmpl
trunk/gcc/ada/system-aix.ads
trunk/gcc/ada/system-aix64.ads
trunk/gcc/ada/system-darwin-ppc.ads
trunk/gcc/ada/system-hpux.ads
trunk/gcc/ada/system-linux-alpha.ads
trunk/gcc/ada/system-linux-hppa.ads
trunk/gcc/ada/system-linux-ppc.ads
trunk/gcc/ada/system-linux-s390.ads
trunk/gcc/ada/system-linux-s390x.ads
trunk/gcc/ada/system-linux-sh4.ads
trunk/gcc/ada/system-linux-sparc.ads
trunk/gcc/ada/system-lynxos-ppc.ads
trunk/gcc/ada/system-mingw.ads
trunk/gcc/ada/system-solaris-sparc.ads
trunk/gcc/ada/system-solaris-sparcv9.ads
trunk/gcc/ada/system-vms_64.ads
trunk/gcc/ada/system-vxworks-arm.ads
trunk/gcc/ada/system-vxworks-m68k.ads
trunk/gcc/ada/system-vxworks-mips.ads
trunk/gcc/ada/system-vxworks-ppc.ads
trunk/gcc/ada/system-vxworks-sparcv9.ads

[Bug ada/54125] [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on multiple platforms

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Arnaud Charlet  2012-08-06 
08:13:38 UTC ---
Should be fixed now.

[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2012-08-06 
08:31:02 UTC ---
What do you gain with -fvisibility-hidden?  Nothing, as for non-shared objects
it is already the default.  Not for GCC though because of our plugin API
(thus, --disable-plugins).

[Bug libstdc++/54186] PowerPC: Double free, same malloc address for two pointers after free

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||powerpc-*-linux
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-08-06
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-08-06 
08:31:58 UTC ---
GCC 4.2.x is no longer maintained, please try at least GCC 4.6.4 and reproduce
your issue.

[Bug c++/54170] Call to lambda elided

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2012-08-06 
08:32:28 UTC ---
I think those errors indicate you don't have Flex installed

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-06
  Component|middle-end  |testsuite
 CC||aldyh at gcc dot gnu.org
 Ever Confirmed|0   |1
   Target Milestone|--- |4.8.0

--- Comment #1 from Richard Guenther  2012-08-06 
08:33:38 UTC ---
As said in the commit mail, the testcase is "broken".  It scans for a random
string not in any way associated with what the testcase checks.  That random
string no longer appears - instead of just deleting the scan I've opted to
let the author of the patch figure a better way to check for a successful
testcase.

Confirmed anyway.

[Bug other/54182] enable -fvisibility=hidden

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Richard Guenther  2012-08-06 
08:35:25 UTC ---
>From your other PR I derive that you mean to include it in CFLAGS/BOOT_CFLAGS.
That's already effectively done if you disable plugins.

[Bug tree-optimization/53986] missing vrp on bit-mask test, LSHIFT_EXPR not handled

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org 2012-08-06 08:37:51 UTC ---
> This tentative patch fixes the problem. I'm currently testing it, let's see if
> I run into any trouble.

Committed in r190168.

[Bug c/54179] please split insn-emit.c !

[rguenth at gcc dot gnu.org]

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

--- Comment #28 from Richard Guenther  2012-08-06 
08:42:57 UTC ---
(In reply to comment #26)
> Well, when I read on the documentation page 
> 
> http://gcc.gnu.org/install/configure.html
> 
> 
> --enable-build-with-cxx
> Build GCC using a C++ compiler rather than a C compiler. This is an 
> experimental option which may become the default in a later release.
> 
> 
> --enable-bootstrap
> In special cases, you may want to perform a 3-stage build even if the
> target and host triplets are different. This is possible when the host can run
> code compiled for the target (e.g. host is i686-linux, target is i486-linux).
> Starting from GCC 4.2, to do this you have to configure explicitly with
> --enable-bootstrap.
> 
> 
> --enable-checking
> --enable-checking=list
> When you specify this option, the compiler is built to perform internal
> consistency checks of the requested complexity. This does not change the
> generated code, but adds error checking within the compiler. This will slow
> down the compiler and may only work properly if you are building the compiler
> with GCC. This is `yes' by default when building from SVN or snapshots, but
> `release' for releases. The default for building the stage1 compiler is `yes'.
> More control over the checks may be had by specifying list. The categories of
> checks available are `yes' (most common checks
> `assert,misc,tree,gc,rtlflag,runtime'), `no' (no checks at all), `all' (all 
> but
> `valgrind'), `release' (cheapest checks `assert,runtime') or `none' (same as
> `no'). Individual checks can be enabled with these flags `assert', `df',
> `fold', `gc', `gcac' `misc', `rtl', `rtlflag', `runtime', `tree', and
> `valgrind'.
> 
> The `valgrind' check requires the external valgrind simulator, available
> from http://valgrind.org/. The `df', `rtl', `gcac' and `valgrind' checks are
> very expensive. To disable all checking, `--disable-checking' or
> `--enable-checking=none' must be explicitly requested. Disabling assertions
> will make the compiler and runtime slightly faster but increase the risk of
> undetected internal errors causing wrong code to be generated.
> 
> 
> 
> 
> 
> 
> Where does it say I cannot build "C" and not "C++" without specifying 
> 
> --enable-languages=c --disable-build-with-cxx 
> --disable-build-poststage1-with-cxx --enable-stage1-languages=c
> 
> which is in fact the case ?
> 
> Where does it say that users should never use "--enable-checking=all" 
> with "--enable-bootstrap" ?

Well, the docs don't say that you need any of --enable-checking to build
GCC.  And --enable-checking=all does exactly what is documented ;)  For
releases the default configuration is --enable-checking=release
--enbale-stage1-checking=yes (to check the compiler but not slow down
the final created compiler).

So, if you don't know what you are doing just stick with the defaults ;)

> And what has any of this to do with the simple question posed in the title
> of this bug report : why can't insn-emit.c be split ?

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2012-08-06 
08:45:12 UTC ---
(In reply to comment #17)
> (In reply to comment #14)
> >  if-conversion : 177.26 (but due to loop_optimizer_init)
> 
> Hmm, this is not loop_optimizer_init. All time is spent in the two memset 
> calls
> in cond_move_process_if_block:
> 
>   /* Build a mapping for each block to the value used for each
>  register.  */
>   max_reg = max_reg_num ();
>   size = (max_reg + 1) * sizeof (rtx);
>   then_vals = (rtx *) alloca (size);
>   else_vals = (rtx *) alloca (size);
>   memset (then_vals, 0, size);
>   memset (else_vals, 0, size);
> 
> There are O(1e6) registers in the test case, and O(1e5) basic blocks. So we 
> end
> up memset'ing O(10)MB X O(1e5)times = O(1e6)MB (assuming 64 bits pointers so
> that each rtx is O(10) bytes).
> 
> I have a few ideas to fix this problem.

Ick, I suppose similar issues exist on the tree level for passes that
think that memory / compile-time usage O(number-of-ssa-names or basic-blocks)
is "ok" (and I suppose it really _is_ ok ...?)

[Bug other/54182] enable -fvisibility=hidden

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |

--- Comment #2 from wbrana  2012-08-06 08:52:14 UTC ---
I don't mean only flags used for building gcc, but -fvisibility=hidden should
be enabled if -O1/2/3/s is used and if -fPIC isn't used. How plugins have to
disabled? It shouldn't be needed.

[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden

[wbrana at gmail dot com]

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

--- Comment #2 from wbrana  2012-08-06 08:57:43 UTC ---
Executables are smaller and loads faster with -fvisibility=hidden.
Since which version -fvisibility=hidden is enabled by default?
4.7.2 pre doesn't use -fvisibility=hidden by default.

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[stevenb.gcc at gmail dot com]

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

--- Comment #20 from stevenb.gcc at gmail dot com  2012-08-06 09:09:02 UTC ---
On Mon, Aug 6, 2012 at 10:45 AM, rguenth at gcc dot gnu.org
 wrote:
> Ick, I suppose similar issues exist on the tree level for passes that
> think that memory / compile-time usage O(number-of-ssa-names or basic-blocks)
> is "ok" (and I suppose it really _is_ ok ...?)

I think this is OK, yes. In general, anything linear in some measure
of the function should be OK.
NB, this thing in ifcvt is *not* O(max_reg_num()) but
O(max_reg_num()*n_basic_blocks).

I suspect that in the tree optimizers, a non-linear issue exists for
rewriting into loop-closed SSA form. It looks like it is
O(num_ssa_names*n_basic_blocks). I'm trying to confirm that (in my
evening free time, so don't hold your breath ;-).

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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

--- Comment #29 from Steven Bosscher  2012-08-06 
09:10:49 UTC ---
(In reply to comment #27)
> Actually, I'm more interested in seeing if insn-emit.c can be reduced in size
> by avoiding duplicate functions (see e.g. gen_swapdi/gen_swapsi/gen_swapxf for
> x86_64 for a simple case of identical functions).

This doesn't seem to be a winning opportunity.

It should be possible to split insn-emit.c into separate files for
define_insns, splitters, expanders, and peephole handlers, but that, too,
doesn't seem to be a win because the vast majority of patterns are insns.

[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |

--- Comment #3 from wbrana  2012-08-06 09:29:09 UTC ---
I was wrong 4.7.2 pre is using -fvisibility=hidden by default, but cc1 isn't
built with -fvisibility=hidden.
Why it isn't possible to have cc1 built with -fvisibility=hidden and
liblto_plugin.so built without -fvisibility=hidden?

[Bug c/54188] New: Inconsistent __alignof__(long long)

[Keith.S.Thompson at gmail dot com]

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

 Bug #: 54188
   Summary: Inconsistent __alignof__(long long)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: keith.s.thomp...@gmail.com


The __alignof__ operator applied to a struct type with a single long
long member yields 4.  This is inconsistent; a struct's alignment
should be at least as large as the alignment of any of its members.

I'm using gcc 4.7.0 on Ubuntu 12.04 x86.

gcc -v says:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.0-7ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --disable-bootstrap --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.7.0 (Ubuntu/Linaro 4.7.0-7ubuntu3) 

Demo program (alignof_bug.c):

#include 
#include 

/*
 * See ,
 * posted by PiotrNycz
 */

/*
 * The ALIGNOF macro yields the alignment in bytes of a given type,
 * determined by how the compiler aligns a member of the type in
 * a struct following a single char member.
 */
#define ALIGNOF(type) ((int)(offsetof(struct {char c; type t;}, t)))

struct wrapper {
long long ll;
};

int main(void) {
printf("__alignof__(long long)  = %d\n",
   (int)__alignof__(long long));
printf("__alignof__(struct wrapper) = %d\n",
   (int)__alignof__(struct wrapper));
printf("ALIGNOF(long long)  = %d\n",
   (int)ALIGNOF(long long));
printf("ALIGNOF(struct wrapper) = %d\n",
   (int)ALIGNOF(struct wrapper));

if (__alignof__(long long) > __alignof__(struct wrapper)) {
puts("Inconsistent __alignof__, long long vs. struct");
}
if (__alignof__(long long) != ALIGNOF(long long)) {
puts("Inconsistent alignment for long long");
}

return 0;
}


Output:

__alignof__(long long)  = 8
__alignof__(struct wrapper) = 4
ALIGNOF(long long)  = 4
ALIGNOF(struct wrapper) = 4
Inconsistent __alignof__, long long vs. struct
Inconsistent alignment for long long


A response to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10360
suggests that __alignof__ needn't necessarily yield the same result
as the offset of a member within a struct.  I'm not sure I agree
with that, but the main problem I'm reporting here refers to the
alignment of the struct type itself, compared to the alignment of
one of its members.

[Bug c/54188] Inconsistent __alignof__(long long)

[Keith.S.Thompson at gmail dot com]

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

--- Comment #1 from Keith Thompson  
2012-08-06 09:33:43 UTC ---
Forgot to mention: I compiled and executed the demo program as follows:

gcc alignof_bug.c -o alignof_bug && ./alignof_bug

[Bug c++/54161] sizeof(void) expressions are accepted

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WORKSFORME
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org

--- Comment #7 from Paolo Carlini  2012-08-06 
09:46:18 UTC ---
In terms of warnings, we decided that the status quo is overall preferable:

  http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00262.html

[Bug c++/54165] Cast to "void" should not implicitly call conversion functions

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  
2012-08-06 09:49:45 UTC ---
Author: paolo
Date: Mon Aug  6 09:49:39 2012
New Revision: 190175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190175
Log:
/cp
2012-08-06  Marc Glisse  
Paolo Carlini  

PR c++/54165
* typeck.c (build_static_cast_1): Move the conversion to void case
before the perform_direct_initialization_if_possible call.

/testsuite
2012-08-06  Marc Glisse  
Paolo Carlini  

PR c++/54165
* g++.dg/conversion/void2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/conversion/void2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/54165] Cast to "void" should not implicitly call conversion functions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from paolo at gcc dot gnu.org  
2012-08-06 09:49:45 UTC ---
Author: paolo
Date: Mon Aug  6 09:49:39 2012
New Revision: 190175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190175
Log:
/cp
2012-08-06  Marc Glisse  
Paolo Carlini  

PR c++/54165
* typeck.c (build_static_cast_1): Move the conversion to void case
before the perform_direct_initialization_if_possible call.

/testsuite
2012-08-06  Marc Glisse  
Paolo Carlini  

PR c++/54165
* g++.dg/conversion/void2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/conversion/void2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

--- Comment #6 from Paolo Carlini  2012-08-06 
09:50:40 UTC ---
Done.

[Bug c++/54165] Cast to "void" should not implicitly call conversion functions

[paolo at gcc dot gnu.org]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  2012-08-06 
09:50:40 UTC ---
Done.

[Bug c++/54161] sizeof(void) expressions are accepted

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-08-06 
10:01:49 UTC ---
I don't see in the testsuite something identical to Jason's Comment #3, thus to
be safe I'm adding it.

[Bug libstdc++/54186] PowerPC: Double free, same malloc address for two pointers after free

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-08-06 
10:12:13 UTC ---
(In reply to comment #0)
> I hope I posted ok.

Please read http://gcc.gnu.org/bugs/

[Bug target/53712] Does not combine unaligned load with _mm_cmpistri, redundant instruction at -O0

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

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

--- Comment #8 from Uros Bizjak  2012-08-06 10:23:33 
UTC ---
Fixed.

[Bug c/54188] Inconsistent __alignof__(long long)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2012-08-06 
10:42:39 UTC ---
Because the ABI says so and __alignof__ does not return the minimum but the
recommended alignment.  Really a dup of 10360.

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

[Bug c/10360] __alignof__(double) answer 8

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail
   ||dot com

--- Comment #9 from Richard Guenther  2012-08-06 
10:42:39 UTC ---
*** Bug 54188 has been marked as a duplicate of this bug. ***

[Bug lto/54187] liblto_plugin.so broken with -fvisibility=hidden

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #4 from Richard Guenther  2012-08-06 
10:45:38 UTC ---
All ELF executables have hidden visibility by default if you not export all
dynamic symbols with -Wl,--export-dynamic.  That's what we need for GCC plugins
(_not_ the linker plugin), because plugin shared objects need to be able to
bind to all cc1 symbols.  Thus, disable GCC plugins.

[Bug other/54182] enable -fvisibility=hidden

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther  2012-08-06 
10:46:06 UTC ---
See the other bug.

[Bug c/54179] please split insn-emit.c !

[steven at gcc dot gnu.org]

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

--- Comment #30 from Steven Bosscher  2012-08-06 
10:49:03 UTC ---
Created attachment 27950
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27950
Split insn-emit.c into four separate files

Untested, etc., and doesn't apply to GCC 4.7 because it doesn't have the patch
to split insn-attrtab.c. But it shows what could be done to split insn-emit.c.

[Bug rtl-optimization/47489] ICE with -fdump-rtl-mach-slim and -O1 on mips (and other targets which have SEQUENCEs)

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.8.0
 Resolution||FIXED
  Known to fail||4.6.3, 4.7.1

--- Comment #2 from Steven Bosscher  2012-08-06 
11:18:34 UTC ---
Accidentally fixed for GCC 4.8 by r190133.
(http://gcc.gnu.org/viewcvs?view=revision&revision=190113)

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-08-06 
11:41:27 UTC ---
There is no straight-forward place to handle transform of

  :
  if (i_2(D) != j_3(D))
goto ;
  else
goto ;

  :
  D.1715_4 = i_2(D) - j_3(D);

  :
  # D.1715_1 = PHI 

to

  :

  :
  D.1715_4 = i_2(D) - j_3(D);

  :
  D.1715_1 = D.1715_4;

but it eventually feels like a phi-opt transform.

[Bug other/54150] [4.8 Regression] gimple dumps no longer honor -blocks

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

  Attachment #27929|0   |1
is obsolete||

--- Comment #5 from Steven Bosscher  2012-08-06 
11:44:14 UTC ---
Created attachment 27951
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27951
Patch, 2nd try

Here's take 2. A few test cases also needed fixing.

BTW, the dumps are also ugly because the alias dumper doesn't honor
TDF_DETAILS. If I ask for just the -fdump-tree-pre dump, I get the function
_and_ all the alias analysis constraints and solutions. It would be nice if
that can be fixed as well.

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot
   ||com

--- Comment #24 from Paolo Carlini  2012-08-06 
11:57:56 UTC ---
Jon, can you help me double checking mainline? Apparently something changed and
I can't reproduce the ICE anymore.

[Bug other/54150] [4.8 Regression] gimple dumps no longer honor -blocks

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-08-06 
11:58:07 UTC ---
Looks good to me (aka, ok if it bootstraps & regtests).  Thanks for fixing
this.

Yes, the PTA dumps in -pre are annoying (PTA is triggered by a TODO here ...).
I'll put it on my TODO list of things to clean up.

[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-08-06 12:20:47 UTC ---
> --- Comment #4 from Eric Botcazou  2012-08-02 
> 15:17:25 UTC ---

>> If I replace only the ld from GNU Binutils 2.21.x with the ld from 2.20.x 
>> then
>> the compilation is successful with -m32/-m64.

Replacing the linker (or assembler) used at gcc configure time with a
different one at runtime is not supported: the configure process
determines several linker features and hardcodes the result into the
compiler built.

>> Is this a bug in the GNU ld 2.21.x?

No, but gcc 4.4.4 doesn't support gld 2.21.  That version introduced the
elf*_sparc_sol2 linker emulations, and this is only handled by gcc 4.4.5
and newer.  Please note that both gcc 4.4 and 4.5 are ancient history by
now and not supported any longer.

> Certainly there is a mismatch between the compiler and the linker, and the
> linker now rejecting elf32_sparc is unexpected.
>
> Rainer, is that a known issue?

In a way, yes, see above.

Rainer

[Bug c++/54155] Newly compiled GCC 4.4.4 on Solaris sparc gives problem with -m32/-m64 flags

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #6 from Eric Botcazou  2012-08-06 
12:35:45 UTC ---
OK, so you need to upgrade to GCC 4.4.5 at least.

[Bug fortran/54189] New: ICE (segfault) with invalid assumed-size dummy

[burnus at gcc dot gnu.org]

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

 Bug #: 54189
   Summary: ICE (segfault) with invalid assumed-size dummy
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Cf. http://gcc.gnu.org/ml/fortran/2012-08/msg00034.html

The following program ICEs in check_assumed_size_reference's
1386  if ((e->ref->u.ar.end[e->ref->u.ar.as->rank - 1] == NULL)
as e->ref == NULL.


implicit none
contains
function g()
  integer :: g(*)
end function g


subroutine test()
  procedure(g), pointer :: x
  x => g
end subroutine test
end

[Bug libfortran/30162] I/O with named pipes does not work

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |

--- Comment #24 from Tobias Burnus  2012-08-06 
13:43:05 UTC ---
(In reply to comment #23)
> The real bug is thus that we shouldn't try to seek or truncate the fd at all,
> as it's not necessary in this case.

I think the issue occurs for:

st_write_done (st_parameter_dt *dtp)
...
  if (dtp->u.p.current_unit != NULL
  && dtp->u.p.current_unit->flags.access == ACCESS_SEQUENTIAL)
switch (dtp->u.p.current_unit->endfile)
...
  case NO_ENDFILE:
/* Get rid of whatever is after this record.  */
if (!is_internal_unit (dtp))
  unit_truncate (dtp->u.p.current_unit,
 stell (dtp->u.p.current_unit->s),
 &dtp->common);
dtp->u.p.current_unit->endfile = AT_ENDFILE;

with a file as simple as

  open (99, file="foo.dat")
  write (99, '(a)') 'Hello world'
  end


$ mkfifo foo.dat
$ tail -f foo.dat &
[2] 342
$ gfortran test.f90 && ./a.out
At line 2 of file test.f90 (unit = 99, file = 'foo.dat')
Fortran runtime error: Invalid argument
Hello world
$ fg
tail -f foo.dat
^C

[Bug libstdc++/54185] condition_variable not properly destructed

[architectbum at hotmail dot com]

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

--- Comment #2 from architectbum at hotmail dot com 2012-08-06 14:19:16 UTC ---
Created attachment 27952
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27952
testcase

[Bug libstdc++/54185] condition_variable not properly destructed

[architectbum at hotmail dot com]

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

--- Comment #3 from architectbum at hotmail dot com 2012-08-06 14:20:03 UTC ---
Because the problem is in thread-handling code, it's impossible to create a
completely deterministic testcase; however, the newly-attached testcase.cc
(compiled with 'g++-4.7.1 --std=c++11 -pthread') consistently behaves as
described for me. (Adjusting the NUM_THREADS seems to help reproduce the
problem on different machines.)

The testcase fails with a segfault in pthread_cond_wait using the unpatched
libstdc++ and completes normally with the patched lib.

[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-06
 CC||abel at gcc dot gnu.org
  Known to work|4.8.0   |
 AssignedTo|unassigned at gcc dot   |abel at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
  Known to fail||4.8.0

--- Comment #6 from Andrey Belevantsev  2012-08-06 
14:21:52 UTC ---
The trunk (with PR53975 fixed and thus the old patch reverted) ICEs in
av_set_could_be_blocked_by_bookkeeping_p, I will take a look.

[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #2 from Hans-Peter Nilsson  2012-08-06 
14:24:37 UTC ---
cris-elf too, since it's global.  It should be xfailed until fixed; that is,
assuming it doesn't randomly succeed, which could be confusing.

[Bug libstdc++/54185] condition_variable not properly destructed

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-08-06 
14:30:31 UTC ---
Thanks very much. For this sort of test it doesn't need to fail every time, the
GCC testsuite is run often enough on a wide enough variety of systems that even
if the test only fails occasionally it will be good enough to catch
regressions.

[Bug libstdc++/54185] condition_variable not properly destructed

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  2012-08-06 
15:29:28 UTC ---
Can you use sleep() to induce the failure reliably?

[Bug fortran/54190] New: TYPE(*)/assumed-rank: Type/rank check too relaxed for dummy procedure

[burnus at gcc dot gnu.org]

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

 Bug #: 54190
   Summary: TYPE(*)/assumed-rank: Type/rank check too relaxed for
dummy procedure
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


The following program is invalid and should print
  Error: Interface mismatch in dummy procedure 'x' at (1): Type/rank mismatch
in argument 'x'

See interface.c's compare_type_rank and its callers.

However, due to the TYPE(*), not error is printed. I suspect that for
assumed-rank ("dimension(..)") a similar issue exists, but it could be already
caught by the as.type checks.

Cf. http://gcc.gnu.org/ml/fortran/2012-08/msg00034.html


As extension, the check could be split. Namely, one should get a separate error
for TYPE and for RANK, the former should use gfc_typename() to print the types
(and the kinds), the latter should also be printed. (Either deferring
assumed-rank to a later check or specially handling the case rank==-1.)

! Example:

implicit none
contains
subroutine g(x)
  integer :: x
end subroutine g

subroutine f(x)
  type(*) :: x
end subroutine f

subroutine sub(x)
  procedure(g) :: x
end subroutine sub

subroutine test()
  call sub(f)  ! INVALID: "f" has an argument 'x' of TYPE(*) instead of integer
end subroutine test
end

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #21 from Steven Bosscher  2012-08-06 
15:36:04 UTC ---
(In reply to comment #20)

Yay, it's always nice to be right the first time when diagnosing a problem.

The tree loop optimizers spend 285s out of 1360s total compile time (with my
flatten hack and ifcvt patch applied) in compute_global_livein. That's 21% of
the total compile time.

I have a few ideas for how to fix this.

[Bug c++/53494] [4.7/4.8 Regression] ICE with invalid initializer list

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
 AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot
   |com |gnu.org

--- Comment #25 from Paolo Carlini  2012-08-06 
15:42:10 UTC ---
Fixed by the patch which fixed c++/53989.

[Bug tree-optimization/51938] missed optimization: 2 comparisons

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  2012-08-06 16:38:52 
UTC ---
Author: glisse
Date: Mon Aug  6 16:38:48 2012
New Revision: 190184

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190184
Log:
2012-08-06 Marc Glisse 

gcc/
PR tree-optimization/51938
PR tree-optimization/52005
* tree-ssa-ifcombine.c (ifcombine_ifandif): New parameters for
inverted conditions.
(ifcombine_iforif): Remove, merge code into ifcombine_ifandif.
(tree_ssa_ifcombine_bb): Update calls to the above. Detect !a&&b
and !a||b patterns.

gcc/testsuite/
PR tree-optimization/51938
PR tree-optimization/52005
* gcc.dg/tree-ssa/ssa-ifcombine-8.c: New testcase.
* gcc.dg/tree-ssa/ssa-ifcombine-9.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-10.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-11.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c   (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ifcombine.c

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c
('svn:keywords' added)

[Bug tree-optimization/52005] tree-ssa-combineif does not work with some cfgs

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  2012-08-06 16:38:52 
UTC ---
Author: glisse
Date: Mon Aug  6 16:38:48 2012
New Revision: 190184

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190184
Log:
2012-08-06 Marc Glisse 

gcc/
PR tree-optimization/51938
PR tree-optimization/52005
* tree-ssa-ifcombine.c (ifcombine_ifandif): New parameters for
inverted conditions.
(ifcombine_iforif): Remove, merge code into ifcombine_ifandif.
(tree_ssa_ifcombine_bb): Update calls to the above. Detect !a&&b
and !a||b patterns.

gcc/testsuite/
PR tree-optimization/51938
PR tree-optimization/52005
* gcc.dg/tree-ssa/ssa-ifcombine-8.c: New testcase.
* gcc.dg/tree-ssa/ssa-ifcombine-9.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-10.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-11.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c   (with props)
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c   (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ifcombine.c

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-10.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-11.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-8.c
('svn:keywords' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c
('svn:eol-style' added)

Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-9.c
('svn:keywords' added)

[Bug other/54182] enable -fvisibility=hidden with -fPIE -pie

[wbrana at gmail dot com]

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

wbrana  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|enable -fvisibility=hidden  |enable -fvisibility=hidden
   ||with -fPIE -pie

--- Comment #4 from wbrana  2012-08-06 16:47:23 UTC ---
-fPIE -pie shouldn't disable -fvisibility=hidden

[Bug tree-optimization/51938] missed optimization: 2 comparisons

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Marc Glisse  2012-08-06 
16:53:19 UTC ---
The testcase is now optimized with -fno-trapping-math. Ideally it should also
be optimized with -ftrapping-math (which a first unapplied patch did), but that
option needs too much work to fix all its issues.

Thus closing (feel free to reopen if someone is interested in the trapping
case).

[Bug tree-optimization/52005] tree-ssa-combineif does not work with some cfgs

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||glisse at gcc dot gnu.org
 Resolution||FIXED

--- Comment #4 from Marc Glisse  2012-08-06 16:58:16 
UTC ---
All the above testcases are now optimized (at least at -O2).

[Bug libstdc++/54185] condition_variable not properly destructed

[architectbum at hotmail dot com]

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

--- Comment #6 from architectbum at hotmail dot com 2012-08-06 17:18:26 UTC ---
I don't have this_thread::sleep_for in my build, but presumably it wouldn't
help as the segfault comes inside the pthread_cond_wait function. The testcase
as written already ensures that NUM_THREADS-1 threads are actually waiting at
cond->wait when notify_all is called (thanks to the lock); the problem seems to
be a race between the final thread doing 'delete cc' and the other threads
clearing the part of pthread_cond_wait which assumes the condition variable's
address still points to a valid object.

To be clear, this isn't a bug with pthread, just the way which libstdc++ uses
it. If/when ~condition_variable (via delete) calls gthread_cond_destroy,
libpthread properly avoids the race.

[Bug c++/21385] __extension__ lost inside template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|gcc-bugs at gcc dot gnu.org |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
  Known to fail||

--- Comment #6 from Paolo Carlini  2012-08-06 
17:18:40 UTC ---
Having a look.

[Bug libstdc++/54186] PowerPC: Double free, same malloc address for two pointers after free

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2012-08-06 
17:31:05 UTC ---
A testcase would be nice.

[Bug libstdc++/54036] Negating a DFP NAN in C++ produces NAN not -NAN

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2012-08-06 18:00:11 UTC ---
Author: paolo
Date: Mon Aug  6 18:00:00 2012
New Revision: 190185

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190185
Log:
2012-08-06  Peter Bergner  

PR libstdc++/54036
* include/decimal/decimal.h (_DEFINE_DECIMAL_UNARY_OP): Use _Op as
a unary operator.
* testsuite/decimal/pr54036-1.cc: New test.
* testsuite/decimal/pr54036-2.cc: Likewise.
* testsuite/decimal/pr54036-3.cc: Likewise.

Added:
branches/gcc-4_7-branch/libstdc++-v3/testsuite/decimal/pr54036-1.cc
branches/gcc-4_7-branch/libstdc++-v3/testsuite/decimal/pr54036-2.cc
branches/gcc-4_7-branch/libstdc++-v3/testsuite/decimal/pr54036-3.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/decimal/decimal.h

[Bug libstdc++/54036] Negating a DFP NAN in C++ produces NAN not -NAN

[paolo at gcc dot gnu.org]

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

--- Comment #4 from paolo at gcc dot gnu.org  
2012-08-06 18:06:46 UTC ---
Author: paolo
Date: Mon Aug  6 18:06:42 2012
New Revision: 190186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190186
Log:
2012-08-06  Paolo Carlini  

* testsuite/decimal/mixed-mode-cmp_neg.cc: Add test variable; minor
tweaks.
* testsuite/decimal/unary-arith.cc: Likewise.
* testsuite/decimal/ctor.cc: Likewise.
* testsuite/decimal/conversion-to-integral.cc: Likewise.
* testsuite/decimal/make-decimal.cc: Likewise.
* testsuite/decimal/comparison.cc: Likewise.
* testsuite/decimal/incdec-memfunc.cc: Likewise.
* testsuite/decimal/conversion-to-generic-float.cc: Likewise.
* testsuite/decimal/compound-assignment-memfunc.cc: Likewise.
* testsuite/decimal/cast_neg.cc: Likewise.
* testsuite/decimal/incdec.cc: Likewise.
* testsuite/decimal/mixed-mode-arith_neg.cc: Likewise.
* testsuite/decimal/binary-arith.cc: Likewise.
* testsuite/decimal/conversion-from-float.cc: Likewise.
* testsuite/decimal/conversion-from-integral.cc: Likewise.
* testsuite/decimal/compound-assignment.cc: Likewise.

2012-08-06  Peter Bergner  

PR libstdc++/54036
* include/decimal/decimal.h (_DEFINE_DECIMAL_UNARY_OP): Use _Op as
a unary operator.
* testsuite/decimal/pr54036-1.cc: New test.
* testsuite/decimal/pr54036-2.cc: Likewise.
* testsuite/decimal/pr54036-3.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/decimal/pr54036-1.cc
trunk/libstdc++-v3/testsuite/decimal/pr54036-2.cc
trunk/libstdc++-v3/testsuite/decimal/pr54036-3.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/decimal/decimal.h
trunk/libstdc++-v3/testsuite/decimal/binary-arith.cc
trunk/libstdc++-v3/testsuite/decimal/cast_neg.cc
trunk/libstdc++-v3/testsuite/decimal/comparison.cc
trunk/libstdc++-v3/testsuite/decimal/compound-assignment-memfunc.cc
trunk/libstdc++-v3/testsuite/decimal/compound-assignment.cc
trunk/libstdc++-v3/testsuite/decimal/conversion-from-float.cc
trunk/libstdc++-v3/testsuite/decimal/conversion-from-integral.cc
trunk/libstdc++-v3/testsuite/decimal/conversion-to-generic-float.cc
trunk/libstdc++-v3/testsuite/decimal/conversion-to-integral.cc
trunk/libstdc++-v3/testsuite/decimal/ctor.cc
trunk/libstdc++-v3/testsuite/decimal/incdec-memfunc.cc
trunk/libstdc++-v3/testsuite/decimal/incdec.cc
trunk/libstdc++-v3/testsuite/decimal/make-decimal.cc
trunk/libstdc++-v3/testsuite/decimal/mixed-mode-arith_neg.cc
trunk/libstdc++-v3/testsuite/decimal/mixed-mode-cmp_neg.cc
trunk/libstdc++-v3/testsuite/decimal/unary-arith.cc

[Bug libstdc++/54036] Negating a DFP NAN in C++ produces NAN not -NAN

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  2012-08-06 
18:07:35 UTC ---
Fixed mainline and 4.7.2.

[Bug debug/51358] incorrect/missing location for function arg, -O0, without VTA

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-06
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2012-08-06 
18:35:35 UTC ---
I also recently ran into this ... why can't GCC simply provide no location
information for the prologue?  Thus, properly restrict the PC range the
fb-based locations are valid?  At the moment GCC simply lies.

Confirmed.

[Bug c/54188] Inconsistent __alignof__(long long)

[Keith.S.Thompson at gmail dot com]

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

--- Comment #3 from Keith Thompson  
2012-08-06 19:28:37 UTC ---
The results of the _Alignof operator (new in the 2011 ISO C standard)
are the same as for the __alignof__ operator (not surprisingly).

N1370 (C11 draft) 6.5.3.4 paragraph 3 says:

The _Alignof operator yields the alignment requirement of its
operand type.

Richard Guenther: You say it's "Because the ABI says so".  Do you have
a reference to the ABI, particularly to a statement that a structure
should have a smaller alignment than its member?

You also say __alignof__ "does not return the minimum but the
recommended alignment".  That seems inconsistent with the use of the
word "required" in C11.

I just grabbed a copy of http://www.uclibc.org/docs/psABI-i386.pdf;
is that the ABI you're referring to?  Figure 3-1 covers alignment
for scalar types.  It says 8-byte floating-point has an alignment
of 4 bytes, but it doesn't mention 8-byte integers.  Furthermore,
the following page says:

Aggregates (structures and arrays) and unions assume the alignment
of their most strictly aligned component.

That seems inconsistent with the behavior of the following program:

#include 
int main(void) {
printf("_Alignof(long long) = %d\n",
   (int)_Alignof(long long));
printf("_Alignof(struct {long long x;}) = %d\n",
   (int)_Alignof(struct {long long x;}));
return 0;
}

whose output on my system, with
gcc -std=c11 -pedantic c.c -o c && ./c
is:

_Alignof(long long) = 8
_Alignof(struct {long long x;}) = 4

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #22 from Steven Bosscher  2012-08-06 
19:36:35 UTC ---
IRA/reload spends a rather significant amount of time here:

  FOR_EACH_BB_REVERSE (bb)
{ 
  bitmap_iterator bi;
  rtx insn;

  CLEAR_REG_SET (live_relevant_regs);
-->   memset (live_subregs_used, 0, max_regno * sizeof (int));

This is running with max_regno=O(1e6) and n_basic_blocks=O(1e5) ...

[Bug libstdc++/54186] PowerPC: Double free, same malloc address for two pointers after free

[poyo_vl at yahoo dot com]

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

--- Comment #4 from Ionut Popescu  2012-08-06 
19:38:37 UTC ---
I'm sorry for posting it wrong.

First, I can't use other compiler (a newer one), it not depends on me...

Second, I figured out where is the problem: realloc()!

The problem is that when I don't have enough space (512 B blocks) I realloc()
for more space, both of my pointers. 

Even if the pointers get the same value as before or new values, it crashes on
free, free on the realloc() resulted pointer!

I also wrote my own "realloc" function, that calls just malloc(), memcpy() and
free() to avoid original realloc() but strange, it also crashes on free()-ing
resulted pointers.

I'm sorry and thank you for your time, please close this.

Ionut

[Bug target/54176] lm32-elf-gcc: internal compiler error: Segmentation fault (program cc1)

[tommy-gccbugs at thorn dot ws]

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

--- Comment #4 from Tommy Thorn  2012-08-06 
19:42:45 UTC ---
FWIW, it works in 4.5.3.  I can narrow down the range if that's helpful.

[Bug libstdc++/54186] PowerPC: Double free, same malloc address for two pointers after free

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #5 from Paolo Carlini  2012-08-06 
19:43:29 UTC ---
Closing.

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #23 from Steven Bosscher  2012-08-06 
20:22:02 UTC ---
Created attachment 27953
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27953
Be memory friendlier in build_insn_chain

My first ever reload patch! :-)

[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org 2012-08-06 20:36:23 UTC ---
Author: janus
Date: Mon Aug  6 20:36:16 2012
New Revision: 190187

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190187
Log:
2012-08-06  Janus Weil  

PR fortran/35831
* interface.c (check_result_characteristics): New function, which checks
the characteristics of function results.
(gfc_compare_interfaces,gfc_check_typebound_override): Call it.

2012-08-06  Janus Weil  

PR fortran/35831
* gfortran.dg/dummy_procedure_5.f90: Modified.
* gfortran.dg/dummy_procedure_8.f90: New.
* gfortran.dg/interface_26.f90: Modified.
* gfortran.dg/proc_ptr_11.f90: Modified.
* gfortran.dg/proc_ptr_15.f90: Modified.
* gfortran.dg/proc_ptr_result_5.f90: Modified.
* gfortran.dg/typebound_override_1.f90: Modified.
* gfortran.dg/typebound_proc_6.f03: Modified.

Added:
trunk/gcc/testsuite/gfortran.dg/dummy_procedure_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dummy_procedure_5.f90
trunk/gcc/testsuite/gfortran.dg/interface_26.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_15.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_5.f90
trunk/gcc/testsuite/gfortran.dg/typebound_override_1.f90
trunk/gcc/testsuite/gfortran.dg/typebound_proc_6.f03

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #24 from Steven Bosscher  2012-08-06 
20:55:37 UTC ---
(In reply to comment #23)
> Created attachment 27953 [details]

Needs this extra bit:

diff -u ira.c ira.c
--- ira.c   (working copy)
+++ ira.c   (working copy)
@@ -3539,7 +3539,8 @@
   *p = NULL;

   for (i = 0; i < (unsigned int) max_regno; i++)
-sbitmap_free (live_subregs[i]);
+if (live_subregs[i] != NULL)
+  sbitmap_free (live_subregs[i]);
   free (live_subregs);
   BITMAP_FREE (live_subregs_used);
   BITMAP_FREE (live_relevant_regs);


With that, reload time goes down to ~14s, down from ~124s.

[Bug fortran/35831] [F95] Shape mismatch check missing for dummy procedure argument

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org 2012-08-06 21:03:01 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > Related ToDos:
> > 1) check shape of dummy function results (in 'gfc_compare_interfaces')
> > 2) check shape of function results when overriding TBPs (in
> > 'gfc_check_typebound_override')
> 
> 3) check string length of dummy function results (so far we only have a string
> length check when overriding)

r190187 does all of this (and basically a complete check of the result
characteristics).

Related TODOs:
 * improve gfc_dep_compare_expr to catch more cases (and/or enable the warnings
in check_result_characteristics and check_dummy_characteristics, marked by
FIXMEs)
 * check more attributes in check_dummy_characteristics (another FIXME)
 * Tobias' remarks at http://gcc.gnu.org/ml/fortran/2012-08/msg00034.html, e.g.
PR54189 and PR54190

[Bug c/54188] Inconsistent __alignof__(long long)

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2012-08-06 21:10:54 UTC ---
My conclusion in bug 52023 was that _Alignof should differ from 
__alignof__ to meet the standard requirements (but really the standard 
didn't have such strange ABIs in mind at all).

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #25 from Steven Bosscher  2012-08-06 
22:42:12 UTC ---
(In reply to comment #21)
> The tree loop optimizers spend 285s out of 1360s total compile time (with my
> flatten hack and ifcvt patch applied) in compute_global_livein. That's 21% of
> the total compile time.

Hmm, I've underestimated this problem. It's not a simple matter of speeding up
compute_global_livein with a few caches. I've collected some statistics:
* The largest function has 408254 basic blocks
* The largest number of blocks visited in compute_global_livein is 185939
* compute_global_livein looked at 148056 edges to visit those blocks
* The maximum size of the work list was only 6419

185939 is the number of basic blocks that end up in livein. That is a bitmap,
so most time is spent in traversing bitmap linked lists.

Perhaps this can be fixed with a fibheap, which may improve the access pattern
on the livein bitmap.

[Bug target/20020] x86_64 - 128 bit structs not targeted to TImode

[chip at pobox dot com]

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

Chip Salzenberg  changed:

   What|Removed |Added

 CC||chip at pobox dot com

--- Comment #13 from Chip Salzenberg  2012-08-06 
22:52:41 UTC ---
Is this bug obsolete now?

[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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

--- Comment #26 from Steven Bosscher  2012-08-06 
22:58:22 UTC ---
(In reply to comment #25)
> 185939 is the number of basic blocks that end up in livein. That is a bitmap,
> so most time is spent in traversing bitmap linked lists.

Oh, and this doesn't happen just once, but several 100 times.
Only to prune the set to (livein & loop_exits) ...

[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2012-07-24 00:00:00 |
 AssignedTo|unassigned at gcc dot   |aoliva at gcc dot gnu.org
   |gnu.org |

--- Comment #6 from Alexandre Oliva  2012-08-07 
01:54:12 UTC ---
On it

[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva  2012-08-07 
02:26:55 UTC ---
Created attachment 27954
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27954
Patch that fixes (or works around?) the problem

We have a relatively large expression to represent the outgoing “mode”
parameter, computed from “perms”, that requires more than 64KiB to represent. 
block2 is not enough for that.  Jakub, is it intentional that we ICE in this
case, or is this patch a reasonable change?  We successfully output the
location expression; surely 64KiB+ expressions might be excessive, but I don't
think an ICE is the most desirable way to deal with such large expressions if
we build them in the first place.