[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #15 from mrs at gcc dot gnu.org  2011-03-19 
06:13:31 UTC ---
I can't do anything about this until we have a test case.  The last email has a
lot of interesting discussion potential, but the bug database is a poor place
for it, so, I'll resist the temptation.

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #14 from Jack Howarth  2011-03-19 
04:53:53 UTC ---
(In reply to comment #13)

Have you asked these questions on the cfe-dev mailing list? Isn't clang
effectively defining the objective c language now?

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[john.engelhart at gmail dot com]

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

--- Comment #13 from John Engelhart  
2011-03-19 04:06:28 UTC ---
I'm the original reporter.

At this point, I no longer have any specific examples that demonstrate this
problem (this was filed quite some time ago).

m...@gcc.gnu.org:

> So, I'm sort of skeptical of this problem.  Please engineer a test case that 
> shows bad code.  

Are the fundamental principles and reasoning for why this could be a problem
sound?

Specifically: Can pointers to Objective-C objects break C99's strict aliasing
rules?

// objc method rewritten as a C function, for those not familiar with ObjC
void objc_method(
  MYSuperMutableArray self, // subclass of NSMutableArray
  SEL _cmd,
  NSMutableArray *mutableArray,
  NSArray *array) {
  int myCount = count; // compiler rewrites as self->count
  int arrayCount = array->count;
  int mutableArrayCount = mutableArray->count;

  int totalCount = mutableArray->count++;
  totalCount += array->count;
  totalCount += count;

}

Does this break C99 strict aliasing rules?

What if self, array, and mutableArray all point to the same thing (i.e., self =
array = mutableArray)?

The fact is that Objective-C uses pointers to objects in a way that violates
C99 strict aliasing rules.  I don't think anyone has disputed this point.

If this is indeed the case, then there exists the possibility of generating bad
optimized code when you apply C99's strict type based aliasing rules to
pointers to Objective-C objects.

> I think you'll find it is a rather bit harder than you expect.

How difficult it is, or how unlikely it might be in practice, does not change
the fact that C99's strict aliasing rules are not compatible with Objective-C's
use of pointers to objects.  As someone suggested, the easiest solution is to
simply automatically tag them with "may alias" and be done with it.

This turns it from a "maybe / hypothetically / phase of the moon" in to "can
not possibly be a problem / correct by design."

> I think most dynamic things happen at the end of a function call, that you
> can't see into (the Object-C run-time), and those things that happen before
> that point, must happen before that point, and those things that happen after
> that point, can't come before it.  Objective-C adds a ton of these type of
> calls all over the place, which controls just how far the optimizer can move
> anything.  Escape analysis should quickly realize that it doesn't own much of
> anything, which further prevents almost anything from happening.

This is true of any violation of C99's strict aliasing rules- certain bits of
codes, or usage styles, can make a huge difference as to whether or not a
strict aliasing violation ends up manifesting itself as a genuine problem.

With pure C99 code, the programmer has basically two options: Don't do
something that the C99 spec says is undefined behavior, or result to compiler
hacks, like adding __attribute__((may_alias)) or -fno-strict-aliasing.  You
might not agree with the C99 spec, but the spec is Correct(tm), even the parts
that are wrong.

Objective-C has no formal spec.  This is a bit of a problem, for a lot of
reasons.  However, it is often defined as a "strict super-set of C".  If you
use -std=(gnu|c)99, I interpret this to mean "a strict super-set of C99".  I
won't get in to definitions, but both super-set, and the qualifier "strict"
have very specific meanings.  The short version is that it doesn't really leave
you a whole lot of wiggle room to pick and choose which parts of the C99 spec
you want to include in your interpretation of Objective-C- you're basically
stuck importing the C99 spec wholesale.

This particular bug is due to the fact that C99 is not Objective-C.  C99 was
not written (to my knowledge) in a way that took the needs of Objective-C in to
account.

For better or for worse, C99's strict aliasing and Objective-C (as it is used
today) just do not get along.  It's unreasonable to expect the vast body of
Objective-C code to change to a C99 sanctioned way of accomplishing object
oriented inheritance (don't, or use "unions"!), so we're sort of stuck with
grand-fathering in Objective-C's wild C99 strict-aliasing violating ways.

> As for an
> individual pointer, statically, the type should always be reasonable, though,
> we do expect to up-cast and downcast pointers.

In Objective-C?  Sure.  But this (usually) violates C99's strict aliasing
rules.  This is why this bug exists- Objective-C needs to be able to do this,
but it also needs to let the C99 part of the compiler know that the usual type
base strict-aliasing rules don't apply to a pointer to an Objective-C object
(i.e., treat it as void * or char *, aliases anything).

http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
http://mail.python.org/pipermail/python-dev/2003-July/036898.html
http://lkml.org/lkml/2003/2/26/158
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

>From Apples gcc-5664/gcc/config

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mikestump at comcast dot net]

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

--- Comment #12 from Mike Stump  2011-03-19 
03:58:25 UTC ---
Any warnings generated that are invalid are bugs.  These bugs should be filed,
and we'll fix them.  Please attach an example file that generate warnings.

[Bug pch/48201] ndefined reference to `__builtin_stdarg_start' when compiling util-vserver-0.30.216 on gentoo

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2011-03-19 
02:54:17 UTC ---
__builtin_stdarg_start has been removed as it was broken and not used by GCC's
headers any more (it was really internal to GCC's stdards headers). 
__builtin_va_start is the replacement.

[Bug pch/48201] New: ndefined reference to `__builtin_stdarg_start' when compiling util-vserver-0.30.216 on gentoo

[praktakus at go2 dot pl]

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

   Summary: ndefined reference to `__builtin_stdarg_start' when
compiling util-vserver-0.30.216 on gentoo
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: pch
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: prakta...@go2.pl


diet -Os i686-pc-linux-gnu-gcc -O2 -pipe -march=native -s -fno-ident
-fomit-frame-pointer -std=c99 -Wall -pedantic -W -funit-at-a-time -Wl,-O1 -o
src/check-unixfile src/check-unixfile.o
/usr/diet/lib-i386/libc.a(__fcntl64.o): In function `fcntl64':
(.text+0x1b): undefined reference to `__builtin_stdarg_start'
collect2: ld returned 1 exit status
make[2]: *** [src/chain-echo] Error 1
make[2]: *** Waiting for unfinished jobs
/bin/sh ./libtool --tag=CC --mode=link diet -Os i686-pc-linux-gnu-gcc  -O2
-pipe -march=native -s -fno-ident -fomit-frame-pointer -std=c99 -Wall -pedantic
-W -funit-at-a-time  -Wl,-O1 -o src/fakerunlev$
diet -Os i686-pc-linux-gnu-gcc -O2 -pipe -march=native -s -fno-ident
-fomit-frame-pointer -std=c99 -Wall -pedantic -W -funit-at-a-time -Wl,-O1 -o
src/fakerunlevel src/fakerunlevel.o
make[2]: Leaving directory
`/var/tmp/portage/sys-cluster/util-vserver-0.30.216_pre2935/work/util-vserver-0.30.216-pre2935'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/sys-cluster/util-vserver-0.30.216_pre2935/work/util-vserver-0.30.216-pre2935'
make: *** [all] Error 2
emake failed
 ^[[31;01m*^[[0m ERROR: sys-cluster/util-vserver-0.30.216_pre2935 failed
(compile phase):
 ^[[31;01m*^[[0m   emake failed!
 ^[[31;01m*^[[0m
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m ebuild.sh, line  56:  Called src_compile
 ^[[31;01m*^[[0m   environment, line :  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m   emake || die "emake failed!"







app-shells/bash: 4.1_p9
dev-lang/python: 2.6.6-r2, 3.1.3-r1
sys-apps/baselayout: 1.12.14-r1
sys-apps/sandbox:2.4
sys-devel/autoconf:  2.65-r1
sys-devel/automake:  1.11.1
sys-devel/binutils:  2.20.1-r1
sys-devel/gcc:   4.4.5
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.10
sys-devel/make:  3.81-r2
virtual/os-headers:  2.6.36.1 (sys-kernel/linux-headers)
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native -s -fno-ident -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf
/etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=native -s -fno-ident -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news
parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn
unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org";
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
Portage 2.1.9.42 (default/linux/x86/10.0/server, gcc-4.4.5, glibc-2.11.3-r0,
2.6.35-vs2.3.0.36.32-gentoo i686)
=
 System Settings
=
System uname:
Linux-2.6.35-vs2.3.0.36.32-gentoo-i686-Intel-R-_Xeon-TM-_CPU_2.40GHz-with-gentoo-1.12.14
Timestamp of tree: Fri, 18 Mar 2011 23:00:01 +
USE="acl apache2 aspnet2 berkdb bzip2 cli cracklib crypt cups cxx dri fbcon
fortran gdbm gnutls gpm iconv ipv6 modules mudflap mysql ncurses nls nptl
nptlonly openmp pam pcre pppd readline session snmp$
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL,
LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS,
PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[nicola at gcc dot gnu.org]

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

--- Comment #11 from Nicola Pero  2011-03-19 
01:24:47 UTC ---
Having looked at some of the warnings generated in GNUstep if you compile
with -fstrict-aliasing, they seem to be C warnings with little relevance
to Objective-C (they mostly seem to be due to casting to (void **)).

So on that side (the warnings) I guess I am inclined to join Mike and become 
skeptical of this issue.

Unless the original report was that using -fstrict-aliasing would miscompile
Objective-C code ?  We need an example though.

Thanks

[Bug lto/48200] New: linking shared library with LTO results in different exported symbols

[zeev.tarantov at gmail dot com]

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

   Summary: linking shared library with LTO results in different
exported symbols
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeev.taran...@gmail.com


The library is libpci.so.3.1.7, released 2010-01-31, part of every linux
distro.
Homepage is: http://mj.ucw.cz/pciutils.html, source repository is:
http://www.kernel.org/git/?p=utils/pciutils/pciutils.git;a=shortlog

Object files compiled with CFLAGS: "-O2 -fPIC -Wall -Wno-parentheses
-Wstrict-prototypes -Wmissing-prototypes -flto".

If linked with: gcc -shared -Wl,-O1 -Wl,--as-needed -Wl,-soname,libpci.so.3
-Wl,--version-script=libpci.ver -o libpci.so.3.1.7 init.o access.o generic.o
dump.o names.o filter.o names-hash.o names-parse.o names-net.o names-cache.o
params.o caps.o sysfs.o proc.o i386-ports.o  -lz -lresolv

Then (as expected): objdump -T libpci.so.3.1.7 | grep pci_fill_info
32f0 gDF .text  006c (LIBPCI_3.0) pci_fill_info
32f0 gDF .text  006c  LIBPCI_3.1  pci_fill_info

But if linked with LTO: gcc -shared -Wl,-O1 -Wl,--as-needed -Wl,-flto
-Wl,-soname,libpci.so.3 -Wl,--version-script=libpci.ver -o libpci.so.3.1.7
init.o access.o generic.o dump.o names.o filter.o names-hash.o names-parse.o
names-net.o names-cache.o params.o caps.o sysfs.o proc.o i386-ports.o  -lz
-lresolv

Then: objdump -T libpci.so.3.1.7 | grep pci_fill_info

No such symbol.

gcc (Gentoo SVN) 4.6.0-pre9999 20110318 (prerelease) rev. 171169
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GNU ld (Linux/GNU Binutils) 2.21.51.0.7.20110306
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

I don't know enough to tell whether the problem is in pciutils, binutils or
gcc. If this is invalid and I'm just spamming, I apologize. Please kindly point
me in the right direction to fix this issue.

Preproccessed source is (relevant parts):

int pci_fill_info(struct pci_dev *, int flags)
__attribute__((visibility("default")));
# 170 "pci.h"

int pci_fill_info_v30(struct pci_dev *, int flags)
__attribute__((visibility("default")));
int pci_fill_info_v31(struct pci_dev *, int flags)
__attribute__((visibility("default")));


int
pci_fill_info_v31(struct pci_dev *d, int flags)
{
  if (flags & 0x1)
{
  flags &= ~0x1;
  d->known_fields = 0;
  pci_free_caps(d);
}
  if (flags & ~d->known_fields)
d->known_fields |= d->methods->fill_info(d, flags & ~d->known_fields);
  return d->known_fields;
}


;
extern int pci_fill_info_v30(struct pci_dev *d, int flags)
__attribute__((alias("pci_fill_info_v31")));
asm(".symver " "pci_fill_info_v30" "," "pci_fill_info@LIBPCI_3.0");
asm(".symver " "pci_fill_info_v31" "," "pci_fill_info@@LIBPCI_3.1");

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

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

--- Comment #10 from Nicola Pero  2011-03-19 
00:22:52 UTC ---
Mike,

to clarify, the problem is that if you do not use -fno-strict-aliasing
when compiling Objective-C, then compiling any largish Objective-C project
(with perfectly correct Objective-C code) will generate many strict aliasing 
warnings.

The rumours that GNUstep compiles everything with -fno-strict-aliasing are 
correct - that is the case.  The reason is simply to avoid the warnings.

But I guess that this means that all C code that is scattered inside 
Objective-C source files is generally not optimized as much as it could be. :-(

So, it would be nice to clarify the problem once and for all, and make sure
it is safe to use -fstrict-aliasing in Objective-C (and it doesn't generate 
warnings), then GNUstep could stop using -fno-strict-aliasing and people
could get the full benefit of -O2. :-)

The next step is producing a few testcases showing the actual warnings, so we
have something to discuss about. :-)

Thanks

[Bug objc/48187] infinite errors with misplaced [ in @interface definition

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.19 00:03:52
 CC||nicola at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Nicola Pero  2011-03-19 00:03:52 
UTC ---
Yes, confirmed.  Well spotted!

Thanks a lot

[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3

[sje at cup dot hp.com]

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

--- Comment #9 from Steve Ellcey  2011-03-18 23:45:07 
UTC ---
Andrey,

I was just looking at PR 48191, a bug submitted against GCC 4.5.2.  It looks
like it is caused by the same problem that this patch fixes.  Can you back port
this fix to the 4.5 branch?  Also is there any reason not to close this defect
as resolved since it is fixed on the trunk and in 4.6.

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2011-03-18 23:40:43 
UTC ---
It looks like this is the same problem as PR 43603 (but with a different error
result).  I can reproduce it on the trunk at r167587, but it is fixed at
r167588.

To fix it in the 4.5 branch we just need to backport the fix to PR 43603 to the
4.5 branch.

[Bug preprocessor/48192] Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #23711|0   |1
is obsolete||

--- Comment #2 from Michael Meissner  2011-03-18 
23:12:48 UTC ---
Created attachment 23719
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23719
Patch to correctly ignore conditional macros in #ifdef

The previous patch had a typo in it.  This patch is the corrected version.

[Bug preprocessor/48192] Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.18 23:10:58
 Ever Confirmed|0   |1

[Bug target/41482] ICE in libgfortran arm thumb multilib compile

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #23718|0   |1
is obsolete||

--- Comment #6 from Michael Meissner  2011-03-18 
23:08:06 UTC ---
Comment on attachment 23718
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23718
Patch that correctly ignores conditional macros

I entered the wrong bug number.  Sorry about that.

[Bug target/41482] ICE in libgfortran arm thumb multilib compile

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING
 AssignedTo|meissner at gcc dot gnu.org |unassigned at gcc dot
   ||gnu.org

[Bug target/41482] ICE in libgfortran arm thumb multilib compile

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 AssignedTo|unassigned at gcc dot   |meissner at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Michael Meissner  2011-03-18 
23:06:08 UTC ---
Created attachment 23718
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23718
Patch that correctly ignores conditional macros

This obsoletes the previous patch which was buggy.

[Bug c/48199] unable to emulate 'TF'. Patch for mips64el r5900

[archicharmer at mail dot ru]

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

--- Comment #1 from Deny  2011-03-18 22:43:34 UTC 
---
http://www.megaupload.com/?d=GREE7D1X

[Bug c/48199] New: unable to emulate 'TF'. Patch for mips64el r5900

[archicharmer at mail dot ru]

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

   Summary: unable to emulate 'TF'. Patch for mips64el r5900
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: archichar...@mail.ru


Hello. I speaking at once: "Sorry for my English"

MIPSel r5900 processor - 128bit processor of Playstation2. One man has created
new toolchain and i trying to optimize it. Problem arises while compiling glibc
(no matter that versions, but i need version >2.7) for
mips64el-unknown-linux-gnu target:
In file included from
../glibc-ports-2.12.1/sysdeps/mips/mips64/soft-fp/e_sqrtl.c:24:
../soft-fp/quad.h:63: error: unable to emulate 'TF'
make[2]: *** [/root/glibc-2.12.1/build/math/e_sqrtl.o] Error 1
make[2]: *** Ожидание завершения заданий...
make[2]: Leaving directory `/root/glibc-2.12.1/math'
make[1]: *** [math/others] Error 2
make[1]: Leaving directory `/root/glibc-2.12.1'
make: *** [all] Error 2

I didn't found any patches for glibc, but for gcc for powerpc-none-linux-gnuspe
 target:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01388.html

Would you be so kind as to "walk on my stops" - please, download this toolchain
and follow the instruction. It should be for 32bit linuxes.
Then you are finished, please, try to compile glibc>2.7 with ports for
mips64el-unknown-linux-gnu target.
I understand that it is not gcc BUG... i don't know who else can help.

[Bug tree-optimization/48198] [4.7 Regression] ICE: verify_ssa failed: no immediate_use list with -fopenmp --param partial-inlining-entry-probability=101

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  2011-03-18 
22:23:08 UTC ---
Requesting 101% probability is certainly unexpected, I guess this one was meant
to have 100 as maximum value.  Honza?

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-03-18 
20:54:07 UTC ---
I think the bug is in shorten_compare.
We are called for GT_EXPR with op0 0LL and op1 (unsigned) (short) ((short) 0 ^
(short) y)
with long long result type. ^ above is BIT_XOR_EXPR with short type (shortened
earlier, but that's fine, (unsigned) (short) ((short) 0 ^ (short y)) is still
(unsigned) (short) y, i.e. sign extending y from 16 bits to 32 bits.  In the
above the (short) cast doesn't really exist, it is simply a NOP_EXPR with
unsigned int type of BIT_XOR_EXPR with short int type.
get_narrower gives us 0LL (no change, unsignedp0 set to 0) and the short int
BIT_XOR_EXPR (again, with unsignedp1 set to 0).  That is IMHO also fine,
unsignedp1 says that the BIT_XOR_EXPR needs to be sign extended to the type.

But in the end shorten_compare says that the comparison just should be done in
short int, which is wrong.

[Bug c/48197] possible wrong code bug at -O0

[regehr at cs dot utah.edu]

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

--- Comment #6 from John Regehr  2011-03-18 20:23:32 
UTC ---
Bleh... nevermind the longer test, it carries along my misunderstanding of the
sign extension.  Anyway, thanks!

[Bug bootstrap/45381] [4.6/4.7 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #19 from Richard Henderson  2011-03-18 
20:21:22 UTC ---
Patch committed.

[Bug bootstrap/45381] [4.6/4.7 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function

[rth at gcc dot gnu.org]

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

--- Comment #18 from Richard Henderson  2011-03-18 
20:20:45 UTC ---
Author: rth
Date: Fri Mar 18 20:20:35 2011
New Revision: 171165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171165
Log:
PR bootstrap/45381
* lex.c [ALTIVEC] (search_line_fast): Require gcc version 4.5.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug bootstrap/45381] [4.6/4.7 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function

[rth at gcc dot gnu.org]

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

--- Comment #17 from Richard Henderson  2011-03-18 
20:20:01 UTC ---
Author: rth
Date: Fri Mar 18 20:19:45 2011
New Revision: 171164

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171164
Log:
PR bootstrap/45381
* lex.c [ALTIVEC] (search_line_fast): Require gcc version 4.5.

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

[Bug c/48197] possible wrong code bug at -O0

[regehr at cs dot utah.edu]

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

--- Comment #5 from John Regehr  2011-03-18 20:14:51 
UTC ---
Here's a test case:

int printf(const char *format, ...);

int main (void)
{
  int y = 0x8000;
  int x1 = (long)0 > ((unsigned int)0 ^ (signed short)y);
  int x2 = (long)0 > ((unsigned int)0 ^ (signed short)((int)0x8000));
  int x3 = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
  int x4 = (long)0 > ((unsigned)0 ^ (unsigned)y);
  int x5 = (long)0 > ((unsigned)0 ^ (unsigned)32768);
  int x6 = (long)0 > (unsigned)32768;
  int x7 = (long)0 > (long)32768;
  int x8 = 0;

  printf("%d %d %d %d %d %d %d %d\n",
 x1, x2, x3, x4, x5, x6, x7, x8);

  return 0;
}

And here's the output:

[regehr@gamow ~]$ current-gcc -O0 small.c -o small -Wall
[regehr@gamow ~]$ ./small 
1 0 0 0 0 0 0 0

I think 0 should be assigned into all of x1..x8.

[Bug c/48197] possible wrong code bug at -O0

[regehr at cs dot utah.edu]

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

--- Comment #4 from John Regehr  2011-03-18 20:12:31 
UTC ---
Thanks Jakub, I was just about to send the same example!

[Bug debug/47308] Dwarf Error: Cannot find signatured DIE referenced from DIE at 0x2581 [in module D:\main64.exe]

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Target|x86_64-pc-mingw32   |*-pc-mingw32

--- Comment #15 from Pawel Sikora  2011-03-18 20:11:44 
UTC ---
still occurs on fresh 4.6 branch build.

[Bug c/48197] possible wrong code bug at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-18 
20:09:18 UTC ---
That's true, the step from the 3rd to 4th line is wrong.
But that doesn't mean that on LP64 targets it should print 1.

On:

extern void abort (void);
static int y = 0x8000;

int
main ()
{
  if (0LL > (0U ^ (short)0x8000))
abort ();
  if (0LL > (0U ^ (short)y))
abort ();
  return 0;
}

the first test doesn't abort, the second one does.

[Bug c/48197] possible wrong code bug at -O0

[regehr at cs dot utah.edu]

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

--- Comment #2 from John Regehr  2011-03-18 20:04:04 
UTC ---
(In reply to comment #1)
>x = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
>x = (long)0 > ((unsigned)0 ^ (unsigned)0x8000);
> I think you missed something here (unsigned)(signed short) still sign extends.

Thanks Andrew, I'll look more closely.

If GCC is right, then Clang and Intel CC are wrong (assuming all three
compilers make the same implementation-dependent decisions for integers on
x86-64, which I was under the impression they did).

[Bug c/48197] possible wrong code bug at -O0

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-03-18 
19:56:42 UTC ---
   x = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
   x = (long)0 > ((unsigned)0 ^ (unsigned)0x8000);
I think you missed something here (unsigned)(signed short) still sign extends.

[Bug tree-optimization/48198] New: [4.7 Regression] ICE: verify_ssa failed: no immediate_use list with -fopenmp --param partial-inlining-entry-probability=101

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: verify_ssa failed: no
immediate_use list with -fopenmp --param
partial-inlining-entry-probability=101
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -fopenmp --param partial-inlining-entry-probability=101
testcase.Ctestcase.C: In destructor 'A::~A()':
testcase.C:9:1: error: no immediate_use list
for SSA_NAME: .MEM_2 in statement:
# VUSE <.MEM_2>
return;
testcase.C:9:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Similiar to PR48193 and PR48195, I am not sure if this value of
partial-inlining-entry-probability is valid.

Tested revisions:
r171152 - crash
4.6 r170955 - OK

[Bug c/48197] New: possible wrong code bug at -O0

[regehr at cs dot utah.edu]

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

   Summary: possible wrong code bug at -O0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


Here gcc's output is the same at all optimization levels.  We think the correct
answer for this function is "x = 0" because all of the following statements are
equivalent:

   x = (long)0 > ((unsigned int)0 ^ (signed short)y);
   x = (long)0 > ((unsigned int)0 ^ (signed short)((int)0x8000));
   x = (long)0 > ((unsigned int)0 ^ (signed short)0x8000);
   x = (long)0 > ((unsigned)0 ^ (unsigned)0x8000);
   x = (long)0 > ((unsigned)0 ^ (unsigned)32768);
   x = (long)0 > (unsigned)32768;
   x = (long)0 > (long)32768;
   x = 0;

[regehr@gamow ~]$ current-gcc -O0 small.c -o small
[regehr@gamow ~]$ ./small
x = 1
[regehr@gamow ~]$ cat small.c


static int x = 0;
static int y = 0x8000;

int printf(const char *format, ...);

int main (void)
{
   x = (long)0 > ((unsigned int)0 ^ (signed short)y);
   printf("x = %d\n", x);
   return 0;
} 
[regehr@gamow ~]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r171139-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r171139-install
--program-prefix=r171139- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110318 (experimental) (GCC)

[Bug bootstrap/48167] [4.7 Regression] Bootstrapping revision 171075 fails on x86_64-apple-darwin10

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #1 from John David Anglin  2011-03-18 
19:39:22 UTC ---
This also occurs on hppa*-*-*.

[Bug c++/48196] ICE (segmentation fault) on inclusion of , C++0x

[gcchelp.5.adept at 0sg dot net]

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

--- Comment #1 from gcchelp.5.adept at 0sg dot net 2011-03-18 19:35:45 UTC ---
Created attachment 23716
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23716
does not exhibit the bug

[Bug c++/48196] New: ICE (segmentation fault) on inclusion of , C++0x

[gcchelp.5.adept at 0sg dot net]

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

   Summary: ICE (segmentation fault) on inclusion of ,
C++0x
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcchelp.5.ad...@0sg.net


Created attachment 23715
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23715
preprocessed source, exhibiting the bug

I will attach two preprocessed files, one for which GCC is working, and one for
which GCC stops with an ICE. The difference is in the inclusion of  at
one point.

I am using GCC 4.5.2 on mac, compiled from FSF source as follows

Using built-in specs.
COLLECT_GCC=/opt/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.5/bin/../libexec/gcc/x86_64-apple-darwin10.6.0/4.5.2/lto-wrapper
Target: x86_64-apple-darwin10.6.0
Configured with: ../gcc-4.5.2/configure -prefix=/opt/gcc --with-gmp=/opt/gmp
--with-mpfr=/opt/mpfr --with-mpc=/opt/mpc --with-ppl=/opt/ppl
--with-cloog=/opt/cloog --disable-nls --enable-visibility --with-arch=nocona
Thread model: posix
gcc version 4.5.2 (GCC) 

The command line option used to produce the bug:

/opt/bin/gcc -x c++ -m32 -fmessage-length=0 -pipe -std=gnu++0x -Wno-trigraphs
-fno-exceptions -fno-rtti -O0 -D_DEBUG=1 -isysroot
/Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -ffast-math
-Wno-invalid-offsetof -mmacosx-version-min=10.5 -gdwarf-2
-F/Users/christian/Desktop/depot/dev/build/../bin
-I/Users/christian/Desktop/depot/dev/build/../bin/include
-I/Users/christian/Desktop/depot/dev/build/../00-temp/mbl.build/Debug/arieslib-level0.build/DerivedSources/i386
-I/Users/christian/Desktop/depot/dev/build/../00-temp/mbl.build/Debug/arieslib-level0.build/DerivedSources
-Wall -fvisibility=hidden -c
/Users/christian/Desktop/depot/dev/build/../source/arieslib/script-compiler-codegen.cc
-o
/Users/christian/Desktop/depot/dev/build/../00-temp/mbl.build/Debug/arieslib-level0.build/Objects-normal/i386/script-compiler-codegen.o

When the ICE occurs, the output is

In file included from
/Users/christian/Desktop/depot/dev/build/../source/arieslib/core-table.h:29:0,
 from
/Users/christian/Desktop/depot/dev/build/../source/arieslib/script-parser.h:11,
 from
/Users/christian/Desktop/depot/dev/build/../source/arieslib/script-compiler.h:11,
 from
/Users/christian/Desktop/depot/dev/build/../source/arieslib/script-compiler-codegen.cc:11:
/Users/christian/Desktop/depot/dev/build/../source/arieslib/core-array.h: In
member function 'void Array::InsertSpace(unsigned int, unsigned
int)':
/Users/christian/Desktop/depot/dev/build/../source/arieslib/core-array.h:716:34:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Thanks!

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 19:33:15
 CC||sje at cup dot hp.com
 Ever Confirmed|0   |1

--- Comment #2 from Steve Ellcey  2011-03-18 19:33:15 
UTC ---
I can reproduce this using GCC 4.5.2 on HP-UX but I cannot reproduce it with
Top of tree or the 4.6 branch.

[Bug target/48191] internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sje at cup dot hp.com]

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

--- Comment #1 from Steve Ellcey  2011-03-18 19:31:20 
UTC ---
Created attachment 23714
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23714
shorter test case

Shorter test case.  Reproducible on IA64 HP-UX as well with -mlp64 (and -O3
-fPIC).

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from Jakub Jelinek  2011-03-18 
19:11:54 UTC ---
Fixed.

[Bug c/48194] gcc -std=c99 fails to link when calling inline function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2011-03-18 
19:10:22 UTC ---
Because you are not using inline correctly.  inline without any qualifiers in
C99 is what is called GNU's extern inline;  You need to declare an extern
(exported) version of the inline function.

[Bug tree-optimization/48195] New: ICE: vector VEC(ipa_node_params_t,base) index domain error, in ipa_analyze_node at ipa-prop.c:1525 with -flto --param partial-inlining-entry-probability=101

[zsojka at seznam dot cz]

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

   Summary: ICE: vector VEC(ipa_node_params_t,base) index domain
error, in ipa_analyze_node at ipa-prop.c:1525 with
-flto --param partial-inlining-entry-probability=101
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -flto --param partial-inlining-entry-probability=101 testcase.c
In function '_GLOBAL__D_65535_1_d1':
lto1: internal compiler error: vector VEC(ipa_node_params_t,base) index domain
error, in ipa_analyze_node at ipa-prop.c:1525
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Tested revisions:
r171152 - crash
4.6 r170955 - crash
4.5 - doesn't know --param partial-inlining-entry-probability

[Bug c/48194] New: gcc -std=c99 fails to link when calling inline function

[adam at adamrosenfield dot com]

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

   Summary: gcc -std=c99 fails to link when calling inline
function
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@adamrosenfield.com


$ cat test.c
inline void foo() {}
int main(void) { foo(); }
$ gcc test.c -std=c99
test.c:(.text+0xa): undefined reference to `foo'
collect2: ld returned 1 exit status

Same result happens with -std=gnu99.  Bug does NOT happen with optimization
turned on: at any level besides -O0, this compiles correctly.

$ gcc --version
gcc-4.3 (Ubuntu 4.3.5-3ubuntu1) 4.3.5
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a Linux epoch 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:46 UTC
2011 x86_64 GNU/Linux

This bug also happens on at least the following versions:

gcc-4.4 (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
gcc-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1
gcc (GCC) 4.7.0 20110317 (experimental)

It does NOT happen in:

gcc-4.1 (GCC) 4.1.3 20080704 (prerelease) (Ubuntu 4.1.2-29ubuntu1)

Related: bug 34697

[Bug tree-optimization/48193] New: [4.7 Regression] ICE: verify_ssa failed: type mismatch between an SSA_NAME and its symbol with -flto --param partial-inlining-entry-probability=101

[zsojka at seznam dot cz]

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

   Summary: [4.7 Regression] ICE: verify_ssa failed: type mismatch
between an SSA_NAME and its symbol with -flto --param
partial-inlining-entry-probability=101
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -flto --param partial-inlining-entry-probability=101 testcase.c
testcase.c: In function 'foo':
testcase.c:6:5: error: type mismatch between an SSA_NAME and its symbol
testcase.c:6:5: error: in statement
# VUSE <.MEM_10>
return x_12;
testcase.c:6:5: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  error (gmsgid=0x119c068 "type mismatch between an SSA_NAME and its symbol")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:747
#1  0x00a0f5f5 in verify_ssa_name (ssa_name=0x75bee528,
is_virtual=Unhandled dwarf expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/tree-ssa.c:590
#2  0x00a1273e in verify_ssa (check_modified_stmt=1 '\001') at
/mnt/svn/gcc-trunk/gcc/tree-ssa.c:1009
#3  0x007f8429 in execute_function_todo (data=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/passes.c:1240
#4  0x007f8b1d in execute_todo (flags=2132516) at
/mnt/svn/gcc-trunk/gcc/passes.c:1271
#5  0x007faeb3 in execute_one_ipa_transform_pass () at
/mnt/svn/gcc-trunk/gcc/passes.c:1463
#6  execute_all_ipa_transforms () at /mnt/svn/gcc-trunk/gcc/passes.c:1487
#7  0x0093f8bd in tree_rest_of_compilation (fndecl=0x75bcef00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:415
#8  0x00b0fc42 in cgraph_expand_function (node=0x75bef000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#9  0x00b1239a in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#10 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#11 0x00b1291a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#12 0x00509124 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#13 0x008e7ca8 in compile_file (argc=18, argv=0x7fffdc18) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591

Tested revisions:
r171152 - crash
r171088 - crash
4.6 r170955 - OK

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #10 from Perry Smith  2011-03-18 18:57:07 
UTC ---
IZ81343 (or one of its sister APARs) fixes the original issue.  But, it leaves
a new issue.  The new error looks like:

ld: 0711-596 SEVERE ERROR: Object expand.o
An RLD for section 2 (.data) refers to symbol 852,
but the storage class of the symbol is not C_EXT or C_HIDEXT.

The word I have presently is that that too is going to turn out to be an AIX
assembler error.

[Bug bootstrap/48168] [4.7 regression] Solaris 2/SPARC bootstrap broken: ICE in sparc_function_arg_1, at config/sparc/sparc.c:5721

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.18 18:44:43
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Eric Botcazou  2011-03-18 
18:44:43 UTC ---
Investigating.

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

--- Comment #9 from Daniel Richard G.  2011-03-18 
18:05:13 UTC ---
(In reply to comment #8)
> It appears that this not a "gcc" bug but an AIX bug.

The error was precipitated by an AIX system update, but at the same time, it
can be said that the AIX linker was previously being lenient in not requiring a
csect declaration for the bss section.

Whether this is an "AIX bug" or "GCC bug" isn't really relevant. IBM changed
how the AIX linker operates, and GCC needs to be updated accordingly.

[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|4.3.6   |4.7.0

--- Comment #2 from Jason Merrill  2011-03-18 
17:48:17 UTC ---
Fixed for 4.7.  Might backport to 4.6.1 (along with the two other patches) if
no problems turn up.

[Bug c++/48162] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from Jason Merrill  2011-03-18 
17:46:32 UTC ---
Fixed.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth  2011-03-18 
17:28:19 UTC ---
The response to Comments 5 through 7 from the darwin linker developer is...
-
Unfortunately, the _sigtramp function in our libSystem.dylib does not have the
'S' letter in its augmentation string. I wrote a bug for that.  With that
fixed, I'll need to verify our unwinder the properly uses that 'S' flag to
change the boundary conditions when search for the applicable FDE.
-
So it appears that if this gets fixed, it will likely only be for darwin11.

[Bug c++/48185] if(struct ...)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-03-18 
17:27:43 UTC ---
G++ is right

a declaration in a selection-statement (if or switch) must be of the form:
  if ( type-specifier id = initializer )
or in C++0x:
  if ( type-specifier id { init } )

See 6.4 in the C++ standard

[Bug rtl-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Maxim Kuvyrkov  2011-03-18 
17:24:03 UTC ---
Fixed.

[Bug go/48019] Need to handle EINTR in libgo testsuite

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-18 17:21:42 UTC ---
> --- Comment #10 from Ian Lance Taylor  2011-03-17 
> 02:58:56 UTC ---
> Thanks.  It looks like the Solaris connect call does not honor SA_RESTART for
> some reason.

It's not only Solaris, though:

Tru64 UNIX V5.1B:

connect: Interrupted system call

but:

IRIX 6.5:

connect: Connection timed out

Rainer

[Bug preprocessor/48192] Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2011-03-18 
17:20:34 UTC ---
Created attachment 23711
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23711
Patch to make conditional macros not 'defined'

[Bug c++/48185] if(struct ...)

[lisp2d at lisp2d dot net]

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

--- Comment #2 from Lisp2D  2011-03-18 17:15:23 UTC 
---
Code

{ struct passwd*pwd(getpwuid(...));
  if(pwd)return true;}

is still compiled.

Code

if(struct passwd*pwd=getpwuid(...))return;

compiled too.

But 

if(struct passwd*pwd(getpwuid(...)))return;

will not.

Who is right?

[Bug rtl-optimization/48170] ICE: in hoist_code, at gcse.c:4524 with -fgcse --param max-hoist-depth={0,1}

[mkuvyrkov at gcc dot gnu.org]

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

--- Comment #3 from Maxim Kuvyrkov  2011-03-18 
17:12:24 UTC ---
Author: mkuvyrkov
Date: Fri Mar 18 17:12:19 2011
New Revision: 171155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171155
Log:
PR rtl-optimization/48170
* gcse.c (hoist_code): Remove bogus asserts.

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

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[pedzsan at gmail dot com]

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

--- Comment #8 from Perry Smith  2011-03-18 17:10:32 
UTC ---
It appears that this not a "gcc" bug but an AIX bug.  There is one change but
more changes are needed.  I'll try to update when I know more.  Expect it to be
a week or so.

[Bug preprocessor/48192] New: Conditional macros should not pass #ifdef

[meissner at gcc dot gnu.org]

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

   Summary: Conditional macros should not pass #ifdef
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: meiss...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


The PowerPC port defines 3 conditional macros, vector, bool, and pixel in
non-standards complaint mode to implement the Altivec/VSX vector keywords.  The
rs6000 backend only expands these keywords if the next token is a type or
keyword that would be used for the Altivec/VSX vector support, to allow the
user to use these 'keywords' as normal identifiers.  So vector int foo; would
expand vector to the vector __attribute__ to define a vector type, but int
vector = 0 would not be expanded.

The Spu also defines vector as a conditional macro.

No other port currently uses conditional macros.

The problem is if the user does:
#ifndef bool
#define bool char
#endif
static bool variable = 0;

The #ifndef case will not succeed because 'bool' is a macro, but 'bool' will
not be expanded because it was not preceded with 'vector'.

[Bug rtl-optimization/48143] [4.6/4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2011-03-18 16:39:36 
UTC ---
(In reply to comment #2)
> We ICE because we again issue more than issue_rate insns.  And this happens
> because we hit an insn which does not modify the DFA state at all, thus we do
> not account for it when checking that we obey issue_rate limits.  The insn is
> coming from sse2_cvtps2pd pattern of sse.md and it doesn't have a reservation
> (has "nothing").
> 
> I don't have any idea how the pattern attributes should be fixed, but the
> following seems to work on the test case.  Uros, does this make sense?

Sure, but there are some other patterns missing athlon_decode attribute:

*sse2_cvtpd2dq
*sse2_cvttpd2dq
sse2_cvtss2sd
*sse2_cvtpd2ps
sse2_cvtps2pd

Can you please add missing athlon_decode attribute also for these?

Patch is pre-approved for 4.7 and needs RM approval for 4.6.

[Bug target/48191] New: internal compiler error: in issue_nops_and_insn, at config/ia64/ia64.c:8258

[sebastian.heg...@tu-dresden.de]

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

   Summary: internal compiler error: in issue_nops_and_insn, at
config/ia64/ia64.c:8258
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sebastian.heg...@tu-dresden.de


Created attachment 23710
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23710
The preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, compressed with gzip.

I am trying to compile the CGAL v3.7 ("www.cgal.org") library on IA-64, which
fails with: 

In file included from /scratch/build/CGAL-3.7/src/CGAL/all_files.cpp:37:0:
/scratch/build/CGAL-3.7/src/CGAL/MP_Float.cpp: In function
‘std::pair, int> CGAL::to_interval_exp(const
CGAL::MP_Float&)’:
/scratch/build/CGAL-3.7/src/CGAL/MP_Float.cpp:400:1: internal compiler error:
in issue_nops_and_insn, at config/ia64/ia64.c:8258



Continuing as per "http://gcc.gnu.org/bugs/#report";. Full Terminal output
follows here, the output from "-save-temps" comes as an attachment.



/home/radar-08/modules-ia64/gcc/4.5.2/bin/g++ -v -save-temps  -DCGAL_EXPORTS
-DNDEBUG -frounding-math -O3 -DNDEBUG -fPIC -I/scratch/build/CGAL-3.7/include
-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include
-I/home/radar-08/modules-ia64/cgal/3.7/release/include   -o
CMakeFiles/CGAL.dir/all_files.cpp.o -c
/scratch/build/CGAL-3.7/src/CGAL/all_files.cpp
Using built-in specs.
COLLECT_GCC=/home/radar-08/modules-ia64/gcc/4.5.2/bin/g++
COLLECT_LTO_WRAPPER=/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.5.2/configure
--prefix=/home/radar-08/modules-ia64/gcc/4.5.2
--with--mpfr=/home/radar-08/modules-ia64/gcc/4.5.2
--with-gmp=/home/radar-08/modules-ia64/gcc/4.5.2
--with-mpc=/home/radar-08/modules-ia64/gcc/4.5.2
--with-libelf=/home/radar-08/modules-ia64/gcc/4.5.2 --enable-lto --enable-gold
--enable-bootstrap
Thread model: posix
gcc version 4.5.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DCGAL_EXPORTS' '-DNDEBUG'
'-frounding-math' '-O3' '-DNDEBUG' '-fPIC' '-I/scratch/build/CGAL-3.7/include'
'-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include'
'-I/home/radar-08/modules-ia64/cgal/3.7/release/include' '-o'
'CMakeFiles/CGAL.dir/all_files.cpp.o' '-c' '-shared-libgcc'

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../libexec/gcc/ia64-unknown-linux-gnu/4.5.2/cc1plus
-E -quiet -v -I/scratch/build/CGAL-3.7/include
-I/home/h0/radar-08/modules-ia64/cgal/3.7/release/include
-I/home/radar-08/modules-ia64/cgal/3.7/release/include -iprefix
/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/
-D_GNU_SOURCE -DCGAL_EXPORTS -DNDEBUG -DNDEBUG
/scratch/build/CGAL-3.7/src/CGAL/all_files.cpp -frounding-math -fPIC -O3
-fpch-preprocess -o all_files.ii
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../ia64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/ia64-unknown-linux-gnu"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include"
ignoring duplicate directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include-fixed"
ignoring nonexistent directory
"/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/../../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../ia64-unknown-linux-gnu/include"
ignoring duplicate directory
"/home/radar-08/modules-ia64/cgal/3.7/release/include"
#include "..." search starts here:
#include <...> search starts here:
 /scratch/build/CGAL-3.7/include
 /home/h0/radar-08/modules-ia64/cgal/3.7/release/include

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/ia64-unknown-linux-gnu

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/../../../../include/c++/4.5.2/backward

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include

/home/h0/radar-08/modules-ia64/gcc/4.5.2/bin/../lib/gcc/ia64-unknown-linux-gnu/4.5.2/include-fixed
 /usr/local/include
 /home/h0

[Bug c/48190] New: [regression?] Huge memory use while compiling qemu-0.4.0

[w41ter at gmail dot com]

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

   Summary: [regression?] Huge memory use while compiling
qemu-0.4.0
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w41...@gmail.com


Created attachment 23709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23709
The patch to qemu code that causes gcc-4.5.2 to hog memory

While compiling qemu-0.4.0, gcc-4.5.2 consumes > 3GB of RAM at one point
(building target-i386/translate.c) instead of < 1GB needed by gcc-4.4.4.

$gcc -v
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /U/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.5.2
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.5.2/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls
--without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.5.2/python
--enable-checking=release --enable-java-awt=gtk --with-arch=i686
--enable-languages=c,c++,java --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.1,
pie-0.4.5'
Thread model: posix
gcc version 4.5.2 (Gentoo 4.5.2 p1.1, pie-0.4.5) 

CFLAGS="-march=athlon-xp -O2 -pipe"

The memory hogging started with this commit to the qemu git repository, which I
will attach:

commit c832e3de64f1069313fc0672087791cc3dd5b4d8
Author: Richard Henderson
Date:   Mon Jan 10 19:23:47 2011 -0800

target-i386: Use deposit operation.

Use this for assignment to the low byte or low word of a register.

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[bonzini at gnu dot org]

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

--- Comment #8 from Paolo Bonzini  2011-03-18 16:24:25 
UTC ---
I like the patch from comment 6.

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  2011-03-18 
16:22:10 UTC ---
Author: jakub
Date: Fri Mar 18 16:22:01 2011
New Revision: 171151

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171151
Log:
PR debug/48176
* dwarf2out.c (dwarf2out_finish): Call output_aranges even when
arange_table_in_use is 0, but either text_section_used or
cold_text_section_used is true.  Don't call it if
!info_section_emitted.

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

[Bug tree-optimization/48189] New: [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0

[zsojka at seznam dot cz]

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

   Summary: [4.3/4.4/4.5/4.6/4.7 Regression] ICE: SIGFPE (division
by zero) in in predict_loops () at predict.c:991 with
--param max-predicted-iterations=0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O --param max-predicted-iterations=0 testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x0080aab2 in predict_loops () at /mnt/svn/gcc-trunk/gcc/predict.c:991
991   probability = ((REG_BR_PROB_BASE + nitercst / 2) / nitercst);

[Bug debug/48176] [4.6/4.7 Regression] .debug_aranges is no longer emitted

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  2011-03-18 
16:18:12 UTC ---
Author: jakub
Date: Fri Mar 18 16:18:05 2011
New Revision: 171150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171150
Log:
PR debug/48176
* dwarf2out.c (dwarf2out_finish): Call output_aranges even when
arange_table_in_use is 0, but either text_section_used or
cold_text_section_used is true.  Don't call it if
!info_section_emitted.

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

[Bug rtl-optimization/48188] New: ICE: SIGSEGV in remove_unnecessary_regions (ira-build.c:1855) with --param ira-max-loops-num=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in remove_unnecessary_regions
(ira-build.c:1855) with --param ira-max-loops-num=0 on
basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc --param ira-max-loops-num=0 testcase.c
==13273== Use of uninitialised value of size 8
==13273==at 0x792776: remove_unnecessary_regions (ira-build.c:1855)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==13273==by 0x509113: c_write_global_declarations (c-decl.c:9872)
==13273==  Uninitialised value was created by a heap allocation
==13273==at 0x4C26F30: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13273==by 0x10BD427: xmalloc (xmalloc.c:147)
==13273==by 0x79264C: remove_unnecessary_regions (ira-build.c:1835)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273== 
==13273== Invalid write of size 1
==13273==at 0x792776: remove_unnecessary_regions (ira-build.c:1855)
==13273==by 0x794213: ira_build (ira-build.c:2994)
==13273==by 0x78D4DE: ira (ira.c:3175)
==13273==by 0x78F51F: rest_of_handle_ira (ira.c:3344)
==13273==by 0x7F9C45: execute_one_pass (passes.c:1556)
==13273==by 0x7F9F34: execute_pass_list (passes.c:1611)
==13273==by 0x7F9F46: execute_pass_list (passes.c:1612)
==13273==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==13273==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==13273==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==13273==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==13273==by 0x509113: c_write_global_declarations (c-decl.c:9872)
==13273==  Address 0x3c is not stack'd, malloc'd or (recently) free'd
==13273== 
testcase.c: In function 'foo':
testcase.c:1:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/48174] DWARF for subroutine with no args indicates 'varargs'

[longb at cray dot com]

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

--- Comment #4 from Bill Long  2011-03-18 16:08:37 UTC 
---
Additional comment from originator of the bug at Cray:

The DIE tag DW_TAG_unspecified_parameters indicates that a variable argument
list starts. Try a simple C program for contrast. Just create x.c

#include 

int foo (int a, ...)
{
return a;
}

and do

gcc -c -g x.c

then

readelf -wip x.o

and you'll see a subprogram, followed by the first formal parameter, then the
unspecified parameters. This doesn't seem to make sense in the Fortran context.

...
 <1><37>: Abbrev Number: 4 (DW_TAG_subprogram)
<38>   DW_AT_external: 1
<39>   DW_AT_name: foo
<3d>   DW_AT_decl_file   : 1
<3e>   DW_AT_decl_line   : 4
<3f>   DW_AT_prototyped  : 1
<40>   DW_AT_type: <0x6b>
<44>   DW_AT_low_pc  : 0x0
<4c>   DW_AT_high_pc : 0x91
<54>   DW_AT_frame_base  : 0x0(location list)
<58>   DW_AT_sibling : <0x6b>
 <2><5c>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<5d>   DW_AT_name: a
<5f>   DW_AT_decl_file   : 1
<60>   DW_AT_decl_line   : 3
<61>   DW_AT_type: <0x6b>
<65>   DW_AT_location: 3 byte block: 91 bc 7e (DW_OP_fbreg: -196)
 <2><69>: Abbrev Number: 6 (DW_TAG_unspecified_parameters)

[Bug c++/48185] if(struct ...)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-03-18 
16:02:01 UTC ---
That is neither C nor C++.

[Bug objc/48187] New: infinite errors with misplaced [ in @interface definition

[cjwl at objc dot net]

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

   Summary: infinite errors with misplaced [ in @interface
definition
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@objc.net


While parsing the code:

@interface InfiniteErrors { ]} @end


The compiler will repeatedly and indefinitely log the error:

error: expected specifier-qualifier-list before ']' token

This occurs in 4.2.1 also, so I believe it is an old problem, searched for an
existing report but don't see anything similar.

[Bug ada/48151] Bootstrap failure in stage3 comparison

[anhvofrcaus at gmail dot com]

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

Anh Vo  changed:

   What|Removed |Added

  Component|bootstrap   |ada

--- Comment #5 from Anh Vo  2011-03-18 15:58:57 
UTC ---
After rebooting the machine, the build resumed and passed this problem.

As the build progress, another problem surfaced due to Ada syntax error
messages as follows:

/c/Gcc/Build-Test_MinWG/./gcc/xgcc -B/c/Gcc/Build-Test_MinWG/./gcc/
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/mingw/include -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/w32api/include
-B/usr/local/i686-pc-mingw32/bin/ -B/usr/local/i686-pc-mingw32/lib/ -isystem
/usr/local/i686-pc-mingw32/include -isystem
/usr/local/i686-pc-mingw32/sys-include-c -g -O2-W -Wall -gnatpg  
g-socket.adb -o g-socket.o
/c/Gcc/Build-Test_MinWG/./gcc/xgcc -B/c/Gcc/Build-Test_MinWG/./gcc/
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/mingw
-L/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/winsup/w32api/lib -isystem
/c/Gcc/gcc-4.6.0-RC-20110314/winsup/mingw/include -isystem /c/Gcc/gcc-4.6.0
RC-20110314/winsup/w32api/include -B/usr/local/i686-pc-mingw32/bin/
-B/usr/local/i686-pc mingw32/lib/ -isystem /usr/local/i686-pc-mingw32/include
-isystem /usr/local/i686-pc-mingw32/sys-include-c -g -O2-W -Wall
-gnatpg   g-socthi.adb -o g-socthi.o
g-socthi.adb:280:45: value not in range of type "Interfaces.C.unsigned"
g-socthi.adb:280:45: static expression fails Constraint_Check
make[6]: *** [g-socthi.o] Error 1
make[6]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada/rts'
make[5]: *** [gnatlib] Error 2
make[5]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[4]: *** [gnatlib-shared-win32] Error 2
make[4]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/c/Gcc/Build-Test_MinWG/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory `/c/Gcc/Build-Test_MinWG/i686-pc-mingw32/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/c/Gcc/Build-Test_MinWG'
make: *** [all] Error 2

After this Ada syntax error was fixed (I fixed it with my own way for now), the
build continued on. Finally, it completed successfully without any additional
problem.

[Bug tree-optimization/48186] New: ICE: SIGFPE (division by zero) in maybe_hot_frequency_p at predict.c:129 with --param hot-bb-frequency-fraction=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGFPE (division by zero) in
maybe_hot_frequency_p at predict.c:129 with --param
hot-bb-frequency-fraction=0 on basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc -O --param hot-bb-frequency-fraction=0 testcase.c
testcase.c: In function 'foo':
testcase.c:1:6: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x00806f9c in maybe_hot_frequency_p (bb=Unhandled dwarf expression
opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/predict.c:129
129   if (freq < ENTRY_BLOCK_PTR->frequency / PARAM_VALUE
(HOT_BB_FREQUENCY_FRACTION))

[Bug c++/48185] New: if(struct ...)

[lisp2d at lisp2d dot net]

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

   Summary: if(struct ...)
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net


Variable definition in structure if() can't receive type struct.

if(struct passwd*pwd(getpwuid(...)))return;

error: expected primary-expression before ‘struct’
error: expected ‘)’ before ‘struct’

[Bug tree-optimization/48184] New: ICE: SIGFPE (division by zero) in compute_alignments () at final.c:731 with --param align-threshold=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGFPE (division by zero) in compute_alignments
() at final.c:731 with --param align-threshold=0 on
basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase.c -
void foo (void) { }
--

Compiler output:
$ gcc -O --param align-threshold=0 testcase.c
testcase.c: In function 'foo':
testcase.c:1: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x006c5d37 in compute_alignments () at
/mnt/svn/gcc-trunk/gcc/final.c:731
731   freq_threshold = freq_max / PARAM_VALUE (PARAM_ALIGN_THRESHOLD);

[Bug c/48183] New: ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon -g -O1)

[juha.kallioinen at nokia dot com]

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

   Summary: ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon
-g -O1)
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: juha.kallioi...@nokia.com


Created attachment 23707
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23707
pre-processed source

When compiling the attached pre-processed source for arm (-march=armv7-a
-mtune=cortex-a8) and using options -mfpu=neon -g -O1 I get an ICE.

kaltsi@kaltsnatty:~/tmp/ice$ arm-linux-gnueabi-gcc-4.5 -mfpu=neon -O1 -g -c
emit-rtl-ice.i
optimized.c: In function ‘move_16bit_to_32bit’:
optimized.c:4:6: internal compiler error: in immed_double_const, at
emit-rtl.c:552
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This does not happen if I leave the -g option out.

Also reported to linaro: https://bugs.launchpad.net/gcc-linaro/+bug/736007

[Bug fortran/42954] [4.5/4.6/4.7 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||thenlich at users dot
   ||sourceforge.net

--- Comment #14 from Janne Blomqvist  2011-03-18 
15:45:59 UTC ---
*** Bug 47965 has been marked as a duplicate of this bug. ***

[Bug testsuite/47965] gfortran testsuite failures on mingw32

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #1 from Janne Blomqvist  2011-03-18 15:45:59 
UTC ---
AFAICS this is due to gfortran nowadays using libcpp rather than calling an
external cpp.

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

[Bug rtl-optimization/48182] New: ICE: SIGSEGV in try_crossjump_to_edge (cfgcleanup.c:1703) with --param min-crossjump-insns=0 on basic code

[zsojka at seznam dot cz]

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

   Summary: ICE: SIGSEGV in try_crossjump_to_edge
(cfgcleanup.c:1703) with --param min-crossjump-insns=0
on basic code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fcrossjumping --param min-crossjump-insns=0 testcase.c
-fcombine-stack-adjustments
==1021== Invalid read of size 2
==1021==at 0xF68F3C: try_crossjump_to_edge (cfgcleanup.c:1703)
==1021==by 0xF6AE27: try_crossjump_bb (cfgcleanup.c:1875)
==1021==by 0xF6BDBA: cleanup_cfg (cfgcleanup.c:2475)
==1021==by 0xFAC2F0: rest_of_handle_stack_adjustments
(combine-stack-adj.c:554)
==1021==by 0x7F9C45: execute_one_pass (passes.c:1556)
==1021==by 0x7F9F34: execute_pass_list (passes.c:1611)
==1021==by 0x7F9F46: execute_pass_list (passes.c:1612)
==1021==by 0x7F9F46: execute_pass_list (passes.c:1612)
==1021==by 0x93E3F5: tree_rest_of_compilation (tree-optimize.c:422)
==1021==by 0xB0E3E1: cgraph_expand_function (cgraphunit.c:1576)
==1021==by 0xB10E2C: cgraph_optimize (cgraphunit.c:1733)
==1021==by 0xB110B9: cgraph_finalize_compilation_unit (cgraphunit.c:1096)
==1021==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==1021== 
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Originally, it crashed with "-O2 --param min-crossjump-insns=0", so this isn't
a case of running random passes at -O0. 

Tested revisions:
171088 - crash
4.0.4 - 4.6 - crash
3.4.6 - doesn't know min-crossjump-insns

[Bug libobjc/48177] incorrect registration of typed selectors

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.18 15:22:25
 Ever Confirmed|0   |1

--- Comment #3 from Nicola Pero  2011-03-18 15:22:25 
UTC ---

> The problem showed up with argframe information in base ... which presumably
> means that something in base is getting that wrong :-(

Ok - I see.  So, something in base is trying to create a typed selector at
runtime, and register it.  The argframe information in the generated types
doesn't  match the existing one (probably because they are generated buggy,
it's hard to generate them reliably), and the selector gets registered again.

If we were using sel_types_match(), then gnustep-base wouldn't need to provide
argframe information at all, assuming a selector with the same type already 
exists ?  Or if it provides a buggy one, it would be discarded in favour of the
existing one ?

Assuming that most compiler-generated typed selectors (which include valid
type information) are loaded in the runtime before any selector generated
by gnustep-base (or anything else) on the fly at runtime (which may include 
buggy types), then this should generally work in making sure the correct
types are used. :-)

So, I guess we should do it as it should get things to work generally better.

Is this a critical bug ?  Ie, would it actually cause any visible trouble
to users (as opposed to some inefficiency) ?  If so, we need a testcase so
we can backport it at some point to 4.6.x.


> I wonder, could we have a runtime function to take a type encoding without
> argframe info, and convert it to one with argframe info using the same
> algorithm the compiler uses?

If we could do that, then we would not need the argframe info in the selectors
at all. ;-)

In fact, maybe we should get rid of it, or hide it "more" inside the runtime.

It would be nice to audit exactly when and how it is used, and what the 
relationships are between the various parts.  Ideally we'd get rid of the
need for gnustep-base or even end-users to see or know about the argframe
layout information.  Let's have a chat about that offline.

Thanks

[Bug bootstrap/48168] [4.7 regression] Solaris 2/SPARC bootstrap broken: ICE in sparc_function_arg_1, at config/sparc/sparc.c:5721

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-18 15:15:21 UTC ---
> --- Comment #1 from Eric Botcazou  2011-03-17 
> 15:21:03 UTC ---
> Duplicate of PR middle-end/48152?

While a C++-only bootstrap indeed completes as of rev 171126, an Ada
bootstrap still fails, but this seems to be a different error.

The failure can be reproduced with

$ gnat1 -quiet -O2 -fPIC -g g-debpoo.adb
+===GNAT BUG DETECTED==+
| 4.7.0 20110318 (experimental) [trunk revision 171126] (sparc-sun-solaris2.10)
GCC error:|
| output_operand: invalid expression as operand|
| Error detected around g-debpoo.adb:1723:4|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
g-debpoo.adb
g-debpoo.ads
gnat.ads
s-stoele.ads
s-chepoo.ads
s-stopoo.ads
ada.ads
a-finali.ads
s-finroo.ads
a-stream.ads
a-unccon.ads
a-except.ads
s-parame.ads
s-stalib.ads
s-traent.ads
a-exctra.ads
g-io.ads
s-addima.ads
s-memory.ads
s-soflin.ads
s-stache.ads
g-htable.ads
s-htable.ads
g-traceb.ads
s-stoele.adb
a-tags.ads
s-exctab.ads
s-secsta.ads
s-finimp.ads
s-stratt.ads
s-unstyp.ads
s-imgint.ads
s-htable.adb
a-uncdea.ads
s-strhas.ads
s-imgllu.ads


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423


I find the following stacktrace:

#0  internal_error (gmsgid=0xba4e30 ) at
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:837
#1  0x00523524 in output_operand_lossage (cmsgid=0xba4eb0 ) at /vol/gcc/src/hg/trunk/local/gcc/final.c:3070
#2  0x00523960 in output_addr_const (file=0x11acca8, x=0xfe6a5ce0) at
/vol/gcc/src/hg/trunk/local/gcc/final.c:3613
#3  0x004a6f10 in dw2_asm_output_addr_rtx (size=4, addr=0xfe6a5ce0,
comment=0x0) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2asm.c:282
#4  0x004ac46c in output_loc_operands (loc=0xfe8a0f00, for_eh_or_skip=-1) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:5296
#5  output_loc_sequence (loc=0xfe8a0f00, for_eh_or_skip=-1) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:5360
#6  0x004b5360 in output_die (die=0xfe62fda0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11254
#7  0x004b4e14 in output_die (die=0xfe62fd70) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#8  0x004b4e14 in output_die (die=0xfe62ec00) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#9  0x004b4e14 in output_die (die=0xfe62e8d0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#10 0x004b4e14 in output_die (die=0xfe62e720) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#11 0x004b4e14 in output_die (die=0xff3800f0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11448
#12 0x004b5d74 in output_comp_unit (die=0xff3800f0, output_if_empty=0) at
/vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:11521
#13 0x004daf04 in dwarf2out_finish (filename=Unhandled dwarf expression opcode
0xf3
) at /vol/gcc/src/hg/trunk/local/gcc/dwarf2out.c:23613
#14 0x007119e4 in compile_file (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:621
#15 do_compile (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1900
#16 toplev_main (argc=6, argv=0xffbff4c4) at
/vol/gcc/src/hg/trunk/local/gcc/toplev.c:1963
#17 0x001025d4 in _start ()

Seems to be a different error caused by the same patch.

Rainer

[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-03-18 
15:07:09 UTC ---
Author: jason
Date: Fri Mar 18 15:07:04 2011
New Revision: 171147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171147
Log:
PR c++/48118
* call.c (build_over_call): Don't skip ck_rvalue.

Added:
trunk/gcc/testsuite/g++.dg/overload/volatile1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/48162] [4.7 Regression] 447.dealII in SPEC CPU 2006 failed to build

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-03-18 
15:07:16 UTC ---
Author: jason
Date: Fri Mar 18 15:07:13 2011
New Revision: 171148

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171148
Log:
PR c++/48162
* semantics.c (finish_call_expr): Allow TARGET_EXPR for now.

Added:
trunk/gcc/testsuite/g++.dg/template/fn-ptr1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value

[jason at gcc dot gnu.org]

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

--- Comment #43 from Jason Merrill  2011-03-18 
15:06:54 UTC ---
Author: jason
Date: Fri Mar 18 15:06:51 2011
New Revision: 171146

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171146
Log:
PR c++/23372
* gimplify.c (gimplify_arg): Strip redundant TARGET_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr23372.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-03-18 
15:06:47 UTC ---
Author: jason
Date: Fri Mar 18 15:06:41 2011
New Revision: 171145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171145
Log:
PR c++/35315
* c-common.c (handle_transparent_union_attribute): Don't
make a duplicate type in C++.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/attrib32.C

[Bug libobjc/48177] incorrect registration of typed selectors

[rfm at gnu dot org]

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

--- Comment #2 from rfm at gnu dot org 2011-03-18 14:58:10 UTC ---
The problem showed up with argframe information in base ... which presumably
means that something in base is getting that wrong :-(

I wonder, could we have a runtime function to take a type encoding without
argframe info, and convert it to one with argframe info using the same
algorithm the compiler uses?  That would avoid us having to do that for
NSMethodSignature in base (and potentially getting it wrong).

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

--- Comment #5 from henry0312 at gmail dot com 2011-03-18 14:50:59 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > LTO is not enabled by default on x86_64-apple-darwin10 and the apple 
> > > > linker
> > > > does not support a linker plugin compatible with LTO.
> > > > 
> > > > But yes, the error message could be improved to state this (no plugin
> > > > compatible linker available) instead of complaining the way it does.
> > > 
> > > 
> > > Should 'liblto_plugin.so' exist indeed?
> > > Is this file created when compile gcc?
> > 
> > I think it should exist, it is built and installed unconditionally.  See
> > the lto-plugin/ directory in your toplevel build directory.
> 
> I was wrong, lto-plugin only gets built for ELF targets and a small list
> of extra targets that does not include x86_64-darwin10

OK, I see.

Thank you very much.

[Bug rtl-optimization/48181] [4.5/4.6/4.7 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

--- Comment #1 from Richard Guenther  2011-03-18 
14:41:47 UTC ---
I suppose a more reasonable minimum value for this param makes sense ;)

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-03-18 
14:40:23 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > LTO is not enabled by default on x86_64-apple-darwin10 and the apple 
> > > linker
> > > does not support a linker plugin compatible with LTO.
> > > 
> > > But yes, the error message could be improved to state this (no plugin
> > > compatible linker available) instead of complaining the way it does.
> > 
> > 
> > Should 'liblto_plugin.so' exist indeed?
> > Is this file created when compile gcc?
> 
> I think it should exist, it is built and installed unconditionally.  See
> the lto-plugin/ directory in your toplevel build directory.

I was wrong, lto-plugin only gets built for ELF targets and a small list
of extra targets that does not include x86_64-darwin10

[Bug rtl-optimization/48181] New: [4.5/4.6/4.7 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6/4.7 Regression] wrong code with -O -fgcse
--param ira-max-conflict-table-size=0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ja...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Output:
$ gcc -O -fgcse --param ira-max-conflict-table-size=0 testcase.c
$ valgrind -q ./a.out 
==11903== Invalid read of size 8
==11903==at 0x4C2B44C: memcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11903==by 0x400602: foo (testcase.c:47)
==11903==by 0x4006AA: main (testcase.c:65)
==11903==  Address 0x38 is not stack'd, malloc'd or (recently) free'd

The way it crashes is similiar to PR48156:
...
learcx, [rsp+128]# tmp126,
cmpQWORD PTR [rsp+8], 0# %sfp,
jne.L11#,
movesi, r14d#, qsize
movrdi, rcx#, tmp126
callbar#
.L11:
movrdx, r12#, D.2735
movrsi, rcx#, tmp126 # -fno-gcse: lea rsi, [rsp+128]
leardi, [rsp+64]#,
callmemcpy#
movrdx, r12#, D.2735
movrsi, rcx#, tmp126 # -fno-gcse: lea rsi, [rsp+128]
leardi, [rsp+32]#,
callmemcpy#
...

both calls to memcpy() read rcx to set its parameters, but rcx is not preserved
across function call (changes either by call to bar(), or by first memcpy())

Tested revisions:
r171088 - fail
4.6 r170095 - fail
4.5 r170095 - fail
4.4 r170095 - OK

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-18 
14:38:26 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
> > does not support a linker plugin compatible with LTO.
> > 
> > But yes, the error message could be improved to state this (no plugin
> > compatible linker available) instead of complaining the way it does.
> 
> 
> Should 'liblto_plugin.so' exist indeed?
> Is this file created when compile gcc?

I think it should exist, it is built and installed unconditionally.  See
the lto-plugin/ directory in your toplevel build directory.

> And If I compile binutils, will I be able to use '-fuse-linker-plugin'?

No, upstream GNU binutils do not have complete support for Mach-O.

[Bug libobjc/48177] incorrect registration of typed selectors

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  2011-03-18 14:36:50 
UTC ---
Good point.  Are you thinking of differences caused by protocol qualifiers,
or by argframe layout information ?

Thanks

[Bug rtl-optimization/48143] [4.6/4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7114 with custom flags

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Andrey Belevantsev  2011-03-18 
14:35:30 UTC ---
We ICE because we again issue more than issue_rate insns.  And this happens
because we hit an insn which does not modify the DFA state at all, thus we do
not account for it when checking that we obey issue_rate limits.  The insn is
coming from sse2_cvtps2pd pattern of sse.md and it doesn't have a reservation
(has "nothing").

I don't have any idea how the pattern attributes should be fixed, but the
following seems to work on the test case.  Uros, does this make sense?


diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index ba2bf24..71c4bb7 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -2878,6 +2878,7 @@
(set_attr "prefix" "maybe_vex")
(set_attr "mode" "V2DF")
(set_attr "prefix_data16" "0")
+   (set_attr "athlon_decode" "double")
(set_attr "amdfam10_decode" "direct")
(set_attr "bdver1_decode" "double")])

[Bug lto/48180] '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

henry0312 at gmail dot com changed:

   What|Removed |Added

  Component|target  |lto

--- Comment #2 from henry0312 at gmail dot com 2011-03-18 14:28:04 UTC ---
(In reply to comment #1)
> LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
> does not support a linker plugin compatible with LTO.
> 
> But yes, the error message could be improved to state this (no plugin
> compatible linker available) instead of complaining the way it does.


Should 'liblto_plugin.so' exist indeed?
Is this file created when compile gcc?

And If I compile binutils, will I be able to use '-fuse-linker-plugin'?

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  2011-03-18 14:18:04 UTC 
---
Author: ro
Date: Fri Mar 18 14:17:58 2011
New Revision: 171142

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171142
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.5.3   |4.7.0

[Bug target/48180] '-fuse-linker-plugin' doesn't work.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin10
  Component|lto |target

--- Comment #1 from Richard Guenther  2011-03-18 
14:15:45 UTC ---
LTO is not enabled by default on x86_64-apple-darwin10 and the apple linker
does not support a linker plugin compatible with LTO.

But yes, the error message could be improved to state this (no plugin
compatible linker available) instead of complaining the way it does.

[Bug rtl-optimization/48156] [4.6/4.7 Regression] wrong code with -fcrossjumping

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2011-03-18 
14:14:15 UTC ---
Another option is:

--- gcc/combine-stack-adj.c2010-12-02 11:51:32.0 +0100
+++ gcc/combine-stack-adj.c2011-03-18 15:12:09.497674812 +0100
@@ -551,7 +551,16 @@ gate_handle_stack_adjustments (void)
 static unsigned int
 rest_of_handle_stack_adjustments (void)
 {
-  cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
+  if (flag_crossjumping && optimize <= 1)
+{
+  df_live_add_problem ();
+  df_live_set_all_dirty ();
+  df_analyze ();
+  cleanup_cfg (CLEANUP_CROSSJUMP);
+  df_remove_problem (df_live);
+}
+  else
+cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);

   /* This is kind of a heuristic.  We need to run combine_stack_adjustments
  even for machines with possibly nonzero TARGET_RETURN_POPS_ARGS

ifcvt.c already does something similar, so the df_get_bb_dirty calls it does
always return whether the bb is dirty in df_live.

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2011-03-18 14:13:37 UTC 
---
Author: ro
Date: Fri Mar 18 14:13:32 2011
New Revision: 171141

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171141
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2011-03-18 14:10:41 UTC 
---
Author: ro
Date: Fri Mar 18 14:10:35 2011
New Revision: 171140

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171140
Log:
PR middle-end/47405
* gcc.dg/torture/20090618-1.c: Skip on mips-sgi-irix*.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/20090618-1.c

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jeffrey A. Law  2011-03-18 14:03:00 
UTC ---
Patch installed after minor formatting and comment tweaks.

[Bug middle-end/47790] [4.5/4.6/4.7 Regression] optimize_bitfield_assignment_op no longer works in 4.5.x

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  2011-03-18 14:01:47 
UTC ---
Author: law
Date: Fri Mar 18 14:01:41 2011
New Revision: 171139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171139
Log:
PR middle-end/47790
* expr.c (optimize_bitfield_assignment_op): Revamp to work
again after expansion changes.



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

[Bug lto/48180] New: '-fuse-linker-plugin' doesn't work.

[henry0312 at gmail dot com]

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

   Summary: '-fuse-linker-plugin' doesn't work.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: henry0...@gmail.com


I compiled gcc version 4.6.0 20110314 (prerelease) on Mac OS X 10.6.6.

configure options:
./configure\
--build=x86_64-apple-darwin10\
--disable-debug\
--disable-multilib\
--enable-threads=posix\
--disable-bootstrap\
--enable-version-specific-runtime-libs\
--enable-languages=c,c++,objc,obj-c++\
--enable-stage1-checking\
--disable-nls\
--enable-werror\
--enable-lto\
--enable-gold\
--enable-ld\
--with-system-zlib\
--enable-fully-dynamic-string

And then,
following explanation of '-flto' (
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Optimize-Options.html#Optimize-Options
),
I tested my gcc.

$ gcc -flto -c a.c
$ gcc -flto -c b.c
$ gcc -o test -O2 -flto -fuse-linker-plugin a.o b.o
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

a.c and b.c --> http://www.privatepaste.com/34b31b77a5

My compiling environment:
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
gmp-5.0.1
mpfr-3.0.0
mpc-0.9