[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 08:20 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 08:21 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug c/20379] New: Gcc 3.4.3 got internal compiler error: Segmentation fault
We were using GCC 3.2.3 before and the code is OK to compile, but after upgrade to GCC 3.4.3 and GCC 3.4.1, both version give internal compiler error: Segmentation fault when compile this file. We are running on RHEL 3.0 ( Linux 2.4.21) on x86_64. The GCC version:gcc -v: === Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure Thread model: posix gcc version 3.4.3 The command: /usr/local/bin/gcc -c -pipe -m64 -fno-omit-frame-pointer -fPIC -Di386 - D_REENTRANT -O3 -DSERVER -DMONITORS -DHA_KEY='NONE'- I/aseamd1_tst2/wfeng/aselinuxamd64/build/sql/linuxamd64/64bit - I/aseamd1_tst2/wfeng/aselinuxamd64/build/sql/linuxamd64/src - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/ksource/dblkio - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/ksource/dblkio - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/conn/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/sysam/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/unicode/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/capslib/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/sslplus/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/thread/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/kaio/include - I. -I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/kinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/kinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/kinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/cinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/cinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/cinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/jinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/jinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/jinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/jvminclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/jvminclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/jvminclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/stlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/stlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/stlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/intlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/intlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/intlinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/fdp/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/fdp/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/fdp/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/mda/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/mda/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/mda/include - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linuxamd64/oinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/linux/oinclude - I/ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/oinclude - o /aseamd1_tst2/wfeng/aselinuxamd64/build/sql/linuxamd64/64bit/libkrn/diskio.o /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio.c The Output: == In file included from /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/conn/include /intl.h:53, from /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio. c:50: /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/../ext/linuxamd64/conn/include/sybv arg.h:129:1: warning: syb_va_arg redefined In file included from /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/cinclude/syb_std.h:103 2, from /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio. c:33: /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/include/sybvarargs.h:121:1: warning: this is the location of the previous definition /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio.c:135 : warning: struct aioinit declared inside parameter list /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio.c:135 : warning: its scope is only this definition or declaration, which is probably not what you want /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio.c: In function `basis_dllaio': /ccview/aselinuxamd64_wfeng_vu/calm/svr/sql/generic/ksource/dblkio/diskio.c:130 5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See
[Bug c/20379] Gcc 3.4.3 got internal compiler error: Segmentation fault
--- Additional Comments From wei dot feng at sybase dot com 2005-03-08 09:40 --- Created an attachment (id=8358) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8358action=view) The preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug bootstrap/20380] New: bootstrap failure
Bootstrap of gcc-3.4.3 (and 3.4.2) fails with following messages while trying to create libstdc++.so.6. I applied the APAR's mentioned in the Platform notes (btw it is a aix51 ML 3) bos.adt.base.5.1.0.55.bff bos.rte.bind_cmds.5.1.0.55.bff .libs/codecvt.o(.tc+0x0):/soft/gcc/gcc-3.4.2/gcc-3.4.2/libstdc++-v3/src/codecvt.cc: undefined reference to `vtable for std::__codecvt_abstract_basewchar_t, char, char*' .libs/codecvt.o(.tc+0x0):/soft/gcc/gcc-3.4.2/gcc-3.4.2/libstdc++-v3/src/codecvt.cc: undefined reference to `vtable for std::__codecvt_abstract_basechar, char, char*' .libs/codecvt.o(.rw+0x2c):/soft/gcc/gcc-3.4.2/gcc-3.4.2/libstdc++-v3/src/codecvt.cc: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' .libs/codecvt.o(.rw+0x34):/soft/gcc/gcc-3.4.2/gcc-3.4.2/libstdc++-v3/src/codecvt.cc: undefined reference to `typeinfo fo r std::__codecvt_abstract_basechar, char, char*' .libs/codecvt.o(.rw+0x64):/soft/gcc/gcc-3.4.2/gcc-3.4.2/libstdc++-v3/src/codecvt.cc: undefined reference to `vtable for tons of other undefined references omitted ... -- Summary: bootstrap failure Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: o dot flebbe at science-computing dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-ibm-aix5.1.0.0 GCC host triplet: powerpc-ibm-aix5.1.0.0 GCC target triplet: powerpc-ibm-aix5.1.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20380
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From ramya dot chandar at wipro dot com 2005-03-08
09:44 ---
(In reply to comment #9)
Invalid, as what you are doing is called explicit specializtion and when this
happens you instantiate the
template and now you are violating the one defintional rule (which is 14.7/5
in the C++ standard).
Note that if you use 3.4.0, it works with adding template.
(In reply to comment #9)
Invalid, as what you are doing is called explicit specializtion and when this
happens you instantiate the
template and now you are violating the one defintional rule (which is 14.7/5
in the C++ standard).
Note that if you use 3.4.0, it works with adding template.
Since solving this Compiler error is very critical to us, We made some more
investigation in our code to see if it violates the one defintional rule of C++.
Here is our consolidated investigation.
Explicit template specialization itself does NOT instantiate the template. It
only specializes it. Hence, we feel, it is not violating any C++ standard rules.
E.g.,
templateclass T class A {
public:
void f(T t) { /* ... */ } // definition in general case
};
template void Aint::f(int i) { /* ... */ } // definition in specific, i.e.,
'T=int' case
The above code does NOT instantiate the template, it only does explicit
specialization of its 'f' member function for the case of 'T= int'.
Template instantiation is an another issue, and it can happen either implicitly
or explicitly.
Implicit template instantiation happens when the template is being used in the
way that its usage requires the instantiation.
E.g.,
Aint* aP; // No instantiation happens!
Aint a; // Implicit template instantiation happens!
Explicit template instantiation happens when the explicit template instantiation
syntax is applied.
E.g.,
template class Aint;
template void Aint::f(int);
template class Achar;
Looking at our IOCM Sequence.hh and Sequence.impl files, within these files the
templates, that generate errors with the new GNU compiler( 3.3.2), are surely
NOT instantiated.
However it is true that the template specializations in the Sequence.impl files
should have template prefix (but most of the compilers are actually accept
them without this as well).
I checked these files with the Microsoft Visual Studio .Net 2003 which is
commonly known as having one of the compilers that most follow the C++ standard.
With this compiler everything compiles well (in fact, with or without the
template prefix).
Can you please explain us, if it is the problem with GCC 3.3.2 compiler.
surprisingly, with GCC 2.95.3 compiler, we are able to compile the same code
without any changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug java/20351] compilation with a redundant jar fails, if output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-08 09:56 --- FWIW, with the new verifier enabled this seems to work just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20351
[Bug java/20362] ICE: bus error if missed interface used in abstract class and output file specified
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-08 10:05 --- As of 2005-03-08, this testcase works quite fine for me with mainline CVS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20362
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From falk at debian dot org 2005-03-08 10:11
---
I can reproduce this with 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
(i486-linux), but not with 3.4.4 20050203 (prerelease) (Debian 3.4.3-9)
(alpha-linux). Probably it's already fixed.
Test case:
void dblkIO_aio_init (struct aioinit *);
void basis_dllaio ()
{
struct aioinit { int x; } rt_init;
dblkIO_aio_init(rt_init);
}
--
What|Removed |Added
Keywords||ice-on-valid-code
Known to work||3.3.5
Summary|Gcc 3.4.3 got internal|Segfault after struct
|compiler error: Segmentation|declared inside parameter
|fault |list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug bootstrap/20380] bootstrap failure
--- Additional Comments From o dot flebbe at science-computing dot de 2005-03-08 10:27 --- Someone has placed the gnu ld into my PATH Arghhh. Closed, invalid. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20380
[Bug c++/20381] New: ICE in build_ptrmemfunc, at cp/typeck.c:5702
I compiled ACE 5.4.2 with the 20050306 snapshot and got an ICE in build_ptrmemfunc, at cp/typeck.c:5702. This ICE is new (snapshot from last week works) and occurs even at -O0. Michael Cieslinski g++41b -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1-20050306/configure --prefix=/usr/local/gcc41b --program-suffix=41b --with-arch=opteron --enable-languages=c,c++ --enable-checking Thread model: posix gcc version 4.1.0 20050306 (experimental) g++41b -march=opteron -c -o POSIX_Proactor.o POSIX_Proactor.ii /home/cie019/ace542-gcc40x/ACE_wrappers/ace/Select_Reactor_T.cpp: In member function 'virtual int ACE_Select_Reactor_TACE_SELECT_REACTOR_TOKEN::dispatch_io_handlers (ACE_Select_Reactor_Handle_Set, int, int)': /home/cie019/ace542-gcc40x/ACE_wrappers/ace/Select_Reactor_T.cpp:1253: internal compiler error: in build_ptrmemfunc, at cp/typeck.c:5702 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE in build_ptrmemfunc, at cp/typeck.c:5702 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: micis at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug c++/20381] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From micis at gmx dot de 2005-03-08 10:40 --- Created an attachment (id=8359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8359action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
Rq4Clarification: std::uncaught_exception
Hi, I have been reading http://gcc.gnu.org/bugs.html, but I cannot figure out if the bug I have found in the way std::uncaught_exception works is a gcc or a libstdc++ bug. Since the faulty behavior is the same with MinGW and Linux native gcc, I guess it is a language/compiler issue. (The bug is that std::uncaught_exception returns false in a corner case, when the standard asks for true return. I think it is probably the least important issue, but I still would like to get it registered somewhere.) Please let me know where should I report this bug! I am sorry, if I have sent this message to the wrong place. Just let me know where to ask for clarifications, and I won't make the mistake again. TIA, Attila aka WW
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 11:44 --- Subject: Bug 20035 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-08 11:44:40 Modified files: gcc/ada: ChangeLog Makefile.in Added files: gcc/ada: system-linux-sparc.ads Log message: 2005-03-07 James A. Morrison [EMAIL PROTECTED] Laurent Guerby [EMAIL PROTECTED] PR ada/20035 * system-linux-sparc.ads: New. * Makefile.in: Add sparc linux entry. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/system-linux-sparc.ads.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.638r2=1.638.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.110r2=1.110.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 11:48 --- Subject: Bug 20035 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-08 11:48:35 Modified files: gcc/ada: ChangeLog Makefile.in Added files: gcc/ada: system-linux-sparc.ads Log message: 2005-03-07 James A. Morrison [EMAIL PROTECTED] Laurent Guerby [EMAIL PROTECTED] PR ada/20035 * system-linux-sparc.ads: New. * Makefile.in: Add sparc linux entry. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/system-linux-sparc.ads.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/ChangeLog.diff?cvsroot=gccr1=1.640r2=1.641 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ada/Makefile.in.diff?cvsroot=gccr1=1.111r2=1.112 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
Re: Rq4Clarification: std::uncaught_exception
Please let me know where should I report this bug! Unsurprisingly, I suggest: http://gcc.gnu.org/bugzilla/ *Please* strive to reduce the relevant testcase as much as possible. Thanks, Paolo.
[Bug target/18836] [4.1] target fold_builtin for alpha
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-08 12:02 --- Committed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18836
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 18836, which changed state. Bug 18836 Summary: [4.1] target fold_builtin for alpha http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18836 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c++/20381] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From martin at mpa-garching dot mpg dot de
2005-03-08 12:19 ---
Here is a shorter testcase:
class foo {
public:
int f1(int);
};
templatetypename T class bar: public foo {
void baz () {
foo::f1;
}
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug c++/20381] ICE in build_ptrmemfunc, at cp/typeck.c:5702
-- What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From giovannibajo at libero dot it 2005-03-08 12:30 --- So, to recap: testcase in comment #5 should not be optimized (at least, it is not related to this bug). Testcase in comment #2 is already optimized correctly in the tree-profiling-branch, which is due to be merged for 4.1. If so, we can suspend this bug until the branch is merged. The proposed patch cannot be merged to release branches because this is not a regression, AFAICT. I also guess that on the mainline we want to fix this at the tree level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c/20382] New: internal compiler error in emit_move_insn, at expr.c:2809
systemConfig/5xx_board_init.c:104 internal compiler error: in emit_move_insn, at expr.c:2809 gcc version 3.4.0-macraigor1 GNU C version 3.4.0-macraigor1 (powerpc-elf) compiled by GNU C version 3.3.1 (cygming special). I didn't configure GNU, Macraigor did, I didn't even know one could configure it, I haven't seen documentation on this. command line is in file bug.rpt I don't see how to attach the files you have asked for: I'm running GNU on a Dell 8400 with WindowsXP and cygwin. -- Summary: internal compiler error in emit_move_insn, at expr.c:2809 Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sailors3 at comcast dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 3.3.1-macraigor1 GCC host triplet: 3.4.0 GCC target triplet: 3.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c/20382] internal compiler error in emit_move_insn, at expr.c:2809
--- Additional Comments From sailors3 at comcast dot net 2005-03-08 13:13 --- Created an attachment (id=8360) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8360action=view) preprocessed input file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c/20382] internal compiler error in emit_move_insn, at expr.c:2809
--- Additional Comments From sailors3 at comcast dot net 2005-03-08 13:14 --- Created an attachment (id=8361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8361action=view) command line that triggered bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-08 13:19 --- Subject: Bug 14411 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-08 13:19:41 Modified files: gcc: ChangeLog c-common.c calls.c tree.h gcc/doc: extend.texi Added files: gcc/testsuite/gcc.dg: attr-returns_twice-1.c Log message: PR c/14411 * calls.c (flags_from_decl_or_type): Handle eturns_twice' attribute. * c-common.c (handle_returns_twice): New function. (c_common_attribute_table): Declare eturns_twice' attribute. * doc/extend.texi: Document eturns_twice' attribute. * tree.h (DECL_IS_RETURNS_TWICE): New macro. (struct tree_decl): Add returns_twice_flag. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7728r2=2.7729 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gccr1=1.606r2=1.607 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gccr1=1.380r2=1.381 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.698r2=1.699 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/extend.texi.diff?cvsroot=gccr1=1.242r2=1.243 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/attr-returns_twice-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug rtl-optimization/20359] [3.3/3.4 regression] Incorrect code with global register variables
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-08 14:01
---
Seems to be the combiner, that combines:
(insn 8 22 10 0 (set (reg/v:DI 42 r13 [ r ])
(symbol_ref:DI (g) [flags 0x3] function_decl 0x2a97cde410 g)) 84
{*movdi_1_rex64_nointerunit} (nil)
(nil))
(insn 10 8 12 0 (set (reg:DI 59 [ r ])
(reg/v:DI 42 r13 [ r ])) 84 {*movdi_1_rex64_nointerunit} (insn_list 8
(nil))
(expr_list:REG_DEAD (reg/v:DI 42 r13 [ r ])
(nil)))
into:
(insn 10 8 12 0 (set (reg:DI 59 [ r ])
(symbol_ref:DI (g) [flags 0x3] function_decl 0x2a97cde410 g)) 84
{*movdi_1_rex64_nointerunit} (nil)
(nil))
without taking into account that there is a hard reg assignment.
This means it is not certain that the problem is not present in 4.0/4.1 as well,
just that combiner is not presented the same *.life RTLs and therefore makes
different decisions.
In 4.0, *.life looks like:
(insn 8 6 9 0 (set (reg/v:DI 42 r13 [ r ])
(symbol_ref:DI (g) [flags 0x3] function_decl 0x2a97d09820 g)) 81
{*movdi_1_rex64} (nil)
(expr_list:REG_UNUSED (reg/v:DI 42 r13 [ r ])
(nil)))
(insn 9 8 10 0 (set (reg/f:DI 59)
(symbol_ref:DI (g) [flags 0x3] function_decl 0x2a97d09820 g)) 81
{*movdi_1_rex64} (nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:07 --- (In reply to comment #8) So, to recap: testcase in comment #5 should not be optimized (at least, it is not related to this bug). Testcase in comment #2 is already optimized correctly in the tree-profiling-branch, which is due to be merged for 4.1. Nope the testcase in comment #2 is already optimizated on the mainline (and in 4.0.0) so this could be closed as fixed. Now the one in Comment #5 is a dup of bug 19905 so this could be closed as fixed for 4.0.0 and not worried about. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 20367, which changed state. Bug 20367 Summary: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug middle-end/20382] internal compiler error in emit_move_insn, at expr.c:2809
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug c++/20381] [4.0/4.1 Regression] ICE in build_ptrmemfunc, at cp/typeck.c:5702
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:12 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-03-08 14:12:44 date|| Summary|ICE in build_ptrmemfunc, at |[4.0/4.1 Regression] ICE in |cp/typeck.c:5702|build_ptrmemfunc, at ||cp/typeck.c:5702 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20381
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From joern dot rennecke at st dot com 2005-03-08 14:21 --- Subject: Re: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-03-08 12:30 --- So, to recap: testcase in comment #5 should not be optimized (at least, it is not related to this bug). Actually, it is related inasmuch as it demonstrates a pitfall you have to avoid. Testcase in comment #2 is already optimized correctly in the tree-profiling-branch, which is due to be merged for 4.1. If so, we can suspend this bug until the branch is merged. The proposed patch cannot be merged to release branches because this is not a regression, AFAICT. I also guess that on the mainline we want to fix this at the tree level. It still makes sense to also handle this at the rtl level, so that the scheduler knows that the MEMs don't alias. Unless you propose to convert sched1 and sched2 to do machine-independent scheduling on trees ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug inline-asm/20382] internal compiler error with bogus asm output constraint
--- Additional Comments From falk at debian dot org 2005-03-08 14:25
---
Confirmed. This is triggered by a bogus argument for an output constraint.
Not a regression.
void f() {
__asm__ ( : =r (r5), +r (r5));
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |inline-asm
Ever Confirmed||1
GCC build triplet|3.3.1-macraigor1|
GCC host triplet|3.4.0 |
GCC target triplet|3.3.1 |
Keywords||ice-on-invalid-code
Known to fail||2.95.4 3.2.3 3.3.5 3.4.3
||4.1.0
Summary|internal compiler error in |internal compiler error with
|emit_move_insn, at |bogus asm output constraint
|expr.c:2809 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug ada/20035] failed run-time assertion : Tasking not implemented on this configuration on sparc-linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:29 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20035
[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 14:29:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20375
[Bug libstdc++/20352] FAIL: 26_numerics/complex/pow.cc execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-03-08 14:35 --- Subject: Re: FAIL: 26_numerics/complex/pow.cc execution test Digging more (in C99 and Posix), it seems that pow(x,y) always behaves the same for x == +0 and x == -0: this would imply that probably it's safe to have in the generic code something like the attached (vs mainline, very same change also for 4.0 and 3.4). And should also improve the QoI of complex::pow(0, 0), aligning it to the real case, as per F.9.4.4 Can you test it on the targets you have access to? This fixes the fail on hppa1.1-hp-hpux10.20. Also tested with no regressions on hppa2.0w-hp-hpux11.11 (4.1.0), hppa64-hp-hpux11.11 (4.1.0) and hppa-unknown-linux-gnu (4.0.0). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20352
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:36 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:38 --- Actually I take that back, it is only 1 out of 3 which was applied. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 14:49 --- Lets close this as fixed then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug middle-end/19985] executables created with -fprofile-arcs -ftest-coverage segfault in gcov_exit ()
-- What|Removed |Added Severity|critical|normal Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19985
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:57 --- Reopen ... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug c/20379] Segfault after struct declared inside parameter list
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:58 --- ... to mark as duplicate of PR 18978. *** This bug has been marked as a duplicate of 18978 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20379
[Bug c/18978] [3.4 Regression] Segfault after a warning about 'struct sigaction'
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-03-08 14:58 --- *** Bug 20379 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||wei dot feng at sybase dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18978
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 15:10 --- You have not addressed the scheduling issues. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 20367, which changed state. Bug 20367 Summary: alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367 What|Old Value |New Value Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug c++/20383] New: #line directive breaks try-catch statement
The following legal input produces the error message:
`...' handler must be the last handler for its try block.
int main () {
try {}
#line 1 xxx
catch (int) {}
}
--
Summary: #line directive breaks try-catch statement
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinlein at informatik dot uni-ulm dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20383
[Bug c++/20383] [3.3/3.4 Regression] #line directive breaks try-catch statement
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 15:21 --- Fixed by the merge of the tree-ssa : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455). Broke: : Search converges between 2002-01-13-trunk (#54) and 2002-01-20-trunk (#55). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Known to fail||3.4.3 3.0.4 3.3.3 Known to work||2.95.3 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-03-08 15:21:31 date|| Summary|#line directive breaks try- |[3.3/3.4 Regression] #line |catch statement |directive breaks try-catch ||statement Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20383
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 15:35 --- Here's a somewhat reduced testcase that fails for me on ia64-unknown-linux-gnu: $ cat forall_5.f90 program evil_forall implicit none type t logical valid integer :: s integer, dimension(:), pointer :: p end type type (t), dimension (2) :: v integer i allocate (v(1)%p(2)) allocate (v(2)%p(2)) v(:)%valid = (/.true., .true./) v(:)%s = (/1, 2/) v(1)%p(:) = (/9, 10/) v(2)%p(:) = (/11, 12/) forall (i=1:2,v(i)%valid) v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s) end forall if (any(v(1)%p(:) .ne. (/11, 10/))) call abort end program Still gives me 335 lines of *.t02.original - not easy to debug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug java/20384] New: Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
gcj -O2 -shared -fjni -findirect-dispatch ojdbc14.jar -o ojdbc14.so gcj -o oracletest -O2 --classpath=/home/acuser/gcj/DB/ojdbc14.jar jdbcTester.java -main=jdbcTester /home/acuser/gcj/DB/ojdbc14.so -L /usr/local/lib -lgcj jc1: error: invalid option #915;Çÿain=jdbcTester#915;ÇÖ make: *** [oracletest] Error 1 -- Summary: Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: delarosa at ilstechnology 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=20384
[Bug java/20384] Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 16:40 --- -main=jdbcTester You want --main= jdbcTester -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20384
Re: Rq4Clarification: std::uncaught_exception
Attila Feher F (JO/LMF) wrote: Hi, I have been reading http://gcc.gnu.org/bugs.html, but I cannot figure out if the bug I have found in the way std::uncaught_exception works is a gcc or a libstdc++ bug. Since the faulty behavior is the same with MinGW and Linux native gcc, I guess it is a language/compiler issue. (The bug is that std::uncaught_exception returns false in a corner case, when the standard asks for true return. I think it is probably the least important issue, but I still would like to get it registered somewhere.) Please let me know where should I report this bug! You might find this bug report helpful: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10606 Martin
[Bug java/20384] Can't compile oracle test jdbc app with oracle jdbc14.jar shared lib version
--- Additional Comments From delarosa at ilstechnology dot com 2005-03-08 16:49 --- Thanks, --main fixed it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20384
[Bug rtl-optimization/13024] [3.4 regression] gcj can't build current rhug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 17:31 --- Hmm, this fails on the mainline again: PR13024.java: In class 'PR13024':^MPR13024.java: In method 'PR13024.isZipOrJarArchive(java.io.File)': ^MPR13024.java:0: error: dominator of 3 should be 2, not 0^M PR13024.java:0: internal compiler error: in verify_dominators, at dominance.c:854^M Please submit a full bug report,^Mwith preprocessed source if appropriate.^M See URL:http://gcc.gnu.org/bugs.html for instructions.^M I think this was caused by Jeff's patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13024
[Bug bootstrap/13993] [3.4 Regression] Relative path as srcdir causes problem
--- Additional Comments From drow at gcc dot gnu dot org 2005-03-08 17:31 --- Fixed on 3.4 and 4.0 branches. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13993
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From giovannibajo at libero dot it 2005-03-08 18:18 --- (In reply to comment #10) So, to recap: testcase in comment #5 should not be optimized (at least, it is not related to this bug). Actually, it is related inasmuch as it demonstrates a pitfall you have to avoid Right. We then should prepare a testcase from this code that scans the ivopts dump to check that the IV is not strength reduced or something like that. It still makes sense to also handle this at the rtl level, so that the scheduler knows that the MEMs don't alias. Unless you propose to convert sched1 and sched2 to do machine-independent scheduling on trees ;-) To tell you the truth, I would like the expanders to somehow preserve tree aliasing information while creating RTL. But this is gonna be post 4.1 anyway since nobody is working on it, so yes, you are right, for now we want to handle this at RTL level too. Can you show us the SH code generated by mainline for the testcase in comment #2? Or otherwise provide another testcase where the scheduling conflict is visible? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 18:18:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug c/20385] New: Lame error message for undefined type
% cat test.c
unknowntype f() { return 0; }
% gcc -c test.c
test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
Firstly, since this is a frequent mistake, we should really be able to produce
unknowntype used like a type, as other compilers do.
Secondly, IMHO this kind of expected ... error message is *never* a good
idea. I cannot recall a single instance where it was actually helpful to me,
and very often, as in this case, it is extremely confusing, and I would be
better off with plain syntax error before f as it used to be in the old
parser. Even though my knowledge of C parsing is probably slightly above
average, I have not the slightest idea why the parser expects '=', ',', ';',
'asm' or '__attribute__' here, and what I can derive from that about the
mistake I made. But maybe that's just me.
--
Summary: Lame error message for undefined type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug tree-optimization/20386] New: Missing computed goto to normal goto optimization
We miss a computed goto to non computed got if there is code between the
assignment and the goto:
void g();
int f(int i)
{
void *a;
if (i) a = l1;
else a = l2;
g();
goto *a;
l1:
return 1;
l2:
return 2;
}
I saw this while debugging PR13024.java and why if I tried compiling it with
javac it passed.
That function should be equivalent to the following:
void g();
int f(int i)
{
void *a;
g();
if (i) a = l1;
else a = l2;
goto *a;
l1:
return 1;
l2:
return 2;
}
where we check i is not revalant here.
--
Summary: Missing computed goto to normal goto optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20386
[Bug c/20385] Lame error message for undefined type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 18:33 --- The `new' C++ parser gives the best error message: t.c:1: error: 'unknowntype' does not name a type -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 18:33:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug c/20385] Lame error message for undefined type
--- Additional Comments From joseph at codesourcery dot com 2005-03-08
18:59 ---
Subject: Re: New: Lame error message for undefined type
On Tue, 8 Mar 2005, falk at debian dot org wrote:
% cat test.c
unknowntype f() { return 0; }
% gcc -c test.c
test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
Firstly, since this is a frequent mistake, we should really be able to produce
unknowntype used like a type, as other compilers do.
Secondly, IMHO this kind of expected ... error message is *never* a good
idea. I cannot recall a single instance where it was actually helpful to me,
and very often, as in this case, it is extremely confusing, and I would be
better off with plain syntax error before f as it used to be in the old
parser. Even though my knowledge of C parsing is probably slightly above
average, I have not the slightest idea why the parser expects '=', ',', ';',
'asm' or '__attribute__' here, and what I can derive from that about the
mistake I made. But maybe that's just me.
Functions can be defined without declaration specifiers in C90. GNU C
also allows (but pedwarns for) definitions (at file scope) of objects with
no declaration specifiers (for example, *foo; meaning int *foo;). So
unknowntype has been parsed as the name being declared at this point.
So it must either be a function definition of a function called
unknowntype (which it isn't as the declaration isn't a function one) or
a data declaration, and the tokens listed are those which would follow
unknowntype in a data declaration (for example, unknowntype = 1; f()
...).
It would be possible to have special-case detection for where empty
declaration specifiers are followed by a declarator consisting only of an
identifier, unparenthesised, and in the case of a parse error act like
that identifier was a type and look for a new declarator. This would
cover unknowntype foo; and unknowntype *foo;. You can't detect
undeclared types in full generality; for example,
unknowntype (foo)() { return 0; }
is syntactically valid C90 which should be diagnosed, as it is at present,
as declaring a function unknowntype returning a function and so breaking
a constraint, rather than the compiler second-guessing that unknowntype
is a type and (foo) is the parenthesised function name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20385
[Bug c/14411] Request for setjmp/longjmp attributes
--- Additional Comments From avn at any dot ru 2005-03-08 19:02 --- Actually, it is fixed. The other two patches that I pinged are not related to this PR. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411
[Bug other/17652] [meta-bug] GCC 4.1 pending patches
-- Bug 17652 depends on bug 14411, which changed state. Bug 14411 Summary: Request for setjmp/longjmp attributes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14411 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
[Bug fortran/20387] New: ICE in gfc_conv_array_initializer
From http://www.cs.kuleuven.ac.be/~bartv/downloads/bug04.f95: $ gfortran bug04.f90 bug04.f90:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:2936 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050306 (prerelease) $ cat bug04.f90 module bug04 integer, dimension(300), parameter, private :: primes_1_to_300 = (/ 2,3,5,7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, 547, 557, 563, 569, 571, 577, 587, 593, 599, 601, 607, 613, 617, 619, 631, 641, 643, 647, 653, 659, 661, 673, 677, 683, 691, 701, 709, 719, 727, 733, 739, 743, 751, 757, 761, 769, 773, 787, 797, 809, 811, 821, 823, 827, 829, 839, 853, 857, 859, 863, 877, 881, 883, 887, 907, 911, 919, 929, 937, 941, 947, 953, 967, 971, 977, 983, 991, 997, 1009, 1013, 1019, 1021, 1031, 1033, 1039, 1049, 1051, 1061, 1063, 1069, 1087, 1091, 1093, 1097, 1103, 1109, 1117, 1123, 1129, 1151, 1153, 1163, 1171, 1181, 1187, 1193, 1201, 1213, 1217, 1223, 1229, 1231, 1237, 1249, 1259, 1277, 1279, 1283, 1289, 1291, 1297, 1301, 1303, 1307, 1319, 1321, 1327, 1361, 1367, 1373, 1381, 1399, 1409, 1423, 1427, 1429, 1433, 1439, 1447, 1451, 1453, 1459, 1471, 1481, 1483, 1487, 1489, 1493, 1499, 1511, 1523, 1531, 1543, 1549, 1553, 1559, 1567, 1571, 1579, 1583, 1597, 1601, 1607, 1609, 1613, 1619, 1621, 1627, 1637, 1657, 1663, 1667, 1669, 1693, 1697, 1699, 1709, 1721, 1723, 1733, 1741, 1747, 1753, 1759, 1777, 1783, 1787, 1789, 1801, 1811, 1823, 1831, 1847, 1861, 1867, 1871, 1873, 1877, 1879, 1889, 1901, 1907, 1913, 1931, 1933, 1949, 1951, 1973, 1979, 1987 /) integer, dimension(300), parameter, private :: primes_301_to_600 = (/ 1993, 1997, 1999, 2003, 2011, 2017, 2027, 2029, 2039, 2053, 2063, 2069, 2081, 2083, 2087, 2089, 2099, 2111, 2113, 2129, 2131, 2137, 2141, 2143, 2153, 2161, 2179, 2203, 2207, 2213, 2221, 2237, 2239, 2243, 2251, 2267, 2269, 2273, 2281, 2287, 2293, 2297, 2309, 2311, 2333, 2339, 2341, 2347, 2351, 2357, 2371, 2377, 2381, 2383, 2389, 2393, 2399, 2411, 2417, 2423, 2437, 2441, 2447, 2459, 2467, 2473, 2477, 2503, 2521, 2531, 2539, 2543, 2549, 2551, 2557, 2579, 2591, 2593, 2609, 2617, 2621, 2633, 2647, 2657, 2659, 2663, 2671, 2677, 2683, 2687, 2689, 2693, 2699, 2707, 2711, 2713, 2719, 2729, 2731, 2741, 2749, 2753, 2767, 2777, 2789, 2791, 2797, 2801, 2803, 2819, 2833, 2837, 2843, 2851, 2857, 2861, 2879, 2887, 2897, 2903, 2909, 2917, 2927, 2939, 2953, 2957, 2963, 2969, 2971, 2999, 3001, 3011, 3019, 3023, 3037, 3041, 3049, 3061, 3067, 3079, 3083, 3089, 3109, 3119, 3121, 3137, 3163, 3167, 3169, 3181, 3187, 3191, 3203, 3209, 3217, 3221, 3229, 3251, 3253, 3257, 3259, 3271, 3299, 3301, 3307, 3313, 3319, 3323, 3329, 3331, 3343, 3347, 3359, 3361, 3371, 3373, 3389, 3391, 3407, 3413, 3433, 3449, 3457, 3461, 3463, 3467, 3469, 3491, 3499, 3511, 3517, 3527, 3529, 3533, 3539, 3541, 3547, 3557, 3559, 3571, 3581, 3583, 3593, 3607, 3613, 3617, 3623, 3631, 3637, 3643, 3659, 3671, 3673, 3677, 3691, 3697, 3701, 3709, 3719, 3727, 3733, 3739, 3761, 3767, 3769, 3779, 3793, 3797, 3803, 3821, 3823, 3833, 3847, 3851, 3853, 3863, 3877, 3881, 3889, 3907, 3911, 3917, 3919, 3923, 3929, 3931, 3943, 3947, 3967, 3989, 4001, 4003, 4007, 4013, 4019, 4021, 4027, 4049, 4051, 4057, 4073, 4079, 4091, 4093, 4099, 4111, 4127, 4129, 4133, 4139, 4153, 4157, 4159, 4177, 4201, 4211, 4217, 4219, 4229, 4231, 4241, 4243, 4253, 4259, 4261, 4271, 4273, 4283, 4289, 4297, 4327, 4337, 4339, 4349, 4357, 4363, 4373, 4391, 4397, 4409 /) integer, dimension(300), parameter, private :: primes_601_to_900 = (/ 4421, 4423, 4441, 4447, 4451, 4457, 4463, 4481, 4483, 4493, 4507, 4513, 4517, 4519, 4523, 4547, 4549, 4561, 4567, 4583, 4591, 4597, 4603, 4621, 4637, 4639, 4643, 4649, 4651, 4657, 4663, 4673, 4679, 4691, 4703, 4721, 4723, 4729, 4733, 4751,
[Bug java/20388] New: gcj should have a -print-libgcj-jar-file-name option
To locate gcj's version-specific jni.h header, we use: gcj -print-file-name=include/jni.h We should have a similar way to print the libgcj.jar file name. This would be useful for packagers. -- Summary: gcj should have a -print-libgcj-jar-file-name option Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat 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=20388
[Bug java/20388] gcj should have a -print-libgcj-jar-file-name option
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20388
[Bug fortran/20387] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 19:49 --- Confirmed, reduced testcase which shows where the problem is (one less initializer and it will work): module bug04 integer, dimension(101), parameter, private :: a = (/ 2,3,5,7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, 547 /) integer, dimension(101), public :: b=(/ a /) contains end module bug04 -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-03-08 19:49:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
[Bug java/20388] gcj should have a -print-libgcj-jar-file-name option
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-08 19:49:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20388
[Bug fortran/20387] ICE in gfc_conv_array_initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 20:11 --- Looks like we don't handle EXPR_ARRAY in gfc_conv_array_initializer, if we have 100 or less we get EXPR_CONSTANT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 20:30 --- On i686-pc-linux-gnu, forall_5.f90 does the following: $ gfortran forall_5.f90 $ ./a.out Fortran runtime error: Attempt to allocate a negative amount of memory. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050306 (prerelease) Did I mention I don't like memory corruption? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[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-03-08
20:44 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Mark Mitchell [EMAIL PROTECTED] wrote:
No, because there would be no TARGET_EXPR. In a template, you would
just have a COMPOUND_LITERAL_EXPR, with no TARGET_EXPR, because we
want a syntactic representation of the input program.
Yes, and introducing TARGET_EXPRs into templates *is a bug* because in
templates we want a syntactic representation. The closest thing we
have to a syntactic representation of a compound literal is a
CONSTRUCTOR; it's certainly not a TARGET_EXPR wrapped around a
CONSTRUCTOR. It may be just fine to use CONSTRUCTOR, instead of
introducing COMPOUND_LITERAL_EXPR, but TARGET_EXPRs should not be
appearing here at all.
Unfortunately, you've also caused me to think about this long enough
to realize that having the TARGET_EXPR here is wrong in the first
place, as per above.
Okie dokie, how about this?
The change to the gimplify.c is needed to avoid having
gimple_add_tmp_var twice for the variable, once while expanding the
declaration/initialization, once while expanding the clean-ups.
Ok to install? Passed check-g++ (except for the already-broken
eh/cleanup1.C) on x86_64-linux-gnu; just started bootstrap and full
reg-testing.
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20103
* gimplify.c (gimplify_decl_expr): Don't add temp variable if it
was already seen in a bind expr.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.115
diff -u -p -r2.115 gimplify.c
--- gcc/gimplify.c 8 Mar 2005 13:56:57 - 2.115
+++ gcc/gimplify.c 8 Mar 2005 20:33:03 -
@@ -1047,7 +1047,8 @@ gimplify_decl_expr (tree *stmt_p)
/* This decl isn't mentioned in the enclosing block, so add it to the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else is. */
- if (DECL_ARTIFICIAL (decl) DECL_NAME (decl) == NULL_TREE)
+ if (DECL_ARTIFICIAL (decl) DECL_NAME (decl) == NULL_TREE
+ !DECL_SEEN_IN_BIND_EXPR_P (decl))
gimple_add_tmp_var (decl);
}
@@ -2123,7 +2124,8 @@ gimple_boolify (tree expr)
*EXPR_P should be stored. */
static enum gimplify_status
-gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target)
+gimplify_cond_expr (tree *expr_p, tree *pre_p, tree *post_p, tree target,
+ fallback_t fallback)
{
tree expr = *expr_p;
tree tmp, tmp2, type;
@@ -2137,18 +2139,40 @@ gimplify_cond_expr (tree *expr_p, tree *
the arms. */
else if (! VOID_TYPE_P (type))
{
+ tree result;
+
if (target)
{
ret = gimplify_expr (target, pre_p, post_p,
is_gimple_min_lval, fb_lvalue);
if (ret != GS_ERROR)
ret = GS_OK;
- tmp = target;
+ result = tmp = target;
tmp2 = unshare_expr (target);
}
+ else if ((fallback fb_lvalue) == 0)
+ {
+ result = tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), iftmp);
+ ret = GS_ALL_DONE;
+ }
else
{
- tmp2 = tmp = create_tmp_var (TREE_TYPE (expr), iftmp);
+ tree type = build_pointer_type (TREE_TYPE (expr));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 1)) != void_type_node)
+ TREE_OPERAND (expr, 1) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 1));
+
+ if (TREE_TYPE (TREE_OPERAND (expr, 2)) != void_type_node)
+ TREE_OPERAND (expr, 2) =
+ build_fold_addr_expr (TREE_OPERAND (expr, 2));
+
+ tmp2 = tmp = create_tmp_var (type, iftmp);
+
+ expr = build (COND_EXPR, void_type_node, TREE_OPERAND (expr, 0),
+ TREE_OPERAND (expr, 1), TREE_OPERAND (expr, 2));
+
+ result = build_fold_indirect_ref (tmp);
ret = GS_ALL_DONE;
}
@@ -2169,7 +2193,7 @@ gimplify_cond_expr (tree *expr_p, tree *
/* Move the COND_EXPR to the prequeue. */
gimplify_and_add (expr, pre_p);
- *expr_p = tmp;
+ *expr_p = result;
return ret;
}
@@ -2907,7 +2931,8 @@ gimplify_modify_expr_rhs (tree *expr_p,
if (!is_gimple_reg_type (TREE_TYPE (*from_p)))
{
*expr_p = *from_p;
- return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p);
+ return gimplify_cond_expr (expr_p, pre_p, post_p, *to_p,
+ fb_rvalue);
}
else
ret = GS_UNHANDLED;
@@ -3721,7 +3746,8 @@ gimplify_expr (tree *expr_p, tree *pre_p
break;
case COND_EXPR:
- ret = gimplify_cond_expr (expr_p, pre_p, post_p, NULL_TREE);
+ ret = gimplify_cond_expr (expr_p, pre_p,
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 20:51 --- (In reply to comment #16) And that should be fixed via the structure aliasing improvements that Daniel is working on. Will this also work when a[0] .. a[2] are replaced with a0 .. a2 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-08 20:53 --- Hint taken. I'm testing the patch with gcc-3.4, and then will check it in if there are no problems. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-07 18:58:59 |2005-03-08 20:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug libgcj/20389] New: Buff
-- Summary: Buff Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: daney at gcc dot gnu dot org ReportedBy: daney at gcc dot gnu dot org 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=20389
[Bug libgcj/20389] Buffere
-- What|Removed |Added Summary|Buff|Buffere http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-08 21:13 --- I will attach a testcase. I also have a tentative patch and Mauve test that I will submit shortly. -- What|Removed |Added GCC build triplet||i686-pc-linux GCC host triplet||i686-pc-linux GCC target triplet||i686-pc-linux Known to fail||4.0.0 4.1.0 Known to work||3.4.3 Summary|Buffere |BufferedInputStream gets ||ArrayIndexOutOfBoundsExecept ||ion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-08 21:16 --- Created an attachment (id=8367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8367action=view) Testcase As shown in the testcase, a series of marks and reads can cause either ArrayIndexOutOfBoundsException or erroneous EOF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 21:23 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to work|3.4.3 |3.4.3 3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-03-08 21:23:11 date|| Summary|BufferedInputStream gets|[4.0/4.1 Regression] |ArrayIndexOutOfBoundsExecept|BufferedInputStream gets |ion |ArrayIndexOutOfBoundsExecept ||ion http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
-- What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2005-03-08 21:23:11 |2005-03-08 21:32:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[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-03-08
21:55 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 8, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
Okie dokie, how about this?
The change to the gimplify.c is needed to avoid having
gimple_add_tmp_var twice for the variable, once while expanding the
declaration/initialization, once while expanding the clean-ups.
Ok to install? Passed check-g++ (except for the already-broken
eh/cleanup1.C) on x86_64-linux-gnu; just started bootstrap and full
reg-testing.
Err... *This* was the one that passed check-g++. The one I posted in
a hurry earlier was very incomplete, and contained fragments of other
patches. Sorry about that.
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20103
* gimplify.c (gimplify_decl_expr): Don't add temp variable if it
was already seen in a bind expr.
Index: gcc/gimplify.c
===
RCS file: /cvs/gcc/gcc/gcc/gimplify.c,v
retrieving revision 2.115
diff -u -p -r2.115 gimplify.c
--- gcc/gimplify.c 8 Mar 2005 13:56:57 - 2.115
+++ gcc/gimplify.c 8 Mar 2005 21:48:41 -
@@ -1047,7 +1047,8 @@ gimplify_decl_expr (tree *stmt_p)
/* This decl isn't mentioned in the enclosing block, so add it to the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else is. */
- if (DECL_ARTIFICIAL (decl) DECL_NAME (decl) == NULL_TREE)
+ if (DECL_ARTIFICIAL (decl) DECL_NAME (decl) == NULL_TREE
+ !DECL_SEEN_IN_BIND_EXPR_P (decl))
gimple_add_tmp_var (decl);
}
Index: gcc/cp/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/20103
* cp-tree.h (build_compound_literal): Declare.
* semantics.c (finish_compound_literal): Move most of the code...
* tree.c (build_compound_literal): ... here. New function.
(lvalue_p_1): Handle COMPOUND_LITERAL_EXPR.
(stabilize_init): Likewise.
* pt.c (tsubst_copy_and_build): Likewise.
* call.c (build_over_call): Likewise.
* class.c (fixed_type_or_null): Likewise.
* cp-gimplify.c (cp_gimplify_init_expr): Likewise.
* cvt.c (force_rvalue, ocp_convert): Likewise.
* typeck.c (build_x_unary_op): Likewise.
(cxx_mark_addressable): Likewise.
(maybe_warn_about_returning_address_of_local): Likewise.
Index: gcc/cp/cp-tree.h
===
RCS file: /cvs/gcc/gcc/gcc/cp/cp-tree.h,v
retrieving revision 1.1107
diff -u -p -r1.1107 cp-tree.h
--- gcc/cp/cp-tree.h 1 Mar 2005 09:57:38 - 1.1107
+++ gcc/cp/cp-tree.h 8 Mar 2005 21:48:50 -
@@ -4218,6 +4218,7 @@ extern tree build_min_nt (enum tree_co
extern tree build_min_non_dep (enum tree_code, tree, ...);
extern tree build_cplus_new(tree, tree);
extern tree get_target_expr(tree);
+extern tree build_compound_literal (tree, tree);
extern tree build_cplus_array_type (tree, tree);
extern tree hash_tree_cons (tree, tree, tree);
extern tree hash_tree_chain(tree, tree);
Index: gcc/cp/semantics.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.463
diff -u -p -r1.463 semantics.c
--- gcc/cp/semantics.c 23 Feb 2005 05:30:48 - 1.463
+++ gcc/cp/semantics.c 8 Mar 2005 21:48:52 -
@@ -1980,23 +1980,16 @@ finish_compound_literal (tree type, tree
compound_literal = build_constructor (NULL_TREE, initializer_list);
/* Mark it as a compound-literal. */
TREE_HAS_CONSTRUCTOR (compound_literal) = 1;
+
if (processing_template_decl)
+/* This causes template substitution to run digest_init on the
+ CONSTRUCTOR. */
TREE_TYPE (compound_literal) = type;
else
-{
- /* Check the initialization. */
- compound_literal = digest_init (type, compound_literal, NULL);
- /* If the TYPE was an array type with an unknown bound, then we can
-figure out the dimension now. For example, something like:
-
- `(int []) { 2, 3 }'
-
-implies that the array has two elements. */
- if (TREE_CODE (type) == ARRAY_TYPE !COMPLETE_TYPE_P (type))
- complete_array_type (type, compound_literal, 1);
-}
+/* Check the initialization. */
+compound_literal = digest_init (type, compound_literal, NULL);
- return compound_literal;
+ return build_compound_literal (type, compound_literal);
}
/* Return the declaration for the function-name variable indicated by
Index: gcc/cp/tree.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/tree.c,v
retrieving revision 1.427
diff -u -p -r1.427
[Bug target/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-08 21:58 --- (In reply to comment #1) I've traced what's going on: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00525.html It includes a patch for comment. The sh64 port is partcularily exposed in emit_libcall_block because it uses paradoxical subregs to set up the offset part of the PIC address, but I think your patch makes sense. Except that this is only the tip of the iceberg. The problem was introduced in a maga-patch to remove RTX_UNCHANGING_P; there are a number of other places that need to be fixed up similarily. 2004-08-18 Richard Henderson [EMAIL PROTECTED] * rtl.h (MEM_READONLY_P): Replace RTX_UNCHANGING_P. * alias.c (true_dependence): Update to match new semantics. (canon_true_dependence, write_dependence_p): Likewise. (anti_dependence, output_dependence): Update write_dependence_p args. (unchanging_anti_dependence): Remove. * calls.c (purge_mem_unchanging_flag): Remove. (fixup_tail_calls): Don't call it. (expand_call): Don't add unchanging memory to function usage. * expr.c (emit_block_move_via_libcall): Likewise. (clear_storage_via_libcall): Don't clobber RTX_UNCHANGING_P mems. (get_subtarget): Don't use RTX_UNCHANGING_P. (expand_assignment, store_constructor, expand_expr_real_1): Likewise. (do_tablejump): Set MEM_READONLY_P, not RTX_UNCHANGING_P. * combine.c (get_last_value_validate): Use MEM_READONLY_P. * cse.c (insert): Don't use RTX_UNCHANGING_P. (cse_insn, canon_hash): Use MEM_READONLY_P. * emit-rtl.c (set_mem_attributes_minus_bitpos): Use MEM_READONLY_P instead of RTX_UNCHANGING_P. * explow.c (maybe_set_unchanging): Remove. * expr.h (maybe_set_unchanging): Remove. * flow.c (insn_dead_p, mark_used_regs): Use anti_dependence. * function.c (assign_stack_temp_for_type): Don't use RTX_UNCHANGING_P. (assign_parm_setup_reg, expand_function_start): Likewise. * integrate.c (copy_rtx_and_substitute): Likewise. * ra-rewrite.c (emit_colors): Likewise. * regmove.c (copy_src_to_dest, regmove_optimize): Likewise. (fixup_match_1): Likewise. * reload1.c (reload, alter_reg): Likewise. * local-alloc.c (validate_equiv_mem): Check MEM_READONLY_P, not RTX_UNCHANGING_P. (equiv_init_varies_p): Likewise. * loop-invariant.c (check_maybe_invariant): Likewise. * resource.c (mark_referenced_resources, mark_set_resources): Likewise. * loop.c (note_addr_stored): Likewise. (prescan_loop): Likewise. Don't check function usage for clobbered unchanging memory. * rtlanal.c (rtx_unstable_p): Check MEM_READONLY_P, not RTX_UNCHANGING_P. (rtx_varies_p, modified_between_p, modified_in_p): Likewise. * varasm.c (force_const_mem): Likewise. * stmt.c (expand_decl): Don't set RTX_UNCHANGING_P. * web.c (entry_register): Likewise. * tree-gimple.h (get_base_address): Move decl ... * tree.h: ... here. * doc/rtl.texi (MEM_READONLY_P): Replace RTX_UNCHANGING_P. * config/alpha/alpha.c (alpha_set_memflags_1): Rewrite to be called via for_each_rtx. Copy MEM_SCALAR_P, MEM_NOTRAP_P too. (alpha_set_memflags): Update to match. * config/darwin.c (machopic_indirect_data_reference): Set MEM_READONLY_P instead of RTX_UNCHANGING_P. (machopic_indirect_call_target): Likewise. (machopic_legitimize_pic_address): Likewise. * config/arm/arm.c (legitimize_pic_address, arm_gen_load_multiple, arm_gen_store_multiple, arm_gen_movmemqi): Likewise. * config/arm/arm.md (load_multiple, store_multiple): Likewise. * config/frv/frv.md (symGOT2reg): Likewise. * config/i386/i386.c (legitimize_pic_address, legitimize_tls_address, ix86_split_to_parts): Likewise. * config/ia64/ia64.c (ia64_expand_tls_address): Likewise. * config/ia64/ia64.md (load_fptr): Likewise. * config/m32r/m32r.c (m32r_legitimize_pic_address): Likewise. * config/m68k/m68k.c (legitimize_pic_address): Likewise. * config/mcore/mcore.c (block_move_sequence): Likewise. * config/mn10300/mn10300.md (symGOT2reg): Likewise. * config/pa/pa.c (legitimize_pic_address): Likewise. * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Likewise. (rs6000_emit_move): Likewise. * config/s390/s390.c (legitimize_pic_address): Likewise. (legitimize_tls_address): Likewise. * config/s390/s390.md (casesi): Likewise. * config/sh/sh.c (prepare_move_operands, sh_reorg): Likewise. * config/sh/sh.md (symGOT2reg): Likewise. * config/sparc/sparc.c (legitimize_pic_address): Likewise. * config/v850/v850.md (casesi): Likewise. * config/ia64/ia64.c
[Bug other/20390] New: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
The gfortran frontend defines the two options -i8 and -r8 in gfortran/lang.opt.
gcc/opts.sh appears to process lang.opt without a problem, because the produced
options.h file contains OPT_i8 and OPT_r8. However, neither -i8 nor -r8 is
passed to gfc_handle_option, which is defined to LANG_HOOKS_HANDLE_OPTION
in f95-lang.c.
I have added some debugging printfs to gfc_handle_option
int
gfc_handle_option (size_t scode, const char *arg, int value)
{
int result = 1;
enum opt_code code = (enum opt_code) scode;
printf(code = %d , code);
if (arg != NULL) printf(arg = %s , arg);
printf(value = %d\n, value);
The execution of gfortran shows that gfc_handle_option is
never called if -i8 or -r8 is specified.
troutmask:sgk[307] gfc41 -static -o kl -d8 kl.f90
code = 138 value = 1
troutmask:sgk[308] gfc41 -static -o kl -r8 kl.f90
gfc41: unrecognized option '-r8'
troutmask:sgk[309] gfc41 -static -o kl -i8 kl.f90
Note, -d8 is OPT_d8 in options.h and it is passed to gfc_handle_option.
So, it appears that some magic parsing of command line arguments occurs
before gfc_handle_option is called. Is there someway to inhibit this
magic??
--
Summary: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sgk at troutmask dot apl dot washington dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 23:21 --- This was basically fixed as PR 13464, do you want to close this as a dup and add your analysis there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-08
23:23 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 7, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
For example, I believe that Alex's proposed solution to PR c++/19199
isn't an appropriate fix. It's perfectly reasonable for fold to convert
a C++ COND_EXPR into a MIN_EXPR or MAX_EXPR, as according to the C++
front-end all three of these tree nodes are valid lvalues. Hence it's
not this transformation in fold that's in error.
Bugzilla was kept out of the long discussion that ensued, so I'll try
to summarize. The problem is that the conversion is turning a
COND_EXPR such as:
((int)a (int)b ? a : b)
into
(__typeof(a)) ((int)a ? (int)b)
which is not an lvalue. This is the transformation we have to avoid.
Simply disabling the COND_EXPR - MIN_EXPR/MAX_EXPR transformation is
also likely to be a serious performance penalty, especially on targets
that support efficient sequences for min and max.
This was not what I intended to do with my patch, FWIW.
Unfortunately, I goofed in the added call to operand_equal_p, limiting
too much the situations in which the optimization could be applied.
The patch fixes this problem, and updates the patch such that it
applies cleanly again.
As for other languages whose COND_EXPRs can't be lvalues, we can
probably arrange quite easily for them to ensure at least one of their
result operands is not an lvalue, so as to enable the transformation
again.
Comments? Ok to install?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_ternary): Use it to avoid turning a COND_EXPR lvalue into
a MIN_EXPR rvalue.
Index: gcc/fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.535
diff -u -p -r1.535 fold-const.c
--- gcc/fold-const.c 7 Mar 2005 21:24:21 - 1.535
+++ gcc/fold-const.c 8 Mar 2005 22:07:52 -
@@ -2005,16 +2005,12 @@ fold_convert (tree type, tree arg)
}
}
-/* Return an expr equal to X but certainly not valid as an lvalue. */
+/* Return false if expr can be assumed to not be an lvalue, true
+ otherwise. */
-tree
-non_lvalue (tree x)
+static bool
+maybe_lvalue_p (tree x)
{
- /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
- us. */
- if (in_gimple_form)
-return x;
-
/* We only need to wrap lvalue tree codes. */
switch (TREE_CODE (x))
{
@@ -2054,8 +2050,24 @@ non_lvalue (tree x)
/* Assume the worst for front-end tree codes. */
if ((int)TREE_CODE (x) = NUM_TREE_CODES)
break;
-return x;
+return false;
}
+
+ return true;
+}
+
+/* Return an expr equal to X but certainly not valid as an lvalue. */
+
+tree
+non_lvalue (tree x)
+{
+ /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
+ us. */
+ if (in_gimple_form)
+return x;
+
+ if (! maybe_lvalue_p (x))
+return x;
return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
}
@@ -9734,10 +9746,16 @@ fold_ternary (tree expr)
of B and C. Signed zeros prevent all of these transformations,
for reasons given above each one.
+We don't want to use operand_equal_for_comparison_p here,
+because it might turn an lvalue COND_EXPR into an rvalue one,
+see PR c++/19199.
+
Also try swapping the arguments and inverting the conditional. */
if (COMPARISON_CLASS_P (arg0)
- operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-arg1, TREE_OPERAND (arg0, 1))
+ ((maybe_lvalue_p (op1) maybe_lvalue_p (op2))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0), op1, 0)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ arg1, TREE_OPERAND (arg0, 1)))
!HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (arg1
{
tem = fold_cond_expr_with_comparison (type, arg0, op1, op2);
@@ -9746,9 +9764,10 @@ fold_ternary (tree expr)
}
if (COMPARISON_CLASS_P (arg0)
- operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
-op2,
-TREE_OPERAND (arg0, 1))
+ ((maybe_lvalue_p (op1) maybe_lvalue_p (op2))
+ ? operand_equal_p (TREE_OPERAND (arg0, 0), op2, 0)
+ : operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
+ op2, TREE_OPERAND (arg0, 1)))
!HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (op2
{
tem = invert_truthvalue (arg0);
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/19199
*
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:47 --- Subject: Re: Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS On Tue, Mar 08, 2005 at 11:21:52PM -, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 23:21 --- This was basically fixed as PR 13464, do you want to close this as a dup and add your analysis there? What do you mean by fixed? The -i8 and -r8 options are swallowed before gfc_handle_option is called, and I have a patch that actually fixes -d8. PR 13464 does not show up if one searches bugzilla with fortran. I'll add what I found. BTW, it I change lang.opt to have -fiate instead of -i8, things works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-08 23:50 --- (In reply to comment #2) What do you mean by fixed? I mean filed, woops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-03-08 23:52 ---
The gfortran frontend defines the two options -i8 and -r8 in gfortran/lang.opt.
gcc/opts.sh appears to process lang.opt without a problem, because the produced
options.h file contains OPT_i8 and OPT_r8. However, neither -i8 nor -r8 is
passed to gfc_handle_option, which is defined to LANG_HOOKS_HANDLE_OPTION
in f95-lang.c.
I have added some debugging printfs to gfc_handle_option
int
gfc_handle_option (size_t scode, const char *arg, int value)
{
int result = 1;
enum opt_code code = (enum opt_code) scode;
printf(code = %d , code);
if (arg != NULL) printf(arg = %s , arg);
printf(value = %d\n, value);
The execution of gfortran shows that gfc_handle_option is
never called if -i8 or -r8 is specified.
troutmask:sgk[307] gfc41 -static -o kl -d8 kl.f90
code = 138 value = 1
troutmask:sgk[308] gfc41 -static -o kl -r8 kl.f90
gfc41: unrecognized option '-r8'
troutmask:sgk[309] gfc41 -static -o kl -i8 kl.f90
Note, -d8 is OPT_d8 in options.h and it is passed to gfc_handle_option.
So, it appears that some magic parsing of command line arguments occurs
before gfc_handle_option is called. Is there someway to inhibit this
magic??
BTW, I have a patch that actually makes -d8 work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug other/20390] Options aren't handled by LANG_HOOKS_HANDLE_OPTIONS
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:53 --- *** This bug has been marked as a duplicate of 13464 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20390
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-03-08 23:53 --- *** Bug 20390 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug libgcj/20389] [4.0/4.1 Regression] BufferedInputStream gets ArrayIndexOutOfBoundsExeception
--- Additional Comments From daney at gcc dot gnu dot org 2005-03-09 00:16 --- Patch posted here: http://gcc.gnu.org/ml/java-patches/2005-q1/msg00669.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20389
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-09 01:01 --- Subject: Bug 20364 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-09 01:00:56 Modified files: gcc: ChangeLog c-opts.c Log message: Fix for PR middle-end/20364, backported from mainline. Backport from mainline 2004-04-13 James E Wilson [EMAIL PROTECTED] PR middle-end/20364 * c-opt.c (c_common_post_options): If this_input_filename is NULL, increment errorcount and return false instead of true. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.813r2=2.2326.2.814 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-opts.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.96.4.9r2=1.96.4.10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-09 01:10 --- Fix by the patch I just checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From roger at eyesopen dot com 2005-03-09 01:28 --- Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary On 8 Mar 2005, Alexandre Oliva wrote: * fold-const.c (non_lvalue): Split tests into... (maybe_lvalue_p): New function. (fold_ternary): Use it to avoid turning a COND_EXPR lvalue into a MIN_EXPR rvalue. This version is Ok for mainline, and currently open release branches. Thanks, Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-03-09 01:47 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Mon, Mar 07, 2005 at 06:56:19PM -0300, Alexandre Oliva wrote: loop attempts to eliminate a biv represented by a pseudo in favor of a giv represented by (plus (reg) (const_int -1)). Unfortunately, the biv pseudo appears in an insn that doesn't accept anything but a register, so validate_change fails and the error goes unnoticed. The patch below fixes the problem and passed bootstrap on x86_64-linux-gnu (testing still pending), but I'm not very comfortable with the use of location for the assignment. Is this a safe change? Any loop experts around willing to take a second look on this? Thanks in advance, Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: ../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': ../../gcc/ada/ali.adb:2070: error: unrecognizable insn: (insn:HI 5987 1558 1560 230 ../../gcc/ada/ali.adb:996 (set (plus:SI (reg:SI 2074) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7e2b360 ali__cumulative_restrictions)) (plus:SI (reg:SI 2074) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7e2b360 ali__cumulative_restrictions))) -1 (nil) (nil)) ../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': ../../gcc/ada/ali.adb:2070: error: unrecognizable insn: (insn:HI 6040 1461 1463 230 ../../gcc/ada/ali.adb:992 (set (plus:DI (plus:DI (reg:DI 2096) (reg/f:DI 726)) (const_int 12 [0xc])) (plus:DI (reg:DI 2096) (const:DI (plus:DI (symbol_ref:DI (ali__cumulative_restrictions) [flags 0x2] var_decl 0x2a96136ea0 ali__cumulative_restrictions) (const_int 92 [0x5c]) -1 (nil) (nil)) Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug inline-asm/20382] internal compiler error with bogus asm output constraint
--- Additional Comments From sailors3 at comcast dot net 2005-03-09 02:48
---
Subject: RE: internal compiler error with bogus asm output constraint
Where can I find some documentation on using this extended asm format? I
have read all the GNU docs on it and can not understand how to use it.
Thanks,
Dave
-Original Message-
From: falk at debian dot org [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 08, 2005 6:25 AM
To: [EMAIL PROTECTED]
Subject: [Bug inline-asm/20382] internal compiler error with bogus asm
output constraint
--- Additional Comments From falk at debian dot org 2005-03-08 14:25
---
Confirmed. This is triggered by a bogus argument for an output constraint.
Not a regression.
void f() {
__asm__ ( : =r (r5), +r (r5));
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |inline-asm
Ever Confirmed||1
GCC build triplet|3.3.1-macraigor1|
GCC host triplet|3.4.0 |
GCC target triplet|3.3.1 |
Keywords||ice-on-invalid-code
Known to fail||2.95.4 3.2.3 3.3.5 3.4.3
||4.1.0
Summary|internal compiler error in |internal compiler error
with
|emit_move_insn, at |bogus asm output constraint
|expr.c:2809 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09 04:02 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Mar 8, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote: Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: Odd... It surely completed bootstrap for me with default build flags. Hmm... FORTIFY_SOURCE? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-09
04:11 ---
Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a
reference to a temporary
On Mar 8, 2005, Roger Sayle [EMAIL PROTECTED] wrote:
On 8 Mar 2005, Alexandre Oliva wrote:
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_ternary): Use it to avoid turning a COND_EXPR lvalue into
a MIN_EXPR rvalue.
This version is Ok for mainline, and currently open release branches.
Unfortunately, the problem in g++.oliva/expr2.C resurfaced, because,
as it turns out, the transformation (I != J ? I : J) = I yields an
lvalue as required, but not the *correct* lvalue in all cases. I
tried what you'd suggested on IRC (testing whether the thing is an
lvalue after the fact), but that obviously failed in this case as
well.
So I figured a better approach would be to perform lvalue tests to
fold_cond_expr_with_comparison(), where we can avoid specific
inappropriate transformations while still trying other alternatives.
While at that, I figured we could use pedantic_lvalues to avoid
refraining from applying optimizations just because it looks like the
cond-expr might be an lvalue, even though the language requires it not
to be.
This is currently bootstrapping on x86_64-linux-gnu. Ok to install if
bootstrap completes and regtesting passes?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR c++/19199
* fold-const.c (non_lvalue): Split tests into...
(maybe_lvalue_p): New function.
(fold_cond_expr_with_comparison): Preserve lvalue-ness.
Index: gcc/fold-const.c
===
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.535
diff -u -p -r1.535 fold-const.c
--- gcc/fold-const.c 7 Mar 2005 21:24:21 - 1.535
+++ gcc/fold-const.c 9 Mar 2005 03:59:18 -
@@ -2005,16 +2005,12 @@ fold_convert (tree type, tree arg)
}
}
-/* Return an expr equal to X but certainly not valid as an lvalue. */
+/* Return false if expr can be assumed to not be an lvalue, true
+ otherwise. */
-tree
-non_lvalue (tree x)
+static bool
+maybe_lvalue_p (tree x)
{
- /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
- us. */
- if (in_gimple_form)
-return x;
-
/* We only need to wrap lvalue tree codes. */
switch (TREE_CODE (x))
{
@@ -2054,8 +2050,24 @@ non_lvalue (tree x)
/* Assume the worst for front-end tree codes. */
if ((int)TREE_CODE (x) = NUM_TREE_CODES)
break;
-return x;
+return false;
}
+
+ return true;
+}
+
+/* Return an expr equal to X but certainly not valid as an lvalue. */
+
+tree
+non_lvalue (tree x)
+{
+ /* While we are in GIMPLE, NON_LVALUE_EXPR doesn't mean anything to
+ us. */
+ if (in_gimple_form)
+return x;
+
+ if (! maybe_lvalue_p (x))
+return x;
return build1 (NON_LVALUE_EXPR, TREE_TYPE (x), x);
}
@@ -4162,7 +4174,15 @@ fold_cond_expr_with_comparison (tree typ
tree arg00 = TREE_OPERAND (arg0, 0);
tree arg01 = TREE_OPERAND (arg0, 1);
tree arg1_type = TREE_TYPE (arg1);
- tree tem;
+ tree tem = NULL;
+ /* If the COND_EXPR can possibly be an lvalue, we don't want to
+ perform transformations that return a simplified result that will
+ be recognized as lvalue, but that will not match the expected
+ result. We may still return other expressions that would be
+ incorrect, but those are going to be rvalues, and the caller is
+ supposed to discard them. */
+ bool lvalue = !pedantic_lvalues
+ maybe_lvalue_p (arg1) maybe_lvalue_p (arg2);
STRIP_NOPS (arg1);
STRIP_NOPS (arg2);
@@ -4196,10 +4216,12 @@ fold_cond_expr_with_comparison (tree typ
case EQ_EXPR:
case UNEQ_EXPR:
tem = fold_convert (arg1_type, arg1);
- return pedantic_non_lvalue (fold_convert (type, negate_expr (tem)));
+ tem = pedantic_non_lvalue (fold_convert (type, negate_expr (tem)));
+ break;
case NE_EXPR:
case LTGT_EXPR:
- return pedantic_non_lvalue (fold_convert (type, arg1));
+ tem = pedantic_non_lvalue (fold_convert (type, arg1));
+ break;
case UNGE_EXPR:
case UNGT_EXPR:
if (flag_trapping_math)
@@ -4211,7 +4233,8 @@ fold_cond_expr_with_comparison (tree typ
arg1 = fold_convert (lang_hooks.types.signed_type
(TREE_TYPE (arg1)), arg1);
tem = fold (build1 (ABS_EXPR, TREE_TYPE (arg1), arg1));
- return pedantic_non_lvalue (fold_convert (type, tem));
+ tem = pedantic_non_lvalue (fold_convert (type, tem));
+ break;
case UNLE_EXPR:
case UNLT_EXPR:
if (flag_trapping_math)
@@ -4222,12 +4245,18 @@ fold_cond_expr_with_comparison (tree typ
arg1 = fold_convert (lang_hooks.types.signed_type
(TREE_TYPE (arg1)), arg1);
tem = fold (build1 (ABS_EXPR,
[Bug java/15525] suggestion to enable cast elimination
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Last reconfirmed|2004-11-06 19:02:10 |2005-03-09 04:38:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15525
[Bug c++/14777] [3.4/4.0/4.1 Regression] typedef doesn't fully expose base class type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-09 04:45 --- (In reply to comment #5) The first example has been fixed in 3.4.1. The second example is an accepts-invalid and may not be a regression. It is a regression from 3.3.3 and 3.2.3. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail|3.4.0 4.0.0 |3.4.0 4.0.0 2.95.3 4.1.0 Summary|typedef doesn't fully expose|[3.4/4.0/4.1 Regression] |base class type |typedef doesn't fully expose ||base class type Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14777
[Bug c++/17256] [3.3/3.4/4.0/4.1 Regression] undefined but used static or inline functions should be diagnosed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-09 04:49 --- This broke again on the mainline (before the branch of 4.0.0 and even before 3.5.0 was changed to 4.0.0). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail|3.3.4 3.4.0 |3.3.4 3.4.0 4.0.0 4.1.0 Known to work|2.95.3 4.0.0|2.95.3 Summary|[3.3/3.4 Regression]|[3.3/3.4/4.0/4.1 Regression] |undefined but used static or|undefined but used static or |inline functions should be |inline functions should be |diagnosed |diagnosed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17256
[Bug libgcj/20391] New: gcj-dbtool shows incorrect error message if JAR and DSO are switched on the command line
If the JAR and DSO are switched on the command line to gcj-dbtool -a, it shows an incorrect error message: ~/src/tmp gcj-dbtool -a foo.db foo.so foo.jar error: could not update foo.db: java.lang.NullPointerException -- Summary: gcj-dbtool shows incorrect error message if JAR and DSO are switched on the command line Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rmathew at gcc dot gnu dot org 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=20391
