[Bug bootstrap/43625] New: Revision 157851 has broken build on pure 64bit AMD64 systems

Beginning with revision 157851 the configure script no longer honours --disable-multilib flag and attempts to compile 32bit libgcc. On pure 64bit systems (e.g. Slackware64) this results in # If this is the top-level multilib, build all the other # multilibs. /home/artem/testing/gcc-build/./gcc/xgc

[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory

--- Comment #10 from rwild at gcc dot gnu dot org 2010-04-02 07:32 --- *** Bug 43625 has been marked as a duplicate of this bug. *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added --

[Bug bootstrap/43625] Revision 157851 has broken build on pure 64bit AMD64 systems

--- Comment #1 from rwild at gcc dot gnu dot org 2010-04-02 07:32 --- *** This bug has been marked as a duplicate of 43615 *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added --

[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation

--- Comment #19 from rwild at gcc dot gnu dot org 2010-04-02 07:49 --- Subject: Bug 43531 Author: rwild Date: Fri Apr 2 07:49:06 2010 New Revision: 157941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157941 Log: Revert: Fix dependency of out_object_file on gt header for out_f

[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation

--- Comment #20 from rwild at gcc dot gnu dot org 2010-04-02 08:01 --- Is this fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #19 from ramana at gcc dot gnu dot org 2010-04-02 08:07 --- A bootstrap on an A9 board last night with : /home/ramrad01/trunk/configure --enable-languages=c --with-mode=thumb --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp using gcc version 4.5.0 20100401 (ex

[Bug c/43626] New: No locale support for Kosovo

GNU seems to be limited by political organization called United Nations because ISO only adds countries members of UN. GNU does not have the freedom to add locale support for non-UN countries. Kosovo is one such case. FLOSSK.org is having hard time adding locale support to free/libre software solu

[Bug tree-optimization/43627] New: [4.5 Regression] slow compilation

The to-be-attached file compiles very slowly with 4.5: 4.3 ([gcc-4_3-branch revision 135036]): 37s 4.4 ([gcc-4_4-branch revision 150482]): 30s 4.5 ([trunk revision 157940]):6m35s gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -c hog.f90 --

[Bug tree-optimization/43627] [4.5 Regression] slow compilation

--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-02 08:16 --- Created an attachment (id=20287) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20287&action=view) testcase reproduce with gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native

[Bug tree-optimization/43627] [4.5 Regression] slow compilation

-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )

--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-02 08:27 --- And a timing report as well (notice the machine is not fully idle). The major consumer is tree canonical. Execution times (seconds) garbage collection: 7.71 ( 2%) usr 0.07 ( 4%) sys 14.12 ( 2%) wall 0 kB

[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2

--- Comment #8 from rearnsha at gcc dot gnu dot org 2010-04-02 08:32 --- Subject: Bug 43469 Author: rearnsha Date: Fri Apr 2 08:32:00 2010 New Revision: 157942 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157942 Log: PR target/43469 * arm.c (legitimize_tls_ad

[Bug target/43469] [4.5 Regression] ICE trying to compile glibc for ARM thumb2

--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-02 08:36 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )

--- Comment #3 from steven at gcc dot gnu dot org 2010-04-02 09:18 --- This tells me you are comparing apples and cows: "Extra diagnostic checks enabled; compiler may run slowly." Could you try again with a compiler configured with --enable=checking=release? -- steven at gcc dot gnu

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )

