[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-07 08:08 --- Roger, this is a middle-end problem in fond_cond_expr_with_comparision; that is the routine which makes the invalid transformation. (It has a similar bug for MAX_EXPR.) If the result of the COND_EXPR is an lvalue, I do not believe this transformation is safe. As we have no language-independent means of testing lvalue-ness, I'm not sure that there's a straightforward fix. Would you care to take a look at this issue? -- What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug c++/19159] [4.0 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mark at codesourcery dot com 2005-01-07 08:17 --- Subject: Re: [4.0 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca > 2005-01-06 23:04 --- > Subject: Re: [4.0 Regression] Undefined symbol: vtable for __c > > >>Dave, would you mind testing with this revision to the patch? Thanks! > I'll try this evening. It's taken some time but I believe that the > following change broke my original suggested fix to decl2.c > (import_export_decl): Huh; no, I don't see offhand why that change would have interacted with your proposed change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug tree-optimization/18828] [4.0 Regression] Extraneous warning with var_start and optimization
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 09:01 --- Subject: Bug 18828 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 09:01:00 Modified files: gcc: ChangeLog builtins.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050105-2.c Log message: PR tree-optimization/18828 * builtins.c (expand_builtin_next_arg): Remove argument and all the argument checking. (expand_builtin): Adjust caller. (expand_builtin_va_start): Likewise. Remove error for too many arguments. (fold_builtin_next_arg): Issue error for too many arguments. After checking arguments, replace them with magic arguments that prevent further checking of the args. * gcc.dg/20050105-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7054&r2=2.7055 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.410&r2=1.411 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4860&r2=1.4861 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050105-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18828
[Bug rtl-optimization/18861] [4.0 Regression] ICE Segmentation fault in try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637 with two switches (table jumps)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 09:04 --- Subject: Bug 18861 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 09:04:02 Modified files: gcc: ChangeLog cfgbuild.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050105-1.c Log message: PR rtl-optimization/18861 * cfgbuild.c (BLOCK_USED_BY_TABLEJUMP): Define. (FULL_STATE): Define. (mark_tablejump_edge): New function. (purge_dead_tablejump_edges): New function. (find_bb_boundaries): Use it. * gcc.dg/20050105-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7055&r2=2.7056 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cfgbuild.c.diff?cvsroot=gcc&r1=1.57&r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4861&r2=1.4862 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050105-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18861
[Bug target/19012] [4.0 Regression] ICE on testsuite/gcc.c-torture/execute/930208-1.c with -fpack-struct -Os
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 09:06 --- Subject: Bug 19012 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 09:05:50 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR rtl-optimization/19012 * config/i386/i386.md (addqi_1_slp): Set memory attribute. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7056&r2=2.7057 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.600&r2=1.601 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19012
[Bug tree-optimization/19283] [4.0 Regression] Bad code generated in final_cleanup
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 09:08 --- Subject: Bug 19283 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 09:08:11 Modified files: gcc: ChangeLog fold-const.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050106-1.c Log message: PR tree-optimization/19283 * fold-const.c (fold_widened_comparison): Return NULL if shorter_type is not shorter than the original type. * gcc.c-torture/execute/20050106-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7057&r2=2.7058 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.490&r2=1.491 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4862&r2=1.4863 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050106-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19283
[Bug target/13685] Building simple test application with -march=pentium3 -Os gives SIGSEGV (unaligned sse instruction)
--- Additional Comments From roger dot larsson at norran dot net 2005-01-07 09:49 --- Got a query about this bug... It is still valid for gcc 3.3.4 My computer has been upgraded to a athlon-xp, so I tested both g++ -Os -march=pentium3 matrix.cpp -o matrix and g++ -Os -march=athlon-xp matrix.cpp -o matrix they both gives Segmentation fault when running ./matrix Other optimization levels works. Updated summary etc. -- What|Removed |Added Keywords||wrong-code Priority|P2 |P1 Summary|Building KDE3.2 clock applet|Building simple test |with -march=pentium3 -O1|application with - |gives SIGSEGV |march=pentium3 -Os gives ||SIGSEGV (unaligned sse ||instruction) Version|3.3.1 |3.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
[Bug target/19307] New: ICE with -msse2 -mno-80387
This testcase:
double test (double a, double b) {
double x;
x = (a < b) ? a : 1.0;
return x;
}
will ICE with '-O2 -mno-80387 -msse2':
cmove.c: In function âtestâ:
cmove.c:6: error: unrecognizable insn:
(insn 64 55 52 (parallel [
(set (reg:XF 9 st(1))
(reg:XF 8 st))
(set (reg:XF 8 st)
(reg:XF 9 st(1)))
]) -1 (nil)
(nil))
cmove.c:6: internal compiler error: in insn_default_length, at
insn-attrtab.c:408
Please submit a full bug report,
Without -msse2, there is no ICE, but code still uses FP regs.
test:
pushl %ebp
movl%esp, %ebp
subl$24, %esp
fldl16(%ebp)
fstpl 8(%esp)
fldl8(%ebp)
fstpl (%esp)
call__ltdf2
fldl8(%ebp)
testl %eax, %eax
jns .L8
leave
ret
.p2align 4,,7
.L8:
fstp%st(0)
leave
fld1
.p2align 4,,2
ret
--
Summary: ICE with -msse2 -mno-80387
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: pentium4-pc-linux-gnu
GCC host triplet: pentium4-pc-linux-gnu
GCC target triplet: pentium4-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307
[Bug c++/16792] [4.0 regression] ICE in gen_subprogram_die, at dwarf2out.c:11267
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07 10:02 --- Fixed on mainline by Dan's patch for PR 19267: http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg00198.html I checked all three testcases (original testcase and the ones in comments #7 and #8). -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16792
[Bug target/19012] [4.0 Regression] ICE on testsuite/gcc.c-torture/execute/930208-1.c with -fpack-struct -Os
--- Additional Comments From jbeulich at novell dot com 2005-01-07 10:21 --- Since the change originally having introduced this problem was also applied to 3_4-branch, will this here be applied there, too? -- What|Removed |Added Known to fail|4.0.0 |4.0.0 3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19012
[Bug middle-end/18628] [4.0 regression] miscompilation of switch statement in loop
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07 10:24 --- Alas this is not fixed by the patch for PR18861. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18628
[Bug fortran/19308] New: compiler claims to accept variables of selected_integer_kind(30), I/O leads to internal error
$ cat sel.f90 program sel integer(kind=selected_int_kind(30)) :: j j = 42 print *,j end $ gfortran sel.f90 $ ./a.out At line 4 of file sel.f90 Internal Error: bad integer kind $ gfortran -v Using built-in specs. Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20050102 (experimental) $ gfortran -dumpmachine ia64-unknown-linux-gnu I don't know wether 128-bit integers are supposed to work or not, so this is either a library or a compiler bug. -- Summary: compiler claims to accept variables of selected_integer_kind(30), I/O leads to internal error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19308
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-01-07 10:27 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Fri, 7 Jan 2005, zack at gcc dot gnu dot org wrote: > An obvious rebuttal to this is that the compiler used in step 4 is broken. As > you say, the C standard references ISO10646 not Unicode and the concept of > normalization does not exist in ISO10646, and this could be taken to imply > that > no normalization shall occur. However, there is no unambiguous statement to > that effect in the standard, and there is strong quality-of-implementation I think the relevant text is that treating identifiers as sequences of characters and UCNs denoting single characters. I've had no on-list response yet to the query about this I sent to the WG14 reflector on Tuesday (reflector message 10698), with the HEBREW LETTER SHIN WITH DAGESH AND SHIN DOT examples. > pressure in the opposite direction. Put aside the standard for a moment: are > users going to like a compiler that insists that "Å" (U+00C5) and "Å" > (U+212B) > are not the same character? [It happens that on my screen those are ever so > slightly different, but that's just luck - and X11 will only let me type > U+00C5; > I resorted to hex-editing to get the other.] The question of appearance is the same as that for U+0041 LATIN CAPITAL LETTER A, U+0391 GREEK CAPITAL LETTER ALPHA, U+0410 CYRILLIC CAPITAL LETTER A. Will users like such a compiler less than one which doesn't allow them to use their native language in identifiers at all? > normalization, as a defensive measure against such external changes. > You could argue that this is just another way for C programmers to shoot > themselves in the foot, but I don't think the myriad ways that already > exist are a reason to add more. (It's WG14 and WG21 that added the new way, not us. And it may be that if they are to become convinced there is any mistake then they must see real world problems arising with real implementations of the existing standards, rather than hypothetical problems. Mistakes were made in C99 of adding features in general without adequate implementation experience; changing them without experience showing what is a genuine problem could be seen as another such mistake to avoid.) I could believe there could be a case for -fextended-identifiers required to enable UCNs in identifiers until there is more experience, with documentation along the lines of that formerly associated with -pedantic "This option is not intended to be useful; ...". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug fortran/15553] Array copy operation produces garbage
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07 10:37 --- (In reply to comment #8) > Still fails on i686-pc-linux: Is this something that should be put into the test suite, so it is possible to get a better overview of when and on which machines this fails? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug preprocessor/19309] New: Wrong documentation of predefined __GNUC__ with cpp invocation
Hi, According to documentation of preprocessor (cpp.texi:1934) the predefined macros __GNUC__ __GNUC_MINOR__ __GNUC_PATCHLEVEL__ "are defined only when the entire compiler is in use; if you invoke the preprocessor directly, they are not defined." But, > touch foo.c > cpp -dM -E foo.c | grep GNUC produces #define __GNUC_PATCHLEVEL__ 0 #define __GNUC__ 4 #define __GNUC_MINOR__ 0 Same behaviour is observed on 3.4.4. Macros are also defined with cpp -traditional-cpp. Should the documentation be modified? Or is there any reason _not_ to define __GNUC__ when invoking cpp. Danny -- Summary: Wrong documentation of predefined __GNUC__ with cpp invocation Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug fortran/19310] New: unnecessary error for overflowing results
The following compile-time error is uneecessary: $ cat overflow.f90 program main real :: a a = exp(1000.) print *,a end program main $ gfortran overflow.f90 In file overflow.f90:3 a = exp(1000.) 1 Error: Result of EXP overflows its kind at (1) Assigning infinity would work just fine: $ cat overflow2.f90 program main real :: a a = 1000. a = exp(a) print *,a end program main $ gfortran overflow2.f90 $ ./a.out +Infinity $ gfortran -v Using built-in specs. Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20050102 (experimental) $ gfortran -dumpmachine ia64-unknown-linux-gnu -- Summary: unnecessary error for overflowing results Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19310
[Bug fortran/19302] intrinsic_nearest.f90 fails
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07 10:56 --- I am not sure that this is indeed a bug. Is the result of nearest for +/- infinity defined to be +/huge ? Look at what ifort does: $ cat near-inf.f90 program test_nearest real inf inf = exp(1000.) print *,inf print *,nearest(inf,-1.0) print *,nearest(-inf,1.0) end $ ifort near-inf.f90 $ ./a.out Infinity Infinity -Infinity -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19302
[Bug other/19300] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-01-07 11:03 --- well, running this: # sparc32 ./gcc/contrib/test_installed --without-gcc --without-g77 --without-objc I get this: Running /usr/local/src/trunk/gcc/gcc/testsuite/g++.dg/pch/pch.exp ... FAIL: g++.dg/pch/wchar-1.C -g assembly comparison Running /usr/local/src/trunk/gcc/gcc/testsuite/g++.dg/special/ecos.exp ... The rest of the pch tests are fine, so, it's a regression I'd say. Oh, this is with gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug other/19300] [4.0 Regression] PCH failures
-- What|Removed |Added Summary|PCH failures on sparc-linux |[4.0 Regression] PCH ||failures Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug target/19250] minss/maxss SSE insn not generated for -mfpmath=sse
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:15 --- The same trick as in http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html with sqrtf applied to return value gets the code as expected. minf: subl$4, %esp movss 8(%esp), %xmm0 movss 12(%esp), %xmm1 minss %xmm1, %xmm0 sqrtss %xmm0, %xmm0 movss %xmm0, (%esp) flds(%esp) addl$4, %esp ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19250
[Bug fortran/15553] Array copy operation produces garbage
--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-07 11:19 --- Subject: Re: Array copy operation produces garbage Thomas dot Koenig at online dot de wrote: > --- Additional Comments From Thomas dot Koenig at online dot de > 2005-01-07 10:37 --- > (In reply to comment #8) > >>Still fails on i686-pc-linux: > > > Is this something that should be put into the test suite, > so it is possible to get a better overview of when and > on which machines this fails? gcc's policy is no known failures in the testsuite, so I'm afraid this is not possible. I do think this is a good idea, but only to the extent that other people's development work is not interfered with by spurious testsuite FAILs / XPASSes, which is inevitable in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:29 --- This bugreport shows similar problem for x87 code as PR 19252 shoes for SSE code. The cause of both probems is described in http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug libgcj/18115] JNI nio buffer functions only work with byte buffers
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 11:32 --- Subject: Bug 18115 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 11:32:07 Modified files: libjava: ChangeLog jni.cc libjava/java/nio: Buffer.java CharViewBufferImpl.java DirectByteBufferImpl.java DoubleViewBufferImpl.java FloatViewBufferImpl.java IntViewBufferImpl.java LongViewBufferImpl.java MappedByteBufferImpl.java ShortViewBufferImpl.java Added files: libjava/testsuite/libjava.jni: directbuffer.c directbuffer.java directbuffer.out bytebuffer.c bytebuffer.java bytebuffer.out Log message: 2005-01-07 Michael Koch <[EMAIL PROTECTED]> PR libgcj/18115 * java/nio/Buffer.java (address): New field. * java/nio/DirectByteBufferImpl.java (address): Removed. * java/nio/MappedByteBufferImpl.java (address): Likewise. * java/nio/CharViewBufferImpl.java (CharViewBufferImpl): Explicitly initialize Buffer.address if needed. * java/nio/DoubleViewBufferImpl.java (DoubleViewBufferImpl): Likewise. * java/nio/FloatViewBufferImpl.java (FloatViewBufferImpl): Likewise. * java/nio/IntViewBufferImpl.java (IntViewBufferImpl): Likewise. * java/nio/LongViewBufferImpl.java (LongViewBufferImpl): Likewise. * java/nio/ShortViewBufferImpl.java (ShortViewBufferImpl): Likewise. * jni.cc (_Jv_JNI_GetDirectBufferAddress): Don't assume buffer is a DirectByteBufferImpl object. (_Jv_JNI_GetDirectBufferCapacity): Likewise. * testsuite/libjava.jni/directbuffer.c, testsuite/libjava.jni/directbuffer.java, testsuite/libjava.jni/directbuffer.out, testsuite/libjava.jni/bytebuffer.c, testsuite/libjava.jni/bytebuffer.java, testsuite/libjava.jni/bytebuffer.out: New files. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3273&r2=1.3274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni.cc.diff?cvsroot=gcc&r1=1.91&r2=1.92 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/Buffer.java.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/CharViewBufferImpl.java.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/DirectByteBufferImpl.java.diff?cvsroot=gcc&r1=1.16&r2=1.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/DoubleViewBufferImpl.java.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/FloatViewBufferImpl.java.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/IntViewBufferImpl.java.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/LongViewBufferImpl.java.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/MappedByteBufferImpl.java.diff?cvsroot=gcc&r1=1.14&r2=1.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/nio/ShortViewBufferImpl.java.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/directbuffer.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/directbuffer.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/directbuffer.out.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/bytebuffer.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/bytebuffer.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/bytebuffer.out.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18115
[Bug fortran/15553] Array copy operation produces garbage
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-07 11:37 --- I took time to look at this again, and I'm sorry to say that my reduced testcase did print out an uninitialized variable, and was therefore wrong. My apologies to all those who have wasted their time on this. Since I don't know when or how this was fixed, I'll close this as WORKSFORME. I'll see about creating something for the testsuite. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug target/19252] sub optimal use of fpu comparisons in SSE code
--- Additional Comments From uros at kss-loka dot si 2005-01-07 11:32 --- Also some discussion here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00394.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19252
[Bug fortran/15553] Array copy operation produces garbage
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 11:56 --- Subject: Bug 15553 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 11:56:12 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: array-1.f90 Log message: PR fortran/15553 * gfortran.dg/array-1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4863&r2=1.4864 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/array-1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner
--- Additional Comments From nathan at gcc dot gnu dot org 2005-01-07 12:08 --- It is somekind of inliner funkiness. make_decl_rtl is complaining about making the rtl for a non-register auto var. I'll leave it for an inliner guy. -- What|Removed |Added AssignedTo|nathan at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19241
[Bug rtl-optimization/18861] [4.0 Regression] ICE Segmentation fault in try_crossjump_to_edge at ../../gcc/gcc/cfgcleanup.c:1637 with two switches (table jumps)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-07 12:12 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18861
[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked on ppc
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-07 12:23:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046
[Bug target/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base
-- What|Removed |Added GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19075
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-07 12:24:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug fortran/19302] intrinsic_nearest.f90 fails
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-07 12:30 --- (reply to comment #4) After your comment, not sure either if it's a bug. The original testcase (intrinsic_nearest.f90) fails with Intel (7 and 8) and Portland Group compilers on i686, but works with g95 and gfortran on i686. On sparc-sun-solaris, it works with Sun's f90 compiler but (as we know!) fails with gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19302
[Bug c++/19298] [4.0 Regression] dependent type (references) and calling a function method
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-07 00:54:46 |2005-01-07 12:57:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298
[Bug c++/19311] New: ICE in resolve_overloaded_unification
template
struct A
{
explicit A (R (T::*xf) ()) : M (xf) {}
R operator () (T *x) const { return (x->*M) (); }
private:
R (T::*M) ();
};
template
struct B
{
explicit B (R (T::*xf) (C)) : M (xf) {}
R operator () (T *x, C y) const { return (x->*M) (y); }
private:
R (T::*M) (C);
};
template
inline A
foo (R (T::*x) ()) { return A (x); }
template
inline B
foo (R (T::*x) (C)) { return B (x); }
template< int X = 1 >
struct I
{
unsigned int i;
I () : i (0) {}
void o (unsigned int x) { i = x; }
unsigned int o () const { return i; }
};
template
struct S
{
unsigned int bar (void)
{
I<> j;
return foo > (&I<>::o) (&j);
}
};
ICEs in GCC 3.4.x and HEAD, compiles with GCC 3.2.3.
--
Summary: ICE in resolve_overloaded_unification
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
13:14 ---
A testcase never made it to testsuite. :-(
Well, the ICE was fixed in gcc 3.2.1, I don't think we need a testcase
for that one.
The other issue is the testcase from comment #4:
-
template struct X {
enum { N = 10 };
int items[N+1];
};
template int operator+(A,B);
X x;
--
The question is whether this is valid code or not.
There are two issues involved:
a) operator+ is defined *after* the definition of X.
Do we really have to take it into account for overload resolution
to compute N+1?
Mark's opinion (as stated in private email) to this is "no".
This would render the code valid.
Alas, gcc *does* take operator+ into account. And that's a bug.
b) Because gcc behaves wrong in a) we end up with a second problem:
Anonymous types cannot be template parameters. That's not an SFINAE
problem, this should be diagnosed as a hard error.
However, gcc 3.4.0 - 3.4.3 treat this as an SFINAE case, thus
accepting the code (although for the wrong reason).
Mark's patch for PR17413 changed that behavior for mainline
(maybe it will be backported to the 3.4 branch). So the code
is again rejected - because of the bug in a).
To make things short:
We have a rejects-valid bug in mainline. To the user this is a
regression from gcc 3.4.3, although the bug was latent in the compiler
and papered over by a second bug (PR 17413).
--
What|Removed |Added
CC||mark at codesourcery dot com
Status|RESOLVED|REOPENED
Keywords||monitored, rejects-valid
Known to fail||2.95.3 3.3.5 4.0.0
Known to work||3.4.0 3.4.3
Resolution|FIXED |
Summary|User-defined operator+ and |[4.0 regression] User-
|use of enum values in |defined operator+ and use of
|computation of array bounds |enum values in computation
||of array bounds
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
[Bug c++/6273] [4.0 regression] User-defined operator+ and use of enum values in computation of array bounds
-- What|Removed |Added AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273
[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:45 --- Confirmed. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||3.4.0 4.0.0 Known to work||3.3.2 Last reconfirmed|-00-00 00:00:00 |2005-01-07 13:45:56 date|| Summary|ICE in |[3.4/4.0 Regression] ICE in |resolve_overloaded_unificati|resolve_overloaded_unificati |on |on Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug libgcj/18115] JNI nio buffer functions only work with byte buffers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:46 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18115
[Bug target/19012] [3.4 Regression] ICE on testsuite/gcc.c-torture/execute/930208-1.c with -fpack-struct -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:47 --- Fixed on the mainline but still a regression on the 3.4 branch. -- What|Removed |Added Summary|[4.0 Regression] ICE on |[3.4 Regression] ICE on |testsuite/gcc.c-|testsuite/gcc.c- |torture/execute/930208-1.c |torture/execute/930208-1.c |with -fpack-struct -Os |with -fpack-struct -Os Target Milestone|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19012
[Bug tree-optimization/18828] [4.0 Regression] Extraneous warning with var_start and optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:48 --- Fixed, thanks Jakub. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18828
[Bug tree-optimization/19283] [4.0 Regression] Bad code generated in final_cleanup
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:49 --- Fixed thanks Jakub. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19283
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:52 --- Does large test fail with 3.4.x, if so then this is not really a regression except for PCH size. -- What|Removed |Added Summary|[4.0 Regression] PCH|[4.0 Regression] PCH |failures|failures on sparc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug libgcj/19301] Can't run Eclipse with libgcj until jaxp is merged from classpath
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-07 13:52:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19301
[Bug fortran/19310] unnecessary error for overflowing results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:54 --- Confirmed but I remember this error being here for a reason and there might be a bug which this is a dup of. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-01-07 13:54:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19310
[Bug libfortran/19308] compiler claims to accept variables of selected_integer_kind(30), I/O leads to internal error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 13:57 --- Confirmed, the bug is in the library which should support 128bit integers. On targets where the register size is 32, we don't support 128bit integers inside the compiler aka we error out. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-07 13:57:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19308
[Bug fortran/18476] internal compiler error on strange read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07 13:58 --- (In reply to comment #3) > I think we should issue an error, because nml is not ASSIGNed a FORMAT, but > since g77 accepts this code I'm not sure. g77 does bomb out at runtime, though; a warning at -Wuninitialized would probably be best (but g77 doesn't do that). The case of an assigned integer variable is already covered in PR 18481. This bug may be a bit different because of the possible confusion between an integer variable named NML and the NML option to the read statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18476
[Bug preprocessor/19309] [3.4/4.0 Regression] Wrong documentation of predefined __GNUC__ with cpp invocation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 14:00 --- I don't know if this an excepted change, but either way the documention does not match reality. Oh, in 3.3.2 we did predefined those macros which is why this is a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||documentation Known to fail||3.4.0 4.0.0 Known to work||3.3.2 Last reconfirmed|-00-00 00:00:00 |2005-01-07 14:00:34 date|| Summary|Wrong documentation of |[3.4/4.0 Regression] Wrong |predefined __GNUC__ with |documentation of predefined |cpp invocation |__GNUC__ with cpp ||invocation Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19309
[Bug libfortran/18398] Formatted I/O problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 14:01 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398
[Bug fortran/19292] [metabug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18398, which changed state. Bug 18398 Summary: Formatted I/O problems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18398 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification
-- What|Removed |Added Severity|minor |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19311
[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 14:05 --- Confirmed, it had worked with 4.0.0 20041124 and 3.4.0 so this is a regression. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||4.0.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-01-07 14:05:02 date|| Summary|ICE with -msse2 -mno-80387 |[4.0 Regression] ICE with - ||msse2 -mno-80387 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307
[Bug fortran/15553] Array copy operation produces garbage
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15553
[Bug preprocessor/19257] mmix-knuth-mmixware testsuite failure: gcc.dg/cpp/subframework1.c
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19257
[Bug libfortran/19064] runtime error when reading complex*16 using formatted I/O
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19064
[Bug target/19059] Atmel AVR Tiny13 and Tiny2313 support corrupted
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19059
[Bug rtl-optimization/18942] Do loop is not as optimized as 3.3.2
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18942
[Bug target/18511] cc1plus segfaults when compiling libstdc++-v3/src/localename.cc
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18511
[Bug target/18323] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/nested-1.c
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18323
[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
[Bug tree-optimization/17578] Missed optimization--failure of gcc.c-torture/execute/ieee/compare-fp-3.c at -O1 and above
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17578
[Bug rtl-optimization/11327] Non-optimal code when using MMX/SSE builtins
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11327
[Bug bootstrap/6525] libjava won't build on Red Hat Linux 6.2/sparc
-- What|Removed |Added Target Milestone|--- |3.1.x/3.2.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6525
[Bug ada/6558] [mainline regression] Wrongly reverted patches
-- What|Removed |Added Target Milestone|--- |3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6558
[Bug c++/19312] New: ICE in stabilize_call
template
struct C
{
static T *foo (A x) { return new T ((T) x); }
};
class A {};
A *bar ()
{
A a;
return C::foo (a);
}
ICEs on gcc-3_4-branch and on HEAD, works with GCC 3.2.3.
--
Summary: ICE in stabilize_call
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19312
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-07 14:27 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes: | I've had no on-list response yet to the query about this I sent to the | WG14 reflector on Tuesday (reflector message 10698), with the HEBREW | LETTER SHIN WITH DAGESH AND SHIN DOT examples. Since this issue contains a compatibility fragment and affects both C and C++, it occurs to me that you should resend a copy of your message to the C/C++ compatibility reflector (reaching both WG14 and WG21). I highly encourage you to do that. The address is c++std-compat at accu dot org. It would be wrong to let the issue debated by WG14 only without WG21 knowing. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug c++/19312] [3.4/4.0 Regression] ICE in stabilize_call
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
14:27 ---
Confirmed here is another testcase for the same ICE:
template
T *foo (A x)
{
throw ((T) x);
}
class A {};
A *bar ()
{
A a;
return foo (a);
}
--
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Known to fail||3.4.0 4.0.0
Known to work||3.3.2
Last reconfirmed|-00-00 00:00:00 |2005-01-07 14:27:55
date||
Summary|ICE in stabilize_call |[3.4/4.0 Regression] ICE in
||stabilize_call
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19312
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2005-01-07 15:01 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Fri, 7 Jan 2005, gdr at integrable-solutions dot net wrote: > > --- Additional Comments From gdr at integrable-solutions dot net > 2005-01-07 14:27 --- > Subject: Re: UCNs not recognized in identifiers (c++/c99) > > "joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes: > > | I've had no on-list response yet to the query about this I sent to the > | WG14 reflector on Tuesday (reflector message 10698), with the HEBREW > | LETTER SHIN WITH DAGESH AND SHIN DOT examples. > > Since this issue contains a compatibility fragment and affects both C > and C++, it occurs to me that you should resend a copy of your message > to the C/C++ compatibility reflector (reaching both WG14 and WG21). I > highly encourage you to do that. The address is c++std-compat at accu > dot org. It would be wrong to let the issue debated by WG14 only > without WG21 knowing. I've now sent it to c++std-compat (having checked that the C++ list of characters also includes combining characters in more than one combining class so the same issues can arise there at least in principle, whether or not they can arise with realistic natural language identifiers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug libfortran/19313] New: inquire(pad=) not implemented
$ cat pad.f character*20 chr open(7) inquire(7,pad=chr) print *,chr end $ gfortran pad.f && ./a.out $ gfortran -v ; gfortran -dumpmachine Using built-in specs. Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20050102 (experimental) ia64-unknown-linux-gnu This is not a g77 regression. g77 does not support pad= in inquire. -- Summary: inquire(pad=) not implemented Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19313
[Bug middle-end/18089] [4.0 regression] Valgrind errors in real.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-07
15:07 ---
I just stumbled over this one, too.
Even shorter testcase: valgrind --tool=memcheck cc1 -quiet vg.c
==
int foo() { return 1.0 + 1.1; }
==
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
Ever Confirmed||1
Known to fail||4.0.0
Known to work||3.4.3
Last reconfirmed|-00-00 00:00:00 |2005-01-07 15:07:18
date||
Summary|Valgrind errors in real.c |[4.0 regression] Valgrind
||errors in real.c
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089
[Bug tree-optimization/18241] [4.0 Regression] volatile causes mis-compiling
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-01-07
15:09 ---
BTW, the original case is no longer reproducible on mainline, but the test in
#35 still fails.
This happens when a pointer to volatile storage takes the address of a variable.
One way to fix this is by marking variables that have been aliased with
volatile tags. When adding operands for these variables, we mark the statement
as having volatile operands. While correct, this tends to pessimize code. I'm
working on a variant of this patch that would only mark variables whose address
is taken by a pointer pointing to volatile memory.
Jeff has been working on the idea of exposing volatile operands to the
optimizers and make the optimizers responsible for dealing with them properly.
This has the advantage that we would not have any magic operands hidden from us,
but it requires auditing all the optimizers to make sure that they don't mess
things up.
Given the stage that we are for 4.0, it may be better to go with the simpler
solution. But perhaps we can finish the other approach in time.
Diego.
Index: tree-flow.h
===
RCS file: /cvs/gcc/gcc/gcc/tree-flow.h,v
retrieving revision 2.75
diff -d -c -p -u -r2.75 tree-flow.h
--- tree-flow.h 10 Dec 2004 21:54:41 - 2.75
+++ tree-flow.h 5 Jan 2005 00:06:23 -
@@ -174,6 +174,9 @@ struct var_ann_d GTY(())
in the v_may_def list. */
unsigned in_v_may_def_list : 1;
+ /* Nonzero if this variable is aliased to a volatile variable. */
+ unsigned aliased_with_volatile : 1;
+
/* An artificial variable representing the memory location pointed-to by
all the pointers that TBAA (type-based alias analysis) considers
to be aliased. If the variable is not a pointer or if it is never
Index: tree-ssa-alias.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v
retrieving revision 2.64
diff -d -c -p -u -r2.64 tree-ssa-alias.c
--- tree-ssa-alias.c20 Dec 2004 18:18:28 - 2.64
+++ tree-ssa-alias.c5 Jan 2005 00:06:24 -
@@ -1668,6 +1668,9 @@ add_may_alias (tree var, tree alias)
else if (is_call_clobbered (alias))
mark_call_clobbered (var);
+ if (TREE_THIS_VOLATILE (var))
+a_ann->aliased_with_volatile = 1;
+
VARRAY_PUSH_TREE (v_ann->may_aliases, alias);
a_ann->is_alias_tag = 1;
}
Index: tree-ssa-operands.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-operands.c,v
retrieving revision 2.60
diff -d -c -p -u -r2.60 tree-ssa-operands.c
--- tree-ssa-operands.c 10 Dec 2004 17:28:32 - 2.60
+++ tree-ssa-operands.c 5 Jan 2005 00:06:24 -
@@ -1528,6 +1528,9 @@ add_stmt_operand (tree *var_p, stmt_ann_
return;
}
+ if (v_ann->aliased_with_volatile && s_ann)
+s_ann->has_volatile_ops = true;
+
if (is_real_op)
{
/* The variable is a GIMPLE register. Add it to real operands. */
--
What|Removed |Added
CC|dnovillo at gcc dot gnu dot |
|org |
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
[Bug tree-optimization/19121] [4.0 Regression] ICE: in merge_alias_info, at tree-ssa-copy.c:236
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19121
[Bug rtl-optimization/13674] [4.0 Regression] ICE in reload_cse_simplify_operands, at postreload.c:378 on PPC64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 15:30 --- Subject: Bug 13674 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 15:30:22 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c Log message: PR target/13674 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Convert non-word aligned offset address using ld/std into indirect address. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7060&r2=2.7061 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.772&r2=1.773 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13674
[Bug fortran/19313] inquire(pad=) not implemented
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 15:31 --- This is partly a front-end bug: _gfortran_filename = "t.f"; _gfortran_line = 3; _gfortran_ioparm.unit = 7; _gfortran_st_inquire (); And a library bug. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|libfortran |fortran Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-07 15:31:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19313
Re: [Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
"joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes: | I've now sent it to c++std-compat (having checked that the C++ list of | characters also includes combining characters in more than one combining | class so the same issues can arise there at least in principle, whether or | not they can arise with realistic natural language identifiers). Thanks a lot! -- Gaby
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From gdr at integrable-solutions dot net 2005-01-07 15:39 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) "joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes: | I've now sent it to c++std-compat (having checked that the C++ list of | characters also includes combining characters in more than one combining | class so the same issues can arise there at least in principle, whether or | not they can arise with realistic natural language identifiers). Thanks a lot! -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug fortran/19313] inquire(pad=) not implemented
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-07 15:40 --- inquire (delim= ) also doesn't work (returns blanks). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19313
[Bug rtl-optimization/13674] [4.0 Regression] ICE in reload_cse_simplify_operands, at postreload.c:378 on PPC64
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-07 15:40 --- patch applied -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13674
[Bug libfortran/19314] New: inquire(position=) segfaults at runtime
Because of the segfault, I assume that this is different from PR 19313. $ cat inquire-position.f character*20 chr open(7) inquire(7,position=chr) print *,chr end $ gfortran inquire-position.f $ ./a.out Segmentation fault $ gfortran -v ; gfortran -dumpmachine Using built-in specs. Configured with: ../gcc-4.0-20050102/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20050102 (experimental) ia64-unknown-linux-gnu $ gfortran -g inquire-position.f $ gdb ./a.out GNU gdb Red Hat Linux (6.1post-1.20040607.52rh) 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 "ia64-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /home/zfkts/Krempel/a.out Program received signal SIGSEGV, Segmentation fault. 0x202cee11 in strlen () from /lib/tls/libc.so.6.1 (gdb) bt #0 0x202cee11 in strlen () from /lib/tls/libc.so.6.1 #1 0x20052470 in *_gfortrani_cf_strcpy (dest=0x0, dest_len=0, src=0x0) at ../../../gcc-4.0-20050102/libgfortran/runtime/string.c:84 #2 0x200a3890 in inquire_via_unit (u=0x6000a2e0) at ../../../gcc-4.0-20050102/libgfortran/io/inquire.c:166 #3 0x200a48a0 in *_gfortran_st_inquire () at ../../../gcc-4.0-20050102/libgfortran/io/inquire.c:370 #4 0x4cb0 in MAIN__ () at inquire-position.f:3 #5 0x4df0 in main (argc=1, argv=0x6fffa108) at ../../../gcc-4.0-20050102/libgfortran/fmain.c:18 (gdb) -- Summary: inquire(position=) segfaults at runtime Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19314
[Bug target/19315] New: variable is not emitted in the asm
Take the following code:
void bar (const int * const x);
static const int y[];
void
foo (void)
{
bar (y);
}
This should at assemble but does not.
If I get some time this weekend I will look into fixing this.
--
Summary: variable is not emitted in the asm
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: minor
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315
[Bug target/19315] variable is not emitted in the asm
--- Additional Comments From schwab at suse dot de 2005-01-07 16:07 --- Shouldn't this be rejected as y is of incomplete type? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315
[Bug target/19315] variable is not emitted in the asm
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 16:52 --- If you trust Comeau's C compiler, then yes this is not valid code and should be rejected. Also one more note, this was able to compile with 3.3.2 but we called y as an extern symbol which is just wrong also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19315
[Bug c/18978] [3.4 Regression] Segfault after a warning about 'struct sigaction'
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-07 16:56 --- Should be fixed now: http://gcc.gnu.org/ml/gcc-cvs/2005-01/msg00184.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18978
[Bug c++/19298] [4.0 Regression] dependent type (references) and calling a function method
--- Additional Comments From nathan at gcc dot gnu dot org 2005-01-07 17:09 --- 2005-01-07 Nathan Sidwell <[EMAIL PROTECTED]> PR c++/19298 * pt.c (tsubst_qualified_id): Call convert_from_reference. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298
[Bug c++/19298] [4.0 Regression] dependent type (references) and calling a function method
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-07 17:09 --- Subject: Bug 19298 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-07 17:09:16 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: ref2.C Log message: cp: PR c++/19298 * pt.c (tsubst_qualified_id): Call convert_from_reference. testsuite: PR c++/19298 * g++.dg/template/ref2.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4572&r2=1.4573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.965&r2=1.966 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4865&r2=1.4866 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ref2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19298
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-01-07 18:05 --- well, I can't find the large test in the c++ pch testsuite. And, from the test results posted here http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00244.html I can't tell if the largefile test in the c pch testsuite fails or not. new test results are on the way. stay tuned -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug other/18720] collect2 uses wrong search order if -brtl specified
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-07 18:22 --- Created an attachment (id=7893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7893&action=view) swap library extension search order for -brtl Attached is my proposed patch for this problem. Albert, would you let me know if it works for you? Thanks, David -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18720
[Bug other/19316] New: kernel built with gcc-3.4.3 works / with gcc-4.0.0 doesn't work.
during kernel startup I get an oops in lib/radix-tree.c (null pointer dereference). testcase: vanilla linux-2.6.10 sources If You need assembly radix-tree.S sources I'll provide it tomorrow. -- Summary: kernel built with gcc-3.4.3 works / with gcc-4.0.0 doesn't work. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at pld-linux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pld-linux GCC host triplet: i686-pld-linux GCC target triplet: i686-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19316
[Bug other/19316] kernel built with gcc-3.4.3 works / with gcc-4.0.0 doesn't work.
--- Additional Comments From giovannibajo at libero dot it 2005-01-07 18:43 --- *** This bug has been marked as a duplicate of 18241 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19316
[Bug tree-optimization/18241] [4.0 Regression] volatile causes mis-compiling
--- Additional Comments From giovannibajo at libero dot it 2005-01-07 18:43 --- *** Bug 19316 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pluto at pld-linux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
[Bug c++/19317] New: forgets to deep-copy temporary return value
Mark Mitchel's commit to fix PR c++/16405 introduced a miscompilation
in Qt. It took me a few weeks to deduce a testcase. testcase is:
=== Cut ===
extern "C" void abort( void );
struct A
{
A() { d = d2 = 0; width = -1; }
A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {}
A b( const A &r ) const;
int d;
int d2;
int width;
};
A A::b( const A &r ) const
{
A tmp;
tmp.width = width < r.width ? width : r.width;
return tmp;
}
int main()
{
A a( 100 );
a = a.b( A( 10 ) );
if ( a.width != 10 )
abort();
}
=== Cut ===
The issue is that the result of "a.b(A (10))" is never copied to a, hence
the if() afterwards fails.
--
Summary: forgets to deep-copy temporary return value
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at kde dot org
CC: gcc-bugs at gcc dot gnu dot org,mark at codesourcery dot
com
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=19317
[Bug c++/19317] forgets to deep-copy temporary return value
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/19317] [4.0 Regression] forgets to deep-copy temporary return value
-- What|Removed |Added Priority|P2 |P1 Summary|forgets to deep-copy|[4.0 Regression] forgets to |temporary return value |deep-copy temporary return ||value Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-01-07 19:23 --- oh, the last one was run with gcc cvs trunk LAST_UPDATED: Thu Jan 6 20:22:33 UTC 2005 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug c++/19317] [4.0 Regression] forgets to deep-copy temporary return value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
19:26 ---
Hmm,
a = b (&a, &D.1613);
I think the problem is that we cannot remove the tempory return value for this
testcase.
Here is another testcase which is related testcase:
extern "C" void abort( void );
struct A
{
A() { d = d2 = 0; width = -1; }
A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {}
A b( ) const;
int d;
int d2;
int width;
};
A A::b( ) const
{
A tmp;
tmp.width = 10+this->width;
return tmp;
}
int main()
{
A a( 100 );
a = a.b();
if ( a.width != 110 )
abort();
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||4.0.0
Known to work||3.4.0
Last reconfirmed|-00-00 00:00:00 |2005-01-07 19:26:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-01-07 19:21 --- This is what I find about largefile in the c testsuite: Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O0 -g -o largefile.h.gch (timeout = 1200) PASS: ./largefile.h -O0 -g (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O0 -g -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O0 -g (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O0 -g -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O0 -g (test for excess errors) PASS: gcc.dg/pch/largefile.c -O0 -g assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O0-o largefile.h.gch (timeout = 1200) PASS: ./largefile.h -O0 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O0 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O0 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O0 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O0 (test for excess errors) PASS: gcc.dg/pch/largefile.c -O0 assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O1-o largefile.h.gch (timeout = 1200) PASS: ./largefile.h -O1 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O1 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O1 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O1 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O1 (test for excess errors) PASS: gcc.dg/pch/largefile.c -O1 assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O2-o largefile.h.gch (timeout = 1200) PASS: ./largefile.h -O2 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O2 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O2 (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O2 -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -O2 (test for excess errors) PASS: gcc.dg/pch/largefile.c -O2 assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O3 -fomit-frame-pointer -o largefile.h.gch \ (timeout = 1200) PASS: ./largefile.h -O3 -fomit-frame-pointer (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O3 -fomit-frame-pointer -I. -S -o largefile.s \ (timeout = 1200) PASS: largefile.c -O3 -fomit-frame-pointer (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O3 -fomit-frame-pointer -I. -S -o largefile.s \ (timeout = 1200) PASS: largefile.c -O3 -fomit-frame-pointer (test for excess errors) PASS: gcc.dg/pch/largefile.c -O3 -fomit-frame-pointer assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -O3 -g-o largefile.h.gch(timeout = 1200\) PASS: ./largefile.h -O3 -g (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O3 -g -I. -S -o largefile.s(timeout = 1200\) PASS: largefile.c -O3 -g (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -O3 -g -I. -S -o largefile.s(timeout = 1200\) PASS: largefile.c -O3 -g (test for excess errors) PASS: gcc.dg/pch/largefile.c -O3 -g assembly comparison Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ ./largefile.h -Os-o largefile.h.gch (timeout = 1200) PASS: ./largefile.h -Os (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -Os -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c -Os (test for excess errors) Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trun\k/objdir32/gcc/ largefile.c -Os -I. -S -o largefile.s (timeout = 1200) PASS: largefile.c
[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07
19:30 ---
And another one (note on most targets a is passed by reference which is where
the problem comes
from):
extern "C" void abort( void );
struct A
{
A() { d = d2 = 0; width = -1; }
A( int _w ) : d( 0 ), d2( 0 ), width( _w ) {}
A b( const A &r ) const;
int d;
int d2;
int width;
};
A A::b( const A &r ) const
{
A tmp;
tmp.width = width < r.width ? width : r.width;
return tmp;
}
int main()
{
A a( 10 );
A b(100);
a = b.b( a );
if ( a.width != 10 )
abort();
}
--
What|Removed |Added
Summary|[4.0 Regression] forgets to |[4.0 Regression] removing a
|deep-copy temporary return |temporary return value when
|value |we cannot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 20:39 --- Some information. It failed since at least 2004-05-12: http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00747.html But it passed on 2004-04-28: http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00073.html I will see if there are more testresults between those dates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 20:51 --- (In reply to comment #8) > Some information. One more note this is not related to the tree-ssa merge because that happened on the 13th. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 20:53 --- It was broken on the 2nd: http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg00231.html Now someone has to figure out which patch broke it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug other/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-07 20:55 --- Hmm but according to earlier results in April it was broken before then: http://gcc.gnu.org/ml/gcc-testresults/2004-04/msg01175.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
