[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #14 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-04-02 06:03:56 UTC --- Author: hjl Date: Sat Apr 2 06:03:52 2011 New Revision: 171877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171877 Log: Don't check zero/sign extended hard registers. 2011-03-29 H.J. Lu hongjiu...@intel.com PR middle-end/47725 * combine.c (cant_combine_insn_p): Don't check zero/sign extended hard registers. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/combine.c
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #15 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-04-02 06:05:06 UTC --- Author: hjl Date: Sat Apr 2 06:05:03 2011 New Revision: 171878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171878 Log: Promote pointer function arguments and return values to Pmode. 2011-03-29 H.J. Lu hongjiu...@intel.com PR middle-end/47725 PR target/48085 * calls.c (precompute_register_parameters): Convert pointer to TLS symbol if needed. * config/i386/i386.c (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/calls.c branches/x32/gcc/config/i386/i386.c
[Bug target/48085] [x32] Unnecessary zero-extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48085 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-04-02 06:05:06 UTC --- Author: hjl Date: Sat Apr 2 06:05:03 2011 New Revision: 171878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171878 Log: Promote pointer function arguments and return values to Pmode. 2011-03-29 H.J. Lu hongjiu...@intel.com PR middle-end/47725 PR target/48085 * calls.c (precompute_register_parameters): Convert pointer to TLS symbol if needed. * config/i386/i386.c (ix86_promote_function_mode): New. (TARGET_PROMOTE_FUNCTION_MODE): Likewise. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/calls.c branches/x32/gcc/config/i386/i386.c
[Bug c++/48409] New: const qualifier for function type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48409 Summary: const qualifier for function type Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zeratul...@hotmail.com GCC compiles the following code without error: templatetypename struct S; template struct Svoid(); template struct Svoid() const; I believe this code is invalid. Both Comeau C++ and clang give the following error for it: error: type qualifier is not allowed on this function struct Svoid() const;
[Bug go/48410] New: weird installation dir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48410
Summary: weird installation dir
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: corse...@gcc.gnu.org
When cross-building gccgo (gcc-4.6.0) for *-rtems* targets,
libgo's *.gox files end up installed under a what I assume to be a bogus
directory:
e.g.:
/opt/rtems-4.11/lib/gcc/i386-rtems4.11/4.6.0/mpentium/go/4.6.0/i386-rtems4.11/archive/tar.gox
${prefix}/lib/gcc/${target}/${gcc_version}/${multisubdir}/go/${gcc_version}/${target}/...
At least I would expect them to end up under
${prefix}/lib/gcc/${target}/${gcc_version}/${multisubdir}/go
(This would match how other languages support targets files are installed,
e.g. libstdc++)
FYI: I am configuring gcc with --enable-version-specific-runtime-libs
I would not want to exclude this issue to be related to this option,
because other languages had similar issues related to this option in the past.
[Bug go/48411] New: Bogusly canonicalized $target-gccgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48411 Summary: Bogusly canonicalized $target-gccgo Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: corse...@gcc.gnu.org Crossbuilding gcc with go enable installs the target's gccgo under a bogusly canonizalized name: E.g. (--prefix=/opt/rtems4.11 --target=i386-rtems4.11 ...) results in: /opt/rtems-4.11/bin/i386-rtems4.11-i386-rtems4.11-gccgo Correct would be: /opt/rtems-4.11/bin/i386-rtems4.11-gccgo
[Bug fortran/48412] New: [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412
Summary: [4.7 Regression] CP2K miscompiled due to some Fortran
frontend pass
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@pci.uzh.ch
after the latest fix, CP2K now compiles at -O1, but is miscompiled. Manually
disabling the frontend passes like:
gfc_run_passes (gfc_namespace *ns)
{
if (0 optimize)
{
fixes the issue (and also running at -O0). The compiler was working fine before
the function optimization patch that went in a couple of days ago, so I suspect
that's the cause.
I have no other testcase than compiling CP2K and running an input like
cp2k/tests/QS/H2O.inp.
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target|x86_64-linux-gnu|{i686, x86_64}-linux-gnu
CC||ebotcazou at gcc dot
||gnu.org
Severity|normal |blocker
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-02
07:57:00 UTC ---
Confirmed on both platforms, for example:
Bootstrap comparison failure!
gcc/resource.o differs
gcc/ada/sem_case.o differs
gcc/ada/lib.o differs
gcc/ada/exp_ch3.o differs
gcc/ada/sem_ch13.o differs
gcc/ada/exp_ch4.o differs
gcc/ada/sem_util.o differs
gcc/ada/exp_util.o differs
gcc/ada/tbuild.o differs
gcc/ada/prep.o differs
gcc/ada/sem_prag.o differs
gcc/combine.o differs
gcc/tree-iterator.o differs
gcc/gimple-iterator.o differs
gcc/c-decl.o differs
gcc/build/genautomata.o differs
gcc/tree-ssa-structalias.o differs
[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48412 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 10:25:12 UTC --- Joost, perhaps you can narrow it down further by using a debug counter. You'd have to add a debug counter to dbgcnt.def, say frontend1 Instead of if (0 ...), you would add'd do if (dbg_cnt (frontend1) ...). Then compile with -fdbg-cnt=frontend1:N where N is a number, run, and see if the bug occurs. The trick is to find the greatest value for N where the bug occurs. This can be done with a binary search, as explained in dbgcnt.def.
[Bug libstdc++/48406] algorithm #undefs isfinite() from math.h in C++0x mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48406 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-02 10:46:32 UTC --- . *** This bug has been marked as a duplicate of bug 14608 ***
[Bug libstdc++/14608] iostream.h nukes isfinite macro from math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jyasskin at gcc dot gnu.org --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-02 10:46:32 UTC --- *** Bug 48406 has been marked as a duplicate of this bug. ***
[Bug c++/48409] const qualifier for function type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48409 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 11:52:57 UTC --- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3236.html#547
[Bug libstdc++/14608] iostream.h nukes isfinite macro from math.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-02 12:01:33 UTC --- In fact, as noticed in 48406, adding back at the end definitions to the global namespace appears to basically work, we have only to be careful about the return type (int or bool in the global namespace? In std::, for C++0x we want bool. It seems to me that, in C++0x mode at least, bool would be more consistent for the global namespace too, but then including or not including cmath after math.h makes a difference, weird) and other details, like, for example, on gnu-linux, math.h appears to define isinf and isnan as functions in the global namespace, I'm, afraid this kind of target dependent vagaries in math.h have to be dealt with on a case by case way, maybe with some configury :(
[Bug c++/48409] const qualifier for function type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48409 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 12:13:48 UTC --- this was changed intentionally for PR 37806 and PR 39310
[Bug rtl-optimization/47612] RTL crash when cc0 setter moved away from cc0 user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612 --- Comment #6 from Vincent Riviere vincent.riviere at freesbee dot fr 2011-04-02 12:13:57 UTC --- Created attachment 23850 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23850 Testcase Here is my simplified testcase. It looks weird, but I didn't manage to simplify more. It fails with ICE when compiled using: gcc -c bug.c -mcpu=5475 -O2
[Bug c++/48409] const qualifier for function type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48409 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 12:26:50 UTC --- I've just checked the minutes of the last C++ meeting and a resolution for DR 547 was voted into the FDIS so GCC is correct.
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #7 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-02 12:33:33 UTC --- Tried on Gentoo yesterday, now on Ubuntu 10.04. Still not reproduced. How do the files differ? Would anyone be willing to help debug this?
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 12:35:18 UTC --- (In reply to comment #7) Tried on Gentoo yesterday, now on Ubuntu 10.04. Still not reproduced. How do the files differ? Would anyone be willing to help debug this? May I suggest you try Debian 6.0 or Fedora 14?
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403
Zdenek Sojka zsojka at seznam dot cz changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #9 from Zdenek Sojka zsojka at seznam dot cz 2011-04-02 12:40:13
UTC ---
r171847 failed for me on x86_64 Gentoo as well.
I configured with:
${DIR}/configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-${REV}-lto-fortran-checking-yes-rtl-df/
--with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl/
[Bug middle-end/48413] New: [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48413 Summary: [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 171780 gave gcc -m32 -c -o reg-stack.o -DSPEC_CPU -DNDEBUG -I. -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math reg-stack.c bad allocation for 1452 and 1451 reg-stack.c: In function 'subst_stack_regs_pat': reg-stack.c:1854:1: internal compiler error: in check_allocation, at ira.c:2094 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [reg-stack.o] Error 1
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-02 13:13:57 UTC --- May I suggest you try Debian 6.0 or Fedora 14? I have the problem on RHEL 5 and SLES 10.
[Bug middle-end/48413] [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48413 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 13:16:00 UTC --- Created attachment 23851 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23851 A testcase [hjl@gnu-34 rrs]$ ./171649/usr/bin/gcc -w -m32 -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math pr48413.c -S bad allocation for 1447 and 1446 pr48413.c: In function ‘subst_stack_regs_pat’: pr48413.c:899:2: internal compiler error: in check_allocation, at ira.c:2094 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [hjl@gnu-34 rrs]$
[Bug middle-end/48413] [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48413 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||vmakarov at redhat dot com Target Milestone|--- |4.7.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 13:17:56 UTC --- It is caused by revision 171649: http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg01074.html
[Bug bootstrap/48403] [4.7 Regression] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-02 13:23:51 UTC --- Tried on Gentoo yesterday, now on Ubuntu 10.04. Still not reproduced. How do the files differ? Would anyone be willing to help debug this? For tree-iterator.o: @@ -146,8 +146,8 @@ 20c: 8d 74 26 00 lea0x0(%esi),%esi 210: 8b 6b 14mov0x14(%ebx),%ebp 213: 8b 73 10mov0x10(%ebx),%esi - 216: c7 43 14 00 00 00 00movl $0x0,0x14(%ebx) - 21d: c7 43 10 00 00 00 00movl $0x0,0x10(%ebx) + 216: c7 43 10 00 00 00 00movl $0x0,0x10(%ebx) + 21d: c7 43 14 00 00 00 00movl $0x0,0x14(%ebx) 224: 89 1c 24mov%ebx,(%esp) 227: e8 fc ff ff ff call 228 tsi_link_before+0xe8 22c: 85 ed test %ebp,%ebp @@ -303,8 +303,8 @@ 474: 8d 74 26 00 lea0x0(%esi),%esi 478: 8b 6b 14mov0x14(%ebx),%ebp 47b: 8b 73 10mov0x10(%ebx),%esi - 47e: c7 43 14 00 00 00 00movl $0x0,0x14(%ebx) - 485: c7 43 10 00 00 00 00movl $0x0,0x10(%ebx) + 47e: c7 43 10 00 00 00 00movl $0x0,0x10(%ebx) + 485: c7 43 14 00 00 00 00movl $0x0,0x14(%ebx) 48c: 89 1c 24mov%ebx,(%esp) 48f: e8 fc ff ff ff call 490 tsi_link_after+0xd0 494: 85 ed test %ebp,%ebp
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Target|{i686, x86_64}-linux-gnu|{i686,x86_64}-linux-gnu
Target Milestone|--- |4.7.0
Summary|[4.7 Regression] bootstrap |[4.7 Regression] bootstrap
|failure |comparison failure
[Bug middle-end/48413] [4.7 Regression] 403.gcc in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48413 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 13:30:24 UTC --- This seems to be fixed. I will verify it after bootstrap is fixed.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #12 from Zdenek Sojka zsojka at seznam dot cz 2011-04-02 13:38:00 UTC --- Created attachment 23852 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23852 diff of disassemly Configuring with /mnt/svn/gcc-trunk/configure --enable-languages=c,c++ is enough to reproduce the failure: Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-loop-ivopts.o differs gcc/tree-ssa-loop-ivcanon.o differs gcc/build/genautomata.o differs gcc/fold-const.o differs gcc/mcf.o differs gcc/tree-cfg.o differs gcc/c-parser.o differs gcc/ira-color.o differs gcc/ira-costs.o differs gcc/i386.o differs gcc/cfgcleanup.o differs gcc/loop-iv.o differs gcc/ipa-prop.o differs gcc/c-decl.o differs gcc/omega.o differs gcc/insn-emit.o differs gcc/sched-rgn.o differs gcc/sched-deps.o differs libcpp/expr.o differs zlib/libz_a-infback.o differs make[2]: *** [compare] Error 1 Attached is diff if disassemly (objdump -d) of those files from stage2/3.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #13 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-02 13:43:19 UTC --- Downloading Fedora 14 now, but that'll take a while to get set up. Potentially helpful would be scheduling dumps from stage1 and stage2 compilers for these files; use -da -fsched-verbose=5.
[Bug rtl-optimization/44374] Hoist same instructions in different branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 13:47:01 UTC --- Is this now fixed, or are there reasons why the bug status is REOPENED?
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 13:50:49 UTC --- Bernd, if you have a compile farm account: It reproduces on gcc17 for me.
[Bug rtl-optimization/44374] Hoist same instructions in different branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374 Bernd Schmidt bernds at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #8 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-02 13:51:21 UTC --- Fixed again.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 13:55:31 UTC --- (In reply to comment #14) Bernd, if you have a compile farm account: It reproduces on gcc17 for me. Can you try gcc20: a dual Xeon X5670 2.93 GHz 12 cores 24 threads 24 GB RAM system It is a very fast machine.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|4.7.0 |--- --- Comment #16 from H.J. Lu hjl.tools at gmail dot com 2011-04-02 14:07:36 UTC --- I can reproduce it with C only: configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c --prefix=/usr/gcc-4.7.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-02 15:01:18 UTC --- Well, then someone will have to debug this somehow; it really looks like we're producing the same output before and after... I have bootstrapped revision 171815 and powerpc-apple-darwin9/ppc64/libgcc/_clz_s.o at stage 1 for evision 171816 differs from the same file in stage1-powerpc-apple-darwin9/ppc64/libgcc/. collect2 gives a bus error with the former, but not with the later. The only differences for the outputs of dwarfdump are [karma] gcc/rel_build% diff dw_15 dw_16 2c2 File: ../rel_build-171815/stage1-powerpc-apple-darwin9/ppc64/libgcc/_clz_s.o (ppc64) --- File: powerpc-apple-darwin9/ppc64/libgcc/_clz_s.o (ppc64) 9c9 AT_producer( GNU C 4.7.0 20110401 (experimental) [trunk revision 171815] ) --- AT_producer( GNU C 4.7.0 20110401 (experimental) [trunk revision 171816] ) Will it help if I attach the object files?
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2011-04-02 15:04:05 UTC --- Created attachment 23853 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23853 OK @ 171815 bootstrapped - and then deleted _clz*, - then CFLAGS_FOR_TARGET=-O2 -g -save-temps -fverbose-asm -dA
[Bug c/48414] New: Missing uninitialized warning in simple switch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48414
Summary: Missing uninitialized warning in simple switch
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sarbalap+gccbugzi...@gmail.com
Compiling the following code does not produce any warning, even if the ret
variable would be used uninitialized in most cases:
#include stdio.h
int main(void)
{
int ret;
printf(Input something: );
fflush(stdout);
int c = getchar();
switch (c) {
case 'a':
ret = 0;
break;
default:
/* ret still uninitialized. */
break;
}
return ret;
}
Compiled with gcc -Wall -o uninitialized uninitialized.c under GCC 4.5.2.
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org 2011-04-02 15:07:22 UTC --- Created attachment 23854 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23854 171816 + patch - not working removed i686-apple-darwin9/* ... bootstrap fails... deleted _clz* -- then bootstrapped with CFLAGS_FOR_TARGET=-O2 -g -save-temps -fverbose-asm -dA .. there is a difference, although I can't say whether the fault lies with ld64 or gcc ...
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #17 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 15:08:33 UTC --- FWIW: 171842 is OK, 171843 gives the comparison failure. No surprise, I suppose, but for the record...
[Bug libstdc++/48398] [4.6/4.7 Regression] [C++0x] std::unique_ptrT, D is broken when D::pointer is not T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48398 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 15:34:05 UTC --- Author: redi Date: Sat Apr 2 15:34:01 2011 New Revision: 171889 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171889 Log: 2011-04-02 Jonathan Wakely r...@gcc.gnu.org PR libstdc++/48398 * include/bits/unique_ptr.h (__tuple_type): Store pointer type. * testsuite/20_util/unique_ptr/modifiers/48398.cc: New. * testsuite/20_util/unique_ptr/requirements/pointer_type.cc: Remove unused parameter name. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/modifiers/48398.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/unique_ptr.h branches/gcc-4_6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/requirements/pointer_type.cc
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-02 16:00:46 UTC --- AFAICT the problematic objects are only _clz_s.o and _popcount_tab_s.o.
[Bug bootstrap/48415] New: GC Warning: Repeated allocation of very large block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48415 Summary: GC Warning: Repeated allocation of very large block Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: revital.e...@linaro.org Host: powerpc64-suse-linux Target: powerpc64-suse-linux While bootstrap trunk -r171831 on powerpc64-suse-linux I get the following warning and Out of Memory message: libtool: link: /home/eres/mainline/build/./gcc/gcj -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/eres/mainline/build/./gcc/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/ -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include -m32 -fPIC -mstrict-align -g -O2 -m32 -fPIC -mstrict-align -m32 -fPIC -mstrict-align -o .libs/gij -shared-libgcc -L/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/.libs -L/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava ./.libs/libgij.so /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/.libs/libgcj.so -lpthread -lrt -ldl -Wl,-rpath -Wl,/home/eres/mainline/build/lib/../lib -Wl,-rpath -Wl,/home/eres/mainline/build/lib/../lib/gcj-4.7.0-12 ./gcj-dbtool -n classmap.db || touch classmap.db GC Warning: Repeated allocation of very large block (appr. size 262144000): May lead to memory leak and poor performance. libtool: compile: /home/eres/mainline/build/./gcc/gcj -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/ -B/home/eres/mainline/build/./gcc/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/bin/ -B/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/lib/ -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/include -isystem /home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/sys-include -m32 -fPIC -mstrict-align -fclasspath= -fbootclasspath=../../../../gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-bootstrap-classes -fno-indirect-classes -fsource-filename=/home/eres/mainline/build/powerpc64-unknown-linux-gnu/32/libjava/classpath/tools/all-classes.lst -g -O2 -m32 -fPIC -mstrict-align -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip -o classpath/tools/libgcj_tools_la-tools.o /dev/null 21 GC Warning: Out of Memory! Returning NIL! GC Warning: Out of Memory! Returning NIL! The make instruction I use is as follows: make bootstrap BOOT_CFLAGS=-O2 The configure I use is as follows: ../gcc/configure --enable-bootstrap --enable-checking
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6/4.7 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #121 from lucier at math dot purdue.edu 2011-04-02 16:58:16 UTC ---
I'm inclined to close this as Fixed for 4.6.0.
I've taken the file mentioned in the previous comment and followed the
instructions in the readme. The times for a forward FFT of 2^{25} complex
doubles on a 2.4HGz Intel Core i5 on x86_64-apple-darwin10.7.0 are as follows:
With the usual compiler options of
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp
4.5.2:
2433 ms cpu time (2427 user, 6 system)
4.6.0:
2158 ms cpu time (2154 user, 4 system)
Adding -fschedule-insns -march=native to the above:
4.5.2:
2067 ms cpu time (2060 user, 7 system)
4.6.0:
2016 ms cpu time (2012 user, 4 system)
The assembly for the main loop looks much better.
[Bug rtl-optimization/33928] [4.3/4.4/4.5/4.6/4.7 Regression] 30% performance slowdown in floating-point code caused by r118475
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928 --- Comment #122 from lucier at math dot purdue.edu 2011-04-02 17:05:10 UTC --- Just to be clear, the command to do the test is gsi/gsi -e '(define a (expt 3 1))(set! *bench-bignum-fft* #t)(define b (* a a))'
[Bug target/48416] New: [4.7 Regression] Revision 171890 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48416 Summary: [4.7 Regression] Revision 171890 failed to build Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: kti...@gcc.gnu.org On Linux/x86, revision 171890: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00082.html gave: ../../src-trunk/gcc/config/i386/i386.c: In function 'ix86_function_arg_boundary': ../../src-trunk/gcc/config/i386/i386.c:7491:5: error: too many arguments for format [-Werror=format-extra-args]
[Bug target/48416] [4.7 Regression] Revision 171890 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48416 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-02 18:41:53 UTC --- Author: ktietz Date: Sat Apr 2 18:41:49 2011 New Revision: 171892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171892 Log: 2011-04-02 Kai Tietz kti...@redhat.com PR target/48416 * i386.c (ix86_function_arg_boundary): Fix printf formatter. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/48416] [4.7 Regression] Revision 171890 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48416 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2011-04-02 18:43:02 UTC --- Fixed.
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |target --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-04-02 19:04:24 UTC --- pa_secondary_reload doesn't handle copies to/from FP_REGS correctly. We need an immediate general register on 64-bit targets.
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #18 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 19:16:17 UTC --- Something appears to be wrong with the allocation of scheduled_insns: * It is VEC_alloc'ed on the heap in sched_extend_ready_list() but it is never VEC_free'ed. * It is allocated if sched_ready_n_insns == -1, which is the initial state (static int sched_ready_n_insns = -1;) and also the state after sched_finish_ready_list(). Therefore, AFAICU, a schedule_insns VEC is leaked for each region. I would have VEC_alloc'ed schedule_insns once, at the start of the scheduler, and VEC_reserve elements in sched_extend_ready_list(). But I am not sufficiently familiar with the scheduler to propose a patch.
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #16 from Richard Henderson rth at gcc dot gnu.org 2011-04-02 19:25:50 UTC --- Created attachment 23855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23855 second proposed patch The fault is 100% with ld. GCC is producing valid dwarf2. The *only* changes in your diff are (1) the description of the standard opcodes, and (2) an empty line number region that has been removed. For (1), you'll note that it *is* an extensible table. One can add new opcodes to the table and remain true to the dwarf2 standard. The consumer is free to ignore any opcodes that it doesn't understand. I hate Apple's linker.
[Bug libstdc++/48398] [4.6/4.7 Regression] [C++0x] std::unique_ptrT, D is broken when D::pointer is not T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48398 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 19:32:18 UTC --- Author: redi Date: Sat Apr 2 19:32:15 2011 New Revision: 171894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171894 Log: 2011-04-02 Jonathan Wakely r...@gcc.gnu.org PR libstdc++/48398 * include/bits/unique_ptr.h (__tuple_type): Store pointer type. * testsuite/20_util/unique_ptr/modifiers/48398.cc: New. * testsuite/20_util/unique_ptr/requirements/pointer_type.cc: Remove unused parameter name. Added: trunk/libstdc++-v3/testsuite/20_util/unique_ptr/modifiers/48398.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/unique_ptr.h trunk/libstdc++-v3/testsuite/20_util/unique_ptr/requirements/pointer_type.cc
[Bug libstdc++/48398] [4.6/4.7 Regression] [C++0x] std::unique_ptrT, D is broken when D::pointer is not T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48398 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 19:35:13 UTC --- fixed for 4.6.1 - thanks for the report
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #19 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 19:37:03 UTC --- Created attachment 23856 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23856 Attempt at correcting memory management for scheduled_insns Currently trying to see if this bootstraps. Even if this is not the fix for the comparison failure, something like this still ought to be applied to correct the usage of the VEC data structure.
[Bug java/48417] New: -ffixed-regs option can't work in mips-elf-gcj compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48417 Summary: -ffixed-regs option can't work in mips-elf-gcj compiler Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: java AssignedTo: unassig...@gcc.gnu.org ReportedBy: licheng.1...@gmail.com I hava build a cross compiler for my embeded platform Using built-in specs. Target: mips-elf Configured with: ../gcc-4.4.2/configure --prefix=/home/lee/gnu_src/dist --target=mips-elf --with-newlib --with-headers=../newlib-1.18.0/newlib/libc/include/ --with-ar=/home/lee/gnu_src/dist/bin/mips-elf-ar --with-as=/home/lee/gnu_src/dist/bin/mips-elf-as --with-ld=/home/lee/gnu_src/dist/bin/mips-elf-ld --with-mpfr=/home/lee/gnu_src/dist --with-gmp=/home/lee/gnu_src/dist --with-ppl=/home/lee/gnu_src/dist --with-cloog=/home/lee/gnu_src/dist --enable-languages=c,c++,java --disable-multilib --enable-libgcj --disable-threads --disable-interpreter --disable-libgcj-bc --enable-reduced-reflection --with-system-zlib --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --enable-static --disable-getenv-properties --disable-libunwind-exceptions --enable-sjlj-exceptions --disable-java-awt --disable-dssi --disable-bootstrap --disable-plugin --disable-shared --without-x --enable-java-gc=boehm --without-libffi --disable-jvmpi --disable-tls --disable-java-net --with-gcc-version-trigger=../gcc-4.4.2/gcc/version.c --disable-libstdcxx-pch and I add the following option for compiler -G0 -Wall -msoft-float -march=xcpu -mtune=xcpu -Wa,-march=xcpu,-mtune=xcpu -mips16 -EL -mexplicit-relocs -fweb -frename-registers -mmemcpy -mmips-tfile -nostartfiles -nostdlib -nodefaultlibs -c -pipe -ffixed-t3 -ffixed-t4 -ffixed-t5 -ffixed-t6 -ffixed-t7 -ffixed-s2 -ffixed-s3 -ffixed-s4 -ffixed-s5 -ffixed-s6 -ffixed-s7 -ffixed-fp -minterlink-mips16 as it shows, i make some -fixed-regs options for my compiler,and it work OK for C code, but the java code is still use register s2 ~ fp,I don't konw why? following is some code fragment disassemble from the final elf file 82056f50 _ZN9java_main4mainEJvv: 82056f50: 63f2addiu sp,-112 82056f52 $LCFI4: 82056f52: 679emovea0,s8 82056f54: d41asw a0,104(sp) 82056f56: 6777movev1,s7 82056f58: 6756movev0,s6 82056f5a: 67f5movea3,s5 82056f5c: 67d4movea2,s4 82056f5e: 6792movea0,s2 82056f60: d319sw v1,100(sp) 82056f62: d218sw v0,96(sp) 82056f64: b33clw v1,82057054 $LCFI4+0x102 82056f66: b23dlw v0,82057058 $LCFI4+0x106 82056f68: d717sw a3,92(sp) 82056f6a: d616sw a2,88(sp) 82056f6c: d414sw a0,80(sp) 82056f6e: 060caddiu a2,sp,48 82056f70: d012sw s0,72(sp) 82056f72: 67fdmovea3,sp 82056f74: 67b3movea1,s3 how about of the -ffixed-reg option for gcj? thanks!!
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #20 from Steven Bosscher steven at gcc dot gnu.org 2011-04-02 19:55:07 UTC --- Doesn't fix the comparison failure.
[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48366 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-04-02 19:56:50 UTC --- With pa_secondary_reload fixed, the following code is generated at -O0: subi 63,%r31,%r31 std %r31,80(%r3) fldd 80(%r3),%fr22 fstd %fr22,80(%r3) ldd 80(%r3),%r1 mtsar %r1 depdi,z 1,%sar,64,%r31 I don't know why reload generates such bad code. The SAR shift amount register is a special 5/6 bit register used for shift operations. It can only be loaded from a general register. We seem to have an output reload that causes the copy from r31 to fr22. Then fr22 is copied back to general register r1. Then it is moved to the sar register. Why did reload generate this code? r31 could have been moved directly. I would have thought the costs in moving r31 to fr22 and back to r1 would have inhibited this alternative relative to directly moving r31 to the sar.
[Bug c/48418] New: Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418
Summary: Bit shift operator =
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net
int x=1000;
x=(sizeof(int)3);
x is still 1000
In some cases bit shift operator used with variable (not constant) and compiler
didnot show warning. My opinion is that result must be 0.
Remarked code in my program and code to see what's happened.
/*
ULong::ULong(ULIntconstx):value2(){
if(x.uli){
if(sizeof(unsignedint)==sizeof(unsignedlongint)){
value2.push_back(static_castunsignedint(x.uli));
return;}
UIntconstibs(sizeof(unsignedint)3);
ULIntx2(x);
do{
value2.push_back(static_castunsignedint(x2.uli));
(x2.uli)=(ibs.ui);
}while(x2.uli);}}
*/
#includeiostream
typedefstruct{unsignedinti;}si;
intmain(void){
unsignedintx=1000;
siw;
w.i=sizeof(unsignedint)3;
std::coutx=xstd::endl;
x=w.i;
std::coutx=w.i - x=xstd::endl;
x=(sizeof(unsignedint)3);
std::coutx=(sizeof(unsignedint)3) - x=xstd::endl;
x=32;
std::coutx=32 - x=xstd::endl;
}
[Bug c/48418] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WONTFIX --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-02 21:06:47 UTC --- int x=1000; x=(sizeof(int)3); x is still 1000 The warning is clear: t.cc: In function 'void foo()': t.cc:4:22: warning: right shift count = width of type This invokes undefined behavior, any result is acceptable. In some cases bit shift operator used with variable (not constant) and compiler didnot show warning. My opinion is that result must be 0. The compiler cannot warn about values computed only at run time. If the shift amount is = width of type at run time, this also invokes undefined behavior.
[Bug fortran/48419] New: Reduce gfortran stack usage for procedures doing IO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 Summary: Reduce gfortran stack usage for procedures doing IO Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org Consider program iostack integer, save :: diff = 0 print *, Stack usage when executing print call x(1) print *, Stack usage in equivalent non-IO procedure call y(1) contains recursive subroutine x(i) print *, diff - loc(i) diff = loc(i) if (i 10) call x(i+1) return end subroutine x recursive subroutine y(i) call printy(diff - loc(i)) diff = loc(i) if (i 10) call y(i+1) return end subroutine y recursive subroutine printy(i) print *, i end subroutine printy end program iostack On i686 I get Stack usage when executing print -134515072 1210538920 400 400 400 400 400 400 400 400 Stack usage in equivalent non-IO procedure -1210542120 1210538904 32 32 32 32 32 32 32 32 Which means that for the procedure with an IO call, we need an extra 400-32 = 368 bytes stack space. On 64-bit targets, more. This a) will limit recursion depth as most systems are by default configured with quite small stack sizes, and b) perhaps reduce performance as we put a largish amount of sparsely accessed data right in the cache-hottest memory. This large stack usage is due to allocating a large struct on the stack prior to making any IO calls. There are two main reasons for this. 1. Most of the struct is for library private use. Apart from storing the pointer to the gfc_unit, so that we don't need to lock the unit tree and traverse it for every transfer_*() call, I see little reason why the rest of this data cannot be part of the gfc_unit itself (which is stored on the heap), or in heap memory with only a pointer to it kept. Depending on how wants to structure it, one could maybe argue that it's useful to retain the pointer to the transfer function and another pointer to the transfer data if one wants to keep it separate from gfc_unit. But still, 1-3 pointers vs. the current 16 pointers and 32 ints. 2. Another part of the struct is fields for every possible IO specifier. As most IO calls use just a few specifiers, most of this data is never accessed (one field in the struct is a bitmap specifying which of the other fields are valid). Case #1 should be relatively easy to fix. For #2 there are a few options. Say, a) A char array containing all the data. Walk over the flags variable, and for each set bit, read the appropriate number of bytes from the char array and bump a pointer to the current position. This is probably the most space efficient, but might run into alignment issues on some targets? So maybe one needs to memcpy() the data to some properly aligned data before actually using it. b) Create a union of all the specifier data structs. Then pass an array of this union type, with the flags variable specifying the type of each element (that is, the length of the array is the number of set bits in the flag variable). This might waste a bit of space compared to the previous approach, but should ensure that everything is properly aligned. From a brief scan of current sources, the biggest element is probably for character variables, which is a pointer to the string and the length, so in no case will the union type be particularly large. c) Get rid of the flags variable, and instead pass a variable specifying the array length, the array elements being a struct of an enum specifying the element type, and the union type described in the previous approach. Personally, I think option c) looks the cleanest.
[Bug fortran/48419] Reduce gfortran stack usage for procedures doing IO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2011-04-02 21:12:25 UTC --- (In reply to comment #0) For #2 there are a few options. Say, a) A char array containing all the data. Walk over the flags variable, and for each set bit, read the appropriate number of bytes from the char array and bump a pointer to the current position. This is probably the most space efficient, but might run into alignment issues on some targets? So maybe one needs to memcpy() the data to some properly aligned data before actually using it. b) Create a union of all the specifier data structs. Then pass an array of this union type, with the flags variable specifying the type of each element (that is, the length of the array is the number of set bits in the flag variable). This might waste a bit of space compared to the previous approach, but should ensure that everything is properly aligned. From a brief scan of current sources, the biggest element is probably for character variables, which is a pointer to the string and the length, so in no case will the union type be particularly large. c) Get rid of the flags variable, and instead pass a variable specifying the array length, the array elements being a struct of an enum specifying the element type, and the union type described in the previous approach. Personally, I think option c) looks the cleanest. I meant that I'd prefer b), not c). In any case, whichever is preferred also depends on what is easy-ish to do in the frontend.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #6 from nbi at wideopenwest dot com 2011-04-02 21:16:47 UTC --- I continue to get the originally reported error: make[3]: Entering directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' build/genhooks \ ../.././gcc/doc/tm.texi.in tmp-tm.texi (null): No place specified to document hook TARGET_ASM_OPEN_PAREN make[3]: *** [s-tm-texi] Error 1 make[3]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make: *** [all] Error 2 That's even with unpacking the source in an empty dir. Maybe there's something wrong with the packaging of the source?
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 21:25:35 UTC --- (In reply to comment #6) I continue to get the originally reported error: It looks as though you continue to build in the source dir, but I can't know for sure as you didn't say how you're running configure. make[3]: Entering directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' build/genhooks \ ../.././gcc/doc/tm.texi.in tmp-tm.texi (null): No place specified to document hook TARGET_ASM_OPEN_PAREN make[3]: *** [s-tm-texi] Error 1 make[3]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make: *** [all] Error 2 That's even with unpacking the source in an empty dir. Maybe there's something wrong with the packaging of the source? It works for everyone else.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 21:26:28 UTC --- (In reply to comment #7) Maybe there's something wrong with the packaging of the source? It works for everyone else. Actually maybe that's not true, you're not using the official sources, I have no idea what's in the Debian package.
[Bug c++/48420] New: Missed -Wconversion-null warning when passing const bool to T*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48420
Summary: Missed -Wconversion-null warning when passing const
bool to T*
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
$ g++-mp-4.6 -Wconversion-null -c test.cc
dhcp-172-19-248-71:~/tmp$ cat test.cc
void foo(int* p);
void bar() {
const bool kDebugMode = false; // NULL pointer constant.
foo(kDebugMode); // But no warning!
}
$ g++-mp-4.6 -Wconversion-null -c test.cc
$
Changing the kDebugMode to 'false' or a false expression involving an enum
triggers the warning.
[Bug c/48418] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418
--- Comment #2 from Dmitry Gorbachev d.g.gorbachev at gmail dot com
2011-04-02 21:43:15 UTC ---
GCC 4.x regression, for x = 5:
$ cat foo.c
unsigned foo(void)
{
#ifdef CONST
const
#endif
unsigned i = sizeof(unsigned) 3;
unsigned x = 1000;
return x i;
}
^D
$ gcc-4.5.0 -O -S foo.c -DCONST
$ gcc-4.4.6 -O -S foo.c -DCONST
foo.c: In function 'foo':
foo.c:8: warning: right shift count = width of type
g++ works.
[Bug fortran/48419] Reduce gfortran stack usage for procedures doing IO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-02 22:03:45 UTC --- We have talked about this issue before and the only thing holding us off was a desire to not break the ABI yet. If we can get an all clear to proceed from some of our other teams members I you or I to get started on this. We also need to consider the async IO patch too here. Can we get async and this dome at the same time?
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #9 from nbi at wideopenwest dot com 2011-04-02 22:24:00 UTC --- (In reply to comment #7) (In reply to comment #6) I continue to get the originally reported error: It looks as though you continue to build in the source dir, but I can't know for sure as you didn't say how you're running configure. ../gcc-4.6.0/configure with_gmp_lib=/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/gmp-5.0.1/.libs with_mpfr_lib=/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/mpfr-3.0.0/.libs with_mpc_lib=/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/mpc-0.8.2/src/.libs make[3]: Entering directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' build/genhooks \ ../.././gcc/doc/tm.texi.in tmp-tm.texi (null): No place specified to document hook TARGET_ASM_OPEN_PAREN make[3]: *** [s-tm-texi] Error 1 make[3]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0/host-x86_64-unknown-linux-gnu/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/gcc-4.6-4.6.0.orig/gcc-4.6.0' make: *** [all] Error 2 That's even with unpacking the source in an empty dir. Maybe there's something wrong with the packaging of the source? It works for everyone else.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 22:52:32 UTC --- (In reply to comment #9) (In reply to comment #7) (In reply to comment #6) I continue to get the originally reported error: It looks as though you continue to build in the source dir, but I can't know for sure as you didn't say how you're running configure. ../gcc-4.6.0/configure which is the directory you're building in too, right? i.e. the same as ./configure So you're still building in the source directory. You need TWO directories, one for the sources, and one you build in. And why are you using with_xxx_lib instead of using --with-gmp ? Try the makefile at http://advogato.org/person/redi/diary/229.html which will do it all for you correctly: make -f config-gcc.mk GCC_VERSION=4.6.0 GMP_VERSION=5.0.1
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-02 22:59:09 UTC --- Created attachment 23855 [details] second proposed patch Unfortunately it does not work either. The fault is 100% with ld. GCC is producing valid dwarf2. There is no point to complain about the ld in darwin9: it won't be fixed and the error is not present in darwin10 (even if it fails to bootstrap for other reasons, see pr48403). The *only* changes in your diff are (1) the description of the standard opcodes, and (2) an empty line number region that has been removed. I see three differences: *** 819,826 .byte0x1# Minimum Instruction Length .byte0x1# Default is_stmt_start flag .byte0xf6# Line Base Value (Special Opcodes) ! .byte0xf5# Line Range Value (Special Opcodes) ! .byte0xa# Special Opcode Base .byte0# opcode: 0x1 has 0 args .byte0x1# opcode: 0x2 has 1 args .byte0x1# opcode: 0x3 has 1 args --- 819,826 .byte0x1# Minimum Instruction Length .byte0x1# Default is_stmt_start flag .byte0xf6# Line Base Value (Special Opcodes) ! .byte0xf2# Line Range Value (Special Opcodes) ! .byte0xd# Special Opcode Base .byte0# opcode: 0x1 has 0 args .byte0x1# opcode: 0x2 has 1 args .byte0x1# opcode: 0x3 has 1 args *** *** 830,835 --- 830,838 .byte0# opcode: 0x7 has 0 args .byte0# opcode: 0x8 has 0 args .byte0x1# opcode: 0x9 has 1 args + .byte0# opcode: 0xa has 0 args + .byte0# opcode: 0xb has 0 args + .byte0x1# opcode: 0xc has 1 args .ascii ../../../../gcc-4-7-reghunt/libgcc/../gcc\0# Directory Entry: 0x1 .ascii ../../../../gcc-4-7-reghunt/libgcc/../gcc/config/i386\0# Directory Entry: 0x2 .byte0# End directory table *** *** 847,858 .byte0# uleb128 0 .byte0# End file name table LELTP0: - .byte0# DW_LNE_set_address - .byte0x9# uleb128 0x9 - .byte0x2 - .quadLetext0 - .byte0# DW_LNE_end_sequence - .byte0x1# uleb128 0x1 - .byte0x1 LELT0: .subsections_via_symbols --- 850,854 Are the values ! .byte0xf2# Line Range Value (Special Opcodes) ! .byte0xd# Special Opcode Base OK?
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #11 from nbi at wideopenwest dot com 2011-04-02 23:18:08 UTC --- (In reply to comment #10) (In reply to comment #9) (In reply to comment #7) (In reply to comment #6) I continue to get the originally reported error: It looks as though you continue to build in the source dir, but I can't know for sure as you didn't say how you're running configure. ../gcc-4.6.0/configure which is the directory you're building in too, right? i.e. the same as ./configure So you're still building in the source directory. NO!! gcc-4.6-4.6.0.orig/gcc-4.6.0 contains the source gcc-4.6-4.6.0.orig/build is the build directory You need TWO directories, one for the sources, and one you build in. And why are you using with_xxx_lib instead of using --with-gmp ? What's the difference? Try the makefile at http://advogato.org/person/redi/diary/229.html which will do it all for you correctly: make -f config-gcc.mk GCC_VERSION=4.6.0 GMP_VERSION=5.0.1 I am making progress. I downloaded the 3/25 snapshot from one of the mirrors and I'm not getting the texi error any more. It appears there is something amiss with the Debian packaging. However, now I get the cannot compute suffix of object files error. Hopefully that will go away by use of your advogato recommendation. Sigh. Why is this so convoluted?
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 23:26:24 UTC --- (In reply to comment #11) (In reply to comment #10) (In reply to comment #9) (In reply to comment #7) (In reply to comment #6) I continue to get the originally reported error: It looks as though you continue to build in the source dir, but I can't know for sure as you didn't say how you're running configure. ../gcc-4.6.0/configure which is the directory you're building in too, right? i.e. the same as ./configure So you're still building in the source directory. NO!! gcc-4.6-4.6.0.orig/gcc-4.6.0 contains the source gcc-4.6-4.6.0.orig/build is the build directory But the error you're getting shows you are in the gcc-4.6.0 directory. You need TWO directories, one for the sources, and one you build in. And why are you using with_xxx_lib instead of using --with-gmp ? What's the difference? One is the documented, supported way to build gcc, one isn't. Try the makefile at http://advogato.org/person/redi/diary/229.html which will do it all for you correctly: make -f config-gcc.mk GCC_VERSION=4.6.0 GMP_VERSION=5.0.1 I am making progress. I downloaded the 3/25 snapshot from one of the mirrors and I'm not getting the texi error any more. It appears there is something amiss with the Debian packaging. However, now I get the cannot compute suffix of object files error. Hopefully that will go away by use of your advogato recommendation. Sigh. Why is this so convoluted? http://gcc.gnu.org/wiki/FAQ#configure_suffix Yes, if you use my config-gcc.mk makefile that won't be a problem.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 23:32:10 UTC --- The docs for --with-gmp also point out you might need to use LD_LIBRARY_PATH so the gmp/mpfr/mpc libs will be found, which is the cause of the cannot compute suffix error, but I assume you didn't read those docs since you're not using --with-gmp I have no idea how you'll get the installed gcc to find those shared libs if you haven't bothered to install them and are giving the path to the build dir as with_gmp_lib, you're pretty much on your own if you don't want to follow the installation instructions. That's why you're finding it convoluted. I suggest just using my config-gcc.mk instead
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 23:39:58 UTC --- what my makefile does is put the gmp sources in the gcc tree as gcc-4.6.0/gmp (not as gcc-4.6.0/gmp-5.0.1 as you seem to have it) and similarly for mpfr and mpc. Then just configure gcc, it will detect and build the prerequisite libs, and link to them statically. You seem to have put the source under the gcc tree, then built them there yourself? I don't think that will work.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #15 from nbi at wideopenwest dot com 2011-04-02 23:42:13 UTC --- (In reply to comment #13) The docs for --with-gmp also point out you might need to use LD_LIBRARY_PATH so the gmp/mpfr/mpc libs will be found, which is the cause of the cannot compute suffix error, but I assume you didn't read those docs since you're not using --with-gmp I have no idea how you'll get the installed gcc to find those shared libs if you haven't bothered to install them and are giving the path to the build dir as with_gmp_lib, you're pretty much on your own if you don't want to follow the installation instructions. That's why you're finding it convoluted. I suggest just using my config-gcc.mk instead That doesn't work neither: make -f config-gcc.mk GCC_VERSION=4.6.0 GMP_VERSION=5.0.1 ln -s ../mpfr-3.0.0 gcc-4.6.0/mpfr ln -s ../mpc-0.8.2 gcc-4.6.0/mpc curl -O http://www.mpfr.org/mpfr-current/mpfr-3.0.0.tar.gz curl: (7) couldn't connect to host make: *** [mpfr-3.0.0.tar.gz] Error 7
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-02 23:44:47 UTC --- you can tell it to use local copies of the files if you've already downloaded them, look at the LOCAL_SRC variable
[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48403 --- Comment #21 from Bernd Schmidt bernds at gcc dot gnu.org 2011-04-03 00:10:06 UTC --- Okay, the problem showed up on Fedora 14 (no idea why only there). The bug is that I've missed some uses of last_scheduled_insn. Will probably be able to post a fix on Monday.
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #17 from nbi at wideopenwest dot com 2011-04-03 00:13:45 UTC --- (In reply to comment #16) you can tell it to use local copies of the files if you've already downloaded them, look at the LOCAL_SRC variable Thanks for your help. Your recommendation almost works (at least it got further than previous attempts). Since you claim it does everything for me (which presumably spares me several days of reading) I'm afraid to report it must be flawed: make[5]: Entering directory `/usr/src/gcc/advogato/objdir-4.6.0/x86_64-unknown-linux-gnu/32/libgcc' # If this is the top-level multilib, build all the other # multilibs. /usr/src/gcc/advogato/objdir-4.6.0/./gcc/xgcc -B/usr/src/gcc/advogato/objdir-4.6.0/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -I. -I. -I../../.././gcc -I../../../../gcc-4.6.0/libgcc -I../../../../gcc-4.6.0/libgcc/. -I../../../../gcc-4.6.0/libgcc/../gcc -I../../../../gcc-4.6.0/libgcc/../include -I../../../../gcc-4.6.0/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.6.0/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:378:0, from /usr/include/stdio.h:28, from ../../../../gcc-4.6.0/libgcc/../gcc/tsystem.h:87, from ../../../../gcc-4.6.0/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[5]: *** [_muldi3.o] Error 1 make[5]: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0/x86_64-unknown-linux-gnu/32/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0/x86_64-unknown-linux-gnu/libgcc' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0' make: *** [all] Error 2 make: Leaving directory `/usr/src/gcc/advogato/objdir-4.6.0' And why is it trying to build a 32 bit version when my architecture is obviously 64 bit??
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-03 00:21:32 UTC --- because x86_64 builds a multilib compiler by default, which is what most people want. use CONFIGARGS=--disable-multilib if you don't want that, or install the 32buig glibc headers and libs if you want a compiler that can produce 32bit or 64bit output I think you should continue this on the gcc-help mailing list, there's no gcc bug here
[Bug c++/48421] New: [4.7 Regression] ICE in build_new_method_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48421
Summary: [4.7 Regression] ICE in build_new_method_call
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
#include functional
#include chrono
#include memory
#include condition_variable
struct Impl;
typedef std::shared_ptrImpl shared_base_type;
struct base
{
shared_base_type ptr;
};
struct Impl : base
{
Impl() = default;
};
The c++0x code above gives me an ICE with trunk, but it goes away if I change
any of the includes, or try to compile a preprocessed version (which is why I
haven't attached preprocessed source)
$ ~/gcc/4.x/bin/g++ -std=c++0x ice.cc -c
ice.cc:14:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Program received signal SIGSEGV, Segmentation fault.
build_new_method_call (instance=0x75954b70, fns=value optimized out,
args=0x7fffdd50, conversion_path=0x75a3ae40,
flags=value optimized out, fn_p=0x7fffdd58, complain=value optimized
out) at ../../src/gcc/gcc/cp/call.c:6801
6801 basetype = TYPE_MAIN_VARIANT (TREE_TYPE (instance));
[Bug c++/48421] [4.7 Regression] ICE in build_new_method_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48421 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-03 00:38:43 UTC --- I'm able to reproduce this on two different machines with trunk so I don't think it's just something weird on my machine - can anyone else reproduce it?
[Bug c++/48421] [4.7 Regression] ICE in build_new_method_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48421 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.03 00:48:40 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-04-03 00:48:40 UTC --- Jon, I can, sadly.
[Bug c++/48421] [4.7 Regression] ICE in build_new_method_call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48421 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-03 01:01:27 UTC --- Thanks, Paolo. I'm not sure how to reduce it further, the only header that's needed is memory but removing the others prevents the ICE
[Bug other/48378] gcc 4.6.0 fails to build from source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48378 --- Comment #19 from nbi at wideopenwest dot com 2011-04-03 02:48:01 UTC --- (In reply to comment #18) because x86_64 builds a multilib compiler by default, which is what most people want. use CONFIGARGS=--disable-multilib if you don't want that, or install the 32buig glibc headers and libs if you want a compiler that can produce 32bit or 64bit output I think you should continue this on the gcc-help mailing list, there's no gcc bug here After installing the 32 bit headers it built cleanly. Thanks for your help. I'll let the Debian folks know that they need to give the packaging a look.
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #18 from Richard Henderson rth at gcc dot gnu.org 2011-04-03 02:57:45 UTC --- Both the first and second hunks are part of the same change.
[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48400 --- Comment #19 from Richard Henderson rth at gcc dot gnu.org 2011-04-03 03:06:35 UTC --- What are the changes *after* the second patch? The first two hunks ought to have disappeared.
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307 rfm at gnu dot org changed: What|Removed |Added Attachment #23702|0 |1 is obsolete|| --- Comment #9 from rfm at gnu dot org 2011-04-03 04:40:27 UTC --- Created attachment 23857 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23857 Revised/improved patch against svn trunk Here's a new version of the patch. This adds support for the new runtime function class_respondsToSelector()which was previously not considered as it was added to the runtime after the original fic for this bug. This patch also fixes a completely unrelated possible bug that class_respondsToSelector() and __objc_responds_to() were not necessarily returning OjC BOOL values (ie could in theory return values other than 0 or 1).
