[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/xgcc -B/home/artem/testing/gcc-build/./gcc/ -B/home/artem/testing/gcc45/x86_64-slackware-linux/bin/ -B/home/artem/testing/gcc45/x86_64-slackware-linux/lib/ -isystem /home/artem/testing/gcc45/x86_64-slackware-linux/include -isystem /home/artem/testing/gcc45/x86_64-slackware-linux/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 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/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/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:371:0, from /usr/include/stdio.h:28, from ../../../../gcc/libgcc/../gcc/tsystem.h:87, from ../../../../gcc/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[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/home/artem/testing/gcc-build/x86_64-slackware-linux/32/libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/home/artem/testing/gcc-build/x86_64-slackware-linux/libgcc' make[2]: *** [all-multi] Error 2 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/home/artem/testing/gcc-build/x86_64-slackware-linux/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/artem/testing/gcc-build' make: *** [all] Error 2 I configured GCC with the following options: ../gcc/configure --prefix=/home/artem/testing/gcc45 --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls --verbose --with-arch=athlon64 --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-bootstrap --disable-multilib -- Summary: Revision 157851 has broken build on pure 64bit AMD64 systems Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: x86_64-slackware-linux GCC host triplet: x86_64-slackware-linux GCC target triplet: x86_64-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43625
[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 CC||aanisimov at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43625
[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=gccview=revrev=157941 Log: Revert: Fix dependency of out_object_file on gt header for out_file. gcc/: PR bootstrap/43531 Revert: 2009-09-28 Ralf Wildenhues ralf.wildenh...@gmx.de * Makefile.in ($(out_object_file)): Depend on gt-$(basename $(notdir $(out_file))).h. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[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 (experimental) [trunk revision 157933] (GCC) succeeded. So that's a heavy weight work-around which might cause perf. regressions for the ARM port because it effectively disables cross-jumping. Anyway more later. cheers Ramana -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 solutions in use in Kosovo. Kosovo is a country recognised by 65 countries, including US, and it is not a member of United Nation. For now Kosovo is using 'KV' as a two letter country code and its first official language is Albanian. https://www.cia.gov/library/publications/the-world-factbook/geos/kv.html Please add locale support for Kosovo 'KV', and for Kosovo Albanian language sq_KV. -- Summary: No locale support for Kosovo Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: agron_ca at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43626
[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 -- Summary: [4.5 Regression] slow compilation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[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=20287action=view) testcase reproduce with gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native -c hog.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[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 ( 0%) ggc callgraph construction: 0.18 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall 6675 kB ( 1%) ggc callgraph optimization: 0.61 ( 0%) usr 0.03 ( 2%) sys 0.61 ( 0%) wall 1655 kB ( 0%) ggc ipa cp: 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 539 kB ( 0%) ggc ipa reference : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.17 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc ipa SRA : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.78 ( 0%) usr 0.01 ( 1%) sys 1.27 ( 0%) wall 3661 kB ( 0%) ggc CFG verifier : 2.10 ( 1%) usr 0.00 ( 0%) sys 3.40 ( 1%) wall 0 kB ( 0%) ggc trivially dead code : 0.38 ( 0%) usr 0.00 ( 0%) sys 0.40 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.59 ( 0%) usr 0.00 ( 0%) sys 0.92 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.86 ( 0%) usr 0.00 ( 0%) sys 1.83 ( 0%) wall 0 kB ( 0%) ggc df live regs : 4.92 ( 1%) usr 0.01 ( 1%) sys 8.23 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 1.48 ( 0%) usr 0.01 ( 1%) sys 3.37 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.71 ( 0%) usr 0.00 ( 0%) sys 1.39 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.15 ( 1%) usr 0.01 ( 1%) sys 7.47 ( 1%) wall 9314 kB ( 1%) ggc register information : 1.29 ( 0%) usr 0.01 ( 1%) sys 3.00 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.64 ( 0%) usr 0.00 ( 0%) sys 0.74 ( 0%) wall 21770 kB ( 3%) ggc alias stmt walking: 1.94 ( 1%) usr 0.06 ( 4%) sys 3.50 ( 1%) wall 0 kB ( 0%) ggc register scan : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.26 ( 0%) wall 0 kB ( 0%) ggc parser: 1.27 ( 0%) usr 0.12 ( 7%) sys 1.50 ( 0%) wall 42200 kB ( 5%) ggc inline heuristics : 0.43 ( 0%) usr 0.02 ( 1%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.69 ( 0%) usr 0.03 ( 2%) sys 0.79 ( 0%) wall 52375 kB ( 6%) ggc tree eh : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 9418 kB ( 1%) ggc tree CFG cleanup : 0.49 ( 0%) usr 0.00 ( 0%) sys 0.80 ( 0%) wall 418 kB ( 0%) ggc tree VRP : 2.08 ( 1%) usr 0.05 ( 3%) sys 3.67 ( 1%) wall 54923 kB ( 7%) ggc tree copy propagation : 0.37 ( 0%) usr 0.00 ( 0%) sys 0.59 ( 0%) wall 237 kB ( 0%) ggc tree find ref. vars : 0.07 ( 0%) usr 0.02 ( 1%) sys 0.09 ( 0%) wall 3774 kB ( 0%) ggc tree PTA : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 425 kB ( 0%) ggc tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 315 kB ( 0%) ggc tree SSA rewrite : 0.44 ( 0%) usr 0.03 ( 2%) sys 0.80 ( 0%) wall 20682 kB ( 3%) ggc tree SSA other: 0.22 ( 0%) usr 0.02 ( 1%) sys 0.23 ( 0%) wall 434 kB ( 0%) ggc tree SSA incremental : 0.62 ( 0%) usr 0.04 ( 2%) sys 0.91 ( 0%) wall 438 kB ( 0%) ggc tree operand scan : 0.27 ( 0%) usr 0.14 ( 8%) sys 0.53 ( 0%) wall 21791 kB ( 3%) ggc dominator optimization: 0.42 ( 0%) usr 0.00 ( 0%) sys 0.72 ( 0%) wall 4190 kB ( 1%) ggc tree CCP : 0.56 ( 0%) usr 0.01 ( 1%) sys 0.70 ( 0%) wall 3081 kB ( 0%) ggc tree PHI const/copy prop: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 22 kB ( 0%) ggc tree split crit edges : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 3268 kB ( 0%) ggc tree reassociation: 0.17 ( 0%) usr 0.00 ( 0%) sys 0.36 ( 0%) wall 161 kB ( 0%) ggc tree PRE : 6.54 ( 2%) usr 0.02 ( 1%) sys 11.71 ( 2%) wall 25200 kB ( 3%) ggc tree FRE : 0.76 ( 0%) usr 0.03 ( 2%) sys 1.15 ( 0%) wall 8100 kB ( 1%) ggc tree code sinking : 0.23 ( 0%) usr 0.04 ( 2%) sys 0.44 ( 0%) wall 12275 kB ( 2%) ggc tree linearize phis : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.19 ( 0%) usr 0.01 ( 1%) sys 0.25 ( 0%) wall 9572 kB ( 1%) ggc tree phiprop : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.19 ( 0%) usr 0.02 ( 1%) sys 0.51 ( 0%) wall 17 kB ( 0%) ggc tree aggressive DCE : 0.49 ( 0%) usr 0.01 ( 1%) sys 0.74 ( 0%)
[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=gccview=revrev=157942 Log: PR target/43469 * arm.c (legitimize_tls_address): Adjust call to gen_tls_load_dot_plus_four. (arm_note_pic_base): New function. (arm_cannot_copy_insn_p): Use it. * thumb2.md (tls_load_dot_plus_four): Rework to avoid use of '+' in constraint. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/thumb2.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[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|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43469
[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 dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[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? I'll do now... for reference, 4.4 has: gfortran -ftime-report -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native hog.f90 Execution times (seconds) garbage collection: 0.15 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 0 kB ( 0%) ggc callgraph construction: 0.33 ( 1%) usr 0.03 ( 4%) sys 0.33 ( 1%) wall 9447 kB ( 2%) ggc callgraph optimization: 0.46 ( 2%) usr 0.01 ( 1%) sys 0.50 ( 2%) wall 239 kB ( 0%) ggc ipa cp: 0.22 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 0 kB ( 0%) ggc ipa reference : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 914 kB ( 0%) ggc trivially dead code : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc df live regs : 0.22 ( 1%) usr 0.00 ( 0%) sys 0.18 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.17 ( 1%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall 3443 kB ( 1%) ggc register information : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.14 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 6273 kB ( 1%) ggc register scan : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc parser: 1.27 ( 5%) usr 0.12 (16%) sys 1.31 ( 5%) wall 50936 kB ( 9%) ggc inline heuristics : 0.13 ( 1%) usr 0.05 ( 6%) sys 0.25 ( 1%) wall 0 kB ( 0%) ggc tree gimplify : 0.44 ( 2%) usr 0.04 ( 5%) sys 0.54 ( 2%) wall 61550 kB (11%) ggc tree eh : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 9734 kB ( 2%) ggc tree CFG cleanup : 0.28 ( 1%) usr 0.00 ( 0%) sys 0.18 ( 1%) wall 668 kB ( 0%) ggc tree VRP : 1.21 ( 5%) usr 0.03 ( 4%) sys 1.26 ( 5%) wall 42193 kB ( 8%) ggc tree copy propagation : 0.21 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 315 kB ( 0%) ggc tree find ref. vars : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 8937 kB ( 2%) ggc tree PTA : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 758 kB ( 0%) ggc tree alias analysis : 0.12 ( 0%) usr 0.05 ( 6%) sys 0.12 ( 0%) wall 77 kB ( 0%) ggc tree call clobbering : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 18 kB ( 0%) ggc tree flow sensitive alias: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 121 kB ( 0%) ggc tree flow insensitive alias: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree memory partitioning: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 21 kB ( 0%) ggc tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 201 kB ( 0%) ggc tree SSA rewrite : 0.17 ( 1%) usr 0.01 ( 1%) sys 0.13 ( 1%) wall 19668 kB ( 4%) ggc tree SSA other: 0.11 ( 0%) usr 0.03 ( 4%) sys 0.18 ( 1%) wall 360 kB ( 0%) ggc tree SSA incremental : 0.24 ( 1%) usr 0.02 ( 3%) sys 0.25 ( 1%) wall 40 kB ( 0%) ggc tree operand scan : 0.36 ( 1%) usr 0.15 (19%) sys 0.58 ( 2%) wall 27070 kB ( 5%) ggc dominator optimization: 0.26 ( 1%) usr 0.00 ( 0%) sys 0.14 ( 1%) wall 2270 kB ( 0%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.33 ( 1%) usr 0.01 ( 1%) sys 0.24 ( 1%) wall 4060 kB ( 1%) ggc tree reassociation: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 124 kB ( 0%) ggc tree PRE : 5.18 (21%) usr 0.05 ( 6%) sys 5.07 (20%) wall 87699 kB (16%) ggc tree FRE : 0.51 ( 2%) usr 0.00 ( 0%) sys 0.55 ( 2%) wall 7664 kB ( 1%) ggc tree code sinking : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 75 kB ( 0%) ggc tree linearize phis : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.11 ( 0%) usr 0.02 ( 3%) sys 0.11 ( 0%) wall 11274 kB ( 2%) ggc tree phiprop : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB (
[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: What|Removed |Added Severity|major |enhancement Status|UNCONFIRMED |RESOLVED Component|c |translation Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43626
[Bug debug/43628] New: [4.5 Regression] in-class func-ptr type parameter has unspecified DW_AT_type
Both these testcases:
--
class C {
public:
typedef void (*t) (C);
};
C::t f;
--
class C {
public:
typedef void (*t) (C);
t v;
} c;
--
produce on
g++ (GCC) 4.4.4 20100402 (prerelease)
144: Abbrev Number: 4 (DW_TAG_subroutine_type)
249: Abbrev Number: 5 (DW_TAG_formal_parameter)
4a DW_AT_type: 0x2d
but on
g++ (GCC) 4.5.0 20100402 (experimental)
153: Abbrev Number: 6 (DW_TAG_subroutine_type)
258: Abbrev Number: 7 (DW_TAG_formal_parameter)
--
Summary: [4.5 Regression] in-class func-ptr type parameter has
unspecified DW_AT_type
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628
[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 certainly much older, and works perfectly ok. That said, I had a quick look to the failures and seem to me very similar to the failures I obtain on x86_64-linux if I onfigure with --enable-clocale=generic, thus overriding the normal choice of the gnu locale model. Isn't the case that on the sparc machine at issue the required localedata is missing and the configury falls back to generic? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
[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 void* bar(void);
static struct A foo(void) __attribute__ ((noinline));
static struct A foo(void)
{
struct A result;
void *pB;
result.A1 = (short)0;
result.A2 = (short)0;
/* The next field is intentionally not initialized */
/* result.A3 = 0; */
pB = bar(); /* always return (void*)1 to highlight the bug */
if (pB == ((void *)0)) {
/* Should never been triggered at run time */
result.A1 = (short)1;
result.A2 = (short)2;
result.A3 = 3;
return result;
}
/* result.A1 should be (short)0 */
return result;
}
int main(){
struct A myA = foo();
return (int)myA.A1; /* should always return 0 by design */
}
cat bar.c
void* bar(void){
return (void*)1;
}
Compilation with -O0 works and the return status is 0 as expected:
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc -O0 -Wall -c -o main.o
main.c
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc -O0 -Wall -c -o bar.o
bar.c
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc main.o bar.o -o main
./main
echo $?
0
Compilation with -O1 works but the return status is 1 due to the bug:
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc -O1 -Wall -c -o main.o
main.c
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc -O1 -Wall -c -o bar.o
bar.c
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc main.o bar.o -o main
./main
echo $?
1
As the code is deterministic the result should have been 0 in both cases.
The disassembly of main.o file makes it pretty clear that the generated
optimized code is wrong:
objdump -d main.o
main.o: file format elf64-x86-64
Disassembly of section .text:
foo:
0: 48 83 ec 08 sub$0x8,%rsp
4: e8 00 00 00 00 callq 9 foo+0x9
9: 48 b8 01 00 02 00 03mov$0x300020001,%rax Value always
returned
10: 00 00 00
13: 48 83 c4 08 add$0x8,%rsp
17: c3 retq
0018 main:
18: 48 83 ec 08 sub$0x8,%rsp
1c: e8 df ff ff ff callq 0 foo
21: 98 cwtl
22: 48 83 c4 08 add$0x8,%rsp
26: c3 retq
As you can see in all cases the returned value of function foo is set by mov
$0x300020001,%rax whereas there should also be 2 cases.
My gcc version:
/projects/dsr/work/jetienne/softs/gcc-4.4.3/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
--prefix=/projects/dsr/work/jetienne/softs/gcc-4.4.3 --enable-languages=c,c++
--with-mpfr=/tools/mpfr-2.4.2
Thread model: posix
gcc version 4.4.3 (GCC)
FYI I tried several gcc versions, here are the status:
- gcc 3.4.5 works
- gcc 4.1.2 works
- gcc 4.3.2 does not work
- gcc 4.4.3 does not work
I am testing the svn trunk at the moment I will get back to you with my result.
Best Regards,
Julien
--
Summary: Struct to register optimization fails
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: julien dot etienne at gmail dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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%) ggc callgraph construction: 0.11 ( 0%) usr 0.01 ( 1%) sys 0.12 ( 0%) wall 5939 kB ( 1%) ggc callgraph optimization: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 184 kB ( 0%) ggc ipa cp: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 539 kB ( 0%) ggc ipa reference : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 0.09 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc cfg cleanup : 0.67 ( 0%) usr 0.00 ( 0%) sys 0.83 ( 0%) wall 3661 kB ( 1%) ggc trivially dead code : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc df multiple defs : 0.35 ( 0%) usr 0.00 ( 0%) sys 0.36 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.69 ( 0%) usr 0.00 ( 0%) sys 0.65 ( 0%) wall 0 kB ( 0%) ggc df live regs : 3.08 ( 1%) usr 0.00 ( 0%) sys 3.07 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 1.17 ( 0%) usr 0.00 ( 0%) sys 1.07 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.53 ( 0%) usr 0.00 ( 0%) sys 0.35 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 2.50 ( 1%) usr 0.00 ( 0%) sys 2.73 ( 1%) wall 9314 kB ( 1%) ggc register information : 1.05 ( 0%) usr 0.00 ( 0%) sys 0.84 ( 0%) wall 0 kB ( 0%) ggc alias analysis: 0.58 ( 0%) usr 0.00 ( 0%) sys 0.61 ( 0%) wall 21770 kB ( 3%) ggc alias stmt walking: 1.29 ( 0%) usr 0.04 ( 4%) sys 1.36 ( 0%) wall 0 kB ( 0%) ggc register scan : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.25 ( 0%) wall 0 kB ( 0%) ggc parser: 1.15 ( 0%) usr 0.12 (11%) sys 1.26 ( 0%) wall 42200 kB ( 6%) ggc inline heuristics : 0.24 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.43 ( 0%) usr 0.05 ( 4%) sys 0.47 ( 0%) wall 52375 kB ( 8%) ggc tree eh : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 9418 kB ( 1%) ggc tree CFG cleanup : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.46 ( 0%) wall 418 kB ( 0%) ggc tree VRP : 1.57 ( 1%) usr 0.06 ( 5%) sys 1.60 ( 1%) wall 54731 kB ( 8%) ggc tree copy propagation : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.29 ( 0%) wall 237 kB ( 0%) ggc tree find ref. vars : 0.03 ( 0%) usr 0.01 ( 1%) sys 0.10 ( 0%) wall 3774 kB ( 1%) ggc tree PTA : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 423 kB ( 0%) ggc tree PHI insertion: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 315 kB ( 0%) ggc tree SSA rewrite : 0.24 ( 0%) usr 0.02 ( 2%) sys 0.19 ( 0%) wall 20682 kB ( 3%) ggc tree SSA other: 0.10 ( 0%) usr 0.04 ( 4%) sys 0.19 ( 0%) wall 434 kB ( 0%) ggc tree SSA incremental : 0.56 ( 0%) usr 0.02 ( 2%) sys 0.66 ( 0%) wall 438 kB ( 0%) ggc tree operand scan : 0.21 ( 0%) usr 0.20 (18%) sys 0.42 ( 0%) wall 21791 kB ( 3%) ggc dominator optimization: 0.35 ( 0%) usr 0.01 ( 1%) sys 0.36 ( 0%) wall 4189 kB ( 1%) ggc tree SRA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.49 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 3081 kB ( 0%) ggc tree PHI const/copy prop: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 22 kB ( 0%) ggc tree split crit edges : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 3265 kB ( 0%) ggc tree reassociation: 0.12 ( 0%) usr 0.01 ( 1%) sys 0.11 ( 0%) wall 161 kB ( 0%) ggc tree PRE : 4.88 ( 2%) usr 0.00 ( 0%) sys 4.89 ( 2%) wall 25200 kB ( 4%) ggc tree FRE : 0.65 ( 0%) usr 0.02 ( 2%) sys 0.67 ( 0%) wall 8099 kB ( 1%) ggc tree code sinking : 0.16 ( 0%) usr 0.05 ( 4%) sys 0.17 ( 0%) wall 12275 kB ( 2%) ggc tree linearize phis : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 9572 kB ( 1%) ggc tree phiprop : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.21 ( 0%) usr 0.03 ( 3%) sys 0.15 ( 0%) wall 17 kB ( 0%) ggc tree aggressive DCE : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 2998 kB ( 0%) ggc tree DSE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
[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 ||org Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-02 10:25:15 date|| Summary|[4.5 Regression] slow |[4.5 Regression] slow |compilation (tree canonical |compilation (tree canonical |iv ) |iv takes 75%) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
[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 configured the gmp, mpc, mpfr ppl with --prefix= But the code is really working, with --ppl=/lib (I don't know why because I used to use /local instead of /local/lib but no error found...) Thanks you all! I've change the bug as invalid. -- aflyhorse at foxmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43617
[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;
result.A1 = (short)0;
result.A2 = (short)0;
/* result.A3 is intentionally not initialized */
if (b) {
result.A1 = (short)1;
result.A2 = (short)2;
result.A3 = 3;
return result;
}
return result;
}
extern void abort (void);
int main()
{
struct A myA = foo(0);
if (myA.A1 != 0)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.3.0 4.3.4 4.4.0 4.4.3
Known to work||4.2.4 4.5.0
Last reconfirmed|-00-00 00:00:00 |2010-04-02 11:31:52
date||
Summary|Struct to register |[4.3/4.4 Regression] Struct
|optimization fails |to register optimization
||fails
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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 dot com changed: What|Removed |Added CC||bangerth at gmail dot com Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[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 = (unsigned int) result$A3_24(D); which is likely UNDEFINED Visiting statement: SR.17_26 = (long unsigned int) SR.16_25; which is likely UNDEFINED Visiting statement: SR.18_27 = SR.17_26 32; which is likely UNDEFINED Visiting statement: SR.3_34 = SR.18_27 0x0; which is likely UNDEFINED Visiting PHI node: SR.3_2 = PHI 12885032961(2), SR.3_34(3) Argument #0 (2 - 4 executable) 12885032961 Value: CONSTANT 12885032961 Argument #1 (3 - 4 executable) SR.3_34 Value: UNDEFINED PHI node value: CONSTANT 12885032961 Lattice value changed to CONSTANT 12885032961. and we completely ignore the taken path. One issue is that Visiting statement: SR.3_34 = SR.18_27 0x0; which is likely UNDEFINED is not 100% true - the value is only partially undefined (only the defined pieces will be used later). But of course that's splitting hairs somewhat (but it might be the easiest fix for this bug). tree-ssa-ccp.c:likely_value needs to look at regular rhs operands for literal constants (see trunk version) but also make sure to re-set all_undefined_operands if it encounters such. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-02 11:31:52 |2010-04-02 11:47:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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_TARGET=/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/xgcc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/ -isystem
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include
-isystem /opt/rtems-4.11/h8300-rtems4.11/sys-include\
MULTILIB_CFLAGS=-g -O2 -mh \
T=$T \
T_TARGET=${T}crtbegin.o ${T}crtend.o ${T}crti.o ${T}crtn.o \
T_TARGET
make[5]: Entering directory `/users/rtems/src/toolchains/gcc-trunk/BUILD/gcc'
/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/xgcc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/
-isystem
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include -
isystem /opt/rtems-4.11/h8300-rtems4.11/sys-include-O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I.
-I/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
-I../../gcc
-I../../gcc//users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
-I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-DCLOOG_PPL_BACKEND
-g -O2 -mh -g0 -finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-Dinhibit_libc \
-c ../../gcc/crtstuff.c -DCRT_BEGIN \
-o
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc/crtbegin.o
Note the
-I../../gcc//users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[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 === --- gcc/alias.c (revision 157942) +++ gcc/alias.c (working copy) @@ -2268,6 +2268,10 @@ nonoverlapping_memrefs_p (const_rtx x, c : MEM_SIZE (rtly) ? INTVAL (MEM_SIZE (rtly)) : -1); + /* If the offset is unknown we cannot determine anything. */ + if (!moffsetx || !moffsety) +return 0; + /* If we have an offset for either memref, it can update the values computed above. */ if (moffsetx) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 === --- gcc/alias.c (revision 157942) +++ gcc/alias.c (working copy) @@ -2147,6 +2147,11 @@ nonoverlapping_memrefs_p (const_rtx x, c if (exprx == 0 || expry == 0) return 0; + /* We can only handle real decls, not the fake spill slot. */ + if (exprx == get_spill_slot_decl (false) + || expry == get_spill_slot_decl (false)) +return 0; + /* If both are field references, we may be able to determine something. */ if (TREE_CODE (exprx) == COMPONENT_REF TREE_CODE (expry) == COMPONENT_REF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 testcase.C:3:30: error: template parameters not used in partial specialization: testcase.C:3:30: error: 'template-parameter-1-1' ==5113== Invalid read of size 8 ==5113==at 0x785580: size_binop_loc (fold-const.c:2157) ==5113==by 0x7D83FA: gimplify_compound_lval (gimplify.c:1987) ==5113==by 0x7D3BCF: gimplify_expr (gimplify.c:6569) ==5113==by 0x7E71C9: gimplify_modify_expr (gimplify.c:4460) ==5113==by 0x7D4B34: gimplify_expr (gimplify.c:6614) ==5113==by 0x7DB326: gimplify_stmt (gimplify.c:5264) ==5113==by 0x7DBD32: gimplify_and_add (gimplify.c:391) ==5113==by 0x7DCCDC: gimplify_return_expr (gimplify.c:1241) ==5113==by 0x7D41CE: gimplify_expr (gimplify.c:6763) ==5113==by 0x7DB326: gimplify_stmt (gimplify.c:5264) ==5113==by 0x7E7FFA: gimplify_body (gimplify.c:7523) ==5113==by 0x7E83E4: gimplify_function_tree (gimplify.c:7619) ==5113== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==5113== testcase.C: In member function 'int Aint::f()': testcase.C:11:10: 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. -- Summary: [4.3/4.4/4.5 Regression] ICE: SIGSEGV with invalid template specialization Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43630
[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=20288action=view) reduced testcase It is very similiar to pr34491, but it segfaults instead of assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43630
[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 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase hog.f90 -auxbase hog -g -O3 -version -fbounds-check -ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/finclude -o /tmp/ccA2YvFn.s -- 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 #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 for the spill-slot-decl, or rather what mode or size it has ... Least pessimizing patch follows, it looks like nobody else would disambiguate spill slots otherwise (apart from the tree oracle calls). Index: gcc/alias.c === --- gcc/alias.c (revision 157942) +++ gcc/alias.c (working copy) @@ -2147,6 +2147,13 @@ nonoverlapping_memrefs_p (const_rtx x, c if (exprx == 0 || expry == 0) return 0; + /* For spill-slot accesses make sure we have valid offsets. */ + if ((exprx == get_spill_slot_decl (false) +! MEM_OFFSET (x)) + || (expry == get_spill_slot_decl (false) + ! MEM_OFFSET (y))) +return 0; + /* If both are field references, we may be able to determine something. */ if (TREE_CODE (exprx) == COMPONENT_REF TREE_CODE (expry) == COMPONENT_REF -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00059.html ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43620
[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 --- (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 http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00059.html ? I can't approve it. It's approved from a RM point - let me followup on that thread. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43620
[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:
What|Removed |Added
Summary|[4.3/4.4 Regression] Struct |[4.3/4.4/4.5 Regression]
|to register optimization|Struct to register
|fails |optimization fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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=20289action=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 the address in R1. Because the 'base' values for the two loads are different (and the calculation for that is not merged), merge_memattrs squishes the MEM_OFFSET field, setting it to NULL_RTX. The BBRO pass then splits this set of insns up again and puts them back in their original BBs. Finally the scheduling pass runs and calls nonoverlapping_memrefs_p on the load instruction and a preceding store. That then appears to assume that the two memory accesses cannot overlap and thus cannot alias each other; and finally the scheduler moves the store after the load. This smells very generic to me so setting back to P3 for release maintainer review. In addition to making nonoverlapping_memrefs_p more robust here I wonder how we ended up with mismatching MEM_OFFSETs in the first place. Anyway, it would be nice if somebody could verify if the patch in comment #22 fixes the issue on the arm. I will bootstrap test it on x86_64 today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 example is that it doesn't matter what subobject it refers to, as the type of D::i is 'int B::*'. I notified Daniel Kruegler about this, since the DR got CD2 status. He replied that you might want to consider reopening it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41796
[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 dot gnu dot org changed: What|Removed |Added GCC target triplet||x86_64-*-* 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 #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=20290action=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=20291action=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=20290action=view) [edit] smaller testcase (needs 3s, 80% in tree canonical iv) from valgrind, I see some 1300 cals to get_val_for / fold_binary_loc, for the small 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 #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) :: Ndata INTEGER(KIND=int_8), INTENT(OUT) :: packed_data(*) INTEGER(KIND=int_8), INTENT(IN) :: full_data(*) INTEGER, PARAMETER :: Nbits = 3 INTEGER :: idata, ipack, kdata, Ndata_rep INTEGER(KIND=int_8) :: data_tmp, pack_tmp idata=0 ipack=0 Ndata_rep=(Ndata/2)*2 DO kdata=1,Ndata_rep,2 pack_tmp=0 idata=idata+1 data_tmp = full_data(idata) data_tmp = ISHFT(data_tmp,61) pack_tmp = IOR(pack_tmp,data_tmp) pack_tmp = ISHFT(pack_tmp,-3) idata=idata+1 data_tmp = full_data(idata) data_tmp = ISHFT(data_tmp,61) pack_tmp = IOR(pack_tmp,data_tmp) pack_tmp = ISHFT(pack_tmp,0) pack_tmp = ISHFT(pack_tmp,0) ipack = ipack + 1 packed_data(ipack) = pack_tmp ENDDO END SUBROUTINE ints2bits_3 END MODULE hfx_compression_core_methods likely caused by 2010-02-16 Richard Guenther rguent...@suse.de PR tree-optimization/41043 * tree-vrp.c (vrp_var_may_overflow): Only ask SCEV for real loops. (vrp_visit_assignment_or_call): Do not ask SCEV for regular statements ... (vrp_visit_phi_node): ... but only for loop PHI nodes. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-04-02 10:25:15 |2010-04-02 14:23:22 date|| 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 #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;
do
{
long index;
i = i + 1;
index = i;
if (index = 0)
link_error ();
x[index] = 0;
i = i + 1;
index = i;
if (index = 0)
link_error ();
x[index] = 0;
}
while (i n);
}
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
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 #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 due to firewall restriction (even on http). I will try it from another connection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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 --- 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 due to firewall restriction (even on http). I will try it from another connection. Disabling constant propagation is going to affect code quality a lot more (and might uncover latent bugs). Anyway, I have a patch for trunk already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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=20292action=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/cfgcleanup.c(revision 157942)
+++ gcc/cfgcleanup.c(working copy)
@@ -891,18 +891,14 @@ merge_memattrs (rtx x, rtx y)
set_mem_alias_set (y, 0);
}
- if (! mem_expr_equal_p (MEM_EXPR (x), MEM_EXPR (y)))
+ if (! mem_expr_equal_p (MEM_EXPR (x), MEM_EXPR (y))
+ || MEM_OFFSET (x) != MEM_OFFSET (y))
{
set_mem_expr (x, 0);
set_mem_expr (y, 0);
set_mem_offset (x, 0);
set_mem_offset (y, 0);
}
- else if (MEM_OFFSET (x) != MEM_OFFSET (y))
- {
- set_mem_offset (x, 0);
- set_mem_offset (y, 0);
- }
if (!MEM_SIZE (x))
mem_size = NULL_RTX;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|rguenther at suse dot de|jakub at gcc dot gnu dot
||org, rguenth at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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
__multi3 (TItype u, TItype v)
{
const DWunion uu = {.ll = u};
const DWunion vv = {.ll = v};
DWunion w = {.ll = ({DWunion __w; __asm__ (xma.hu %0 = %2, %3, f0\n\txma.l
%1 = %2, %3, f0 : =f (__w.s.high), =f (__w.s.low) : f (uu.s.low), f
(vv.s.low)); __w.ll; })};
w.s.high += (uu.s.low * vv.s.high + uu.s.high * vv.s.low);
return w.ll;
}
$ ./cc1 -quiet -g -O2 t.c
t.c: In function '__multi3':
t.c:19:1: error: insn 111 outside of basic blocks has non-NULL bb field
t.c:19:1: error: insn 110 outside of basic blocks has non-NULL bb field
t.c:19: confused by earlier errors, bailing out
Needs a patch to var-tracking.c to expose the problem:
Index: var-tracking.c
===
--- var-tracking.c (revision 157942)
+++ var-tracking.c (working copy)
@@ -115,6 +115,8 @@
#include pointer-set.h
#include recog.h
+#undef ENABLE_CHECKING
+#define ENABLE_CHECKING 1
/* var-tracking.c assumes that tree code with the same value as VALUE rtx code
has no chance to appear in REG_EXPR/MEM_EXPRs and isn't a decl.
Currently the value is the same as IDENTIFIER_NODE, which has such
@@ -8489,6 +8491,7 @@ variable_tracking_main (void)
flag_var_tracking_assignments = save;
+ verify_flow_info ();
return ret;
}
This comes from emit_notes_for_differences. I have no idea what the purpose is
of the notes between basic blocks. Apparently the CFG has to be frozen at this
point, or the notes make no sense to begin with. But it's also not clear to me
where the notes should be emitted.
Help sought from a VTA guy, i.e. Jakub or Alexandre :-)
--
Summary: var-tracking inserts notes with non-NULL BLOCK_FOR_INSN
in between basic blocks
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631
[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 offsetted with negative offsets - which is not true for the spill slot decl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[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 | Status|NEW |ASSIGNED Last reconfirmed|2010-04-02 02:38:03 |2010-04-02 16:17:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43621
[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 to UN member states. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43626
[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=gccview=revrev=157944 Log: 2010-04-02 Richard Guenther rguent...@suse.de PR tree-optimization/43629 * tree-ssa-ccp.c (likely_value): Reset all_undefined_operands if we have seen a constant value. * gcc.c-torture/execute/pr43629.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr43629.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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 fail|4.3.0 4.3.4 4.4.0 4.4.3 |4.3.0 4.3.4 4.4.0 4.4.3 |4.5.0 | Known to work|4.2.4 |4.2.4 4.5.0 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] Struct |Struct to register |to register optimization |optimization fails |fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629
[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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-02 16:57:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43628
[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=gccview=revrev=157949 Log: Update to Automake 1.11.1. gcc/: PR other/43620 * doc/install.texi (Prerequisites): Bump Automake version to 1.11.1. * aclocal.m4: Regenerate. lto-plugin/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. intl/: * aclocal.m4: Regenerate. boehm-gc/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * include/Makefile.in: Regenerate. fixincludes/: * aclocal.m4: Regenerate. libcpp/: * aclocal.m4: Regenerate. libdecnumber/: * aclocal.m4: Regenerate. libffi/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * include/Makefile.in: Regenerate. * man/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libgfortran/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. libgomp/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * testsuite/Makefile.in: Regenerate. libjava/classpath/: * HACKING: Update required Automake version. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * doc/Makefile.in: Regenerate. * doc/api/Makefile.in: Regenerate. * examples/Makefile.in: Regenerate. * external/Makefile.in: Regenerate. * external/jsr166/Makefile.in: Regenerate. * external/relaxngDatatype/Makefile.in: Regenerate. * external/sax/Makefile.in: Regenerate. * external/w3c_dom/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * lib/Makefile.in: Regenerate. * native/Makefile.in: Regenerate. * native/fdlibm/Makefile.in: Regenerate. * native/jawt/Makefile.in: Regenerate. * native/jni/Makefile.in: Regenerate. * native/jni/classpath/Makefile.in: Regenerate. * native/jni/gconf-peer/Makefile.in: Regenerate. * native/jni/gstreamer-peer/Makefile.in: Regenerate. * native/jni/gtk-peer/Makefile.in: Regenerate. * native/jni/java-io/Makefile.in: Regenerate. * native/jni/java-lang/Makefile.in: Regenerate. * native/jni/java-math/Makefile.in: Regenerate. * native/jni/java-net/Makefile.in: Regenerate. * native/jni/java-nio/Makefile.in: Regenerate. * native/jni/java-util/Makefile.in: Regenerate. * native/jni/midi-alsa/Makefile.in: Regenerate. * native/jni/midi-dssi/Makefile.in: Regenerate. * native/jni/native-lib/Makefile.in: Regenerate. * native/jni/qt-peer/Makefile.in: Regenerate. * native/jni/xmlj/Makefile.in: Regenerate. * native/plugin/Makefile.in: Regenerate. * resource/Makefile.in: Regenerate. * scripts/Makefile.in: Regenerate. * tools/Makefile.in: Regenerate. libjava/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * configure: Regenerate. * gcj/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libjava/libltdl/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. libmudflap/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/: * aclocal.m4: Regenerate. libssp/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. libstdc++-v3/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. zlib/: * Makefile.in: Regenerate. * aclocal.m4: Regenerate. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/Makefile.in trunk/boehm-gc/aclocal.m4 trunk/boehm-gc/include/Makefile.in trunk/fixincludes/ChangeLog trunk/fixincludes/aclocal.m4 trunk/gcc/ChangeLog trunk/gcc/aclocal.m4 trunk/gcc/doc/install.texi trunk/intl/ChangeLog trunk/intl/aclocal.m4 trunk/libcpp/ChangeLog trunk/libcpp/aclocal.m4 trunk/libdecnumber/ChangeLog trunk/libdecnumber/aclocal.m4 trunk/libffi/ChangeLog trunk/libffi/Makefile.in trunk/libffi/aclocal.m4 trunk/libffi/include/Makefile.in trunk/libffi/man/Makefile.in trunk/libffi/testsuite/Makefile.in trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.in trunk/libgfortran/aclocal.m4 trunk/libgomp/ChangeLog trunk/libgomp/Makefile.in trunk/libgomp/aclocal.m4 trunk/libgomp/testsuite/Makefile.in trunk/libjava/ChangeLog trunk/libjava/HACKING
[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 ... $ make -C ~/src/gcc install ... $ time g++ -std=c++0x -O2 -c test.cpp -g real0m38.055s user0m37.476s sys 0m0.475s $ time g++ -std=c++0x -O2 -c test.cpp real0m28.149s user0m27.861s sys 0m0.278s -- Summary: -g option became very slow after r157834 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: roman at binarylife dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632
[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=20293action=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 trigger maximum hash table size limit. You can certainly compile with --param max-vartrack-size=1000 or something similar, or -fno-var-tracking-assignments as a workaround. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632
[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|UNCONFIRMED |NEW Component|c++ |rtl-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-02 20:26:03 date|| Summary|-g option became very slow |[4.5 Regression] -g option |after r157834 |became very slow after ||r157834 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632
[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 which locale model ends up being selected by [GLIBCXX_ENABLE_CLOCALE]. The ABI baselines have been generated for the GNU locale model, are not suited for the generic locale model. -- 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 #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 (years?). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632
[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 proxies are not being finalized.
I've patched current tree (+ the tree-profile.c patch) with the one below ...
... this fixes the unresolved vars problems .. but, maybe causes one
regression in g++ and a few in libgomp.fortran,
I'm looking into those -- but would really welcome input from people who know
more about emutls.
Index: gcc/varpool.c
===
--- gcc/varpool.c (revision 157942)
+++ gcc/varpool.c (working copy)
@@ -281,6 +281,17 @@
varpool_finalize_decl (tree decl)
{
struct varpool_node *node = varpool_node (decl);
+
+ /* When emulating tls, we actually see references to the control
+ variable, rather than the user-level variable. Make sure that
+ these control variables are finalized. */
+ if (!targetm.have_tls
+ TREE_CODE (decl) == VAR_DECL
+ DECL_THREAD_LOCAL_P (decl))
+{
+ tree control = emutls_decl (decl);
+ varpool_finalize_decl (control);
+}
/* FIXME: We don't really stream varpool datastructure and instead rebuild
it
by varpool_finalize_decl. This is not quite correct since this way we
can't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[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 from emutls_finish()? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[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 configure. I'll report the abi_check result when it's ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
[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 related .dll.a file in /usr/local/lib, so it linked against that DLL even though it isn't present. Get rid of your entire old /usr/local prefix, or make sure it's not visible when you build. I did that and it's now at stage3, so I believe it's going to be OK. I can't wait around for it to finish. I'll see if it works Monday morning. Thanks for all of your help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43619
[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 translated - domain registered with the TP and translations handled through the TP, regeneration part of procedures documented at http://gcc.gnu.org/translation.html - then it would also be desirable to be able to configure message translation for host and target separately.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
[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 test case that
should show the problem on any systems where LONG LONG is 8 bytes. Compiled
without -std=c99 all the prints will print '8', with '-std=c99' the middle two
prints will print out 16 instead of 8. Reproducable with ToT and going back to
at least 4.1.0.
#include stdio.h
main()
{
/* LONG_LONG_MAX */
printf(%ld\n, sizeof(9223372036854775807LL));
/* LONG_LONG_MAX + 1 */
printf(%ld\n, sizeof(9223372036854775808LL));
/* ULONG_LONG_MAX as a long long type */
printf(%ld\n, sizeof(18446744073709551615LL));
/* ULONG_LONG_MAX + 1 as a long long type */
printf(%ld\n, sizeof(18446744073709551616LL));
}
--
Summary: sizeof returns wrong size for large long long values
when using -std=c99
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43633
[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://gcc.gnu.org/bugzilla/show_bug.cgi?id=43633
[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 __n1length(__s), which is not the
behavior documented in the header, on
http://www.cplusplus.com/reference/string/string/replace/ , or in Josuttis The
C++ Standard Library (Addison Wesley).
Suggested fix: it would suffice to take the min() of __n1 and length(__s)
instead of just the latter. In my version, that's on line 1324 of
/usr/include/c++/4.4.3/bits/basic_string.h
Workaround: use the other replace() signature that allows to explicitly set a C
string length.
See also test_std_string.cpp:
// g++ -Wall -g -O0 -o test_std_string test_std_string.cpp
#include string
#include iostream
int main(int argc, char ** argv)
{
static char const * foo_cstr(fooXXX);
std::string foo(something else);
foo.resize(3);
foo.replace(0, 3, foo_cstr);
if (foo != foo) {
std::cout foo.replace(0, 3, foo_cstr) failed: got \ foo \
instead of \foo\\n;
}
foo.resize(3);
foo.replace(0, 3, foo_cstr, 3);
if (foo != foo) {
std::cout foo.replace(0, 3, foo_cstr, 3) failed: got \ foo \
instead of \foo\\n;
}
}
--
Summary: std::string::replace with C string can replace too many
characters
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: poftwaresatent at gmail dot com
GCC target triplet: i486-linux-gnu
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 #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=20294action=view) source file to trigger the bug and see that the workaround works -- 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 #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=20295action=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=20296action=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=20297action=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=20298action=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 same. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID 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 #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. I interpreted that as meaning when s is longer than n, just use the first n characters of it and disregards whatever follows. Similarly, Josuttis (pg 519 of 10th printing) says: Both forms replace, at most, len characters of *this... Thanks for the quick reply! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43634
[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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43623
