[Bug libfortran/19308] I/O library should support more real and integer kinds
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:24 --- This bug is now closed. I/I library support for integer(16), real(10) and real(16) kinds is now complete. New PR should be filed if specific bugs arise (or should I say, *when* specific bugs arise). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19308
[Bug fortran/20120] real(kind=16) and sqrt, sin and other math functions cause ICE
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:26 --- This bug is now closed. Front-end support for integer(16) and real(10)/real(16) kinds is now complete. New PR should be filed if specific bugs arise (or should I say, *when* specific bugs arise). $ cat a.f90 real(10) :: a, b a = 2.0_10 b = sqrt(a) print *, b end $ gfortran a.f90 && ./a.out 1.41421356237310 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20120
[Bug libfortran/22437] Missing array intrinsics for kind=10 and kind=16
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-10-03 07:28 --- This bug is now closed. Library support for integer(16) and real(10)/real(16) kinds is now complete. New PR should be filed if specific bugs arise (or should I say, *when* specific bugs arise). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22437
[Bug ada/19237] ICE on legal (?) code: with type ... is access + variable of the access type
--- Comment #6 from baldrick at free dot fr 2005-10-03 08:54 --- Subject: Re: ICE on legal (?) code: with type ... is access + variable of the access type "with type" is a GNAT extension that has been superseded by the "limited with" clause introduced in the new Ada 0Y language revision. I was told by ACT that they will no longer be fixing "with type" bugs, since it is now deprecated (which seems reasonable to me). Thus I think that the status of this bug should be changed to "wont fix" (I tried to do it, but gcc bugzilla is being annoying this morning). Duncan. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19237
[Bug libfortran/24174] New: real(10) array output broken
The following program, which worked before Janne Blomqvist's recent patch to enable array I/O, now fails: $ cat u.f90 real(kind=10) :: a,b(1) a = 0 b(:) = 0 print *, a print *, b end $ gfortran u.f90 && ./a.out 0.00 At line 5 of file u.f90 Internal Error: bad real kind It appears that, at line 1005 in transfer.c, the transfer routine is called with kind=12 while it was (and probably should be) 10. Somewhere, the distinction between kind and size has to be made. -- Summary: real(10) array output broken Product: gcc Version: 4.1.0 Status: NEW Keywords: rejects-valid Severity: normal Priority: P2 Component: libfortran AssignedTo: jblomqvi at cc dot hut dot fi ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug libfortran/24174] real(10) array output broken
--- Comment #1 from jblomqvi at cc dot hut dot fi 2005-10-03 09:39 --- Ah, yes. Also see PR22519 and PR23419. Which way do we want it for unformatted? Should kind=10 use 10 bytes of storage or should it use whatever the padded size is? I would prefer the padded size, as otherwise we take a x10 speed hit when doing array IO. But anyway, I'm pretty sure this bug is because the size in the array descriptor is 12, since real(10) is padded to 12 bytes, right? Oh, how much simpler life would be without padding. I think it would be quite simple to kludge over this bug in the library, but if we want a real solution, as in splitting the kind=size relationship I think more work is needed. I'll take a look tonight. -- jblomqvi at cc dot hut dot fi changed: What|Removed |Added BugsThisDependsOn||22519 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug fortran/22519] Memory and binary disk layout disagree for real*10
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-10-03 10:36 --- (In reply to comment #4) > We need to settle what kind of disk image we want for real(kind=10) > before resolving this for complex. I am strongly in favour of real(kind=10) being written as 12 bytes on disk. This will make life much easier for all of us, and might speed things up. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-03 10:36:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22519
[Bug libfortran/24174] real(10) array output broken
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-10-03 10:37 --- (In reply to comment #1) > Should kind=10 use 10 bytes of storage or should it use whatever the padded > size is? I would prefer the padded size, as otherwise we take a x10 speed hit > when doing array IO. I do agree with you. 12 bytes will make our life much simpler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug c++/24171] g++-3.3: internal compiler error: in resolve_overloaded_unification, at cp/pt.c:8541
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-03 12:12 --- One of the reduced testcase, reduces down to PR 21592. I will see if I can get the 3.3 reduced testcase and if that does not fail with the 3.4/4.0/mainline, I will mark this as a dup of that bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||21592 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24171
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
--- Comment #51 from fxcoudert at gcc dot gnu dot org 2005-10-03 12:50 --- Some recent results on i686-linux: Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental) Using optimisation flags: -O0 CST:2 out of 4662 tests failed to pass the threshold CST drivers: 1 out of 11664 tests failed to pass the threshold DES:1 out of 3270 tests failed to pass the threshold DSX:1 out of 3500 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SST:2 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold ZGG drivers: 1 out of 1268 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental) Using optimisation flags: -O1 -march=pentium4 CST drivers: 1 out of 11664 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SST:1 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental) Using optimisation flags: -O2 -march=pentium4 CGV drivers: 67 out of 1092 tests failed to pass the threshold CST:1 out of 4662 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SST:1 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold ZGV drivers: 66 out of 1092 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold Running LAPACK tests on gfortran version 4.1.0 20051003 (experimental) Using optimisation flags: -O2 -funroll-loops -march=pentium4 CGV drivers: 67 out of 1092 tests failed to pass the threshold CST:1 out of 4662 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SST:1 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold ZGV drivers: 66 out of 1092 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2003-08-23 03:35:27 |2005-10-03 12:50:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug java/24120] jc1 incorrectly uses libiberty hashes
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:23 --- Is there going to be a 3.4.5? FWIW it would be somewhat more convenient if, say, whoever is doing releases from 3.4 branch applied this patch. I don't have it checked out, and going through a build is kind of a pain. Could you ask whoever the release person is to do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24120
[Bug java/24162] internal compiler error, make_class_data
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-03 14:26 --- This is a duplicate. I'm not sure what is going on with the patch in PR 23617... *** This bug has been marked as a duplicate of 23617 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24162
[Bug java/23617] Out of memory when classpath contains jar file with zip-style comment
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-03 14:26 --- *** Bug 24162 has been marked as a duplicate of this bug. *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||bflat1 at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
[Bug libgcj/24170] natFilePosix.cc seems to have a security problem
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:28 --- Ben, you can send private email about this to the folks listed as libgcj maintainers in the gcc MAINTAINERS file, namely Bryce and me. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-03 14:28:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24170
[Bug c++/24171] g++-3.3: internal compiler error: in resolve_overloaded_unification, at cp/pt.c:8541
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-03 14:28 ---
Here is a reduced testcase for the bug effecting 2.95.3-3.4.0 but not 4.0.0 or
the mainline:
template struct _List_iterator {};
_List_iterator end();
template class TinyVector {};
template bool TinyVectoreq(const TinyVector& u,
const TinyVector& v);
void test_collision() { (equal(end(), end(), (end(),
TinyVectoreq)));
The other reduced testcase for 3.4.0-current is already recorded as PR 21592 so
closing as a dup of that bug since the first only is only reproducible after
3.3.3 and the one in this comment is only 4.0.0 and below.
*** This bug has been marked as a duplicate of 21592 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24171
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-03 14:28 --- *** Bug 24171 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||faheem at email dot unc dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/22621] [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors
--- Comment #12 from reichelt at gcc dot gnu dot org 2005-10-03 14:43 --- Hi Mark, your patch for the 4.0 branch seems to be broken: The ChangeLog entries are missing and it seems responsible for heavy breakage in the testsuite, see http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00094.html === g++ tests === Running target unix FAIL: g++.dg/abi/mangle13.C (test for excess errors) ERROR: g++.dg/abi/mangle13.C: error executing dg-final: couldn't open "mangle13.s": no such file or directory UNRESOLVED: g++.dg/abi/mangle13.C: error executing dg-final: couldn't open "mangle13.s": no such file or directory FAIL: g++.dg/abi/mangle14.C (test for warnings, line 12) FAIL: g++.dg/abi/mangle14.C (test for excess errors) FAIL: g++.dg/abi/mangle15.C (test for excess errors) ERROR: g++.dg/abi/mangle15.C: error executing dg-final: couldn't open "mangle15.s": no such file or directory UNRESOLVED: g++.dg/abi/mangle15.C: error executing dg-final: couldn't open "mangle15.s": no such file or directory FAIL: g++.dg/other/stdarg3.C (test for excess errors) FAIL: g++.dg/template/non-dependent7.C (test for excess errors) FAIL: g++.dg/template/non-dependent8.C (test for errors, line 20) FAIL: g++.dg/template/non-dependent8.C (test for excess errors) FAIL: g++.dg/template/non-dependent9.C (test for excess errors) FAIL: g++.dg/template/partial-specialization.C (test for excess errors) FAIL: g++.dg/template/ptrmem1.C (test for excess errors) FAIL: g++.dg/template/ptrmem3.C (test for excess errors) FAIL: g++.dg/template/ptrmem5.C (test for excess errors) FAIL: g++.dg/template/ptrmem7.C (test for excess errors) FAIL: g++.dg/template/static2.C (test for excess errors) FAIL: g++.old-deja/g++.mike/mangle3.C (test for excess errors) WARNING: g++.old-deja/g++.mike/mangle3.C compilation failed to produce executable FAIL: g++.old-deja/g++.mike/p5840.C (test for excess errors) WARNING: g++.old-deja/g++.mike/p5840.C compilation failed to produce executable XPASS: g++.old-deja/g++.other/init5.C execution test FAIL: g++.old-deja/g++.pt/nontype4.C (test for excess errors) FAIL: g++.old-deja/g++.pt/ptrmem2.C (test for excess errors) WARNING: g++.old-deja/g++.pt/ptrmem2.C compilation failed to produce executable FAIL: g++.old-deja/g++.pt/ptrmem6.C (test for excess errors) FAIL: g++.old-deja/g++.pt/ptrmem7.C (test for excess errors) Could you please have a look? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22621
[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O3 -finline-limit=1024 -ftree-vectorize -ftracer
--- Comment #4 from uros at kss-loka dot si 2005-10-03 14:46 --- This one looks like real RA problem to me. For some reason, global register allocator is not allocating an xmm register to pseudo 76. This further leads to malformed RTL pattern as shown in the original report. There is something wrong either in the calculation of reg_renumber[] array or the problem is in alter_reg() function. In alter_reg() pseudo 76 is claimed to be a constant, so no stack slot is produced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
[Bug c++/22621] [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors
--- Comment #13 from mark at codesourcery dot com 2005-10-03 14:57 --- Subject: Re: [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors reichelt at gcc dot gnu dot org wrote: > --- Comment #12 from reichelt at gcc dot gnu dot org 2005-10-03 14:43 > --- > Hi Mark, > > your patch for the 4.0 branch seems to be broken: > The ChangeLog entries are missing and it seems responsible for > heavy breakage in the testsuite, see > http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00094.html Eek, looking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22621
[Bug c++/22621] [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors
--- Comment #14 from cvs-commit at gcc dot gnu dot org 2005-10-03 15:05 --- Subject: Bug 22621 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-03 15:05:10 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Log message: PR c++/22621 * parser.c (cp_parser_template_argument): Don't turn "T::f" into "(*this).T::f". * pt.c (convert_nontype_argument): Remove ??? comment. PR c++/23840 * tree.c (lvalue_p_1): A VA_ARG_EXPR with class type is an lvalue, when class rvalues are lvalues. PR c++/22621 * g++.dg/template/overload5.C : New test. PR c++/23840 * g++.dg/expr/stdarg1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.112&r2=1.4648.2.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.319.2.19&r2=1.319.2.20 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.421&r2=1.5084.2.422 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22621
[Bug c++/23840] [3.4/4.0/4.1 Regression] Bogus "invalid lvalue in unary '&'" diagnostic and ICE with va_arg
--- Comment #11 from cvs-commit at gcc dot gnu dot org 2005-10-03 15:05 --- Subject: Bug 23840 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-03 15:05:10 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Log message: PR c++/22621 * parser.c (cp_parser_template_argument): Don't turn "T::f" into "(*this).T::f". * pt.c (convert_nontype_argument): Remove ??? comment. PR c++/23840 * tree.c (lvalue_p_1): A VA_ARG_EXPR with class type is an lvalue, when class rvalues are lvalues. PR c++/22621 * g++.dg/template/overload5.C : New test. PR c++/23840 * g++.dg/expr/stdarg1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.112&r2=1.4648.2.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.319.2.19&r2=1.319.2.20 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.421&r2=1.5084.2.422 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23840
[Bug tree-optimization/20643] [4.0/4.1 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #4 from sje at cup dot hp dot com 2005-10-03 15:10 --- Just to clarify the main issue here, my main concern here is not the conversion of the for loop to a do loop but rather the alias disambiguation and the movement of loop invariant code out of the inner most loop in P7Viterbi. Because the new alias analysis is not as good as it used to be (with respect to structures) more code is left in the inner loop. This is why the test case is so much slower now than before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug c++/24171] g++-3.3: internal compiler error: in resolve_overloaded_unification, at cp/pt.c:8541
--- Comment #5 from faheem at email dot unc dot edu 2005-10-03 15:32
---
(In reply to comment #4)
> Here is a reduced testcase for the bug effecting 2.95.3-3.4.0 but not 4.0.0 or
> the mainline:
> template struct _List_iterator {};
> _List_iterator end();
> template class TinyVector {};
> template bool TinyVectoreq(const TinyVector& u,
> const TinyVector& v);
> void test_collision() { (equal(end(), end(), (end(),
> TinyVectoreq)));
>
> The other reduced testcase for 3.4.0-current is already recorded as PR 21592
> so
> closing as a dup of that bug since the first only is only reproducible after
> 3.3.3 and the one in this comment is only 4.0.0 and below.
>
> *** This bug has been marked as a duplicate of 21592 ***
>
So, apparently there are two things wrong. The problem that corresponds to
21592 is my error, is that correct? Can you point me to where the error is in
my code?
The second (corresponding to the testcase above) is a bona fide bug,
correct? This looks like it corresponds to the call to equal. Can you suggest a
workaround for this?
Thanks.Faheem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24171
[Bug other/24175] New: bootstrap failed / undefined symbol: nsion__...
gcc-4.1-20051003T0833UTC bootstrap fails.
(...)
make[2]: Leaving directory
`/home/users/builder/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/libcpp'
make[2]: Entering directory
`/home/users/builder/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/gcc'
true: symbol lookup error: /lib/libc.so.6: undefined symbol: nsion__ ({ struct
obstack const *__o = (obstack); (unsigned) (__o->next_free - __o->object_base);
})), version GLIBC_2.0
make[2]: *** [min-insn-modes.c] Error 127
the previous gcc-4.1.0-20051001T1855UTC snapshot builds fine.
glibc-2.3.90-20050415
binutils-2.16.91.0.3
--
Summary: bootstrap failed / undefined symbol: nsion__...
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC build triplet: ppc
GCC host triplet: ppc
GCC target triplet: ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24175
[Bug fortran/24176] New: gfortran segfaults on empty source
$ touch a.f90 $ gfortran -c a.f90 $ gfortran -c a.f90 -Wall a.f90:0: internal compiler error: Segmentation fault Enough said... -- Summary: gfortran segfaults on empty source Product: gcc Version: 4.1.0 Status: NEW Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24176
[Bug c/24177] New: function returning structure produce very long/slow assembly
Compiling this file with -O2 optimisation:
struct str {
int a, b, c, d;
};
void fct3 (struct str *);
extern inline struct str fct (void)
{
struct str returned = { 1, 2, 3, 4 };
return returned;
}
void fct2 (void)
{
struct str tmp;
tmp = fct ();
fct3 (&tmp);
}
with this compiler:
gcc version 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)
creates this assembler having three copies of the structure
in the stack, and one as constant in .rodata:
$ gcc -O2 tmp.c -S -o tmp.s
$ cat tmp.s
.file "tmp.c"
.section.rodata
.align 4
.type C.0.1141, @object
.size C.0.1141, 16
C.0.1141:
.long 1
.long 2
.long 3
.long 4
.text
.p2align 4,,15
.globl fct2
.type fct2, @function
fct2:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
subl$76, %esp
leal-56(%ebp), %edi
movl$C.0.1141, %esi
cld
movl$4, %ecx
rep
movsl
leal-24(%ebp), %edi
leal-56(%ebp), %esi
movb$4, %cl
rep
movsl
leal-40(%ebp), %edi
leal-24(%ebp), %esi
movb$4, %cl
rep
movsl
leal-40(%ebp), %eax
pushl %eax
callfct3
addl$16, %esp
leal-8(%ebp), %esp
popl%esi
popl%edi
popl%ebp
ret
.size fct2, .-fct2
.ident "GCC: (GNU) 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)"
.section.note.GNU-stack,"",@progbits
If compiled with -Os, the "memcpy" function is called three times.
$ gcc -Os tmp.c -S -o tmp.s
$ cat tmp.s
.file "tmp.c"
.section.rodata
.align 4
.type C.0.1141, @object
.size C.0.1141, 16
C.0.1141:
.long 1
.long 2
.long 3
.long 4
.text
.globl fct2
.type fct2, @function
fct2:
pushl %ebp
movl%esp, %ebp
pushl %esi
pushl %ebx
subl$48, %esp
leal-56(%ebp), %ebx
pushl $16
pushl $C.0.1141
pushl %ebx
callmemcpy
leal-24(%ebp), %esi
pushl $16
pushl %ebx
pushl %esi
callmemcpy
leal-40(%ebp), %ebx
pushl $16
pushl %esi
pushl %ebx
callmemcpy
addl$36, %esp
pushl %ebx
callfct3
popl%eax
leal-8(%ebp), %esp
popl%ebx
popl%esi
popl%ebp
ret
.size fct2, .-fct2
.ident "GCC: (GNU) 4.0.2 20050913 (prerelease) (Debian 4.0.1-7)"
.section.note.GNU-stack,"",@progbits
That is not a regression, gcc-3.4* and gcc-2.95 do not produce very good
assembler code neither for this source file.
Etienne.
--
Summary: function returning structure produce very long/slow
assembly
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: etienne_lorrain at yahoo dot fr
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177
[Bug other/24175] bootstrap failed / undefined symbol: nsion__...
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:46 --- This message does not make sense, it looks as your ld or as is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24175
[Bug fortran/24176] gfortran segfaults on empty source
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:48 ---
Confirmed:
487 if (gfc_option.warn_line_truncation
488 && gfc_current_locus.lb->truncated)
489 gfc_warning_now ("Line truncated at %C");
Looks like caused by:
2005-04-15 Richard Guenther <[EMAIL PROTECTED]>
PR fortran/14569
* gfortran.h (gfc_linebuf): Add truncated field.
* parse.c (next_statement): Handle warning for truncated
lines.
* scanner.c (load_line): Return if line was truncated.
No longer warn for truncated lines. Remove unused parameters.
(load_file): Store load_line return value to linebuf.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Last reconfirmed|-00-00 00:00:00 |2005-10-03 15:48:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24176
[Bug fortran/24176] gfortran segfaults on empty source
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-03 15:53 --- Will look into it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-03 15:48:38 |2005-10-03 15:53:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24176
[Bug tree-optimization/24177] function returning structure produce very long/slow assembly
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 15:55 --- Confirmed, this is just another case where aggregate copy prop is needed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||14295 nThis|| Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-10-03 15:55:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24177
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:15 --- A regression hunt identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00236.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||bothner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:20 --- A regression hunt for the patch that fixed this on mainline identified the merge of the tree-ssa branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:24 --- A regression hunt for powerpc-linux on mainline identified the merge of the tree-ssa branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
[Bug c++/22621] [3.4/4.0/4.1 Regression] Member function overloading introduces syntax errors
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-10-03 16:37 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22621
[Bug tree-optimization/24172] [4.1 Regression] error: incorrect sharing of tree nodes
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-03 16:54 ---
Confirmed, reduced testcase:
void IOException( char);
inline int* dummy( const char* const mode )
{
IOException(*mode+*mode);
}
void prepare_inpaint( )
{
dummy ("rb");
}
The problem is that we have &"rb"[0] and we get *(&"rb"[0]) but we only fold
that to "rb"[0] instead of all the way to 'r'.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-10-03 16:54:18
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24172
[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.
--- Comment #4 from redi at gcc dot gnu dot org 2005-10-03 16:54 --- > Until DR228 the name following ".template" had to be a member template, so the > code would have been invalid on those grounds. Erm, the name following .template *is* a member template, that's my whole point! :-) I don't understand why DR228 applies, that is about whether non-member templates can follow the .template syntax, not about whether 3.4.5 para 2 applies to templates. Additionally, I believe the apparently correct behaviour that resulted in my bug report makes the use of "template" even harder to teach - something that was apparently a motivation for DR228. It also means that the template function "f" is dependent on include ordering and whether a global "f" has been declared. However, I'll take the question to a more appropriate forum and try to get an explanation there, rather than banging on about it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.
--- Comment #5 from redi at gcc dot gnu dot org 2005-10-03 16:56 --- Oops, sorry, I meant: template function "call_f" is dependent on include ordering and whether a global "f" has been declared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-03 17:06 --- For what is worth Comeau rejects the code: "ComeauTest.c", line 8: error: name following "template" must be a member template t.template f< int >(); ^ "ComeauTest.c", line 8: error: too few arguments for class template "f" t.template f< int >(); ^ "ComeauTest.c", line 8: warning: ambiguous class member reference -- function template "F::f" (declared at line 14) used in preference to class template "f" (declared at line 2) t.template f< int >(); ^ detected during instantiation of "void call_f(T &) [with T=F]" Removing the template class above does "fix" it too there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.
--- Comment #7 from mark at codesourcery dot com 2005-10-03 17:08 --- Subject: Re: [3.4/4.0/4.1 Regression] Lookup of template member function finds global type. redi at gcc dot gnu dot org wrote: > --- Comment #4 from redi at gcc dot gnu dot org 2005-10-03 16:54 --- > >>Until DR228 the name following ".template" had to be a member template, so the >>code would have been invalid on those grounds. > > > Erm, the name following .template *is* a member template, that's my whole > point! :-) :-) The problem is that we can't do the lookup, because the expression before the "." is dependent. But, we still have to do global-scope lookup, because "t.template S::f()" would be valid, if "S" were a global template, and redundant "template" keywords are specifically allowed. I do see your point, though. It's possible that the lookup after "t.template" should be restricted so that if "t" is dependent, then no lookup is performed. > However, I'll take the question to a more appropriate forum and try to get an > explanation there, rather than banging on about it here. If you do get a DR opened about this, please let me know! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
[Bug other/20731] [3.4 only] contrib/gcc_update hard code -r gcc-3_4-branch
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-03 17:15 --- Confirmed for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|2005-04-02 17:00:47 |2005-10-03 17:15:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20731
[Bug c++/17775] [3.4/4.0/4.1 Regression] -frepo with function template in anonymous namespace fails to compile
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:18 --- Subject: Bug 17775 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-03 17:18:53 Modified files: gcc/cp : repo.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: repo4.C Log message: PR c++/17775 * repo.c: Include flags.h. (finish_repo): Add -frandom-seed to the arguments. PR c++/17775 * g++.dg/template/repo4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/repo.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.18.1&r2=1.54.18.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.113&r2=1.4648.2.114 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/repo4.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 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.422&r2=1.5084.2.423 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17775
[Bug c++/17775] [3.4/4.0/4.1 Regression] -frepo with function template in anonymous namespace fails to compile
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:21 --- Subject: Bug 17775 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-03 17:21:41 Modified files: gcc/cp : repo.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: repo4.C Log message: PR c++/17775 * repo.c: Include flags.h. (finish_repo): Add -frandom-seed to the arguments. PR c++/17775 * g++.dg/template/repo4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/repo.c.diff?cvsroot=gcc&r1=1.59&r2=1.60 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4908&r2=1.4909 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/repo4.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6127&r2=1.6128 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17775
[Bug c++/17775] [3.4/4.0/4.1 Regression] -frepo with function template in anonymous namespace fails to compile
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-03 17:23 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.0 |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17775
[Bug java/24127] ICE in libjava.compile/PR6865.java reported as "PASS" in testsuite.
--- Comment #2 from cvs-commit at gcc dot gnu dot org 2005-10-03 17:30 --- Subject: Bug 24127 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-03 17:30:38 Modified files: gcc/java : ChangeLog parse.y Log message: PR java/24127 * parse.y (method_header): Make the result of the rule a NULL_TREE when a parsing error occurs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1667&r2=1.1668 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gcc&r1=1.556&r2=1.557 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24127
[Bug java/24127] ICE in libjava.compile/PR6865.java reported as "PASS" in testsuite.
--- Comment #3 from rmathew at gcc dot gnu dot org 2005-10-03 17:31 --- Fix checked in. -- rmathew at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24127
[Bug c++/23651] [4.1 Regression] ICE in GC
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-03 17:44 --- I can reproduce this reliably for powerpc64-linux with -m64 using the testcase in comment #3; using -m32 the results are intermittent. A regression hunt identified the following patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00665.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23651
[Bug c++/24161] [3.4/4.0/4.1 Regression] Lookup of template member function finds global type.
--- Comment #8 from redi at gcc dot gnu dot org 2005-10-03 17:54 --- Aah, gotcha. I now see why the global scope has to be considered, and why DR228 is relevant. Thanks! I still think it's of dubious value having the standard defined like that, so might take it to the UK panel and see if anyone there cares about it. Andrew, another interesting variation is to add two template arguments to the function call. Then you don't get the "wrong number of template arguments" you get one saying "invalid use of struct f", which is because it's not valid to refer to a typename there - but then everyone except the compiler already knew that! ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24161
[Bug c/12245] [3.4/4.0/4.1 regression] Uses lots of memory when compiling large initialized arrays
--- Comment #24 from rguenth at gcc dot gnu dot org 2005-10-03 17:54 --- It somehow works (partially), but there's a lot of fallout. Ugh. I don't like it very much. Preliminary patch: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00091.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Re: [Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
"janis187 at us dot ibm dot com" <[EMAIL PROTECTED]> writes: | A regression hunt for the patch that fixed this on mainline identified the | merge of the tree-ssa branch. Thanks. That would indicate that if we're unable to find a minimal patch, then we would just have to close it as WONTFIX. -- Gaby
[Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
--- Comment #3 from gdr at integrable-solutions dot net 2005-10-03 18:16 --- Subject: Re: [3.4 Regression] ICE in simple_cst_equal "janis187 at us dot ibm dot com" <[EMAIL PROTECTED]> writes: | A regression hunt for the patch that fixed this on mainline identified the | merge of the tree-ssa branch. Thanks. That would indicate that if we're unable to find a minimal patch, then we would just have to close it as WONTFIX. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
[Bug c/24178] New: GCC 4.0/4.1 generates code that produces unaligned access exceptions
gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)
gcc version 4.0.2
GNU C version 4.1.0 20050927 (experimental) (alpha-unknown-linux-gnu)
All tested versions generate the same wrong code for the following testcase
(EV4/EV5 only with -O2 optimization):
#include
#include
typedef struct Foo
{
void *p1;
long p2;
void *p3;
unsigned char p4;
char p5[3];
} Foo;
#ifdef __DECC
#undef offsetof
#define offsetof(TYPE, MEMBER) ((char *)(&(((TYPE *)0)-> MEMBER )))
#endif
void foo(const char *fn)
{
Foo *p;
p = (Foo *)(fn - offsetof(Foo, p5));
p->p4 = 1;
}
int main(int argc, char **argv)
{
Foo p;
#if defined(__alpha__) && defined(__linux__)
# include
# include
unsigned int buf[2] =
{
SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT
};
syscall(__NR_osf_setsysinfo, SSI_NVPAIRS, buf, 1, 0, 0, 0);
#endif
printf("Offset - %d\n", offsetof(Foo, p5));
foo(p.p5);
}
The assembler for the function "foo" is:
.globl foo
.ent foo
$foo..ng:
foo:
.frame $30,0,$26,0
.prologue 0
ldah $2,256($31)
ldl $1,-4($16)
zapnot $1,247,$1
bis $1,$2,$2
stl $2,-4($16)
ret $31,($26),1
.end foo
The offset of "p5" member is 25 bytes, but compiler thinks that "p5" is aligned
in "foo" function and issue "ldl" on unaligned address.
DECC compiler generates "ldl $1, -1($16)" instruction.
It might be not very good coding practice, but it taken from Mozilla source.
Thank you.
--
Summary: GCC 4.0/4.1 generates code that produces unaligned
access exceptions
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tsv at solvo dot ru
GCC build triplet: alpha-*-linux-gnu
GCC host triplet: alpha-*-linux-gnu
GCC target triplet: alpha-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-09-29 23:55:30 |2005-10-03 18:58:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
[Bug middle-end/24178] GCC 4.0/4.1 generates code that produces unaligned access exceptions
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 19:03 --- I think you are violating some alignment rule in C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug libgcj/24057] [4.1 regression] libgcj installs jawt.h and jni.h in version independent location
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 19:07 --- Subject: Bug 24057 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-03 19:07:10 Modified files: libjava/classpath: ChangeLog.gcj libjava/classpath/include: Makefile.am Makefile.in Log message: PR libgcj/24057: * include/Makefile.in: Rebuilt. * include/Makefile.am: Don't install headers. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/classpath/ChangeLog.gcj.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/classpath/include/Makefile.am.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/classpath/include/Makefile.in.diff?cvsroot=gcc&r1=1.4&r2=1.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24057
[Bug libgcj/24154] Make requires too much memory building libjava
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
[Bug libgcj/24057] [4.1 regression] libgcj installs jawt.h and jni.h in version independent location
--- Comment #5 from tromey at gcc dot gnu dot org 2005-10-03 19:08 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24057
[Bug libfortran/24174] real(10) array output broken
--- Comment #3 from jblomqvi at cc dot hut dot fi 2005-10-03 19:37 --- Created an attachment (id=9865) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9865&action=view) Patch for PR24174, also fixes formatted output for complex(10) libgfortran Changelog: 2005-10-03 Janne Blomqvist <[EMAIL PROTECTED]> PR fortran/24174 * io/io.h: Add argument to prototypes. * io/list_read.c (list_formatted_read): Add kind argument, cleanup. * io/transfer.c: Add argument to transfer function pointer. (unformatted_read): Add kind argument. (unformatted_write): Likewise. (formatted_transfer_scalar): Fix for padding with complex(10). (formatted_transfer): Add kind argument, cleanup. (transfer_integer): Add kind argument to transfer call. (transfer_real): Likewise. (transfer_logical): Likewise. (transfer_character): Likewise. (transfer_complex): Likewise. (transfer_array): Likewise. (data_transfer_init): Add kind argument to formatted_transfer call. (iolength_transfer): Add kind argument, cleanup. * io/write.c (write_complex): Fix for padding with complex(10). (list_formatted_write): Add kind argument, cleanup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug fortran/24179] New: internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr.c:783
The following FORTRAN source crashes the gfortran 4.02 compiler when using the -fdefault-integer-8 option logical function junk(num,isat) implicit none c character*2 pre_atnam external pre_atnam integer num(*),isat(*) c write(6,*) pre_atnam(num(isat(3))) junk=.true. return end % gfortran -c -fdefault-integer-8 junk.f junk.f: In function junk: junk.f:8: internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr.c:783 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. % gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.0.2/configure --prefix=/home/edo/apps/gcc402 --with-mpfr=/home/edo/apps --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.2 -- Summary: internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr.c:783 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edoardo dot apra at pnl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24179
[Bug libfortran/24174] real(10) array output broken
--- Comment #4 from jblomqvi at cc dot hut dot fi 2005-10-03 19:40 --- Created an attachment (id=9866) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9866&action=view) Testcase And here is a test case to go with the previous patch. Sorry my mail is b0rked at the moment so I can't send the patch via the mailing list. It should be noted that the patch assumes that the padding for real(10) is 10 bytes data + 2 bytes padding. This works on i686-Linux, might not work on other targets (big endian?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24174
[Bug fortran/24179] internal compiler error: in gfc_conv_string_tmp, at fortran/trans-expr.c:783
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 19:43 --- *** This bug has been marked as a duplicate of 20971 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24179
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-03 19:43 --- *** Bug 24179 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||edoardo dot apra at pnl dot ||gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug middle-end/24178] GCC 4.0/4.1 generates code that produces unaligned access exceptions
--- Comment #2 from falk at debian dot org 2005-10-03 20:48 --- (In reply to comment #0) > The offset of "p5" member is 25 bytes, but compiler thinks that "p5" is > aligned > in "foo" function You are casting a pointer to a Foo* that doesn't have proper alignment for a Foo. This is undefined behavior, so anything can happen, including an unaligned access at some later point. This is not a gcc bug. > It might be not very good coding practice, but it taken from Mozilla source. Please report it there instead. -- falk at debian dot org changed: What|Removed |Added CC||falk at debian dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
--- Comment #3 from cvs-commit at gcc dot gnu dot org 2005-10-03 20:57 --- Subject: Bug 24135 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-03 20:57:45 Modified files: gcc: ChangeLog tree-nested.c Added files: gcc/testsuite/gcc.c-torture/execute: pr24135.c Log message: PR 24135 * tree-nested.c (convert_nl_goto_reference): Lookup a translation before creating a new one. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10070&r2=2.10071 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-nested.c.diff?cvsroot=gcc&r1=2.31&r2=2.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr24135.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
[Bug objc/24180] New: [4.1 Regression] rejects union cast
The following code is rejected even though it should not be:
#import
union a { id g; };
void f(union a);
void g(Object *b)
{
f((union a)b);
}
-
Object* should be able to goto id without any troubles.
--
Summary: [4.1 Regression] rejects union cast
Product: gcc
Version: 4.1.0
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24180
[Bug objc/24180] [4.1 Regression] rejects union cast
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 21:14 --- Forgot to say this shows up while compiling GNUStep. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24180
[Bug objc/24180] [4.1 Regression] rejects union cast
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-03 21:30 ---
The code is invalid, the related C testcase:
union a { void *g; };
void f(union a);
void g(int *b)
{
f((union a)b);
}
Which is rejected everywhere.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24180
[Bug spam/24181] New: testing (please ignore)
Testing -- Summary: testing (please ignore) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: spam AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24181
[Bug spam/24181] testing (please ignore)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-03 21:32 --- Please ignore. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24181
[Bug tree-optimization/24172] [4.1 Regression] error: incorrect sharing of tree nodes
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-03 21:59 --- A regression hunt using the testcase from comment #3 identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00624.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24172
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-03 22:02 --- Subject: Bug 24135 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-10-03 22:01:55 Modified files: gcc: ChangeLog tree-nested.c Added files: gcc/testsuite/gcc.c-torture/execute: pr24135.c Log message: PR 24135 * tree-nested.c (convert_nl_goto_reference): Lookup a translation before creating a new one. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.441&r2=2.7592.2.442 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-nested.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.24.10.1&r2=2.24.10.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr24135.c.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=24135
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
--- Comment #5 from rth at gcc dot gnu dot org 2005-10-03 22:05 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O1 -ftree-vectorize -msse
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-03 22:26 --- A regression hunt using an i686-linux cross compiler with the testcase from comment #3 identifies this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00534.html That doesn't fit with the submitter's information that it worked on 20050723 and the patch doesn't seem particularly relevant to this bug, so I tried several builds around the date of this patch and afterwards; there are rare intermittent passes after this patch, but no failures (that I saw) before it. -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||phython at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
[Bug target/21623] [4.0 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Comment #3 from kkojima at gcc dot gnu dot org 2005-10-03 22:28 --- This PR was discussed at the thread of gcc-patches list statring with http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01527.html and Joern pointed out that we must improve the reload infrastrucure to fix this PR. There is an argument about whether it's appropriate for stage3 or not. I've checked in the patch in http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01952.html as a temporary workwround on mainline and 4.0-branch under Joern's approval. It gets rid of the ICEs for the testcase, though it doesn't fix the real problem. So please don't close this PR ATM. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug libgcj/24182] New: standard.omit not properly rebuilt
If you touch standard.omit.in, 'make' won't rebuild standard.omit -- the file is only created by configure, and not via AC_OUTPUT. -- Summary: standard.omit not properly rebuilt Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: tromey at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24182
[Bug libgcj/24183] New: xmlj code not properly built
The native xmlj code in classpath is not properly built for libgcj. We most likely need to link the JNI code into whatever library contains the java code; the xmlj code will need the standard loadLibrary tweak for this to work properly. -- Summary: xmlj code not properly built Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24183
[Bug target/22553] [4.1 regression] ICE building libstdc++
--- Comment #5 from kkojima at gcc dot gnu dot org 2005-10-03 23:13 --- Joern has analyzed this PR in http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01654.html and pointed out that it's a middle-end issue. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug java/24184] New: bytecode miscompilation of CORBA
Compilation of gnu/CORBA/DynAny/gnuDynValue to bytecode has a bug. The resulting equal() method has this in it: 61: invokespecial #193= However, DynAny is an interface. The corresponding source code is a call like "super.equal(other)". I believe the bug occurs when calling super.m() where m() is also declared in an implemented interface. (In this case, super.m() is also not declared in the immediate superclass, but is inherited, that may play a role.) It should be simple to make a small test case, I will do that some other time. This bug prevents us from building corba in libgcj. -- Summary: bytecode miscompilation of CORBA Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24184
[Bug target/24185] New: gcc.dg/vect/vect-shift-1.c execution test fails
FAIL: gcc.dg/vect/vect-shift-1.c execution test has appeared on mainline on ia64-hp-hpux11.23 between 20051001 and 20051003. This is a new test added between those test runs. -- Summary: gcc.dg/vect/vect-shift-1.c execution test fails Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24185
[Bug java/24186] New: interface and extends does not cause us to reject invalid code
interface a
{
void f();
}
class b
{
void f(){}
}
class d extends b implements a
{
void f(){}
static public void main(String args[])
{
d eee = new d();
eee.f();
}
}
--
Summary: interface and extends does not cause us to reject
invalid code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24186
[Bug c++/24139] [4.0/4.1 Regression] Rejects definition of member of specialized inner class
--- Comment #6 from bangerth at dealii dot org 2005-10-04 02:03 ---
Confirmed. A redux is here:
--
template
struct O {
struct I;
};
template<>
struct O::I
{
I();
};
O::I::I() {}
--
g/x> /home/bangerth/bin/gcc-3.4.5-pre/bin/c++ -c x.cc
g/x> /home/bangerth/bin/gcc-4.0*/bin/c++ -c x.cc
x.cc:12: error: explicit specialization of ‘O::I::I()’
must be introduced by ‘template <>’
x.cc:12: error: template-id ‘I<>’ for
‘O::I::I()’ does not match any template declaration
x.cc:12: error: invalid function declaration
Not only is gcc wrong to reject the code, but to use O::I when I
is in fact not a template at all also reveals that something is going wrong.
This is a 4.0/4.1 regression.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2005-10-04 02:03:46
date||
Summary|Forward declaration of class|[4.0/4.1 Regression] Rejects
|in template class |definition of member of
||specialized inner class
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24139
[Bug c++/24139] [4.0/4.1 Regression] Rejects definition of member of specialized inner class
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 02:11 --- : Search converges between 2004-07-20-trunk (#491) and 2004-07-21-trunk (#492). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.0 4.1.0 Known to work||3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24139
[Bug c++/24139] [4.0/4.1 Regression] Rejects definition of member of specialized inner class
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-04 02:17 --- This looks like it was introduced by the fix for PR 14497. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24139
[Bug c++/16068] Bad error message
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-04 02:31 --- Fixed by: * error.c (dump_type) : Print reworded message. * g++.dg/overload/unknown1.C: New. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16068
[Bug c++/16555] Diagnostic shows instead of
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 02:31 --- Fixed by: Fixed by: * error.c (dump_type) : Print reworded message. * g++.dg/overload/unknown1.C: New. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16555
[Bug c++/19741] suboptimal error message for template functions (as opposed to non-templates)
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-04 02:32 --- The error message was changed by: Fixed by: * error.c (dump_type) : Print reworded message. * g++.dg/overload/unknown1.C: New. But reading comment 4, that will not fix the issue fully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19741
[Bug tree-optimization/24126] [4.1 Regression] tree-stdarg.c causes wrong code, not tracking va_list variable correctly
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-04 02:41 --- Fixed by: 2005-10-01 Richard Henderson <[EMAIL PROTECTED]> * tree-stdarg.c (execute_optimize_stdarg): Process PHI nodes too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24126
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-10-04 02:43 --- I am going to fix this tonight. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug tree-optimization/23445] [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-pointer-checks
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-04 03:02 --- Subject: Bug 23445 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-04 03:02:20 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr23445.c Log message: PR 23445 * tree-vrp.c (extract_range_from_assert): If the new numeric range created out of the assertion contradicts the existing numeric range of the ASSERT_EXPR variable, make the new range varying. testsuite/ PR 23445 * gcc.c-torture/compile/pr23445.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10072&r2=2.10073 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.61&r2=2.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6129&r2=1.6130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23445.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
[Bug tree-optimization/23445] [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-pointer-checks
--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-10-04 03:05 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00117.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-10-04 03:05 --- Created an attachment (id=9867) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9867&action=view) Patch which I am testing This is the correct version of your patch which does not effect AIX or PPC64-linux (with -malign-power which is not default). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug tree-optimization/23049] [4.1 Regression] ICE with -O3 -ftree-vectorize on 4.1.x
--- Comment #32 from cvs-commit at gcc dot gnu dot org 2005-10-04 05:57 --- Subject: Bug 23049 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-04 05:57:38 Modified files: gcc: ChangeLog tree-ssa-dom.c gcc/doc: tree-ssa.texi gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: ucnid-4.c Added files: gcc/testsuite/gcc.dg: pr23049.c Log message: 2005-10-05 Steven Bosscher <[EMAIL PROTECTED]> gcc/ PR tree-optimization/23049 * tree-ssa-dom.c (thread_across_edge): Make sure that the condition of a COND_EXPR is folded before calling fold on the whole rhs of a conditional assignment. * doc/tree-ssa.texi: Update the GIMPLE grammar for a valid rhs to document that a COND_EXPR may appear there. testsuite/ * gcc.dg/pr23049.c: New test. * gcc.dg/ucnid-4.c: Fix test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10073&r2=2.10074 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dom.c.diff?cvsroot=gcc&r1=2.128&r2=2.129 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/tree-ssa.texi.diff?cvsroot=gcc&r1=1.31&r2=1.32 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6130&r2=1.6131 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr23049.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ucnid-4.c.diff?cvsroot=gcc&r1=1.3&r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049
[Bug middle-end/24178] GCC 4.0/4.1 generates code that produces unaligned access exceptions
--- Comment #3 from tsv at solvo dot ru 2005-10-04 05:59 --- (In reply to comment #2) > (In reply to comment #0) > > > The offset of "p5" member is 25 bytes, but compiler thinks that "p5" is > > aligned > > in "foo" function > > You are casting a pointer to a Foo* that doesn't have proper alignment for > a Foo. This is undefined behavior, so anything can happen, including an > unaligned access at some later point. This is not a gcc bug. Correct me if I wrong, but loading long from passed pointer to char minus 4 is not correct too. I could agree if the compiler did substruct 25 from pointer and added 24 and that did load (it does it in not optimized version). In this case it would me me who passed incorrect pointer (in fact DEC C did that) and I agree with compiler that warns me about it. I can't test right now, but if I recall gcc 3.4 didn't have such problems. > > > It might be not very good coding practice, but it taken from Mozilla source. > > Please report it there instead. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24178
[Bug target/20614] PowerPC - inefficient use of condition register
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-04 06:18 --- I should note on the 970 (fx at least), logical cr instructions can only appear in the first dispatch group. (Table6-6. Instructions with Group Formation Restrictions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20614
[Bug rtl-optimization/16796] PowerPC - Unnecessary Floating Point Register Copy
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-04 06:26 --- Oh, this is -ftracer being too late in the game problem. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-07-04 22:23:06 |2005-10-04 06:26:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796
[Bug other/24175] bootstrap failed / undefined symbol: nsion__...
--- Comment #2 from pluto at agmk dot net 2005-10-04 06:56 --- yes, You've right. binutils was miscompiled but i found something else: (...) /home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/gcc/gcj -B/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/ppc-pld-linux/libjava/ -B/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/gcc/ -O2 -fsigned-char -ggdb -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/ppc-pld-linux/libjava -L/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/ppc-pld-linux/libjava/.libs ./.libs/libgcj.so -L/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/ppc-pld-linux/libstdc++-v3/src -L/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/ppc-pld-linux/libstdc++-v3/src/.libs -lpthread -ldl -lz -L/home/users/builder2/rpm/BUILD/gcc-4.1-20051003T0833UTC/obj-ppc-pld-linux/./gcc -L/usr/lib/gcc/ppc-pld-linux/4.1.0 -L/usr/lib/gcc/ppc-pld-linux/4.1.0/../../.. -lgcc_s -lc -lgcc_s -Wl,--rpath -Wl,/usr/lib ./.libs/libgcj.so: undefined reference to `java::awt::dnd::peer::DropTargetContextPeer::class$' ./.libs/libgcj.so: undefined reference to `java::awt::dnd::peer::DragSourceContextPeer::class$' collect2: ld returned 1 exit status this occurs only on ppc (full bootstrap). could You confirm this on another ppc? additional patches applied to my gcc: PR7776, PR20297, PR23128, PR22533, PR23948, PR19505, PR20606+PR24069. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24175