--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 09:26 --- (In reply to comment #3) > This tells me you are comparing apples and cows: "Extra diagnostic checks > enabled; compiler may run slowly." > > Could you try again with a compiler configured with --enable=checking=release

[Bug translation/43626] No locale support for Kosovo

--- Comment #1 from steven at gcc dot gnu dot org 2010-04-02 09:29 --- The GCC project is not responsible for its own translations. You should take this proposal to the GNU translation project (or http://translationproject.org). -- steven at gcc dot gnu dot org changed: W

[Bug debug/43628] New: [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type

; -- produce on g++ (GCC) 4.4.4 20100402 (prerelease) <1><44>: Abbrev Number: 4 (DW_TAG_subroutine_type) <2><49>: Abbrev Number: 5 (DW_TAG_formal_parameter) <4a> DW_AT_type: <0x2d>

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-02 09:37 --- Sorry if I'm misunderstanding what you are saying, but, first, I should point out that a baseline is a **baseline**, not something you update from time to time at will. Eg, the x86_64-linux baseline is certainl

[Bug c/43629] New: Struct to register optimization fails

Hello, It seems that when a structure is 64bit large the optimizer uses a register to store it, but does not managed the initialization of the fields properly, leading to a wrong result at the end. Here is my test case: cat main.c struct A { short A1 ; short A2 ; int A3 ; }; extern vo

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv )

--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-02 09:47 --- (In reply to comment #3) cows with cows now (i.e. --enable-checking=release), on an idle machine. Execution times (seconds) garbage collection: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall 0 kB ( 0%)

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot |

[Bug other/43617] cloog-ppl 0.15.9's configure corrupts with funny codes

--- Comment #4 from aflyhorse at foxmail dot com 2010-04-02 10:33 --- (In reply to comment #3) > (In reply to comment #2) > > I configured it with: > > ../src/configure --build=x86_64-w64-mingw32 --with-ppl="" --with-gmp="" > > --prefix="" > that can't be right Why? I had also configure

[Bug c++/43621] [4.5 Regression] ICE: in poplevel_class, at cp/name-lookup.c:2615 with invalid qualified name

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43621

[Bug tree-optimization/43629] [4.3/4.4 Regression] Struct to register optimization fails

--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-02 11:31 --- Confirmed. Yet another SRA to bitfield magic issue. Workaround: -fno-tree-sra. struct A { short A1 ; short A2 ; int A3 ; }; static struct A __attribute__((noinline)) foo(int b) { struct A result;

[Bug c++/43601] Enormous increase in DLL object files size in 4.5

--- Comment #8 from bangerth at gmail dot com 2010-04-02 11:37 --- I think this is a bug the MingW maintainers should handle. While I understand Andrew's position, it seems to me that this is nevertheless a definite regression from the user's perspective. W. -- bangerth at gmail do

[Bug tree-optimization/43629] [4.3/4.4 Regression] Struct to register optimization fails

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-02 11:47 --- SRA introduces a use of the uninitialized value when re-constructing the unsigned long representation. That boils down to later CCP recognizing the result as undefined and thus: Visiting statement: SR.16_25 = (unsi

[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation

--- Comment #21 from corsepiu at gcc dot gnu dot org 2010-04-02 11:48 --- (In reply to comment #20) > Is this fixed now? Partially, I'd say. The hard-breakdown due is gone, but now I am observing another bug: T=`${PWDCMD-pwd}`/ \ && cd ../../.././gcc \ && make GCC_FOR_

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-02 11:59 --- It means that the C frontend did not properly merge the _rand_ctx types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug other/43620] Uploading to gnu.org will fail due to automake security issue

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-02 12:01 --- I think we want no-dist on the branches and an update on trunk (possibly adding no-dist to GCC local pieces anyway). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43620

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #20 from rguenth at gcc dot gnu dot org 2010-04-02 12:09 --- The obvious bug is that nonoverlapping_memrefs_p thinks that a NULL MEM_OFFSET is equal to MEM_OFFSET == const0_rtx. It is not, it's "unknown offset". The following should fix that. Index: gcc/alias.c ==

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #21 from rguenth at gcc dot gnu dot org 2010-04-02 12:15 --- Or rather the code tries to account for that but fails to notice that the spill-slot decl isn't really a decl. Thus the following is better: Index: gcc/alias.c

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-02 12:19 --- The issue is for certain the many manually unrolled loops and possibly the new autoinc code. What's your native arch? I can't reproduce this on a core i?86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug c++/43630] New: [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid template specialization

Command line: g++ testcase.C Tested revisions: r157877 - crash 4.4 r157895 - crash 4.3.4 - crash (bails out, no checking) 3.4.6 - crash (bails out, no checking) 3.3.6 - OK (no checking) Valgrind output: $ valgrind -q --trace-children=yes /mnt/svn/gcc-trunk/binary-157877-lto/bin/g++ testcase.C tes

[Bug c++/43630] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid template specialization

--- Comment #1 from zsojka at seznam dot cz 2010-04-02 12:28 --- Created an attachment (id=20288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20288&action=view) reduced testcase It is very similiar to pr34491, but it segfaults instead of assert. -- http://gcc.gnu.org/bugzil

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-02 12:28 --- (In reply to comment #6) > What's your native arch? I can't reproduce this on a core i?86. -v output: /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951 hog.f90 -march=k8-sse3 -mcx16 -msa

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #22 from rguenth at gcc dot gnu dot org 2010-04-02 12:33 --- Or a combination of both. In particular the code doesn't account for the negative offsets we offset the spill-slot decl with when trying to handle a NULL MEM_OFFSET conservatively. I wonder what sizex / sizey is

[Bug other/43620] Uploading to gnu.org will fail due to automake security issue

--- Comment #4 from rwild at gcc dot gnu dot org 2010-04-02 12:40 --- (In reply to comment #3) > I think we want no-dist on the branches and an update on trunk (possibly > adding no-dist to GCC local pieces anyway). Is that an approval for

[Bug other/43620] Uploading to gnu.org will fail due to automake security issue

--- Comment #5 from rguenther at suse dot de 2010-04-02 12:44 --- Subject: Re: Uploading to gnu.org will fail due to automake security issue On Fri, 2 Apr 2010, rwild at gcc dot gnu dot org wrote: > > > --- Comment #4 from rwild at gcc dot gnu dot org 2010-04-02 12:40 ---

[Bug c++/43630] [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid template specialization

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43630

[Bug tree-optimization/43629] [4.3/4.4/4.5 Regression] Struct to register optimization fails

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-02 12:50 --- Really a CCP bug. int flag; extern void abort (void); int main() { int x; if (flag) x = -1; else x &= 0xff; if (x & ~0xff) abort (); return 0; } -- rguenth at gcc dot gnu dot org changed:

[Bug c++/43621] [4.5 Regression] ICE: in poplevel_class, at cp/name-lookup.c:2615 with invalid qualified name

--- Comment #2 from jason at gcc dot gnu dot org 2010-04-02 12:58 --- Created an attachment (id=20289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20289&action=view) patch Here's a patch for when 4.5 unfreezes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43621

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #23 from rguenth at gcc dot gnu dot org 2010-04-02 13:54 --- (In reply to comment #17) > So what is happening is that the cfg cleanup pass in the CSA pass is merging > the tails of two basic blocks. These blocks both contain an insn that loads a > DI value into R0/R1 from t

[Bug c++/41796] ambiguous subobject diagnostic given too early

--- Comment #6 from schaub-johannes at web dot de 2010-04-02 14:02 --- (In reply to comment #4) > Thanks for pointing out that this has changed since C++03, though the change > was to fix to something that was clearly broken. > > In any case, I disagree with issue 983. The point of the

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-02 14:07 --- Confirmed on x86_64-linux with -O2 -fbounds-check. find_loop_niter_by_eval takes a lot of time in each of the ints2bits_* routines because the loops have a lot of exits (due to -fbounds-check). -- rguenth at gcc

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-02 14:07 --- Created an attachment (id=20290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view) smaller testcase (needs 3s, 80% in tree canonical iv) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-02 14:08 --- Created an attachment (id=20291) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20291&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-02 14:13 --- Compared to 4.4 we no longer eliminate most of the bound checks in 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-02 14:17 --- (In reply to comment #9) > Created an attachment (id=20290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view) [edit] > smaller testcase (needs 3s, 80% in tree canonical iv) from valgrind, I see som

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-02 14:23 --- Testcase for that: MODULE hfx_compression_core_methods IMPLICIT NONE INTEGER, PARAMETER :: int_8=8 CONTAINS SUBROUTINE ints2bits_3(Ndata,packed_data,full_data) INTEGER, INTENT(IN)

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #14 from rguenth at gcc dot gnu dot org 2010-04-02 14:26 --- Interestingly it works on i?86 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #15 from rguenth at gcc dot gnu dot org 2010-04-02 14:39 --- C testcase for the missed VRP, fails with long on x86_64 only, with long long also on i?86: extern void link_error (void) __attribute__((noreturn)); int n; float *x; int main() { if (n > 0) { int i = 0

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-02 14:53 --- It's the strict-overflow stuff that cripples VRP again here. I have a kludge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug tree-optimization/43629] [4.3/4.4/4.5 Regression] Struct to register optimization fails

--- Comment #4 from julien dot etienne at gmail dot com 2010-04-02 15:03 --- What about using -O1 -fno-tree-ccp as a workaround rather than -O1 -fno-tree-rsa ? Isn't it more efficient and more related to the root cause ? Thanks for your help. FYI: I was unable to check out the trunk d

[Bug tree-optimization/43629] [4.3/4.4/4.5 Regression] Struct to register optimization fails

--- Comment #5 from rguenther at suse dot de 2010-04-02 15:04 --- Subject: Re: [4.3/4.4/4.5 Regression] Struct to register optimization fails On Fri, 2 Apr 2010, julien dot etienne at gmail dot com wrote: > --- Comment #4 from julien dot etienne at gmail dot com 2010-04-02 15:03

[Bug tree-optimization/43627] [4.5 Regression] slow compilation (tree canonical iv takes 75%)

--- Comment #17 from rguenth at gcc dot gnu dot org 2010-04-02 15:10 --- Created an attachment (id=20292) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20292&action=view) minimal patch I'm testing this minimal patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #24 from rguenth at gcc dot gnu dot org 2010-04-02 15:20 --- Alternative patch as suggested by Richard on IRC - it doesn't make sense to retain MEM_EXPR w/o MEM_OFFSET. Index: gcc/cfgcleanup.c === --- gcc/cfgcl

[Bug middle-end/43631] New: var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks

Seen on ia64-unknown-linux, but probably reproducible elsewhere, also: $ cat t.c typedef unsigned int UDItype __attribute__ ((mode (DI))); typedef int TItype __attribute__ ((mode (TI))); struct DWstruct {UDItype low, high;}; typedef union { struct DWstruct s; TItype ll; } DWunion; TItype __m

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

--- Comment #25 from rguenth at gcc dot gnu dot org 2010-04-02 16:14 --- Ok, I reproduced the issue and comment #22 looks like the correct fix. merge_memattrs is doing the right thing, just nonoverlapping_memrefs_p conservative fallback for NULL MEM_OFFSET assumes DECLs are not offsette

[Bug c++/43621] [4.5 Regression] ICE: in poplevel_class, at cp/name-lookup.c:2615 with invalid qualified name

-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org

[Bug translation/43626] No locale support for Kosovo

--- Comment #2 from joseph at codesourcery dot com 2010-04-02 16:19 --- Subject: Re: New: No locale support for Kosovo Note that the existence of a zh_TW language team http://translationproject.org/team/zh_TW.html and associated translations for GCC shows that there is no restriction

[Bug tree-optimization/43629] [4.3/4.4/4.5 Regression] Struct to register optimization fails

--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-02 16:50 --- Subject: Bug 43629 Author: rguenth Date: Fri Apr 2 16:50:04 2010 New Revision: 157944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157944 Log: 2010-04-02 Richard Guenther PR tree-optimization/

[Bug tree-optimization/43629] [4.3/4.4 Regression] Struct to register optimization fails

--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-02 16:50 --- Fixed for 4.5 sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to

[Bug debug/43628] [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type

-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org

[Bug tree-optimization/43611] [4.5 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions

--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-02 17:43 --- The patch probably only papers over the problem. Honza, can you have a look here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43611

[Bug other/43620] Uploading to gnu.org will fail due to automake security issue

--- Comment #6 from rwild at gcc dot gnu dot org 2010-04-02 18:18 --- Subject: Bug 43620 Author: rwild Date: Fri Apr 2 18:18:06 2010 New Revision: 157949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157949 Log: Update to Automake 1.11.1. gcc/: PR other/43620

[Bug translation/43626] No locale support for Kosovo

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-02 18:53 --- Also locale support is in glibc and not in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43626

[Bug debug/43628] [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type

--- Comment #1 from dodji at gcc dot gnu dot org 2010-04-02 19:09 --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00100.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628

[Bug c++/43632] New: -g option became very slow after r157834

$ svn up -r157834 ~/src/gcc ... $ make -C ~/src/gcc install ... $ time g++ -std=c++0x -O2 -c test.cpp -g real4m47.882s user4m47.226s sys 0m0.577s $ time g++ -std=c++0x -O2 -c test.cpp real0m28.247s user0m27.935s sys 0m0.282s For comparison: $ svn up -r157833 ~/src/gcc ...

[Bug c++/43632] -g option became very slow after r157834

--- Comment #1 from roman at binarylife dot net 2010-04-02 19:42 --- Created an attachment (id=20293) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20293&action=view) test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug tree-optimization/43629] [4.3/4.4 Regression] Struct to register optimization fails

--- Comment #8 from julien dot etienne at gmail dot com 2010-04-02 20:12 --- Thanks for your help. I will try the 4.5.0 version as soon as I can access svn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629

[Bug c++/43632] -g option became very slow after r157834

--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-02 20:24 --- The function is huge, > 2000 basic blocks, tracking almost 7000 preserved VALUEs. Most of the time is spent in vt_find_locations (understandably with so many bbs), but the hash table sizes don't grow quickly enough to

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #3 from davem at davemloft dot net 2010-04-02 20:25 --- Sorry, I overlooked that I'd been building with --disable-nls, I'll rebuild with --enable-nls and see how things look after that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-02 20:26 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-02 20:39 --- I don't think it can be the whole story. Please, double check that you have the required localedata installed, per: http://gcc.gnu.org/onlinedocs/libstdc++/manual/setup.html#manual.intro.setup.prereq and w

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-04-02 21:03 --- Another datapoint: I now get WARNING: program timed out. FAIL: gcc.c-torture/compile/limits-fnargs.c -O3 -g (test for excess errors) consistently on a somewhat old machine. It hadn't showed up for months (yea

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

--- Comment #20 from developer at sandoe-acoustics dot co dot uk 2010-04-02 21:15 --- (In reply to comment #18) > TREE_USED then? It looks to me like the problem is more subtle. I think it is to do with the fact that the emutls variables are proxies for the actual ones and that the pro

[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use

--- Comment #21 from developer at sandoe-acoustics dot co dot uk 2010-04-02 21:31 --- (In reply to comment #20) > I'm looking into those -- but would really welcome input from people who know > more about emutls. for example, is this really something that should be handled in some way

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #5 from davem at davemloft dot net 2010-04-02 21:42 --- I've double checked that I have the locales and everything installed. I'm building a fixed setup now, and I validated that "gnu" instead of "generic" is now choosen for the c++locale.h header file by libstdc++'s configu

[Bug bootstrap/43619] Bootstrap failure: "/lib/cpp" fails sanity check

--- Comment #11 from mckelvey at maskull dot com 2010-04-02 22:31 --- (In reply to comment #10) > (In reply to comment #8) > > > cygcheck shows a reference to a sjlj dll, > > Woah, deja vu! > > > although --disable-sjlj-exceptions is specified: > > So, you must still have the

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #6 from joseph at codesourcery dot com 2010-04-02 22:54 --- Subject: Re: FAIL: abi_check sparc --enable-nls ought not to affect the choice of locale model; it should be solely about translations of GCC's own messages. (If libstdc++'s messages were actually usefully trans

[Bug c/43633] New: sizeof returns wrong size for large long long values when using -std=c99

If I compile a program with -std=c99 and do a sizeof of a constant that is larger then LONG_LONG_MAX but smaller then ULONG_LONG_MAX I get 16 instead of 8. For values larger then ULONG_LONG_MAX I get 8. I can reproduce this on x86 Linux and IA64 HP-UX (and probably other systems).Here is a te

[Bug c/43633] sizeof returns wrong size for large long long values when using -std=c99

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-02 23:04 --- t.c:7:32: warning: integer constant is so large that it is unsigned t.c:9:32: warning: integer constant is so large that it is unsigned t.c:11:32: warning: integer constant is too large for its type -- http://gc

[Bug libstdc++/43634] New: std::string::replace with C string can replace too many characters

gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) basic_string::replace(size_type __pos, size_type __n1, const _CharT* __s) replaces length(__s) characters even if __n1http://www.cplusplus.com/reference/string/string/replace/ , or in Josuttis "The C++ Standard Library" (Addison Wesley). Su

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #1 from poftwaresatent at gmail dot com 2010-04-02 23:48 --- Created an attachment (id=20294) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20294&action=view) source file to trigger the bug and see that the workaround works -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #2 from poftwaresatent at gmail dot com 2010-04-02 23:49 --- Created an attachment (id=20295) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20295&action=view) .o from "g++ -v -save-temps ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #3 from poftwaresatent at gmail dot com 2010-04-02 23:49 --- Created an attachment (id=20296) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20296&action=view) .ii from "g++ -v -save-temps ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #4 from poftwaresatent at gmail dot com 2010-04-02 23:50 --- Created an attachment (id=20297) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20297&action=view) .s from "g++ -v -save-temps ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #5 from poftwaresatent at gmail dot com 2010-04-02 23:50 --- Created an attachment (id=20298) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20298&action=view) console output of "g++ -v -save-temps ..." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634

[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime

--- Comment #12 from mrs at gcc dot gnu dot org 2010-04-02 23:57 --- Ok. Ok for gcc-4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716

[Bug objc/35996] ICE while building simple ObjC code with -fobjc-gc

--- Comment #6 from mrs at gcc dot gnu dot org 2010-04-03 00:05 --- Ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-03 00:51 --- Our behavior is conforming to the C++03 ISO Standard, which we are implementing, see in particular 21.3.5.6/8. And, by the way, SunStudio, which uses a completely different run-time library behaves exactly the

[Bug libstdc++/43634] std::string::replace with C string can replace too many characters

--- Comment #7 from poftwaresatent at gmail dot com 2010-04-03 01:38 --- So, looks more like a documentation issue then, fine by me. Quote from basic_string.h: "Removes the characters in the range [pos,pos + n1) from this string. In place, the first @a n characters of @a s are inserted

[Bug libstdc++/43623] FAIL: abi_check sparc

--- Comment #7 from davem at davemloft dot net 2010-04-03 01:51 --- Ok, once I straightened out all of the locale issues the abi_check failure went away. Closing. -- davem at davemloft dot net changed: What|Removed |Added -