[Bug libfortran/23760] gfortran incorrectly succeeds on record overflow
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-08 06:52 --- Subject: Bug 23760 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-08 06:52:04 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gfortran.dg/g77: 1832.f Log message: 2005-09-07 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/23760 * gfortran.dg/g77/1832.f: Remove long string in write statement to allow the test to pass on correct list directed output with prepended space. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6025&r2=1.6026 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/g77/1832.f.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23760
[Bug target/23775] [4.1 Regression] wrong code in argument passing
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08 05:52 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-09-08 05:52:53 date|| Summary|4.1: wrong code in argument |[4.1 Regression] wrong code |passing |in argument passing Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug classpath/23768] doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
--- Additional Comments From csm at gnu dot org 2005-09-08 05:49 --- Confirmed. The doFinal methods should leave 'state' as-is, as the reporter suggests. It is up to CipherSpi subclasses to reset themselves when their 'engineDoFinal' methods are called. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |csm at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-08 05:49:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug target/23774] dealloc of dynamic stack space breaks backchain
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-08 03:22:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23774
[Bug driver/22600] Exit code should be different from 1 for internal compiler error
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-08 03:07 --- I think this is a good idea. I don't think we need a switch; this should just be the default. We also need a documentation update to mention this. And, I think the default ICE_EXIT_CODE shold be "2", unless we're already using that for something else. With those changes, I'll review and approve the patch for 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug debug/23190] [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs)
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:42 --- A more severe example is gdb.base/call-ar-st.c wherein the local static variable "double_array" is not put to the debug info at all. Not even its name as in the example here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/23190] [4.0/4.1 Regression] debug info omitted for uninitialized variables (stabs)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-08-02 00:37:12 |2005-09-08 02:39:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23190
[Bug debug/20830] [3.4 Regression] bad debug info for static nested struct with virtual function
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:35 --- >From the log, this was a gdb bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20830
[Bug middle-end/23775] New: 4.1: wrong code in argument passing
On a i686 platform, the example below is miscompiled with -O1. I expect this program to print -0.96. Here's what it actually does: $ g++ -O1 -o y y.cc $ ./y -1.288766 $ g++ -o y y.cc $ ./y -0.96 $ The value that the optimized version prints is actually different on each run of the program. Here's the generated code for main(), .globl main .type main, @function main: pushl %ebp movl%esp, %ebp subl$24, %esp movl%ebx, -8(%ebp) movl%esi, -4(%ebp) andl$-16, %esp subl$16, %esp movl$0, 12(%esp) movl8(%esp), %ebx; this seems to load ebx with garbage??? movl12(%esp), %esi fldz fstl8(%esp) fstpl (%esp) call_Z8x_from_zdd fstpl 4(%esp) movl%ebx, 8(%esp); this clobbers half of the arg with ; the garbage movl%esi, 12(%esp) movl$0, (%esp) call_Z17local_to_trflocalidi movl$0, %eax movl-8(%ebp), %ebx movl-4(%ebp), %esi movl%ebp, %esp popl%ebp ret It looks to me like the error occurs during RTL generation. Here's the tree dump from the t87.final_cleanup file (slightly trimmed): void local_to_trflocal(int, double, int) (D.1741, x_loc, D.1743) { : printf (&"%f\n"[0], x_loc); return; } double x_from_z(double, double) (pitch, stereo) { : return -9.59964472863211994990706443786621094e-1 / cos (stereo); } int main() () { : local_to_trflocal (0, x_from_z (0.0, 0.0), 0); return 0; } But in the 00.expand file, here's the sequence leading to the local_to_trflocal() call: (insn 27 26 28 1 (set (mem/i:DF (plus:SI (reg/f:SI 56 virtual-outgoing-args) (const_int 4 [0x4])) [0 S8 A32]) (reg:DF 71)) -1 (nil) (nil)) (insn 28 27 29 1 (set (mem:DI (plus:SI (reg/f:SI 56 virtual-outgoing-args) (const_int 8 [0x8])) [0 S8 A8]) (reg:DI 68)) -1 (nil) (nil)) (insn 29 28 30 1 (set (mem:SI (reg/f:SI 56 virtual-outgoing-args) [0 S4 A32]) (const_int 0 [0x0])) -1 (nil) (nil)) (call_insn 30 29 31 1 (call (mem:QI (symbol_ref:SI ("_Z17local_to_trflocalidi") [flags 0x3] ) [0 S1 A8]) (const_int 16 [0x10])) -1 (nil) (nil) (nil)) Reg 71 here is the return value from x_from_z. I don't know where the DI store to v-o-a+8 is coming from... Environment: System: Linux karma 2.6.12.1sss #2 Thu Jul 7 00:28:21 EDT 2005 i686 i686 i386 GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc --enable-threads=posix --enable-long-long --enable-languages=c,c++,f95 How-To-Repeat: Compile with -O1 - //g++ -O1 -g -o y y.cc extern "C" double cos(double); extern "C" int printf (...); double x_from_z(double pitch=0, double stereo=0) { return -0.96/cos(stereo); } void local_to_trflocal(int, double x_loc, int=0) { printf ("%f\n", x_loc); } int main() { local_to_trflocal(0, x_from_z()); return 0; } - --- Additional Comments From snyder at fnal dot gov 2005-09-08 02:31 --- Fix: -- Summary: 4.1: wrong code in argument passing Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: snyder at fnal dot gov CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
[Bug middle-end/8743] receiving result from __builtin_return_address() beyond stack top causes segfault
--- Additional Comments From normbograham at yahoo dot com 2005-09-08 01:43 --- Ed: I also have the same problem, but a little thought gives you a good work- around. First a little background. There is a function that calls main. This is the last function on the stack you can query using __builtin_return_address. If you query who calls that function you get a seg "fault" , quicker then grass through a goose. They should have called their __builtin_return_address(0) logic from there and stored the address, stopping future calls to this function from going further.This is exactly what you can do from main. (This is your workaround) Call _builtin_return_address(0) from main, store the result to a global, and you can compare against this address in the future (provided your not in an at_exit, or on_exit function call stack). Of course you've got to turn optimization off (-O0), I think or the results could be silly. Then you can query back to the main function (or one up if you wish to the boot-up routine.). Again: Dont be silly, turn off optmization (or function calls will colapse), store the result from main, and DONT call from "onexit" or "atexit" routines. good luck. n. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8743
[Bug target/23774] dealloc of dynamic stack space breaks backchain
-- What|Removed |Added Known to fail||4.0.2 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23774
[Bug target/23774] New: dealloc of dynamic stack space breaks backchain
The following compiled with -m32 -O2 -S void badFunc (int size) { char temp[size]; temp[size-1] = '\0'; }; gives badFunc: mflr 0 stwu 1,-16(1) stw 0,20(1) addi 0,3,30 lwz 9,0(1) mr 11,1 stw 31,12(1) mr 31,1 rlwinm 0,0,0,0,27 neg 0,0 stwux 9,1,0 li 9,0 addi 0,1,23 rlwinm 0,0,0,0,27 add 3,3,0 stb 9,-1(3) <- old backchain possibly overwritten nop nop nop lwz 0,0(1) mr 1,11 <- adjust stack, backchain possibly invalid! stw 0,0(1) <- write backchain nop lwz 11,0(1) lwz 0,4(11) lwz 31,-4(11) mr 1,11 mtlr 0 blr This testcase also shows a) excess allocation of dynamic stack space, b) needless alignment of dynamic stack space, c) poor epilogue code, with unnecesary stack adjustments. -- Summary: dealloc of dynamic stack space breaks backchain Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amodra at bigpond dot net dot au CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23774
[Bug libstdc++/23773] New: Improve abi.html
In particular, describe in the detail all the allowed and disallowed changes to the library headers (vs library proper, .so and .a): see the audit trail of libstdc++/23767 for some examples. -- Summary: Improve abi.html Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: documentation Severity: enhancement Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23773
[Bug target/23772] [3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886
-- What|Removed |Added Summary|[3.3/3.4 regression] [arm] |[3.4 regression] [arm] ICE |ICE in change_address_1, at |in change_address_1, at |emit-rtl.c:1886 |emit-rtl.c:1886 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23772
[Bug target/23772] [3.3/3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886
--- Additional Comments From raj dot khem at gmail dot com 2005-09-07 23:15 --- I think it needs backporting this particular patch from Richard to 3.4 branch submitted for bug #12133 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-07-09 10:06:03 Modified files: gcc: ChangeLog gcc/config/arm : arm.c Log message: PR target/12133 * arm.c (arm_legitimate_index_p) Allow DFmode for soft-float and DImode to use +/-4k offset. may be then it can be closed as duplicate of bug #12133 if the patch is backported to gcc 3.4 branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23772
[Bug target/23772] New: [3.3/3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886
There is an internal error in gcc when following code is compiled with -O2 -c options. = typedef float floatvect2 __attribute__((mode(V2DF))); typedef union { floatvect2 vector; double f[2]; }resfloatvect2; void tempf(double *x, double *y) { floatvect2 temp={x[0],x[1]}; floatvect2 temp1={y[0],y[1]}; resfloatvect2 temp2; temp2.vector=temp+temp1; x[0]=temp2.f[0]; } == test.c: In function `tempf': test.c:16: internal compiler error: in change_address_1, at emit-rtl.c:1886 Please submit a full bug report, with preprocessed source if appropriate. I could reproduce this error on 3.3.1, 3.4.3, 3.4.4 It is working on gcc build from trunk. Moreover if I compile the compiler with --with-fpu=vfp the testcase works for 3.4.x There has been a similar fix done in bug #11183. -- Summary: [3.3/3.4 regression] [arm] ICE in change_address_1, at emit-rtl.c:1886 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com CC: gcc-bugs at gcc dot gnu dot org,rearnsha at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23772
[Bug ada/22285] __gnat_is_absolute_path: Segmentation fault
--- Additional Comments From danglin at gcc dot gnu dot org 2005-09-07 22:45 --- No longer occurs. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22285
[Bug ada/22285] __gnat_is_absolute_path: Segmentation fault
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-09-07 22:43 --- Subject: Re: __gnat_is_absolute_path: Segmentation fault > Do you still see the problem ? This is fixed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22285
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From bangerth at dealii dot org 2005-09-07 22:40 --- Yea, but I guess I'll leave this to you guys, that sounds too complicated for me. I'll just stick my head out every once in a while and try to find a loophope in your reasoning and to invent ways to show that a proposed change is, in fact, not ABI compatible :-) Like, I guess, it should be possible to find some way around if the proposed addition of a new parameter was for a regular function (for which one can take the address), rather than a constructor... In the meantime, I go back to solving partial differential equations -- that's simpler. W. -- What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug rtl-optimization/23524] bigger version of mov + cmp produced
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-09-07 22:05 --- It seems that expand generates different insns in 4.0 and 4.1 for the comparison in question: 4.0 generates: (from .00.expand) (insn 15 13 16 1 (set (reg/f:SI 62) (mem/s/f:SI (plus:SI (reg/v/f:SI 58 [ gw ]) (const_int 4 [0x4])) [5 .core.widget_class+0 S4 A32])) -1 (nil) (nil)) (insn 16 15 17 1 (set (reg/f:SI 63) (mem/f/i:SI (symbol_ref:SI ("xtermWidgetClass") [flags 0x40] ) [5 xtermWidgetClass+0 S4 A32])) -1 (nil) (nil)) (insn 17 16 18 1 (set (reg:CCZ 17 flags) (compare:CCZ (reg/f:SI 62) (reg/f:SI 63))) -1 (nil) (nil)) 4.1 generates: (insn 15 13 16 1 (set (reg:SI 62) (mem/s/f:SI (plus:SI (reg/v/f:SI 58 [ gw ]) (const_int 4 [0x4])) [5 .core.widget_class+0 S4 A32])) -1 (nil) (nil)) (insn 16 15 17 1 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 62) (mem/f/i:SI (symbol_ref:SI ("xtermWidgetClass") [flags 0x40] ) [5 xtermWidgetClass+0 S4 A32]))) -1 (nil) (nil)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23524
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:36 --- (In reply to comment #16) > I guess then there is no danger involved. Yeah! ;) > BTW, I'm not one of the corporate folks, so I have few problems with > breaking ABI compatibility :-) I was just too fast raising a point that > in the end didn't turn out to be very interesting... Very interesting, in fact. You know what, Wolfgang? Sooner or later we should write a FAQ/guidelines/whatever about those topics. Personally, I learned a lot of it by trial and error, without a clear guide, and whereas there are some good docs around about C, a lot less is available for the C++-specific issues. In my opinion would be very useful! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23261] [meta-bug] [mingw32] gfortran testsuite bugs
-- Bug 23261 depends on bug 23262, which changed state. Bug 23262 Summary: [mingw32] rewind truncates file http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23261
[Bug libfortran/23262] [mingw32] rewind truncates file
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07 21:33 --- Patch commited, bug fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug libfortran/23262] [mingw32] rewind truncates file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 21:32 --- Subject: Bug 23262 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 21:31:57 Modified files: libgfortran: ChangeLog acinclude.m4 config.h.in configure configure.ac libgfortran/io : transfer.c unix.c Log message: PR libfortran/23262 * acinclude.m4 (LIBGFOR_CHECK_CRLF): New check. * configure.ac: Use new check. * configure.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * io/transfer.c (next_record_w): Add case for CRLF as line terminator. * io/unix.c (tempfile, regular_file): Open files with O_BINARY on systems with CRLF. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.88&r2=1.163.2.89 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/acinclude.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5.12.1&r2=1.5.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/config.h.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.12.6&r2=1.16.12.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.26.12.8&r2=1.26.12.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.ac.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.20.12.8&r2=1.20.12.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.15&r2=1.32.2.16 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.13&r2=1.21.10.14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From bangerth at dealii dot org 2005-09-07 21:27 --- I guess then there is no danger involved. BTW, I'm not one of the corporate folks, so I have few problems with breaking ABI compatibility :-) I was just too fast raising a point that in the end didn't turn out to be very interesting... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23262] [mingw32] rewind truncates file
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 21:25 --- Subject: Bug 23262 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 21:25:40 Modified files: libgfortran: ChangeLog acinclude.m4 config.h.in configure configure.ac libgfortran/io : transfer.c unix.c Log message: PR libfortran/23262 * acinclude.m4 (LIBGFOR_CHECK_CRLF): New check. * configure.ac: Use new check. * configure.in: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * io/transfer.c (next_record_w): Add case for CRLF as line terminator. * io/unix.c (tempfile, regular_file): Open files with O_BINARY on systems with CRLF. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.296&r2=1.297 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/acinclude.m4.diff?cvsroot=gcc&r1=1.6&r2=1.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/config.h.in.diff?cvsroot=gcc&r1=1.24&r2=1.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/configure.ac.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.56&r2=1.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.36&r2=1.37 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
[Bug fortran/20848] PARAMETER and SAVE attribute conflict
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07 21:20 --- Fixed on mainline and 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20848
[Bug fortran/20848] PARAMETER and SAVE attribute conflict
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 21:19 --- Subject: Bug 20848 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 21:19:21 Modified files: gcc/fortran: ChangeLog symbol.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: parameter+save.f90 Log message: 2005-09-07 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20848 * symbol.c(check_conflict): Add conflict for parameter/save, 2005-09-07 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20848 * gfortran.dg/parameter+save.f90: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.112&r2=1.335.2.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.26.2.2&r2=1.26.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.387&r2=1.5084.2.388 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/parameter+save.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20848
[Bug tree-optimization/22471] [4.1 Regression] corrupted profile info with -O3 -fprofile-use
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 21:11 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22471
[Bug fortran/20848] PARAMETER and SAVE attribute conflict
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 21:08 --- Subject: Bug 20848 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 21:08:24 Modified files: gcc/fortran: ChangeLog symbol.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: parameter+save.f90 Log message: 2005-09-07 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20848 * symbol.c(check_conflict): Add conflict for parameter/save, 2005-09-07 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/20848 * gfortran.dg/parameter+save.f90: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.537&r2=1.538 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/symbol.c.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6022&r2=1.6023 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/parameter+save.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20848
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 21:07 --- Actually for inline functions, even with -fno-implicit-templates, instansiations are still generated (I can kind of see why. You could argue they shouldn't be, but they are) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug tree-optimization/23449] vortex fails without -fno-strict-aliasing
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-07 21:07 --- The code in mem*.[ch] is much messier than I originally thought. There are lots of casts in assignments of pointer variables. The macros in mem00.h starting with Unit_Size, which are used in both lvalues and rvalues, dereference through pointer casts. I'm no longer planning to suggest a fix to SPEC. The code in vortex violates aliasing rules and any fix would not be portable C; we'll need to work around it by compiling with -fno-strict-aliasing until someone comes up with a better solution. Closing this PR as INVALID. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23449
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:04 --- (In reply to comment #12) > What I had meant was liba.so containing an explicit specialization of > std::vector and libb.so using it while being compiled with > -fno-implicit-instantiations (or whatever the correct name for that > flag was). If you only re-compile libb.so, this won't work any more. > Likewise the other way round. If, however, std/vector.h contained both > the old and the new signature, the latter case would still work. Thanks for the explanation, I'm still trying to digest it fully ;) > This sounds like a pretty academic case, though (but hey, that's the kind > of work I'm paid for :-), so I don't think it's worth bothering about... Well, at some point we have to make a tradeoff, between fixing bugs and providing every possible sort of compatibility guarantee. Maybe we can delay as much as possible the choice, maybe this PR will be a turning point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:58 --- (In reply to comment #11) > I just tried adding a template parameter, You mean, to the __normal_iterator class itself? That does not work, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07 20:58 --- Even with the committed patch, there is still something wrong on i686: $ cat compl.f program main complex (kind=10) a, b integer(kind=1), dimension(32) :: ea, eb equivalence (ea, a), (eb, b) ea = 0 a = (3.2_10, -2.1_10) print '(16(Z2.2),1X,16(Z2.2))', ea(1:16),ea(17:32) open (10,form="unformatted",status="replace") write(10) a rewind(10) eb = 0 read(10) b print '(16(Z2.2),1X,16(Z2.2))', eb(1:16),eb(17:32) print *,b rewind(10) end $ gfortran -g compl.f $ gdb ./a.out GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /home/ig25/Krempel/a.out CDCC0040 668600C0 CDCC0040 6686 Program received signal SIGSEGV, Segmentation fault. 0xb7fb1f41 in output_float (f=0x8052390, value=) at ../../../gcc-4.1/libgfortran/io/write.c:475 475 if (buffer[2] != '.' || buffer[ndigits + 2] != 'e') (gdb) bt #0 0xb7f44f41 in output_float (f=0x8052390, value=) at ../../../gcc-4.1/libgfortran/io/write.c:475 #1 0xb7f45b78 in write_float (f=0xfff9, source=Variable "source" is not available. ) at ../../../gcc-4.1/libgfortran/io/write.c:900 #2 0xb7f45d08 in write_real (source=0xbfd71402 "", length=Variable "length" isnot available. ) at ../../../gcc-4.1/libgfortran/io/write.c:1387 #3 0xb7f45db1 in write_complex (source=0xbfd713f8 "ÍÌÌÌ", len=10) at ../../../gcc-4.1/libgfortran/io/write.c:1401 #4 0xb7f465bd in *_gfortrani_list_formatted_write (type=BT_COMPLEX, p=0xbfd713f8, len=10) at ../../../gcc-4.1/libgfortran/io/write.c:1462 #5 0xb7f3f760 in *_gfortran_transfer_complex (p=0xbfd713f8, kind=10) at ../../../gcc-4.1/libgfortran/io/transfer.c:891 #6 0x08048a28 in MAIN__ () at compl.f:15 #7 0x08048a83 in main (argc=1, argv=0xbfd714b4) at ../../../gcc-4.1/libgfortran/fmain.c:18 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:55 --- What I had meant was liba.so containing an explicit specialization of std::vector and libb.so using it while being compiled with -fno-implicit-instantiations (or whatever the correct name for that flag was). If you only re-compile libb.so, this won't work any more. Likewise the other way round. If, however, std/vector.h contained both the old and the new signature, the latter case would still work. This sounds like a pretty academic case, though (but hey, that's the kind of work I'm paid for :-), so I don't think it's worth bothering about... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:51 --- I just tried adding a template parameter, and it does break things unfortunatly. In an "old" file define something like: void f(vector::iterator v) {..} and then try to call it from a file that includes the new definition, and they won't link together. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug rtl-optimization/18853] [4.0 Regression] ICE: genautomata.c:5238, error: verify_flow_info: Incorrect fallthru
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:48 --- Works just fine on the mainline. -- What|Removed |Added Known to work|3.3.2 3.4.4 |3.3.2 3.4.4 4.1.0 Summary|[4.0/4.1 Regression] ICE: |[4.0 Regression] ICE: |genautomata.c:5238, error: |genautomata.c:5238, error: |verify_flow_info: Incorrect |verify_flow_info: Incorrect |fallthru|fallthru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18853
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:45 --- (In reply to comment #9) > Actually, __normal_iterator is what std::string uses for it's iterator class, > so we could be in trouble. As long as no user code expects instantiations of members of __normal_iterator inside the library proper to link against I don't think there are any risks (At least, this is my present understanding of these torny matters) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:39 --- Actually, __normal_iterator is what std::string uses for it's iterator class, so we could be in trouble. On the note of removing enable_if, my only other thought is something like: template then change the problem constructor to: template inline __normal_iterator(const __normal_iterator<_Iter, _Container, true>&..) and add That worries me more than the enable_if however... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:26 --- (In reply to comment #7) > If you add a third argument to the constructor, don't you somehow have to > add the old constructor with its two-argument signature to the library to > allow old programs to link against the new library? Why? As far as I can see there are *no* instantiations of the iterator class inside the library proper (*.so or *.a). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 20:21 --- Subject: Bug 23419 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 20:21:34 Modified files: libgfortran: ChangeLog libgfortran/io : write.c Log message: PR libfortran/23419 * io/write.c (extract_int): Use memcpy to access buffer. (extract_uint): Ditto. (extract_real): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.87&r2=1.163.2.88 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.23.2.11&r2=1.23.2.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:19 --- If you add a third argument to the constructor, don't you somehow have to add the old constructor with its two-argument signature to the library to allow old programs to link against the new library? How would you do that in this case? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 20:16 --- Subject: Bug 23419 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-07 20:16:47 Modified files: libgfortran: ChangeLog libgfortran/io : write.c Log message: PR libfortran/23419 * io/write.c (extract_int): Use memcpy to access buffer. (extract_uint): Ditto. (extract_real): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.295&r2=1.296 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/write.c.diff?cvsroot=gcc&r1=1.46&r2=1.47 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:14 --- (In reply to comment #5) > How about something like: Yes, in my mind earlier today I considered that solution. In principle should work. However, there are issues, I'm afraid: optimization issues with the extra dummy parameter (right?) and, well, maybe we can figure out something cleaner (in particular, I'm under the impression that, as a policy, we do our best to minimize the enable_if-isms) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c++/23691] [4.0 Regression] `mpl_::bool_::value' is not a valid template argument for type `bool' because it is a non-constant expression
-- What|Removed |Added CC||bangerth at dealii dot org Last reconfirmed|2005-09-06 18:49:14 |2005-09-07 20:12:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug c++/23771] [4.0/4.1 regression] Constant template argument not recognized as such
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:08 --- Note unlike PR 23691, this one does ___not___ work on the mainline. They might be the same issue but we won't really know until either one is fixed. -- What|Removed |Added OtherBugsDependingO||23691 nThis|| Known to fail||4.1.0 4.0.2 Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:06 --- You are right, I previously didn't think it was possible without adding some more template parameters. However, I should have known there is nothing you can't do with a few templates :) How about something like: template inline __normal_iterator(const __normal_iterator<_Iter, _Container>& __i, typename std::__enable_if::value>::__type = 0) : _M_current(__i.base()) { } Which shouldn't effect any existing code, as unless _Iter is convertable to _Iterator, _M_current(__i.base ()) isn't going to compile. I'm adding #include #include to do this, and of course I imagine we'll have to cut is_convertable out of type_traits... I haven't done a full test of this yet, but it seems reasonable at first glance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c++/23691] [4.0 Regression] `mpl_::bool_::value' is not a valid template argument for type `bool' because it is a non-constant expression
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:06 --- (In reply to comment #11) > This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre > but doesn't anymore with today's 4.0.2pre. Actually it is not really as this one works on the mainline. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug c++/23771] [4.0/4.1 regression] Constant template argument not recognized as such
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 20:06 --- Used to work with 4.1 20050822 but does not with 4.1 20050903. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-07 20:06:13 date|| Summary|[4.0.2 regression] Constant |[4.0/4.1 regression] |template argument not |Constant template argument |recognized as such |not recognized as such Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23771] [4.0.2 regression] Constant template argument not recognized as such
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03 --- *** Bug 23691 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug c++/23691] [4.0 Regression] `mpl_::bool_::value' is not a valid template argument for type `bool' because it is a non-constant expression
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:03 --- This is actually a duplicate of PR 23771. It compiles fine with 4.0.1pre but doesn't anymore with today's 4.0.2pre. W. *** This bug has been marked as a duplicate of 23771 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23691
[Bug c++/23771] New: [4.0.2 regression] Constant template argument not recognized as such
This code -- template struct length { static const int value = 3; }; template ::value> struct S {}; template S bar (T); template void foo () { bar (1); } - Used to compile with gcc 4.0.1pre (20050531), but it doesn't any more with today's snapshot of the 4.0.2 branch. It apparently doesn't recognize length::value as an integer constant expression any more: > /home/bangerth/bin/gcc-4.0.2-pre/bin/c++ -c source/grid/grid_generator.cc source/grid/grid_generator.cc: In function ‘void foo()’: source/grid/grid_generator.cc:11: error: ‘length::value’ is not a valid template argument for type ‘int’ because it is a non-constant expression source/grid/grid_generator.cc:11: error: no matching function for call to ‘bar(int)’ I don't really see how to work around this problem short of specifying the value of the second template argument by hand. This bug will (again) prevent 4.0.2 from being able to compile one of the proposed SPEC 2005 benchmarks (4.0.1 couldn't do this due to PR 21799). It would be nice if this could be fixed before 4.0.2 comes out. Thanks Wolfgang -- Summary: [4.0.2 regression] Constant template argument not recognized as such Product: gcc Version: 4.0.2 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bangerth at dealii dot org CC: gcc-bugs at gcc dot gnu dot org,mmitchel at gcc dot gnu dot org,nathan at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23771
[Bug libfortran/23770] New: unaligned buffers in i/o library force use of memcpy()
Currently, the buffers for reading/writing integers and reals in the i/o library are of type char[], which forces the use of memcpy(), as in the fix for PR 23356. It would be better for performance if suitable alignment could be forced on the buffers. -- Summary: unaligned buffers in i/o library force use of memcpy() Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23770
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:37 --- (In reply to comment #3) > Unfortunatly I don't believe thats possible without passing extra > information by more template parameters, which would break binary > compatability. In short, in my preliminary opinion, we can well envisage this assuming anything we do actually changes the signature of the constructor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:33 --- (In reply to comment #2) > Unfortunatly I don't believe thats possible without passing > extra information by more template parameters, which would break binary > compatability. I'm not going to discuss now the substance of this issue (hopefully soon!) but I don't think the binary compatibility thing is obviously true. When two different object modules are built, each one can use the appropriate constructor, and there are no risks of mixups when (possible) weak symbols are merged because the signatures would be different in this case (a very nasty issue instead is when you change *only* the return type of a function, in that case, as Geoff kindly reminded us, there are risks because the sig is the same!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23767] std::vector iterator implementation wrong
--- Additional Comments From chris at bubblescope dot net 2005-09-07 19:22 --- Hmm.. this is I believe a bug, but a very hard one to trigger. 1) This bug is very sensitive. It only occurs if the const_iterator member function is const and the iterator member function isn't. It doesn't appear for a pair of normal functions. 2) Just to point it out, if you try only allowing the first function t(iterator f), then the code won't compile, as it tries and fails to instansiated the templated constructor. The "obvious" way to fix this would be to change the templated constructor so that it only took the const version of the iterator. Unfortunatly I don't believe thats possible without passing extra information by more template parameters, which would break binary compatability. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:19 --- (In reply to comment #10) > one of the key differentiators > with iostreams is type safety, which is effectively broken with the current > behavior. By the way, I don't understand what do you mean by "type safety" in this context. Because the behavior of do_put *is* specified exactly "as if" printf were called, either printf("%x") is able to "digest" somehow a signed integer or not, there isn't much more to say. Currently, the impression is that according to the C99 standard is *not*, according to the C89 standard *maybe* it is. Then the issue would be, in case, only that of adjusting the C++ standard not to trigger undefined behavior from the printf function that it uses to functionally specify the mandated behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- (Cygwin) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From ash at onezero dot org 2005-09-07 19:18 --- I'm on Cywin and couldn't find a later version of gcc - is there one somewhere that I can use? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug middle-end/23769] always inline short functions if inlining would be as small as non-inlined code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 19:14 --- 3.3.x is old and does not have the inlining improvements that went into 3.4.x. You might want to try 3.4.x or even 4.0.x. 4.1.x (the mainline) has better inlining still. But without a full testcase, we won't know if this is fixed. I am thinking it is for 4.0.x or 4.1.x. -- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug c/23769] New: always inline short functions if inlining would be as small as non-inlined code
I noticed when compiling with gcc -std=c99 -Winline that this function inline uint16_t f(uint16_t x) { return x; } wasn't getting inlined. Inlining is also not done even when the function is attributed with "__attribute__ ((always_inline))", nor does inlining happen when there no attributes at all. Maybe this function isn't getting inlined because the compiler decided that it would involve in some sense "too much" expansion in the caller. Regardless of this particular case, I wonder if the following enhancement to gcc would be worthwhile: always inline when it can be deduced that the code with inlining would be no larger than the code without inlining, regardless of the size of the caller in whatever representation is used at the time this decision is being made. For example, on many architectures, a call to a function that accepts an argument and returns a value will use at least 3 instructions in the caller: one to push the argument onto the stack, one to call the function, and one to retrieve the return value from the function. So, if the function uses up to three instructions to do its calculation, plus a return statement (with no calculation in the return), then inlining will use no more instruction space than not inlining. In these cases, inlining probably ought to be done so as to create opportunities for further optimizations later, e.g., common subexpression elimination. A more sophisticated determination could take into account the number of arguments and other factors. This might be especially helpful with C++ programs that have a lot of short methods. At least, this is how it looks to me - if I am wrong, maybe someone could educate me a bit or point me to some documentation where I can learn more about how gcc's inlining works. If inlining is supposed to work this way already, then I'll be happy to try to isolate the code further so that we have a small fully compilable example. I'm compiling with this: gcc -o t.exe -DZCodeTest -g -DZAssert -D__GCC__ -std=c99 -O3 -pedantic -Werror - Wall -W -I. -Wundef -Wshadow -Wpointer-arith -Wcast-qual -Wbad-function-cast - Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations - Wredundant-decls -Wdisabled-optimization -Winline t.c -- Summary: always inline short functions if inlining would be as small as non-inlined code Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ash at onezero dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23769
[Bug c++/17256] [3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 19:11 --- Hmm, this works correctly with the C front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 19:09 --- (In reply to comment #10) > The behavior we are mimicing isn't printf()'s behavior. This statement of yours is by and large incorrect, in the face of the actual way the C++ Standard is formulated. Please read again 22.2.2.2.2/2! printf() doesn't print > out hexadecimal signed integers as though they were unsigned integers. Intead, > C's type coercion allows the signed integers to be interpreted as unsigned > integers, and printf() then prints out the unsigned integers. This is not the case as far as C99 is concerned. According to the actual text of the C99 standard passing a signed type to printf("%x") triggers undefined behavior, see 7.19.6.1/9. And there are good reasons for this, pointed out moments ago by Martin Sebor on the LWG reflector (6.2.6.2/5 basically allows for negative integers that don't have a valid object representation in the corresponding unsigned signed type). On the LWG we are still discussing what the C89 says instead (C89 is rather different). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug target/16888] [3.4 Regression] ICE: in print_reg, at config/i386/i386.c:7254
-- What|Removed |Added Target Milestone|4.0.2 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
[Bug rtl-optimization/23324] [4.1 Regression] unsigned bitfield in struct not accessed correctly at -O2 and above
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-07 18:58 --- Looking into it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-08-11 12:22:54 |2005-09-07 18:58:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23324
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-07 18:40 --- The behavior we are mimicing isn't printf()'s behavior. printf() doesn't print out hexadecimal signed integers as though they were unsigned integers. Intead, C's type coercion allows the signed integers to be interpreted as unsigned integers, and printf() then prints out the unsigned integers. While I understand the value of printf() compatibility, one of the key differentiators with iostreams is type safety, which is effectively broken with the current behavior. If we wanted to preserve printf() like behavior then 'cout << hex << "some string"' should print out the address of the string literal in hex, rather than the string literal's contents, ignoring the hex flag completely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug classpath/23768] doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
-- What|Removed |Added CC||bug-classpath at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug classpath/23768] doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
-- What|Removed |Added Component|libgcj |classpath Product|gcc |classpath Version|4.0.1 |0.18 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug tree-optimization/14705] [tree-ssa] more alias analysis needed!?
-- What|Removed |Added Keywords||alias Last reconfirmed|2005-07-04 21:36:12 |2005-09-07 18:35:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14705
[Bug libgcj/23768] New: doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state
The JCE spec for Cipher.doFinal states: "Upon finishing, this method resets this cipher object to the state it was in when previously initialized via a call to init. That is, the object is reset and available to encrypt or decrypt (depending on the operation mode that was specified in the call to init) more data." However, the various doFinal() methods of the Cipher class reset the cipher to an uninitialized state. Subsequent calls to update() or doFinal() result in an IllegalStateException. The Cipher class contains the following in several doFinal methods: ... if (state != ENCRYPT_MODE && state != DECRYPT_MODE) { throw new IllegalStateException("neither encrypting nor decrypting"); } state = INITIAL_STATE; ... The state of the cipher should not be set to INITIAL_STATE after doFinal but remain either in ENCRYPT_MODE or DECRYPT_MODE. All of the doFinal methods are affected by this bug. This is my first bug report here, so please let me know if more information is needed such as an executable example. I'm also not sure (since I didn't see it in the bug writing guidelines) whether I sould attach a patch for this bug. The same problem also exists in the latest Classpath codebase. -- Summary: doFinal() methods in javax.crypto.Cipher incorrectly resetting cipher state Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: qianzwang at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
[Bug target/20010] *arm_extendqisi appears to never be matched
--- Additional Comments From nico at cam dot org 2005-09-07 18:24 --- I just tested with HEAD today and the problem doesn't appear to be there any longer. Therefore gcc 4.1.0 should be OK. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20010
[Bug c++/10416] 'unused variable' warning ignores ctor/dtor side-effects
-- What|Removed |Added Keywords|missed-optimization |diagnostic Last reconfirmed|2005-05-16 02:30:28 |2005-09-07 17:43:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10416
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added Known to fail||3.0.4 3.3.3 3.4.0 4.0.0 Known to work||2.95.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From richard at codesourcery dot com 2005-09-07 17:07 --- Subject: Re: Functions returning pointers with pointer argument "tobi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: > I don't have the standard at hand, but both the Intel and the Portland Group > compiler accept this. OK, thanks for checking! I'll work on the basis that it's valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug libstdc++/23767] std::vector iterator implementation wrong
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug c++/23767] std::vector iterator implementation wrong
--- Additional Comments From afra at cs dot stanford dot edu 2005-09-07 17:04 --- Created an attachment (id=9688) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9688&action=view) complete program showing bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:04 --- I don't have the standard at hand, but both the Intel and the Portland Group compiler accept this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug c++/23767] New: std::vector iterator implementation wrong
The following code does not compile. According to the compiler, 't' is overloaded ambiguously. #include struct T { typedef std::vector Vector; typedef Vector::iterator iterator; typedef Vector::const_iterator const_iterator; int t( iterator f) { return *f; } int t( const_iterator f) const { return *f; } }; int main(int, char*[]) { std::vector v; T t; T::const_iterator i = v.begin(); t.t(i); return 0; } We've seen this on gcc 3.2.2., 3.4.3, 4.0.1. Basically, the const_iterator matches both the iterator and the const_iterator at function resolution time. This seems to stem from the implementation of iterator in std::vector using __normal_iterator. There is a template copy constructor that appears to allow this illegal conversion. Error on: gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) -- test.cc: In function int main(int, char**): test.cc:18: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: test.cc:10: note: candidate 1: int T::t(__gnu_cxx::__normal_iterator > >) const test.cc:9: note: candidate 2: int T::t(__gnu_cxx::__normal_iterator > >) -- Summary: std::vector iterator implementation wrong Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: afra at cs dot stanford dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:02 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-09/msg00089.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 16:58 --- Hmm. I supposed I'd better check. Is the following code also valid: program main implicit none real, dimension (:), pointer :: x x => null() x => test () contains function test real, dimension (:), pointer :: test if (associated (x)) call abort allocate (test (10)) if (associated (x)) call abort end function test end program main I've not read anything in the standard that forbids it, but I'd appreciate it if more seasoned folks could comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:51 --- (In reply to comment #8) > Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is > not very precise, because, strictly speaking, the C Standard speaks only about > unsigned int and the C++ Standard mandates "%x" for many different types (see > 22.2.2.2.2/Stage1): then the user is allowed to invoke undefined behavior if > he uses "hex" together with anything != unsigned int, that is, basically, > *always* because unsigned int is not among the types over which do_put is > overloaded! I consider this a defect of the C++ Standard and will take care > of reporting it to the LWG Commitee. Thanks for pointing it out! Actually, the issue is less general and serious (i.e., restricted to the signedness issue, that allows the user to easily invoke undefined behavior from the underlying printf), because, anyway, according to Table 59, an 'l' will prefix the 'x' or 'X', in case of long or unsigned long. Sorry about the confusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:32 --- Fixed for 4.0.2 too. -- What|Removed |Added Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libstdc++/23358] _Destroy doesn't optimize for scalar types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 16:30 --- Subject: Bug 23358 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-07 16:30:38 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: stl_construct.h Log message: 2005-09-07 Thomas Kho <[EMAIL PROTECTED]> PR libstdc++/23358 * include/bits/stl_construct.h (_Destroy(_ForwardIterator, _ForwardIterator, allocator<_Tp>)): Removed unused template parameter. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.2917.2.78&r2=1.2917.2.79 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_construct.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.20&r2=1.20.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23358
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:28 --- (In reply to comment #7) > The ANSI definition for %x (or %X) only covers unsigned integers. Surely then > doing hex formatting on a signed integer would at the very least be undefined > behavior. Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is not very precise, because, strictly speaking, the C Standard speaks only about unsigned int and the C++ Standard mandates "%x" for many different types (see 22.2.2.2.2/Stage1): then the user is allowed to invoke undefined behavior if he uses "hex" together with anything != unsigned int, that is, basically, *always* because unsigned int is not among the types over which do_put is overloaded! I consider this a defect of the C++ Standard and will take care of reporting it to the LWG Commitee. Thanks for pointing it out! As long as libstdc++-v3 is concerned, what we are doing in such circumstances, is implementing a kind of behavior, which is the one usually implemented by printf. This is good, in my opinion, because consistent with printf, thus very useful when C++ and C code interoperate. You are right that in principle libstdc++-v3 could well crash and remain conforming ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 16:17 --- Reduced testcase: common /b/ end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug fortran/16404] should reject invalid code with -pedantic -std=f95 ? (x8)
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-07 16:09 --- (In reply to comment #16) > Since number 2 is already reported, we only have 3 and 6 left: I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a moment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16404
[Bug fortran/23765] segfault with syntactically wrong common declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 16:07 --- Confirmed, backtrace: #0 0x080a2406 in translate_common (common=0x96d29b8, var_list=Variable "var_list" is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:879 #1 0x0808ed05 in gfc_traverse_symtree (st=0x96d2998, func=0x80a25d0 ) at / home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/symbol.c:2295 #2 0x080a2534 in gfc_trans_common (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans-common.c:956 #3 0x080a7638 in gfc_generate_function_code (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/ gcc/src/gcc/fortran/trans-decl.c:2355 #4 0x08097a64 in gfc_generate_code (ns=0x96d23d0) at /home/peshtigo/pinskia/src/gnu/gcc/src/ gcc/fortran/trans.c:683 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-07 16:07:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug fortran/21143] cross-built gfortran installed as gfortran
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07 16:07 --- Can someone ping this patch on the gcc-patches ml? -- What|Removed |Added Last reconfirmed|2005-04-21 16:29:45 |2005-09-07 16:07:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-07 16:03 --- The ANSI definition for %x (or %X) only covers unsigned integers. Surely then doing hex formatting on a signed integer would at the very least be undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/23765] New: segfault with syntactically wrong common declaration
[EMAIL PROTECTED]:~/src/tests> cat pr16404.f90 REAL, TARGET :: B(2,2) common x/b/ B = 1. END [EMAIL PROTECTED]:~/src/tests> ../gcc/build/gcc/f951 pr16404.f90 MAIN__ pr16404.f90:3: 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. [EMAIL PROTECTED]:~/src/tests> The segfault happens when the common block is being translated, but the code should have been rejected much earlier. -- Summary: segfault with syntactically wrong common declaration Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
[Bug fortran/23373] Functions returning pointers with pointer argument
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07 15:59 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-13 11:47:53 |2005-09-07 15:59:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
[Bug c++/23764] Implicit conversion to a reference for an object broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 15:49 --- Not a bug as you cannot bind a rvalue to the reference type. Basicially what you have is: int g(void); void h(int&); void j(void) { h(g()); } And that is invalid. You can bind a rvalue to a const reference type though. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23764
[Bug awt/21598] rendering problem with button text
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 15:48 --- I filed a bug against GTK: http://bugzilla.gnome.org/show_bug.cgi?id=315462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
[Bug c++/23764] New: Implicit conversion to a reference for an object broken
Trying to compile the following code on a FreeBSD 5.4 machine, using GCC 4.0.1 # 1 "Test.cpp" # 0 "" # 1 "" # 1 "Test.cpp" class OutStream { public: OutStream(); }; inline OutStream & operator<<( OutStream & output, const int & value ) { return output; } class Client { public: OutStream send() { return OutStream(); } }; int main(int argc,char **argv) { Client myclient; int x = 32; int y = 64; myclient.send() << x << y; return 0; } Produces the following output... Using built-in specs. Target: i386-portbld-freebsd5.4 Configured with: ./..//gcc-4.1-20050730/configure --disable-nls --with-system- zlib --with-libiconv-prefix=/usr/local --program-suffix=41 -- libdir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0 --with-gxx-include- dir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++/ --disable- shared --disable-rpath --prefix=/usr/local i386-portbld-freebsd5.4 Thread model: posix gcc version 4.1.0 20050730 (experimental) /usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.1.0/cc1plus -E -quiet -v Test.cpp -fpch-preprocess -o Test.ii ignoring nonexistent directory "/usr/local/lib/gcc/i386-portbld- freebsd5.4/4.1.0/gcc/i386-portbld-freebsd5.4/4.1.0/../../../../i386-portbld- freebsd5.4/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++/ /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++//i386-portbld- freebsd5.4 /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/include/c++//backward /usr/local/include /usr/local/lib/gcc/i386-portbld-freebsd5.4/4.1.0/gcc/i386-portbld- freebsd5.4/4.1.0/include /usr/include End of search list. /usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.1.0/cc1plus -fpreprocessed Test.ii -quiet -dumpbase Test.cpp -auxbase Test -version -o Test.s GNU C++ version 4.1.0 20050730 (experimental) (i386-portbld-freebsd5.4) compiled by GNU C version 4.1.0 20050730 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: c62afa56bfea22d68bd8bf2d1f862a27 Test.cpp: In function 'int main(int, char**)': Test.cpp:33: error: no match for 'operator<<' in 'myclient. Client::send() << x' Test.cpp:11: note: candidates are: OutStream& operator<<(OutStream&, const int&) -- Summary: Implicit conversion to a reference for an object broken Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rlyle at ritual dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23764
[Bug tree-optimization/22555] array in struct disables salias subvars for other fields
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07 15:25 --- Subject: Bug 22555 CVSROOT:/cvs/gcc Module name:gcc Branch: improved-aliasing-branch Changes by: [EMAIL PROTECTED] 2005-09-07 15:25:13 Modified files: gcc: tree-dfa.c tree-ssa-alias.c tree-ssa-loop-ivopts.c tree-ssa-loop.c tree-ssa-operands.c tree-ssa-structalias.c Added files: gcc: ChangeLog.iab gcc/testsuite : ChangeLog.iab gcc/testsuite/gcc.dg/tree-ssa: alias-3.c Log message: 2005-09-07 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/22555 * tree-dfa.c (okay_component_ref_for_subvars): Do not give up, if one structure field is an array. * tree-ssa-alias.c (create_overlap_variables_for): Likewise. * tree-ssa-structalias.c (create_variable_info_for): Likewise. (get_constraint_for_component_ref): Do not assert we can not only be accessing padding if we deal with an ARRAY_REF. * tree-ssa-loop-ivopts.c (rewrite_use): Mark new vars in stmt for renaming. * tree-ssa-loop.c (pass_iv_optimize): Schedule TODO_update_ssa. * tree-ssa-operands.c (get_expr_operands): Continue scanning operands even if we found a subvar, but ignore VOPs in this case. * gcc.dg/tree-ssa/alias-3.c: New testcase. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.iab.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-dfa.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.63&r2=2.63.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.109&r2=2.109.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.87&r2=2.87.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.33.6.1&r2=2.33.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-operands.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.100&r2=2.100.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-structalias.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=2.27&r2=2.27.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.iab.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/alias-3.c.diff?cvsroot=gcc&only_with_tag=improved-aliasing-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22555
[Bug rtl-optimization/12535] Attempt to delete prologue/epilogue insn
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07 14:39 --- Simplified testcase. This bug is probably a WONTFIX. int bar (int *); int foo (void) { int x; __builtin_memset (&x, 0, 32); return bar (&x); } -- What|Removed |Added Known to fail||3.4.5 4.0.2 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12535