[Bug fortran/28353] ICE: Segmentation fault
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de 2006-07-12 06:30 --- Created an attachment (id=11863) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11863action=view) mpif.h (from MPICH) This file alone is not going to be able to reproduce this bug. Can you attach mpif.h also? INCLUDE 'mpif.h' Hmm, I though I checked that no other files are needed. Anyway, here it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #25 from richard at codesourcery dot com 2006-07-12 06:32 --- Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked. pcarlini at suse dot de [EMAIL PROTECTED] writes: Thanks Rainer and Eric. Then, since we have a workaround in place for the issue (--disable-wchar_t) and apparently it affects only very old (broken as far as such features are concerned) releases of the OS, I'm inclined to close this PR as WONTFIX. Any objections? I will go ahead in a few days... Sounds good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug c++/28016] [4.1 Regression] emitting template constant
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-07-12 07:22 --- Subject: Bug 28016 Author: mmitchel Date: Wed Jul 12 07:22:47 2006 New Revision: 115365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115365 Log: PR c++/28016 * decl.c (cp_finsh_decl): Do not emit uninstantiated static data members. PR c++/28016 * g++.dg/template/static26.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/static26.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] [4.1 Regression] emitting template constant
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-07-12 07:23 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug fortran/28354] New: 0.99999 printed as 0. instead of 1. by format(f3.0)
Compiling the following snippet
write(*,100) 0.9
write(*,100) 0.99
write(*,100) 0.999
write(*,100) 0.
write(*,100) 0.9
write(*,100) 0.99
100 format((f3.0))
end
with gcc-gfortran-4.1.1-1.fc5, I get as output
0.
0.
0.
1.
1.
1.
I get similar faulty output with -0...., but with no other number/format
combination I have tried.
I get normal output (i.e. all 1.) with other compilers on other machines, such
as gcc-g77-3.2.2-5 on i686; moreover (if that's relevant)
#include stdio.h
int main()
{
printf(%3.0f\n,0.999);
printf(%3.0f\n,0.);
printf(%3.0f\n,0.9);
printf(%3.0f\n,0.99);
printf(%3.0f\n,0.999);
printf(%3.0f\n,0.);
}
gives all ones too, when compiled on the same machine with gcc-4.1.1-1.fc5
--
Summary: 0.9 printed as 0. instead of 1. by format(f3.0)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enrico dot segre at weizmann dot ac dot il
GCC host triplet: i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug c++/28345] static const class initialisation causes core dump
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-12 08:16 --- Fixed in 3.4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28345
[Bug ada/28355] New: Ada Problem with Abort
Program1: with Ada.Text_IO; use Ada.Text_IO; procedure Main is task Task1 is entry Stop; end Task1; task body Task1 is begin accept Stop; end Task1; begin Put_Line ( Please wait... ); Delay 3.0; abort Task1; Put_Line ( Task Task1 Aborted! ); end main; All perfectly works. After start passes 3 seconds, the program finishes the work. Program2: with Ada.Text_IO; use Ada.Text_IO; procedure Main is task Task1; task body Task1 is begin loop null; end loop; end Task1; begin Put_Line ( Please wait... ); Delay 3.0; abort Task1; Put_Line ( Task Task1 Aborted! ); end main; Passes 3 seconds. I see message: Task Task1 Aborted and the Program stands out continues to work yet I shall not press Ctrl+C System: CentOS4.3 ( RHEL4U3 ) GNAT 3.4.5 ( Red Hat 3.4.5-2 ) GCC 3.4.5 ( Red Hat 3.4.5-2 ) On idea both programs should come to the end... -- Summary: Ada Problem with Abort Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ksicom at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28355
[Bug fortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-12 08:56 --- 0.9 in Fortran is 0.9f in C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-12 09:25 --- Subject: Bug 28187 Author: rguenth Date: Wed Jul 12 09:25:40 2006 New Revision: 115366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115366 Log: 2006-07-12 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/28187 * tree-vrp.c (vrp_operand_equal_p): New function. (vrp_bitmap_equal_p): Likewise. (update_value_range): Use them to compare old and new max and min values. * gcc.dg/pr28187.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr28187.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-07-12 09:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug c/28356] New: xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
/usr/bin/gcc-3.4 -mmmx -msse -Winline --param inline-unit-growth=1 --param large-function-growth=1 -O3 -mtune=pentium4 -march=i686 -fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -MT libfbmmx_la-fbmmx.lo -MD -MP -MF .deps/libfbmmx_la-fbmmx.Tpo -c fbmmx.i -fPIC -DPIC -o /tmp/fbmmx.out fbmmx.c: In function `fbCompositeSolidMask_nx8x0565mmx': fbmmx.c:1584: internal compiler error: in verify_local_live_at_start, at flow.c:546 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. gcc --version is: gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) -- Summary: xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer-gccbugzilla at 7val dot com GCC build triplet: i486-pc-linux-gnu GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug c/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #1 from rainer-gccbugzilla at 7val dot com 2006-07-12 10:09 --- Created an attachment (id=11864) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11864action=view) preprocessed source file that causes the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug c/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-12 10:53 --- Works for me with 3.4.0 to 3.4.6. /space/rguenther/install/gcc-3.4.0/bin/gcc -mmmx -msse -Winline --param inline-unit-growth=1 --param large-function-growth=1 -O3 -mtune=pentium4 -march=i686 -fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -fPIC -c fbmmx.i can you verify the failure occurs with the preprocessed source you attached? Also works with ii gcc-3.43.4.3-13 The GNU C compiler for me. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|rtl-optimization|c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug target/22250] [sh4] ICE compiling qt-4.0.0-embedded snapshot
--- Comment #7 from mnylund at emtrion dot de 2006-07-12 11:17 --- Here's a workaround for the bug (gcc-3.4.4 qt-3.3.6): - build with -O1 is ok - build with -O2 leads to ICE - build with -O2 -fno-schedule-insns2 is OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22250
[Bug rtl-optimization/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #3 from rainer-gccbugzilla at 7val dot com 2006-07-12 11:26 --- Yes, it fails with the preprocessed file that I attached. I also tried a apt-get install --reinstall gcc-3.4 gcc-3.4-base to make sure that the gcc installation isn't corrupt. Omitting -ftracer stops the error from happening. debianSarge tiffany:/tmp$ dpkg -l |grep gcc-3.4 ii gcc-3.43.4.3-13 The GNU C compiler ii gcc-3.4-base 3.4.3-13 The GNU Compiler Collection (base package) root debianSarge tiffany:/tmp$ cat /tmp/x /usr/bin/gcc-3.4 -mmmx -msse -Winline --param inline-unit-growth=1 --param large-function-growth=1 -O3 -mtune=pentium4 -march=i686 -fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -MT libfbmmx_la-fbmmx.lo -MD -MP -MF .deps/libfbmmx_la-fbmmx.Tpo -c fbmmx.i -fPIC -DPIC -o /tmp/fbmmx.out root debianSarge tiffany:/tmp$ /tmp/x fbmmx.c: In function `fbCompositeSolidMask_nx8x0565mmx': fbmmx.c:1584: internal compiler error: in verify_local_live_at_start, at flow.c:546 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug fortran/28353] ICE: Segmentation fault
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-07-12 11:54 --- Tobias, I am so glad to see that somebody is passing components of derived type arrays; I bust myself to make that work! Anyway, I partially broke it with a recent patch - sorry. Reduced testcase: SUBROUTINE mpi_bc_all(lda_u, ntypd) TYPE t_utype INTEGER l END TYPE t_utype TYPE (t_utype), INTENT (INOUT) :: lda_u(ntypd) EXTERNAL MPI_BCAST CALL MPI_BCAST(lda_u(:)%l) ! No explicit interface - no fsym - segfault END SUBROUTINE mpi_bc_all A work around is to add an interface: interface subroutine MPI_BCAST (i) integer, dimension (:) :: i end subroutine MPI_BCAST end interface Here is a patch that works. It is not regtested but I am sure that it is bombproof. I will do all the regtesting tonight and commit it as obvious tomorrow morning. Patch: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(r#9500;®vision 115306) +++ gcc/fortran/trans-expr.c(copie de travail) @@ -1980,7 +1980,8 @@ array of derived types. In this case, the argument is converted to a temporary, which is passed and then written back after the procedure call. */ - gfc_conv_aliased_arg (parmse, e, f, fsym-attr.intent); + gfc_conv_aliased_arg (parmse, e, f, + fsym ? fsym-attr.intent : INTENT_INOUT); else gfc_conv_array_parameter (parmse, e, argss, f); Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug rtl-optimization/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-12 12:25 --- please report the output from the compiler if you specify -v as additional argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #26 from multix at gmail dot com 2006-07-12 12:27 --- I have 6.5.17 too. I would propose to either improve the autodetect features or point out that flag in the atchitecture specific page so that other users won't ask. I'm available for testing on my box. I Think I have access to a 6.5.4 box too... but am not sure. SGI says that binaries compiled on different minor releases should be compatible each other, I wonder if a binary packager can safely build on = 6.5.18 and expect it to work on older boxes too or not... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #27 from pcarlini at suse dot de 2006-07-12 12:29 --- (In reply to comment #26) I have 6.5.17 too. ... or point out that flag in the atchitecture specific page so that other users won't ask. That makes sense. Can you prepare a patch? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- Comment #4 from multix at gmail dot com 2006-07-12 12:32 --- I already configured using --with-gnu-as but not with --with-gnu-ld. Possibly the two options need to be specified together, that is the gnu assembler needs the gnu linker? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug rtl-optimization/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #5 from rainer-gccbugzilla at 7val dot com 2006-07-12 12:44 --- debianSarge tiffany:/tmp$ cat ./x /usr/bin/gcc-3.4 -v -mmmx -msse -Winline --param inline-unit-growth=1 --param large-function-growth=1 -O3 -mtune=pentium4 -march=i686 -fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -MT libfbmmx_la-fbmmx.lo -MD -MP -MF .deps/libfbmmx_la-fbmmx.Tpo -c fbmmx.i -fPIC -DPIC -o /tmp/fbmmx.out debianSarge tiffany:/tmp$ ./x Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --disable-werror i486-linux Thread model: posix gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) /usr/lib/gcc/i486-linux/3.4.4/cc1 -fpreprocessed fbmmx.i -quiet -dumpbase fbmmx.i -mmmx -msse -mtune=pentium4 -march=i686 -auxbase-strip /tmp/fbmmx.out -O3 -Winline -version -fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -fPIC --param inline-unit-growth=1 --param large-function-growth=1 -o /tmp/ccohFlL4.s GNU C version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) (i486-linux) compiled by GNU C version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 fbmmx.c: In function `fbCompositeSolidMask_nx8x0565mmx': fbmmx.c:1584: internal compiler error: in verify_local_live_at_start, at flow.c:546 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.4/README.Bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug c++/28357] New: c-style downcasts on const multiple inherited objects differ if const vs non-const cast
i.e. the attached test case with gcc (GCC) 4.1.1 20060629 (Red Hat 4.1.1-6) and gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1) gives... New-Style Correct: const 0xbfdb3d2c, unconst 0xbfdb3d2c Old-Style Correct: const 0xbfdb3d2c, unconst 0xbfdb3d2c Old-Style Incorrect: const 0xbfdb3d2c, unconst 0xbfdb3d28 where the final value here should be the same as the rest of them -- Summary: c-style downcasts on const multiple inherited objects differ if const vs non-const cast Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357
[Bug c++/28357] c-style downcasts on const multiple inherited objects differ if const vs non-const cast
--- Comment #1 from caolanm at redhat dot com 2006-07-12 12:51 --- Created an attachment (id=11865) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11865action=view) demo source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357
[Bug c++/28358] New: ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
Full version string: g++-4.1 (GCC) 4.1.2 20060708 (prerelease) (Ubuntu 4.1.1-8ubuntu1) Same problem exists in Debian 'etch'. The error message after the location of the crash is: /usr/include/boost/spirit/core/composite/actions.hpp:106: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6336 It only occurs using the -O1 and -O2 flags, but succeeds in compiling using -O0 or -O3. No other flags need to be given to trigger this crash. Older compiler versions (4.0,3.4,3.3...) do not have this bug. Preprocessed code follows... -- Summary: ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter dot soetens at fmtc dot be GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug c++/28357] [4.0/4.1/4.2 regression] c-style downcasts on const multiple inherited objects differ if const vs non-const cast
--- Comment #2 from jakub at gcc dot gnu dot org 2006-07-12 13:02 --- Works with 3.4.6 and 3.2.3, reproduced on mainline. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com Summary|c-style downcasts on const |[4.0/4.1/4.2 regression] c- |multiple inherited objects |style downcasts on const |differ if const vs non-const|multiple inherited objects |cast|differ if const vs non-const ||cast http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357
[Bug c++/28358] ICE on valide template code using -O1 or -O2, but *not* with -O0 or -O3
--- Comment #1 from peter dot soetens at fmtc dot be 2006-07-12 13:05 --- Created an attachment (id=11866) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11866action=view) Compressed (bzip2) preprocessed file After unzipping, compile this file using: $ g++-4.1 -c attachment.ii -O2 -o attachment.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28358
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #5 from mrs at gcc dot gnu dot org 2006-07-12 13:12 --- Subject: Bug 28280 Author: mrs Date: Wed Jul 12 13:12:08 2006 New Revision: 115369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115369 Log: PR c/28280 * c-parser.c (c_parser_typeof_specifier): Don't use c_finish_expr_stmt, open code desired semantics instead. Added: trunk/gcc/testsuite/gcc.dg/vla-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #6 from mrs at apple dot com 2006-07-12 13:13 --- I have checked in a fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug rtl-optimization/28356] xorg-server-X11R7.1/fb/fbmmx.c:1584: internal compiler error
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-12 13:36 --- I cannot reproduce this with any FSF release of the 3.4 series. This must be a Debian specific bug - please report with them. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
[Bug libgcj/28352] Interpreter: Stack trace line numbers sometimes missing or incorrect
--- Comment #3 from bryce at gcc dot gnu dot org 2006-07-12 13:56 --- Subject: Bug 28352 Author: bryce Date: Wed Jul 12 13:56:25 2006 New Revision: 115370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115370 Log: 2006-07-12 Bryce McKinlay [EMAIL PROTECTED] PR libgcj/28352 * stacktrace.cc (getLineNumberForFrame): Roll back PC by 1 when looking up line number for interpreted frame. Modified: trunk/libjava/ChangeLog trunk/libjava/stacktrace.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug java/28352] gcj -C fails to generate line number info for method
--- Comment #4 from mckinlay at redhat dot com 2006-07-12 13:59 --- I've committed a patch which fixes the off by one error seen with ecj-produced bytecode. The missing line number issue is a different bug. It seems that gcj -C simply does not generate any debug info for the snafu method in the example below. I'm reassigning this as a front-end bug. -- mckinlay at redhat dot com changed: What|Removed |Added Component|libgcj |java Summary|Interpreter: Stack trace|gcj -C fails to generate |line numbers sometimes |line number info for method |missing or incorrect| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352
[Bug c++/28235] [4.0/4.1/4.2 Regression] ICE with static const member as default parameter in template
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-07-12 14:08
---
Even shorter (valid) testcase:
=
templatetypename struct A
{
static const bool i = true;
templatebool = i struct B {};
B b;
};
=
This crashes since GCC 4.0.3 and was rejected by GCC 3.4.0 - 4.0.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28235
[Bug other/28251] dumped addresses makes diffing dumps unusable
--- Comment #5 from patchapp at dberlin dot org 2006-07-12 14:15 --- Subject: Bug number PR other/28251 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00517.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28251
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-07-12
14:20 ---
Created an attachment (id=11867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11867action=view)
For discussion, perusal and testing: a beta-release of the TR15581 patch
This patch represents some months of work by Erik and myself. It is still not
complete and has at least one residual source of memory leakage (derived type
constructors with function array-valued actuals). That withstanding, it does
most of the memory management required by the standard, it does assignments
correctly and handless allocatable components in contructors. There is still a
way to go before it is submittable but it's getting there!
What does it do?
(i) It runs most of the iso_varying_string testsuite (vst16.f95 fails in io,
vst28.f95, vst30.f95 and vst31.f95 need modification to catch zero length
strings).
(ii) This tests the basic functionality:
! { dg-do run}
! { dg-options -O2 -fdump-tree-original }
!
! Check some basic functionality of allocatable components, including that they
! are nullified when created and automatically deallocated when
! 1. A variable goes out of scope
! 2. INTENT(OUT) dummies
! 3. Function results
!
module alloc_m
implicit none
type :: alloc1
real, allocatable :: x(:)
end type alloc1
end module alloc_m
program alloc
use alloc_m
implicit none
type :: alloc2
type(alloc1), allocatable :: a1(:)
integer, allocatable :: a2(:)
end type alloc2
type(alloc2) :: b
integer :: i
type(alloc2), allocatable :: c(:)
if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'main - 1'
call abort()
end if
! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(b)
call check_alloc2(b)
do i = 1, size(b%a1)
! 1 call to _gfortran_deallocate
deallocate(b%a1(i)%x)
end do
! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(b)
call check_alloc2(return_alloc2())
! 3 calls to _gfortran_deallocate (function result)
allocate(c(1))
! 3 calls to _gfortran_deallocate (INTENT(OUT) dummy)
call allocate_alloc2(c(1))
! 4 calls to _gfortran_deallocate
deallocate(c)
! 7 calls to _gfortran_deallocate (b (3) and c(4) goes aout of scope)
contains
subroutine allocate_alloc2(b)
type(alloc2), intent(out) :: b
integer :: i
if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'allocate_alloc2 - 1'
call abort()
end if
allocate (b%a2(3))
b%a2 = [ 1, 2, 3 ]
allocate (b%a1(3))
do i = 1, 3
if (allocated(b%a1(i)%x)) then
write (0, *) 'allocate_alloc2 - 2', i
call abort()
end if
allocate (b%a1(i)%x(3))
b%a1(i)%x = i + [ 1.0, 2.0, 3.0 ]
end do
end subroutine allocate_alloc2
type(alloc2) function return_alloc2() result(b)
if (allocated(b%a2) .OR. allocated(b%a1)) then
write (0, *) 'return_alloc2 - 1'
call abort()
end if
allocate (b%a2(3))
b%a2 = [ 1, 2, 3 ]
allocate (b%a1(3))
do i = 1, 3
if (allocated(b%a1(i)%x)) then
write (0, *) 'return_alloc2 - 2', i
call abort()
end if
allocate (b%a1(i)%x(3))
b%a1(i)%x = i + [ 1.0, 2.0, 3.0 ]
end do
end function return_alloc2
subroutine check_alloc2(b)
type(alloc2), intent(in) :: b
if (.NOT.(allocated(b%a2) .AND. allocated(b%a1))) then
write (0, *) 'check_alloc2 - 1'
call abort()
end if
if (any(b%a2 /= [ 1, 2, 3 ])) then
write (0, *) 'check_alloc2 - 2'
call abort()
end if
do i = 1, 3
if (.NOT.allocated(b%a1(i)%x)) then
write (0, *) 'check_alloc2 - 3', i
call abort()
end if
if (any(b%a1(i)%x /= i + [ 1.0, 2.0, 3.0 ])) then
write (0, *) 'check_alloc2 - 4', i
call abort()
end if
end do
end subroutine check_alloc2
end program alloc
! { dg-final { scan-tree-dump-times deallocate 24 original } }
! { dg-final { cleanup-tree-dump original } }
(iii) The following tests constructors:
program
type :: mytype
integer, allocatable :: a(:, :)
end type mytype
type (mytype) :: x
integer :: y(0:1, -1:0) = reshape ((/42, 99, 55, 77/), (/2,2/))
x = mytype (y)
call foo (x, y)
x = mytype (reshape ((/42, 99, 55, 77/), (/2,2/)))
call foo (x, reshape ((/42, 99, 55, 77/), (/2,2/)))
x = mytype (bar (y))
call foo (x, y**3)
contains
subroutine foo (x, y)
type(mytype) :: x
integer y(:,:)
if (any (x%a .ne. y)) call abort ()
end subroutine foo
function bar (x)
integer, dimension(:,:) :: x
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-07-12 14:23 --- Bother! Forget the last test - it is an old, incorrect version. I will post the right one tonight. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fastjar/28359] New: fastjar directory traversal problem
fastjar contains the following security problem: When a JAR archive is extracted with filenames with ../ inside, it can extract files outside of the current directory (a so called directory traversal). Unconspicious users unpacking such files could overwrite their own files, or even system files when being root. I am attaching a sample cups.jar from an earlier CUPS tarball, which exposes this problem. -- Summary: fastjar directory traversal problem Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fastjar AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #1 from marcus at jet dot franken dot de 2006-07-12 14:50 --- Created an attachment (id=11868) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11868action=view) cups.jar sample file with ../ paths inside. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #2 from marcus at jet dot franken dot de 2006-07-12 14:54 --- Created an attachment (id=11869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11869action=view) fix.patch i would propose this patch to fix this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug c++/28217] [4.0/4.1/4.2 regression] ICE in tree_int_cst_sgn
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-07-12 15:03
---
Reduced (from PR 28219) testcase:
=
templateint struct A
{
enum { a, b = a };
void foo(Ab);
};
=
bug.h:4: internal compiler error: tree check: expected integer_cst, have
const_decl in tree_int_cst_sgn, at tree.c:4517
Please submit a full bug report, [etc.]
If I replace Ab by Aa I get a segfault instead.
The testcase crashes since GCC 4.0.0.
The code compiles fine if I compile it as regular C++ file and not
as C++-header.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Summary|[4.2 regression] ICE in |[4.0/4.1/4.2 regression] ICE
|tree_int_cst_sgn|in tree_int_cst_sgn
Target Milestone|4.2.0 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28217
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-12 15:08 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-12 15:08:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug fortran/28163] Calling libgfortran's copy_string is inefficient
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:11 --- Subject: Bug 28163 Author: fxcoudert Date: Wed Jul 12 15:11:11 2006 New Revision: 115372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115372 Log: PR fortran/28163 * trans-expr.c (gfc_trans_string_copy): Generate inline code to perform string copying instead of calling a library function. * trans-decl.c (gfc_build_intrinsic_function_decls): Don't build decl for copy_string. * trans.h (gfor_fndecl_copy_string): Remove prototype. * intrinsics/string_intrinsics.c (copy_string): Remove function. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28163
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-12 15:14 --- Created an attachment (id=11870) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11870action=view) different fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug fortran/28163] Calling libgfortran's copy_string is inefficient
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:17 --- Fixed on 4.2 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28163
[Bug fortran/28353] ICE: Segmentation fault
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:19 --- Confirmed, then, if there's a patch already :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-12 15:19:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-12 15:19 --- I have applied the 2nd fix to the upstream (savannah) fastjar CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:21 --- Confirmed, and not target-specific. I'll look into it. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 GCC host triplet|i686| Last reconfirmed|-00-00 00:00:00 |2006-07-12 15:21:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug c++/27369] [4.1/4.2 Regression] tree check ICE when attribute externally_visible used
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-07-12 15:45 --- Fails since GCC 4.1.0 for me. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Keywords||monitored Known to fail|4.2.0 4.1.2 |4.1.0 4.2.0 4.1.2 Known to work|4.1.1 |4.0.4 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27369
[Bug c++/28360] New: [4.2 regression] undefined reference when header contains additional namespace
I get an undefined reference error with a recent gcc 4.2 when linking to a
class whose header contains an additional namespace that is references from
that class. This is a very recent error. It started to occur between 20060626
and 20060709.
(sid)1690:[EMAIL PROTECTED]: ~/src/t] make
rm -f *.o
g++-4.1 -c t.cc ; g++-4.1 -c a.c ; g++-4.1 a.o t.o
rm -f *.o
g++-4.2 -c t.cc ; g++-4.2 -c a.c ; g++-4.2 a.o t.o
a.o: In function `main':
a.c:(.text+0x18): undefined reference to `test::MonitorHandle::MonitorHandle()'
collect2: ld returned 1 exit status
(sid)1691:[EMAIL PROTECTED]: ~/src/t] cat t.h
namespace test
{
namespace
{
class SignalProxy_Monitor;
}
class MonitorHandle
{
public:
MonitorHandle();
private:
SignalProxy_Monitor* proxy_;
};
}
(sid)1693:[EMAIL PROTECTED]: ~/src/t] cat t.cc
#include t.h
namespace test
{
MonitorHandle::MonitorHandle()
{}
}
(sid)1694:[EMAIL PROTECTED]: ~/src/t] cat a.c
#include t.h
int main(void) {
test::MonitorHandle handle;
return 0;
}
--
Summary: [4.2 regression] undefined reference when header
contains additional namespace
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28360
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #28 from paolo at gcc dot gnu dot org 2006-07-12 16:03 --- Subject: Bug 27878 Author: paolo Date: Wed Jul 12 16:02:46 2006 New Revision: 115374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115374 Log: 2006-07-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/27878 * doc/install.texi (mips-sgi-irix6): Add note about IRIX 6.5.x, x 19, vs wchar_t support. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug target/28126] gcc moves an expensive instruction outside of a conditional
--- Comment #4 from drow at gcc dot gnu dot org 2006-07-12 16:08 --- (In reply to comment #3) Is it OK to add (set_attr can_delay no) for tls_get_tp_mode definition? I think so, with suitable comment. Some future MIPS architecture may provide a register for this, in which case the instruction will not trap, and putting it in a delay slot will be valuable. But in the mean time, all existing MIPS ISAs guarantee the trap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #29 from paolo at gcc dot gnu dot org 2006-07-12 16:10 --- Subject: Bug 27878 Author: paolo Date: Wed Jul 12 16:10:12 2006 New Revision: 115375 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115375 Log: 2006-07-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/27878 * doc/install.texi (mips-sgi-irix6): Add note about IRIX 6.5.x, x 19, vs wchar_t support. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #30 from ro at techfak dot uni-bielefeld dot de 2006-07-12 16:11 --- Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked. multix at gmail dot com writes: I'm available for testing on my box. I Think I have access to a 6.5.4 box too... but am not sure. That would be fine, in case I get around to investigating this further. On many other platforms (like Tru64 UNIX), it used to be possible to fix or work around problems like this, provided the number of different cases/releases don't get out of hand. Before I start this, I'll probably have to invest some work to get mainline to fully bootstrap on 6.5.2x, though. SGI says that binaries compiled on different minor releases should be compatible each other, I wonder if a binary packager can safely build on = 6.5.18 and expect it to work on older boxes too or not... Certainly not: this only works the other way round: you can build on 6.5.x and run on 6.5.y, y x. There are new symbols introduced e.g. in libc, which are marked as OPTIONAL in nm output. It is possible (though I don't remember how this is done) to check for those functions as runtime and use them only if available. This is certainly far too much trouble in the GCC case, though. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug libstdc++/27878] GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0 worked.
--- Comment #31 from pcarlini at suse dot de 2006-07-12 16:11 --- Doc patch committed to mainline and 4_1-branch. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
[Bug c++/28316] [4.0/4.1/4.2 Regression] ICE in in instantiate_decl, at cp/pt.c:11645
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-12 16:14 --- With little modifications one can trigger all sorts of behaviour: ICEs in different places and accepts-invalid bugs. *** This bug has been marked as a duplicate of 24791 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28316
[Bug c++/24791] ICE on invalid instantiation of template's static member
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-12 16:14 --- *** Bug 28316 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24791
[Bug fortran/28353] ICE: Segmentation fault
--- Comment #6 from pault at gcc dot gnu dot org 2006-07-12 16:39 --- FX I couldn't do the confirmation from the lab! Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
[Bug c++/28058] [4.1/4.2 regression] ICE in inline_forbidden_p
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-12 16:39
---
Here's a testcase that crashes even at -O0 since GCC 4.1.0:
===
templateint struct A
{
A() {}
};
A0 a;
template A0::A() {}
===
As Wolfgang already mentioned: explicit specializations must be declared
before they are first used.
However, no diagnostic is required. (Which indicates that such situations
are hard to detect reliably.)
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28058
[Bug c++/28361] New: Pointer arithmetic failure
if you do something like this: char *buffer; int i; buffer = (char *) malloc (sizeof (struct something) * 1024); for (i=0; i 1024;i++) memcpy (buffer + i * sizeof (struct something),i;sizeof (int)); then when i == 255 there is no data stored in buffer. I mean i can read out the correct value from buffer for every increment (i * sizeof (struct something)), but when i == 255 the value read out is 0. When i == 256 all works fine again. -- Summary: Pointer arithmetic failure Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pfister at reith-pfister dot de GCC build triplet: x86 GCC host triplet: x86 GCC target triplet: x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28361
[Bug c++/28360] [4.2 regression] undefined reference when header contains additional namespace
--- Comment #1 from tbm at cyrius dot com 2006-07-12 16:51 --- This was caused by: r115086 | jason | 2006-06-30 03:15:56 +0200 (Fri, 30 Jun 2006) | 58 lines -- tbm at cyrius dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28360
[Bug c++/27977] [4.0/4.1/4.2 Regression] ICE when declaring recursive member in std namespace (illegal code)
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-12 16:52 --- This has been fixed on mainline, the 4.1 branch, and the 4.0 branch. Probably by Lee Millward's patch for PR 27821. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27977
[Bug c/28362] New: Invalid code e.g. for ALSA kernel driver
gcc creates invalid code for
--
struct snd_mask {
unsigned int bits[6]; // ** (1) ***
};
static int snd_mask_refine(struct snd_mask *mask, const struct snd_mask *v)
{
struct snd_mask old;
old = *mask;
if (mask-bits[0]==0 mask-bits[1]==0)
*(char *)0 = 0;
return mask-bits[0] == old.bits[0] ? 0 : 1;
}
static int test(struct snd_mask *a, struct snd_mask *b)
{
return snd_mask_refine(a, b);
}
int main(int argc, char *argv[])
{
int volatilev= 0;
struct snd_mask mask;
struct snd_mask m;
mask.bits[0] = 23;
mask.bits[1] = 42;
mask.bits[2] = 0;
mask.bits[3] = 0;
mask.bits[4] = 0; // ** (2)
mask.bits[5] = 0;
m.bits[0] = 0x;
m.bits[1] = 0x;
m.bits[2] = 0x;
m.bits[3] = 0x;
m.bits[4] = 0x;
m.bits[5] = 0x;
return !v ? test(mask, m) : test(m, mask);
}
--
| $ arm-xscale-linux-gnu-gcc -Os ./test.c
| $ ./a.out
| Segmentation fault
When changing parameters things are fine; e.g.
| $ arm-xscale-linux-gnu-gcc -O0 ./test.c
| $ ./a.out
| $
Affecting parameters are:
* assigning '1' instead of '0' at (2)
* the array size at (1); e.g. 5 instead of 6 makes it work as expected
* optimization flags; e.g. '-O0' or '-O3' makes it work
* platform; can not reproduce it on non-arm compilers,
The code gnerated by '-Os' is
| 80a0 test:
| 80a0: e52de004str lr, [sp, #-4]!
| 80a4: e24dd018sub sp, sp, #24 ; 0x18
| 80a8: e1a0c00dmov ip, sp
| 80ac: e1a0e000mov lr, r0
| 80b0: e8be000fldmia lr!, {r0, r1, r2, r3}
| 80b4: e8ac000fstmia ip!, {r0, r1, r2, r3}
| 80b8: e89e0003ldmia lr, {r0, r1}
| 80bc: e2503000subsr3, r0, #0 ; 0x0
| 80c0: e88c0003stmia ip, {r0, r1}
| 80c4: e59d2000ldr r2, [sp]
| 80c8: 1a01bne 80d4 test+0x34
| 80cc: e351cmp r1, #0 ; 0x0
| 80d0: 05c33000streqb r3, [r3]
| 80d4: e0530002subsr0, r3, r2
| 80d8: 13a1movne r0, #1 ; 0x1
| 80dc: e28dd018add sp, sp, #24 ; 0x18
| 80e0: e8bd8000ldmia sp!, {pc}
afais:
* 0x80b0 + 0x80b4 copies 'mask[0..3]' to 'old[0..3]'.
* 0x80b8 loads mask[4..5] into {r0,r1}
* now, it uses r0 which contains mask[4] but not mask[0] for comparision
which is wrong
Bug can be reproduced with
$ $C-gcc-3.4.5 -v
Reading specs from /usr/lib/gcc/arm-xscale-linux-gnu/3.4.5/specs
Configured with: ../configure --prefix=/usr --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=arm-xscale-linux-gnu
--with-sysroot=/usr/arm-xscale-linux-gnu/sys-root --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --infodir=/usr/share/info
--mandir=/usr/share/man --enable-version-specific-runtime-libs
--enable-languages=c,c++ --enable-shared --enable-threads --disable-multilib
--with-cpu=xscale --enable-cxx-flags=-mcpu=xscale -fomit-frame-pointer
Thread model: posix
gcc version 3.4.5
$ $C-gcc-4.0.3 -v
Using built-in specs.
Target: arm-xscale-linux-gnu
Configured with: ../configure --prefix=/usr --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=arm-xscale-linux-gnu
--with-sysroot=/usr/arm-xscale-linux-gnu/sys-root --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --infodir=/usr/share/info
--mandir=/usr/share/man --enable-version-specific-runtime-libs
--enable-languages=c --enable-shared --enable-threads --disable-multilib
--with-cpu=xscale --enable-cxx-flags=-mcpu=xscale -fomit-frame-pointer
Thread model: posix
gcc version 4.0.3
$ $C-gcc-4.1.1 -v
Using built-in specs.
Target: arm-xscale-linux-gnu
Configured with: ../configure --prefix=/usr --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=arm-xscale-linux-gnu
--with-sysroot=/usr/arm-xscale-linux-gnu/sys-root --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --infodir=/usr/share/info
--mandir=/usr/share/man --enable-version-specific-runtime-libs
--disable-multilib --enable-languages=c,c++,java,objc --enable-shared
--enable-threads --with-cpu=xscale --enable-cxx-flags=-mcpu=xscale
-fomit-frame-pointer
Thread model: posix
gcc version 4.1.1
The assembler code above was created with 4.1.1.
I think this is a major bug.
--
Summary: Invalid code e.g. for ALSA kernel driver
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enrico dot scholz at informatik dot tu-chemnitz dot de
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: arm-xscale-linux-gnu
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-12 16:57 --- Fastjar no longer is included with GCC so closing as will not fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug java/21900] [4.1/4.2 Regression] debugging regression when debugging libgcj
--- Comment #3 from aph at gcc dot gnu dot org 2006-07-12 16:59 --- I can't duplicate this one. (gdb) s gnu.java.lang.MainThread.MainThread(java.lang.Class, java.lang.String[]) ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at /home/aph/gcc/trunk/libjava/gnu/java/lang/MainThread.java:72 Current language: auto; currently java Please give a complete test case. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21900
[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)
--- Comment #5 from tromey at gcc dot gnu dot org 2006-07-12 17:00 --- Subject: Bug 27271 Author: tromey Date: Wed Jul 12 17:00:49 2006 New Revision: 115378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115378 Log: PR libgcj/27271: * java/util/zip/ZipFile.java (getInputStream): Call addDummyByte on PartialInputStream. (PartialInputStream.dummyByteCount): New field. (PartialInputStream.fillBuffer): Handle dummy byte. (PartialInputStream.read): Likewise. (PartialInputStream.addDummyByte): New method. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/java/util/zip/ZipFile.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)
--- Comment #6 from cvs-commit at developer dot classpath dot org 2006-07-12 17:01 --- Subject: Bug 27271 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey tromey 06/07/12 17:00:34 Modified files: . : ChangeLog java/util/zip : ZipFile.java Log message: PR libgcj/27271: * java/util/zip/ZipFile.java (getInputStream): Call addDummyByte on PartialInputStream. (PartialInputStream.dummyByteCount): New field. (PartialInputStream.fillBuffer): Handle dummy byte. (PartialInputStream.read): Likewise. (PartialInputStream.addDummyByte): New method. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpathr1=1.8080r2=1.8081 http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/zip/ZipFile.java?cvsroot=classpathr1=1.34r2=1.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug c++/28361] Pointer arithmetic failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-12 17:01 --- memcpy (buffer + i * sizeof (struct something),i;sizeof (int)); Well that code should be not compile as there is a syntax error? Also what you gave is not enough to reproduce the bug, do you have a self contained example? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28361
[Bug libgcj/27271] i/o error (java.util.zip.ZipException: Deflated stream ends early.)
--- Comment #7 from tromey at gcc dot gnu dot org 2006-07-12 17:02 --- Fix checked in. It works with the test case from the PR. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27271
[Bug libgcj/26910] re-merging java.util.zip
--- Comment #2 from tromey at gcc dot gnu dot org 2006-07-12 17:03 --- This is no longer a problem. I think the PR 27271 fix cleaned up the lingering problem. (It is hard to be sure since this report is so vague...) -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
[Bug c++/28360] [4.2 regression] undefined reference when header contains additional namespace
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-12 17:05 --- The code is invalid as the anonymous namespace causes an ODR violation. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28360
[Bug c++/28360] [4.2 regression] undefined reference when header contains additional namespace
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-12 17:09 --- To better explain: test::MonitorHandle references a class in an anonymous namespace which causes that class to be different in each TU. Since ODR rules say the class needs to be the same across TUs so we declare test::MonitorHandle also a local class. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28360
[Bug c++/28217] [4.0/4.1/4.2 regression] ICE in tree_int_cst_sgn
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-07-12 17:15 --- Volker, great job on the reduction for this. I am once again amazed. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28217
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-12 17:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug c++/28357] [4.0/4.1/4.2 regression] c-style downcasts on const multiple inherited objects differ if const vs non-const cast
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-12 17:39 --- Hmm: SdOptionsPrint rOldUnconst = (SdOptionsPrint)(rOther); Looks like that is we are saying this is a reinterpret_cast. Related to PR 22132. I bet the fix for PR 22132, just needs to be expanded for reference types also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||22132 Keywords||wrong-code Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-12 17:47 --- Well... maybe the RM has an opinion on this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug bootstrap/28324] boostrapping with gcc fails with unrecognized linker option
--- Comment #5 from ro at gcc dot gnu dot org 2006-07-12 17:48 --- No, not at all. On the contrary, I usually avoid GNU ld on non-Linux platforms. You just need to make sure that GNU ld isn't installed in /usr/local/mips-sgi-irix6.5/bin/ld where gcc looks for ld by default. Rainer -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28324
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #8 from marcus at jet dot franken dot de 2006-07-12 18:30 --- yes, this could still be fixed for release branches ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp
--- Comment #3 from tromey at gcc dot gnu dot org 2006-07-12 19:29 --- testing a patch -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-11 19:28:31 |2006-07-12 19:29:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #11 from pault at gcc dot gnu dot org 2006-07-12 19:41 --- Created an attachment (id=11871) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11871action=view) An unpolluted version of the beta-release patch I do apologise; the previous diff was relative to a development tree that had another patch with it. The net result was that it undid the committed patch and caused regressions. The new attachment includes the three test cases; it regtests on tonight's trunk. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #11867|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp
--- Comment #4 from tromey at gcc dot gnu dot org 2006-07-12 20:01 --- Subject: Bug 28329 Author: tromey Date: Wed Jul 12 20:01:47 2006 New Revision: 115396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115396 Log: PR java/28329: * lang-specs.h: Pass '%U'-based options as separate arguments. Use -faux-classpath. * lang.c (java_handle_option): Handle OPT_faux_classpath. * lang.opt (faux-classpath): New option. Modified: branches/gcj-eclipse/gcc/java/ChangeLog branches/gcj-eclipse/gcc/java/lang-specs.h branches/gcj-eclipse/gcc/java/lang.c branches/gcj-eclipse/gcc/java/lang.opt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
[Bug java/28329] [ecj] gcj leaves .jar and .zip files in /tmp
--- Comment #5 from tromey at gcc dot gnu dot org 2006-07-12 20:06 --- Fixed on branch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28329
[Bug c++/28363] New: Default template parameter causes compiler segfault
[EMAIL PROTECTED] tests]$ gcc --version
gcc (GCC) 4.1.0
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[EMAIL PROTECTED] tests]$ cat test01.cpp
template
class T1, class T2,
template int class T0 = T1,
struct A {
};
[EMAIL PROTECTED] tests]$ g++ -Wall -g test01.cpp -o test01
test01.cpp:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] tests]$
--
Summary: Default template parameter causes compiler segfault
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot lemings at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28363
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- Comment #10 from sje at gcc dot gnu dot org 2006-07-12 21:46 --- Subject: Bug 28114 Author: sje Date: Wed Jul 12 21:46:43 2006 New Revision: 115397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115397 Log: PR c++/28114 * name-lookup.c (pushtag): Return if we have error_mark_node. Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/name-lookup.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug c++/28114] [4.0/4.1 regression] ICE with struct definition in argument of template function
--- Comment #11 from sje at gcc dot gnu dot org 2006-07-12 21:48 --- Subject: Bug 28114 Author: sje Date: Wed Jul 12 21:47:58 2006 New Revision: 115398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115398 Log: PR c++/28114 * g++.dg/other/pr28114.C: New. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/other/pr28114.C Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28114
[Bug c++/28217] [4.0/4.1/4.2 regression] ICE in tree_int_cst_sgn
--- Comment #14 from jason at gcc dot gnu dot org 2006-07-12 21:58 --- Subject: Bug 28217 Author: jason Date: Wed Jul 12 21:57:58 2006 New Revision: 115399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115399 Log: PR c++/28217 * semantics.c (note_decl_for_pch): Don't premangle templates. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28217
[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6
--- Comment #4 from craigwd2000 at gmail dot com 2006-07-12 22:08 --- Created an attachment (id=11872) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11872action=view) This is my config.log file that was generated when attempting to compile GCC 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6
--- Comment #5 from craigwd2000 at gmail dot com 2006-07-12 22:10 --- I have also just updated my iMac G5 to 10.4.7. The error in 7/07/06 comment occurred just shortly after updating to 10.4.7 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-12 22:11 --- The config.log in the libstdc++ directory under the powerpc-apple-darwin8.7.0 directory would be more useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
[Bug other/28297] GCC 4.1.1 fails to build on Mac OS X 10.4.6
--- Comment #7 from craigwd2000 at gmail dot com 2006-07-12 22:25 --- Created an attachment (id=11873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11873action=view) My config.log file that's related to Libstdc++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28297
[Bug tree-optimization/28364] New: poor optimization choices when iterating over a std::string (probably not c++-specific)
Consider the following test program:
#include string
bool has_bad_chars(std::string const path)
{
for (std::string::const_iterator c = path.begin(); c != path.end(); c++)
{
unsigned char x = static_castunsigned char(*c);
if (x = 0x1f || x == 0x5c || x == 0x7f)
return true;
}
return false;
}
At -O2, GCC 4.1 chooses to duplicate the entire body of the loop for no good
reason; the code is not rendered more straight-line by this, and in fact it
executes strictly more instructions even for a single-character string. I'll
attach an assembly file showing what it did (Z13has_bad_charsRKSs) and what it
should have done (_Z14has_bad_chars2RKSs). The bad transformation is done by
the .t45.ch pass, which acronym does not mean anything to me.
--
Summary: poor optimization choices when iterating over a
std::string (probably not c++-specific)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #1 from zackw at panix dot com 2006-07-12 22:33 --- Created an attachment (id=11874) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11874action=view) assembly output (bad on top, hand-corrected below) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-12 22:41 --- Loop-Copy header is doing it Which means there is a confusion at what is the real header of the loop here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #3 from zackw at panix dot com 2006-07-12 22:42 --- I should mention that the exact command line flags were -O2 -fomit-frame-pointer -march=pentium4, and that I hand-tweaked the label numbers for ease of reading. Also, -fno-tree-ch does suppress this bad optimization, but in exchange we get mildly worse code from the loop optimizer proper - it uses [reg+reg] indexing and a 0..n count instead of [reg] indexing and a base..limit count. The code is pretty short so I'll just paste it here (meaningless labels removed): _Z17has_bad_chars_newRKSs: pushl %ebx movl8(%esp), %eax movl(%eax), %eax xorl%ecx, %ecx movl-12(%eax), %ebx .L2: cmpl%ecx, %ebx je .L10 movzbl (%ecx,%eax), %edx cmpb$31, %dl jbe .L4 cmpb$92, %dl je .L4 addl$1, %ecx cmpb$127, %dl jne .L2 .L4: movl$1, %eax popl%ebx .p2align 4,,2 ret .L10: xorl%eax, %eax popl%ebx .p2align 4,,2 ret Looking at the code, I see that the entire purpose of tree-ch is to duplicate loop bodies in this fashion, and the justification given is that it increases effectiveness of code motion and reduces the need for loop preconditioning, which I take to cover the above degradation in addressing mode choice. I'm not an optimizer expert, but surely there is a way to get the best of both worlds here...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #4 from zackw at panix dot com 2006-07-12 22:48 --- I remembered that I had a build of 4.2 from last week lying around. It generates even worse code - still with the duplication of most of the loop, plus a bunch of unnecessary register fiddling and bad addressing mode choice. -- zackw at panix dot com changed: What|Removed |Added Known to fail||4.1.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-12 22:52 --- For me on PPC-darwin, it generates pretty good code at just -O2 even though there is a duplicated header. The loop is pretty good at scheduling the code too: L9: lbz r0,0(r3) cmplwi cr7,r0,31 extsb r0,r0 cmpwi cr1,r0,127 cmpwi cr6,r0,92 ble- cr7,L4 beq- cr6,L4 beq- cr1,L4 L8: addi r3,r3,1 bdnz L9 Though the branches throw off everything (though that is a different issue), for the Cell really cror should be used (I think). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug c++/28365] New: error: ' error: 'MyClass::MyClass(const MyClass)' is private error: within this context
class MyClass
{
public:
MyClass() {}
MyClass(int i) { m_i = i;}
private:
MyClass(const MyClass x) {};
int m_i;
};
class MyInserter
{
public:
MyInserter() {};
MyInserter operator(const MyClass m) {m_c = m; return *this;};
private:
MyClass m_c;
};
int main()
{
MyClass a(1);
MyInserter m;
m a;
m MyClass(2);
return 0;
}
In this case a new MyClass node is not suppose to be constructed so a
constructor should not be needed. This works on gcc 3.2 does not work on 4.1.1
RogueWave has this throughout it's code.
--
Summary: error: ' error: 'MyClass::MyClass(const MyClass)'
is private error: within this context
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kk at microfocus dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28365
[Bug c++/28365] error: ' error: 'MyClass::MyClass(const MyClass)' is private error: within this context
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-12 23:11 --- The C++ standard changed to allow this after we (GCC) decided that we should follow the C++ standard. Anyways this is a dup of bug 25950. *** This bug has been marked as a duplicate of 25950 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|error: ' error: |error: ' error: |'MyClass::MyClass(const |'MyClass::MyClass(const |MyClass)' is private |MyClass)' is private |error: within this context |error: within this context http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28365
[Bug c++/25950] [3.4/4.0/4.1] [DR 391] Reference binding and explicit copy constructors
--- Comment #23 from pinskia at gcc dot gnu dot org 2006-07-12 23:11 --- *** Bug 28365 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kk at microfocus dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25950
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-07-12 23:13 --- Loop header copying is OK; the result is the one I would expect, it certainly does not make the code worse (unless you are optimizing for code size), and in many cases may make it better. I will have a look at the addressing mode choices. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #7 from zackw at panix dot com 2006-07-12 23:19 --- Created an attachment (id=11875) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11875action=view) C test case (with interesting implications) I've found a plain C test case. In the process, I've found that the way libstdc++ string is coded interacts interestingly with the optimizer. In the attached file, has_bad_chars_bad is a literal translation to C of the code seen by the optimizers after inlining for the original C++ test case. Yes, libstdc++ string does the moral equivalent of ((struct rep*)path)[-1].len. This function compiles to the same bad code as my original test case. has_bad_chars_good, on the other hand, is how I naively thought string worked on the first read-through. That one compiles to code which looks optimal to me. I suspect some optimizer or other is not smart enough to see through this particular construct ... it would be good to make it do so, since we want libstdc++ string to generate good code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)
--- Comment #8 from zackw at panix dot com 2006-07-12 23:21 --- Zdenek: I don't see how you can say that what we get is optimal code unless optimizing for size. The code generated *will* be slower than the alternative. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
