[Bug libgcj/20693] javax-imageio.lo failed to build
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 06:51 --- Subject: Bug 20693 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-17 06:51:12 Modified files: libjava: ChangeLog Makefile.am Makefile.in Log message: 2005-04-16 Anthony Green <[EMAIL PROTECTED]> * Makefile.am (gnu-xml.lo, javax-imageio.lo, javax-xml.lo, gnu-java-beans.lo, gtk-awt-peer.lo) : Sort the output of all "find" output in order to work around the libtool bug described in PR libgcj/20693. * Makefile.in: Rebuilt. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.50&r2=1.3391.2.51 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.455.2.11&r2=1.455.2.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.485.2.11&r2=1.485.2.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
[Bug target/20375] [4.0 Regression] C++ ICE in assign_parm_find_entry_rtl
-- What|Removed |Added Target Milestone|4.0.1 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug target/20375] [4.0 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:39 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug c++/17805] too liberal operator lookup
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-17 06:37 --- (In reply to comment #5) > Subject: Re: too liberal operator lookup > > Why are you pinging bugzilla, and not the list, wherein a c++ > maintainer might see it? Actually he pinged both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17805
[Bug c++/17805] too liberal operator lookup
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:31 --- Subject: Re: too liberal operator lookup Why are you pinging bugzilla, and not the list, wherein a c++ maintainer might see it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17805
[Bug target/20375] [4.0 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-17 06:29 --- patch: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01881.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug target/20375] [4.0 Regression] C++ ICE in assign_parm_find_entry_rtl
-- What|Removed |Added Summary|[4.0/4.1 Regression] C++ ICE|[4.0 Regression] C++ ICE in |in |assign_parm_find_entry_rtl |assign_parm_find_entry_rtl | Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 06:24 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types On Apr 17, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> Mark, did you give up on COMPOUND_LITERAL_EXPRs in C++ for 4.0? The >> C++ portion of the patch at http://gcc.gnu.org/PR20103 is still >> awaiting review even for mainline :-( > Our messages crossed. Ironically, I was just making a pass over the > open 4.0 regressions, and realized that I'd failed to review this > patch. It's an ICE-on-invalid on a GNU C++ extension, so I've now > pushed it back to 4.0.1. I will be sure to review it before then. > Sorry, No worries. I didn't think it was all that important, but thought I'd point it out just in case you'd forgotten about it. How about reviewing it for mainline ASAP, so that we can be even more confident when it goes into 4.0.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 06:19 --- Subject: Bug 20375 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-17 06:19:18 Modified files: gcc: ChangeLog gcc/config/alpha: alpha.c Log message: PR target/20375 * config/alpha/alpha.c (alpha_setup_incoming_varargs): Advance a copy of CUMULATIVE_ARGS past the last named argument. (alpha_va_start): Expect pretend_args_size only if strictly less than 6 named arguments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8328&r2=2.8329 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&r1=1.415&r2=1.416 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:57 --- The remaining failures are all either due to (a) defects in the V3 testsuite, or (b) defects in V3 itself, or (c) semi-spurious warnings in the C++ front end. Postponed until GCC 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug target/20799] [4.0/4.1 Regression] bad relocs for new/delete overrides
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:53 --- Postponed until 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20799
[Bug middle-end/20736] [4.0 Regression] -fprofile-generate crashes on numerous occasions
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:52 --- We can get by if there are bugs in -fprofile-generate. Target milestone changed to 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20736
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:51 --- Removed target milestone; alpha is not a primary or secondary platform. -- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:31 --- See: http://gcc.gnu.org/ml/libstdc++/2005-04/msg00152.html for analysis of the: sorry: semantics of inline function static data 'const size_t __align' are wrong (you'll wind up with multiple copies) warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug c++/18681] [3.3/3.4/4.0/4.1 Regression] template friend declaration not recognized
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:10 --- The TYPE_NO_ACCESS_CHECK_P sets off a red flag for me; that suggests that we're at some point doing access checks directly on _TYPE nodes rather than _DECL nodes. If so, that's wrong; only declarations have access associated with them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-04-17 04:03 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > Mark, did you give up on COMPOUND_LITERAL_EXPRs in C++ for 4.0? The > C++ portion of the patch at http://gcc.gnu.org/PR20103 is still > awaiting review even for mainline :-( Our messages crossed. Ironically, I was just making a pass over the open 4.0 regressions, and realized that I'd failed to review this patch. It's an ICE-on-invalid on a GNU C++ extension, so I've now pushed it back to 4.0.1. I will be sure to review it before then. Sorry, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 04:01 --- Joseph, if I understand correctly, this is now an hppa64-hp-hpux* problem only, and is not a regression. If that's correct, would you please (a) fill in the target field, (b) update the summary line to remove the rgression marker, and (c) remove the target milestone? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug c++/17805] too liberal operator lookup
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 04:00 --- Subject: Re: [PR c++/17805] limit operator overload candidates for enum operands On Apr 2, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Mar 18, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> On Mar 1, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >>> On Feb 10, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: We're a bit too lenient in creating the candidate list for overload resolution for expressions that use user-defined operator functions. This patch arranges for us to reject functions that don't get an exact match for at least one of the enum-typed arguments, if none of the arguments have class types. Regression-tested on x86_64-linux-gnu. Ok to install? Index: gcc/cp/ChangeLog from Alexandre Oliva <[EMAIL PROTECTED]> PR c++/17805 * call.c (build_new_op): Filter out operator functions that don't satisfy enum-conversion match requirements. >>> Ping? >>> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00453.html >> Ping? > Ping? Ping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17805
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 03:59 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Mark, did you give up on COMPOUND_LITERAL_EXPRs in C++ for 4.0? The C++ portion of the patch at http://gcc.gnu.org/PR20103 is still awaiting review even for mainline :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 03:58 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 03:57 --- Alexandre, I dropped the ball here. This patch is too much buck for not enough bang for 4.0.0, but I will review it for 4.0.1. Target milestone changed to 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:54 --- Subject: Bug 20739 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-17 03:54:04 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20739.c Log message: gcc/ChangeLog: PR middle-end/20739 * gimplify.c (gimplify_addr_expr): Compensate for removal of e.g. cv-qualification conversions. gcc/testsuite/ChangeLog: PR middle-end/20739 * gcc.dg/tree-ssa/pr20739.c: New test. 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.163&r2=2.7592.2.164 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.113.2.3&r2=2.113.2.4 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.126&r2=1.5084.2.127 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20739.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=20739
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 03:53 --- It looks like we'll end up deciding that the bug here is in failing to issue an error message on invalid code. Target milestone pushed back to 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug c/17913] [4.0/4.1 Regression] ICE jumping into statement expression
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 03:51 --- Joseph has mititgated the problem, and we shan't be doing any further work on this before 4.0.0. So, I have pushed the target milestone back to 4.0.1. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17913
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 03:50 --- Fixed in 3.4.4. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/21066] Regression: template argument deduction finds false ambiguity
--- Additional Comments From mckelvey at maskull dot com 2005-04-17 03:47 --- Created an attachment (id=8664) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8664&action=view) Example source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21066
[Bug c++/21066] New: Regression: template argument deduction finds false ambiguity
The attached code has compiled fine for several years on g++, and compiles on the Compaq CXX compiler. It recently gives the following: /usr/local/bin/g++ -c -g -fno-elide-constructors -pedantic-errors -Werror -ansi -fno-common -fstrict-aliasing -Wall -Wold-style-cast -Wsign-promo -Wpointer-arith -Wconversion -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual -Wcast-qual -Wextra -Wredundant-decls -Wshadow -MMD -fimplicit-templates -o stest.o stest.cc stest.cc: In function 'int main(int, char**)': stest.cc:69: error: call of overloaded 'muv(const functor_t&, int (functor_t::*)()const)' is ambiguous stest.cc:35: note: candidates are: int muv(T&, int (T::*)()) [with T = const functor_t] stest.cc:55: note: int muv(const T&, int (T::*)()const) [with T = functor_t] gmake: *** [stest.o] Error 1 It looks like a type of const functor_t causes int (T::*)() to be interpreted as int (T::*)()const. Even if this represents a new check, and is valid, why doesn't the compiler also complain about an ambiguity with the third form, int muv(T&, int (T::*)()const? alpha1:PD>g++ -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: ../gcc/configure --verbose --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.1.0 20050409 (experimental) alias CONFIGURECVS='../gcc/configure --verbose --enable-languages=c++ --disable-nls >clog 2>&1 &' alias BUILD='nice gmake CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g'\'' LIBCXXFLAGS='\''-g'\'' bootstrap >log 2>&1 &' -- Summary: Regression: template argument deduction finds false ambiguity Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mckelvey at maskull dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alphaev56-unknown-linux-gnu GCC host triplet: alphaev56-unknown-linux-gnu GCC target triplet: alphaev56-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21066
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:43 --- Subject: Bug 21025 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-17 03:43:01 Modified files: gcc/cp : ChangeLog typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: sizeof9.C Log message: PR c++/21025 * typeck.c (cxx_sizeof_or_alignof_type): Check whether the type to which sizeof/alignof is dependent, rather than just whether we are processing_template_decl. PR c++/21025 * g++.dg/template/sizeof9.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4709&r2=1.4710 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.623&r2=1.624 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5357&r2=1.5358 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/sizeof9.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:37 --- Subject: Bug 21025 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-17 03:37:35 Modified files: gcc/cp : typeck.c Log message: PR c++/21025 * typeck.c (cxx_sizeof_or_alignof_type): Check whether the type to which sizeof/alignof is dependent, rather than just whether we are processing_template_decl. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.616.2.5&r2=1.616.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:37 --- Subject: Bug 21025 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-04-17 03:37:21 Modified files: gcc/cp : ChangeLog typeck.c gcc/testsuite : ChangeLog Log message: PR c++/21025 * typeck.c (cxx_sizeof_or_alignof_type): Check whether the type to which sizeof/alignof is dependent, rather than just whether we are processing_template_decl. PR c++/21025 * g++.dg/template/sizeof9.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.211&r2=1.3892.2.212 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.519.2.23&r2=1.519.2.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.380&r2=1.3389.2.381 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:35 --- Subject: Bug 21025 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-04-17 03:35:27 Added files: gcc/testsuite/g++.dg/template: sizeof9.C Log message: PR c++/21025 * typeck.c (cxx_sizeof_or_alignof_type): Check whether the type to which sizeof/alignof is dependent, rather than just whether we are processing_template_decl. PR c++/21025 * g++.dg/template/sizeof9.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/sizeof9.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 03:30 --- Subject: Bug 21025 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-17 03:30:17 Modified files: gcc/cp : ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: sizeof9.C Log message: PR c++/21025 * typeck.c (cxx_sizeof_or_alignof_type): Check whether the type to which sizeof/alignof is dependent, rather than just whether we are processing_template_decl. PR c++/21025 * g++.dg/template/sizeof9.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.31&r2=1.4648.2.32 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.125&r2=1.5084.2.126 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/sizeof9.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=21025
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-17 03:06 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On 16 Apr 2005, Alexandre Oliva wrote: > On Apr 16, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > > > Does this clear things up? Do you agree? > > Yup, for both questions. Thanks for the clarification. It wasn't > clear to me that the assignments played any useful role, as soon as I > found out the givs could be assumed to hold the correct value. It > all makes sense to me now. Your patch (in comment #45) is OK for mainline, with a suitable ChangeLog entry. Hurray, we can close the PR. Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/17053] [4.0/4.1 Regression] Repo functionality partially broken on AIX (collect2.c)
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 03:00 --- Retargeted to 4.0.1. AIX maintainer has indicated that this bug is not particularly critical, and that the problems are difficult to solve. -- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17053
[Bug c++/21025] [3.4/4.0/4.1 Regression] ICE on template
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21025
[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 02:51 --- This bug report contains no information about reproducing the problems, or even any evidence that these are in fact compiler bugs, rather than bugs in the application code. Closing as INVALID. If additional information becomes avaialable suggesting that is indeed a compiler bug, please file that as a new bug. PR 20973 remains open, as it does have information about a bug in the compilation of konqueror. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20949
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 02:46 --- Jakub, thank you for applying this patch to the 4.0 branch. If you've confirmed that the bug has been fixed, would you please remove 4.0 from the summary here, and from the known-to-fail list? Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug tree-optimization/20929] [4.0 Regression] internal compiler error: verify_stmts failed.
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-17 02:44 --- This patch is OK for 4.0.0 RC2. Please apply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20929
[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))
--- Additional Comments From mark at codesourcery dot com 2005-04-17 02:43 --- Subject: Re: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned)) jsm28 at gcc dot gnu dot org wrote: > --- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-16 > 16:15 --- > Much the same issue can arise with array references through > pointer-to-aligned-type, and with arithmetic on such pointers, as does with > array-of-aligned-type. Agreed. > The obvious options include: > > * Make a new type of larger size to match the alignment whenever e.g. an > 8-byte-aligned-int is requested. (Probably breaks too much.) > > * Disallow arrays of extra-aligned types, and array references and pointer > arithmetic on such types; either with an error, or with a warning and removal > of > the "aligned" attribute (in the case of arrays, attaching it to the array; in > the case of pointers, causing the results of the arithmetic to have the > ordinary > type without alignment). As a C front-end maintainer, which of these options do you prefer? It sounds like you, like me, favor the second option, but I'd like to be sure. > We could also add a target_aligned attribute which can be used to describe the > alignment of a pointer's target, to use for pointers to the start of an array > where the start is aligned but the individual elements aren't. That sounds plausible, but should, IMO, be done after first implementing one of your options above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20794
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-17 02:37 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 16, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > Does this clear things up? Do you agree? Yup, for both questions. Thanks for the clarification. It wasn't clear to me that the assignments played any useful role, as soon as I found out the givs could be assumed to hold the correct value. It all makes sense to me now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From mark at codesourcery dot com 2005-04-17 02:36 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs Alexandre Oliva wrote: > Thanks, Roger had already approved it for mainline, but not yet for > the branch. Mark? OK for 4.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug tree-optimization/21021] [4.1 Regression] ICE in tree-vrp building glibc
-- Bug 21021 depends on bug 21024, which changed state. Bug 21024 Summary: fold generates a comparison of two operands whose types do not match http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21021
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-17 01:41 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug middle-end/21024] fold generates a comparison of two operands whose types do not match
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-17 01:38 --- Subject: Bug 21024 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-17 01:38:28 Modified files: gcc: ChangeLog builtins.c fold-const.c Log message: PR middle-end/21024 * builtins.c (expand_builtin_strcat): Convert the result of strlen to the right type. * fold-const.c (fold_binary) : Use fold_convert to avoid creating type mismatches. : Pass op0 and op1 to fold_build2 to avoid creating type mismatches. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8326&r2=2.8327 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.455&r2=1.456 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.561&r2=1.562 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21024
[Bug java/21065] javax.swing.event.EventListenerList.getListenerList() implemented wrong
-- What|Removed |Added Attachment #8663|Simple Testcase showing that|Simple Testcase showing that description|addind a EventListener |adding a EventListener |increments the list by one |increments the list by one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug java/21065] javax.swing.event.EventListenerList.getListenerList() implemented wrong
--- Additional Comments From gruni dot ca at gmail dot com 2005-04-17 00:45 --- Created an attachment (id=8663) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8663&action=view) Simple Testcase showing that addind a EventListener increments the list by one This is a testcase I wrote, I compiled it with gcj --main=GcjEventListenerListTest -o EventTest.exe GcjEventListenerListTest.java the output should be similar to JDK if implemented correctly JDK output: should be=2 is=2 should be=4 is=4 GCJ output: should be=2 is=1 should be=4 is=2 That's all I have -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug libgcj/20693] javax-imageio.lo failed to build
--- Additional Comments From green at redhat dot com 2005-04-17 00:42 --- I'm seeing this same problem. GCC4 won't build reliably without this fix. -- What|Removed |Added CC||green at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20693
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From roger at eyesopen dot com 2005-04-17 00:21 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail Hi Alex, On 16 Apr 2005, Alexandre Oliva wrote: > On Apr 15, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > > I agree with your proposed game plan of keeping the hard failure in > > place temporarily, to discover whether there are any other "fallback" > > strategies that would be useful. Ultimately though, I don't think we > > should close PR20126 until a "soft failure" is implemented on mainline, > > like we've (Jakub has) done on the gcc-4_0-branch (such as the > > mainline code proposed in comment #30). > > But see, the problem with the soft failure mode is that, if it is ever > legitimate to leave the giv alone and not make sure we set whatever > register appears in it to the right value, then can't we always do it, > removing all of the (thus useless) workarounds? > > And if there's any case in which it is not legitimate to do so, then > the soft failure mode would be a disservice to the user, that would > silently get a miscompiled program. We should probably at least warn > in this case. I don't believe there are any cases in which it is not legitimate to leave the GIV alone, so we'll never silently miscompile anything. My understanding is that it's always possible to leave the giv alone (provided that we set all_reduced to false). The "workarounds" as we've got used to calling them are not required for correctness, but for aggressive optimization. There's clearly a benefit to strength reducing GIVs, and the harder we try to replace them, the better the code we generate. Yes, they are (useless/not necessary) from a purely correctness point of view; we don't even have to call validate_change we could just always give-up and punt using clearing all_reduced (technicaly we don't have to perform any loop optimizations for correctness), but we'd generate pretty poor code. The patch you proposed provides the soft failure mode we want (and now have on the release branch). We could, as you say remove all of the current workarounds, and the only thing that would suffer is the quality of the code we generate. Needless to say, I'd prefer to keep these optimizations (for example your recent one for Josh to allow us to strength reduce the ARM's stim instruction). It's not unreasonable to try three or four approaches before giving up, and forcing the optimizers to preserve the original GIV. Does this clear things up? Do you agree? Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug java/21065] New: javax.swing.event.EventListenerList.getListenerList() implemented wrong
I am using a custom Class wich throws events, by using this I rely on the
EventListenerList Class to hold my Eventlisteners. The Method getListenerList is
used by the method
protected void fireFooXXX() {
// Guaranteed to return a non-null array
Object[] listeners = listenerList.getListenerList();
// Process the listeners last to first, notifying
// those that are interested in this event
for (int i = listeners.length-2; i>=0; i-=2) {
if (listeners[i]==FooListener.class) {
// Lazily create the event:
if (fooEvent == null)
fooEvent = new FooEvent(this);
((FooListener)listeners[i+1]).fooXXX(fooEvent);
}
}
}
which is the standard Method given in the API to fire Events to all
EventListeners. This Method relies on the correct implementation of
getListenerList() which should according to the API Documentation of Java by SUN
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/event/EventListenerList.html#getListenerList()
[quote]
getListenerList
public Object[] getListenerList()
Passes back the event listener list as an array of ListenerType-listener
pairs. Note that for performance reasons, this implementation passes back the
actual data structure in which the listener data is stored internally! This
method is guaranteed to pass back a non-null array, so that no null-checking is
required in fire methods. A zero-length array of Object should be returned if
there are currently no listeners. WARNING!!! Absolutely NO modification of the
data contained in this array should be made -- if any such manipulation is
necessary, it should be done on a copy of the array returned rather than the
array itself.
[/quote]
The API doc says "Passes back the event listener list as an array of
ListenerType-listener pairs." my understanding of pairs is multiples of two, so
the EventListenerList can never contain 1 or 3 entries or any other odd number.
But when adding one Eventlistener to such a list it really just adds this
EventListener resulting in a getListenerList() which returns one Element, which
is simply wrong.
A Testcase will follow as soon as I have written one.
btw this is my system: WinXP SP2
gcj 4.0 20050324 from thisiscool.com
Regards,
Andreas
--
Summary: javax.swing.event.EventListenerList.getListenerList()
implemented wrong
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P1
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gruni dot ca at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21065
[Bug fortran/21063] internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 23:22 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-04-16 23:22:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-16 23:20 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 23:19 --- Subject: Bug 21051 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 23:19:35 Modified files: gcc: ChangeLog builtins.c gcc/config/ia64: sync.md Log message: PR target/21051 * builtins.c (expand_builtin) : Use the mode of boolean_type_node when the user doesn't provide one. * config/ia64/sync.md (sync_lock_release): Use operand 1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8325&r2=2.8326 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcc&r1=1.454&r2=1.455 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/sync.md.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug target/21051] [4.1 Regression] sync tests ICE on ia64
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 23:16:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21051
[Bug SWING/21064] StyleContext.addStyle causes NullPointerException
--- Additional Comments From bothner at gcc dot gnu dot org 2005-04-16 23:05 --- Created an attachment (id=8662) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8662&action=view) Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21064
[Bug SWING/21064] New: StyleContext.addStyle causes NullPointerException
The (to-be-shortly) attached testcase (which works with JDK 1.4.x) causes a NullPointerException: $ gcj -o SwStyle SwStyle.java --main=SwStyle -g $ ./SwStyle Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Class.initializeClass() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at SwStyle.main(java.lang.String[]) (/tmp/SwStyle.java:12) at gnu.java.lang.MainThread.call_main() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at gnu.java.lang.MainThread.run() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) Caused by: java.lang.NullPointerException at java.util.Hashtable.put(java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.SimpleAttributeSet.addAttribute(java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext.addAttribute(javax.swing.text.AttributeSet, java.lang.Object, java.lang.Object) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext$NamedStyle.setResolveParent(javax.swing.text.AttributeSet) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext$NamedStyle.StyleContext$NamedStyle(javax.swing.text.StyleContext, java.lang.String, javax.swing.text.Style) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at javax.swing.text.StyleContext.addStyle(java.lang.String, javax.swing.text.Style) (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) at SwStyle.() (/tmp/SwStyle.java:8) at java.lang.Class.initializeClass() (/home/bothner/GNU/install-gcc-4.0/lib/libgcj.so.6.0.0) ...3 more This is using the gcc-4.0 branch; I haven't tested head. (This testcase is simplified from JEmacs.) -- Summary: StyleContext.addStyle causes NullPointerException Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: graydon at redhat dot com ReportedBy: bothner at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21064
[Bug middle-end/17961] ICE for operation on small vector with altivec enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 22:54 --- This is weird in that it works on ppc-darwin, maybe the altivec ABI is changing something or the just the ABI difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug fortran/21063] New: internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
Here's the piece of code: program bug real, dimension(100) :: dummy real, dimension(100) :: foo integer :: i do i=1,100 call random_number(dummy(i)) call random_number(foo(i)) end do write(*,*) foo(maxloc(dummy)) end program and the output. bash-2.05b$ gfc bug.f90 bug.f90: In function 'MAIN__': bug.f90:12: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 Please submit a full bug report, bash-2.05b$ gfc --version GNU Fortran 95 (GCC 4.1.0 20050416 (experimental)) Copyright (C) 2005 Free Software Foundation, Inc. -- Summary: internal compiler error in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guillemborrell at yahoo dot es CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug middle-end/19590] IVs with the same evolution not eliminated
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2005-01-23 16:27:34 |2005-04-16 22:40:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug middle-end/16670] struct { type:0; } passing bugs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 22:37 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16670
[Bug libfortran/16991] [meta-bug] libgfortran does not build every where
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16991
[Bug libfortran/15235] libgfortran doesn't build on Solaris
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15235
[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266
[Bug libfortran/14325] [libgfortran] libgfortran does not build with newlib on arm-elf (stdint.h does not define the right types)
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14325
[Bug testsuite/21062] Incorrect declaration of printf() in alias2.C
--- Additional Comments From oyvind dot harboe at zylin dot com 2005-04-16 22:05 --- Created an attachment (id=8661) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8661&action=view) Fixes declaration of printf() -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21062
[Bug testsuite/21062] New: Incorrect declaration of printf() in alias2.C
See attached patch.
My GCC superpowers aren't quite up to analyzing this, but I suppose this would
cause problems for e.g. the i2pk target as it would receive size=0 in its
arguments in the function below.
If this can't be sorted out by trivial inspection, please let me know and I'll
run some tests.
/* Returns the number of bytes of arguments automatically
popped when returning from a subroutine call.
FUNDECL is the declaration node of the function (as a tree),
FUNTYPE is the data type of the function (as a tree),
or for a library call it is an identifier node for the subroutine name.
SIZE is the number of bytes of arguments passed on the stack. */
int
ip2k_return_pops_args (tree fundecl ATTRIBUTE_UNUSED, tree funtype, int size)
{
if (TREE_CODE (funtype) == IDENTIFIER_NODE)
return size;
if (TYPE_ARG_TYPES (funtype) == NULL_TREE
|| (TREE_VALUE (tree_last (TYPE_ARG_TYPES (funtype))) == void_type_node))
return size;
return 0;
}
--
Summary: Incorrect declaration of printf() in alias2.C
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oyvind dot harboe at zylin dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21062
[Bug c++/19004] ICE in uses_template_parms at cp/pt.c:4860
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug c++/19608] [3.4 Regression] ICE after friend function definition in local class
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug c++/19884] [3.3/3.4 regression] ICE on explicit instantiation of a non-template constructor
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19884
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug java/18212] nativ compilation with multiple jars fails / gives internal compiler error
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18212
[Bug bootstrap/20155] [4.0/4.1 Regression] libgcj build fails with "execvp: /bin/sh: Argument list too long"
-- What|Removed |Added Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20155
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug middle-end/20739] [4.0 regression] ICE in gimplify_addr_expr
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16 21:58 --- Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on cv-qual diffs On Apr 15, 2005, Jeffrey A Law <[EMAIL PROTECTED]> wrote: > On Thu, 2005-04-14 at 14:02 -0300, Alexandre Oliva wrote: >> On Apr 4, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> >> > If the operands of a cond-expr used as an lvalue differ in cv >> > qualification, the front-end adds nop_exprs to add cv qualifiers that >> > the gimplifier drops when simplifying &(T const)*v. The `&' was added >> > by gimplify_cond_expr. >> >> > The problem is that gimplify_addr_expr gimplifies its operand in such >> > a way that the nop_expr is dropped, and nothing puts it back in, so >> > when we test that, in the indirect_ref case in gimplify_addr_expr, the >> > types are compatible, the test fails because of the missing >> > cv-qualifier in the pointed-to type. This patch fixes this. >> >> > Ok to install if bootstrap and regtest on amd64-linux-gnu pass? >> >> Bootstrap and regtest pased on amd64-linux-gnu, at least for mainline. >> I'm retesting on the branch, since I'm not entirely sure I actually >> tested it there. > Approved for mainline. Mark has final call on the branch. Thanks, Roger had already approved it for mainline, but not yet for the branch. Mark? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20739
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:58 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> I agree with your proposed game plan of keeping the hard failure in
> place temporarily, to discover whether there are any other "fallback"
> strategies that would be useful. Ultimately though, I don't think we
> should close PR20126 until a "soft failure" is implemented on mainline,
> like we've (Jakub has) done on the gcc-4_0-branch (such as the
> mainline code proposed in comment #30).
But see, the problem with the soft failure mode is that, if it is ever
legitimate to leave the giv alone and not make sure we set whatever
register appears in it to the right value, then can't we always do it,
removing all of the (thus useless) workarounds?
And if there's any case in which it is not legitimate to do so, then
the soft failure mode would be a disservice to the user, that would
silently get a miscompiled program. We should probably at least warn
in this case.
Anyhow, here's a patch that was tested with bootstrap and regtest on
amd64-linux-gnu on mainline, that brings in the soft failure mode from
the 4.0 branch to mainline, without removing the potentially-useless
workarounds.
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.526
diff -u -p -r1.526 loop.c
--- gcc/loop.c 10 Apr 2005 04:00:45 - 1.526
+++ gcc/loop.c 16 Apr 2005 21:37:45 -
@@ -5494,11 +5494,23 @@ loop_givs_rescan (struct loop *loop, str
rtx reg, seq;
start_sequence ();
reg = force_reg (v->mode, *v->location);
- seq = get_insns ();
- end_sequence ();
- loop_insn_emit_before (loop, 0, v->insn, seq);
- if (!validate_change_maybe_volatile (v->insn, v->location, reg))
- gcc_unreachable ();
+ if (validate_change_maybe_volatile (v->insn, v->location, reg))
+ {
+ seq = get_insns ();
+ end_sequence ();
+ loop_insn_emit_before (loop, 0, v->insn, seq);
+ }
+ else
+ {
+ end_sequence ();
+ if (loop_dump_stream)
+ fprintf (loop_dump_stream,
+"unable to reduce iv in insn %d\n",
+INSN_UID (v->insn));
+ bl->all_reduced = 0;
+ v->ignore = 1;
+ continue;
+ }
}
}
else if (v->replaceable)
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 21:53 --- But fixed in 4.0.0 so closing as fixed as this is not a regression. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:51 --- *** Bug 21026 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug c++/21026] ICE in check_tag_decl, at cp/decl.c:3516
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:51 --- *** This bug has been marked as a duplicate of 2703 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21026
[Bug c++/2703] Internal error #20000409 for g++-3.0 (20010423)
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-04-16 21:50 --- Not fixed in 3.4.4 -- What|Removed |Added Status|RESOLVED|REOPENED Known to fail||2.95.3 3.0.4 3.2.3 3.3.6 ||3.4.4 Known to work||4.0.0 4.1.0 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2703
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-16
21:48 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 15, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline
> to resolve Josh's bootstrap failure. Sounds like you've already done
> the necessary testing, and I'll trust you on a suitable ChangeLog entry.
Thanks, here's what I've just checked in.
Index: gcc/ChangeLog
from Alexandre Oliva <[EMAIL PROTECTED]>
PR target/20126
* loop.c (loop_givs_rescan): Handle non-replaceable (plus (reg)
(const)).
Index: gcc/loop.c
===
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.526
diff -u -p -r1.526 loop.c
--- gcc/loop.c 10 Apr 2005 04:00:45 - 1.526
+++ gcc/loop.c 16 Apr 2005 21:40:02 -
@@ -5488,6 +5488,15 @@ loop_givs_rescan (struct loop *loop, str
loop_insn_emit_before (loop, 0, v->insn,
gen_move_insn (*v->location,
v->new_reg));
+ else if (GET_CODE (*v->location) == PLUS
+ && REG_P (XEXP (*v->location, 0))
+ && CONSTANT_P (XEXP (*v->location, 1)))
+ loop_insn_emit_before (loop, 0, v->insn,
+ gen_move_insn (XEXP (*v->location, 0),
+ gen_rtx_MINUS
+ (GET_MODE (*v->location),
+ v->new_reg,
+ XEXP (*v->location, 1;
else
{
/* If it wasn't a reg, create a pseudo and use that. */
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-16 21:42 --- Subject: Bug 20126 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-16 21:42:27 Modified files: gcc: ChangeLog loop.c Log message: PR target/20126 * loop.c (loop_givs_rescan): Handle non-replaceable (plus (reg) (const)). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8324&r2=2.8325 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop.c.diff?cvsroot=gcc&r1=1.526&r2=1.527 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/21056] Linker errors when deriving from std::iostream
--- Additional Comments From james dot kanze at free dot fr 2005-04-16 21:00 --- Subject: Re: Linker errors when deriving from std::iostream pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 13:12 --- > Fixed but really this is binutils bug but oh well. Actually, I sort of suspected as much. I wasn't 100% sure, but I think I compiled and linked the same thing on a Sparc Solaris without problems. I hesitated sending it to you, but I didn't know who else to address myself to. (You guys seem serious about quality and usability, which isn't always the case. Even, all too often, when you pay for it. Despite my occasional criticisms, I really appreciate what you're doing.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21056
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From andreast at gcc dot gnu dot org 2005-04-16 20:16 --- I just built the tree without awt-gtk enabled. The gnu/java/awt/peer/gtk/GdkFontMetrics.class is built even without gtk enabled. So, a command line compile of the class to .o is possible and makes the bug easier to reproduce for others. As Andrew P already mentioned. On darwin I reproduce the bug this way: /Volumes/src/gcc/gcc-cvs/objdir/./gcc/jc1 gnu/java/awt/peer/gtk/GdkFontMetrics.class -fhash-synchronization -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase GdkFontMetrics.class -auxbase GdkFontMetrics -g -O2 -Wno-deprecated -version -fclasspath= -fbootclasspath=/Volumes/src/gcc/gcc-cvs/objdir/powerpc-apple-darwin7.9.0/libjava:/Volumes/src/gcc/gcc-cvs/gcc/libjava:/Volumes/src/gcc/gcc-cvs/gcc/libjava/external/w3c_dom:/Volumes/src/gcc/gcc-cvs/gcc/libjava/external/sax -fencoding=UTF-8 -findirect-dispatch -fjni -o /var/tmp//ccA7zDFV.s It happens on both, 4.0 and 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 20:07 --- Here is the backtrace: #0 fold_convert (type=0xb7bf8288, arg=0x0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fold- const.c:1883 #1 0x083be08f in bit_from_pos (offset=0xb7bf8288, bitpos=0xb7bf8288) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/stor-layout.c:538 #2 0x083d176f in bit_position (field=0xb7c37510) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/ tree.c:1495 #3 0x081ce78e in dbxout_type (type=0xb7c2abd0, full=0) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/dbxout.c:1406 #4 0x081ce46e in dbxout_type (type=0xb7c2ad80, full=1) at /home/peshtigo/pinskia/src/gnu/gcc/ src/gcc/dbxout.c:2112 #5 0x081d21ea in dbxout_symbol (decl=Variable "decl" is not available. ) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/dbxout.c:2534 #6 0x083f2df2 in rest_of_decl_compilation (decl=0xb7c2ae58, top_level=1, at_end=0) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/passes.c:249 The field decl which is being taken the bit position of: unit size align 32 symtab 21 alias set -1 fields pointer_to_this chain > unsigned SI size unit size align 32 symtab 20 alias set -1 pointer_to_this > ignored decl_1 VOID file gnu/java/awt/peer/gtk/GdkFontMetrics.java line 74 align 1 offset_align 1 context chain > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug java/21022] bootstrap error compiling libgcj with awt support on darwin-ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:53 --- Confirmed on x86-pc-linux-gnu with compiling the generated GdkFontMetrics.class from gcj build with the following command line. gcj -S -gstabs -findirect-dispatch GdkFontMetrics.class -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 19:53:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21022
[Bug fortran/21061] gfortran ignores -Werror
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:26 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-16 19:26:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21061
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:20 --- Andrew could you look into this and see why the use info is not being updated correctly? Also note the patch in comment #4 is only working around the buggyness of the use information not being updated correctly. -- What|Removed |Added CC||amacleod at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug fortran/21061] New: gfortran ignores -Werror
Said option has no effect. -- Summary: gfortran ignores -Werror Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21061
[Bug target/11026] [Darwin] g++ does not instantiate static data members of templates
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:05 --- *** Bug 21060 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||olsonse at umich dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11026
[Bug c++/21060] Symbol for static member of template is not emitted.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 19:05 --- This is a dup of bug 11026 which is fixed for 4.0.0. *** This bug has been marked as a duplicate of 11026 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21060
[Bug c++/21060] New: Symbol for static member of template is not emitted.
For a static member of a template class, the symbol doesn't appear to be
emitted.
For example, with the code:
/*BEGIN CODE*/
#include
template
class Base {
public:
static int bob;
T a;
Base() { printf("Base::Base starting\n"); fflush(stdout); }
~Base() { printf("Base::~Base::bob = %d\n", Base::bob); fflush(stdout); }
};
template
int Base::bob = 10;
int main() {
Base b;
fflush(stdout);
return 0;
}
/*END CODE*/
if you attempt to compile directly to an executable, you get the following
error:
/usr/bin/ld: Undefined symbols:
Base::bob
collect2: ld returned 1 exit status
If you compile to object code (with -c option) and then use nm to dump the
symbols, you get:
m0135:/tmp olsonse$ nm -a bobby.o
U __Unwind_Resume
U __ZN4BaseIfE3bobE
0088 t __ZN4BaseIfEC1Ev
00d8 t __ZN4BaseIfED1Ev
U ___gxx_personality_v0
U ___sF
U _fflush
T _main
U _printf
U dyld_stub_binding_helper
Note that the Base::bob is indicated to be Undefined. If I use an earlier
compile on the same system (3.3.x), Base::bob is definitely shown as being
present.
--
Summary: Symbol for static member of template is not emitted.
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olsonse at umich dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21060
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:41 --- Subject: Re: Initializing string literal data improperly marked frame-relative?, should be readonly static const. > From: Paul Schlie <[EMAIL PROTECTED]> > Subject: Re: [Bug middle-end/21018] Initializing string literal data > improperly marked frame-relative?, should be readonly static const. > >> Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr >> should be changed to recongize them as such. > > Actually the problem seems then be that literal string constants aren't > being consistently defined through CONST_DECL's (just as initializing char > array data, which are equivalent to string initializers, and all other literal > and static constants which end up being stored as literal data are); for which > MEM_READONLY_P allows all memory references to, to be easily identified, which > seems to be it's intent. > > Is there any reason that literal string constant data shouldn't be similarly > declared and correspondingly identifiable? (or just an oversight?) I suspect it was likely an artifact of the now depreciated writeable-strings extension, which previously pretended that literal string constants were not READONLY after being copied from the executable image into read/write memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.
--- Additional Comments From schlie at comcast dot net 2005-04-16 18:22 --- Subject: Re: Initializing string literal data improperly marked frame-relative?, should be readonly static const. > Note the C.x variables are not normal VAR_DECLs but CONST_DECL so maybe avr > should be changed to recongize them as such. Actually the problem seems then be that literal string constants aren't being consistently defined through CONST_DECL's (just as initializing char array data, which are equivalent to string initializers, and all other literal and static constants which end up being stored as literal data are); for which MEM_READONLY_P allows all memory references to, to be easily identified, which seems to be it's intent. Is there any reason that literal string constant data shouldn't be similarly declared and correspondingly identifiable? (or just an oversight?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-04-16 17:50 --- (In reply to comment #41) > Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail > Sure. Your patch in comment #28 of bugzilla PR20126 is OK for mainline > to resolve Josh's bootstrap failure. Sounds like you've already done > the necessary testing, and I'll trust you on a suitable ChangeLog entry. > I'm not convinced. 1) It produces non-canonical RTL: (MINUS (REG) (const)) 2) It doesn't validate that insn, which is necessary in case 'const' or some modified version of it is not valid. R. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug tree-optimization/17217] not removing removal of nested structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 17:37 --- Fixed in 4.1.0 and above by Daniel's aliasing improvements. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17217
[Bug tree-optimization/20922] missed always false conditional
--- Additional Comments From phython at gcc dot gnu dot org 2005-04-16 17:12 --- Created an attachment (id=8654) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8654&action=view) Fold stuff -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |phython at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20922
[Bug java/18399] [4.0/4.1 Regression] Class initialization optimization does not work with the inliner
-- What|Removed |Added Target Milestone|4.1.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/18399] [4.0/4.1 Regression] Class initialization optimization does not work with the inliner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:57 --- *** Bug 21044 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/21044] [4.0/4.1 Regression] Static class init optimization is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-16 16:57 --- This is a dup of bug 18399, the problem comes from recursively inlining. *** This bug has been marked as a duplicate of 18399 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21044
[Bug middle-end/21059] New: Bogus warning about clobbered variable
$ cat m68k-dis.i
typedef int (*fprintf_ftype) (void *, const char*, ...);
typedef struct disassemble_info {
fprintf_ftype fprintf_func;
void *stream;
int (*read_memory_func) (void);
} disassemble_info;
extern char *foo (void);
typedef struct { } jmp_buf[1];
extern int setjmp (jmp_buf);
int
print_insn_m68k (disassemble_info *info)
{
jmp_buf bailout;
if (setjmp (bailout) != 0)
return -1;
info->fprintf_func (info->stream, foo ());
return 0;
}
$ gcc/xgcc -B gcc/ -W -Wall -O2 -S m68k-dis.i -v
Reading specs from gcc/specs
Target: ia64-suse-linux
Configured with: ../configure --host=ia64-suse-linux --enable-shared
--enable-threads --enable-__cxa_atexit --with-system-zlib
--with-system-libunwind
Thread model: posix
gcc version 4.0.0 20050416 (prerelease)
gcc/cc1 -fpreprocessed m68k-dis.i -quiet -dumpbase m68k-dis.i -auxbase
m68k-dis -O2 -W -Wall -version -o m68k-dis.s
GNU C version 4.0.0 20050416 (prerelease) (ia64-suse-linux)
compiled by GNU C version 4.0.0 20050416 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
m68k-dis.i: In function ôòøprint_insn_m68kôòù:
m68k-dis.i:11: warning: argument ôòøinfoôòù might be clobbered by
ôòølongjmpôòù or ôòøvforkôòù
--
Summary: Bogus warning about clobbered variable
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
