[Bug c++/30046] [4.1/4.2/4.3 Regression] ICE on invalid code in digest_init at cp/typeck2.c:709
--- Comment #2 from s__nakayama at infoseek dot jp 2006-12-04 08:11 --- I seem this is same as Bug 29733. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
[Bug c++/30046] [4.1/4.2/4.3 Regression] ICE on invalid code in digest_init at cp/typeck2.c:709
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-04 08:15 --- *** This bug has been marked as a duplicate of 29733 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
[Bug c++/29733] [4.1/4.2/4.3 regression] ICE on initialization of function type
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-04 08:15 --- *** Bug 30046 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jkherciueh at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #18 from pault at gcc dot gnu dot org 2006-12-04 09:09 --- (In reply to comment #17) Created an attachment (id=12735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735action=view) [edit] Compilable version of previous patch. FX and Eric, Thanks for plugging the hole there. The attention that I can give to gfortran is very limited at present. I committed the FMOD patch, under the impression that the library had been fixed across the board. Since then, I have been more or less continuously on the road. I am curious as to why the test in the original patch, for the presence of the builtin, does not work. In principle, it should furnish the old tree-ssa version of MOD. Would it not be an idea to apply the C99 condition there? Regards Paul PS As for breaking the compiler on a regular basis; there was a lot that was fundamentally wrong with it that is now fixed - the trend is upwards, even if there are occasional 'reverses'. Two consistent causes of these reverses are (i) the range of platforms an (ii) the fact that the testsuite is not a systematic regurgitation of the F95 standard. (i) is, of course, a big plus for gcc and we should try to be mindful of it. However, we part-time volunteers have relatively limited resources and rely on PRs like this one coming in as quickly as possible. On (ii), we have no effort to do the equivalent of the NIST suite for F77, on which gfortran is tested regularly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2006-12-04 09:22 --- I am curious as to why the test in the original patch, for the presence of the builtin, does not work. In principle, it should furnish the old tree-ssa version of MOD. Would it not be an idea to apply the C99 condition there? Yes, clearly that would be best. Two consistent causes of these reverses are (i) the range of platforms an (ii) the fact that the testsuite is not a systematic regurgitation of the F95 standard. Note that I'm complaining about one very specific issue, which is the implicit dependencies on C99 that regularly creep through the library. This one can be easily simulated by butchering the configure script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc and i386
--- Comment #29 from irar at il dot ibm dot com 2006-12-04 09:24 --- I reproduced the wrong printings on x86. It seems to be a problem in strided access vectorization after all - no stores are generated. I am looking into this. Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug fortran/29464] problem with duplicate USE, ONLY of procedure in INTERFACE
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-04 09:44 --- Since I posted a fix, I guess that I should accept the bug! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-15 07:02:15 |2006-12-04 09:44:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29464
[Bug middle-end/29965] OpenMP vs always throw in a loop
--- Comment #4 from jakub at gcc dot gnu dot org 2006-12-04 10:21 --- Subject: Bug 29965 Author: jakub Date: Mon Dec 4 10:20:51 2006 New Revision: 119483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119483 Log: PR middle-end/29965 * omp-low.c (determine_parallel_type): Don't try to optimize combined parallels if region-exit or region-inner-exit is NULL. (expand_omp_parallel): Handle NULL region-exit even if cfg is already built. (expand_omp_for_generic): Handle NULL region-cond and region-exit. (expand_omp_for): Use expand_omp_for_generic if either region-cond or region-exit is NULL. (expand_omp_sections): Handle NULL region-cond or region-exit. (expand_omp_synch): * gcc.dg/gomp/pr29965-1.c: New test. * gcc.dg/gomp/pr29965-2.c: New test. * gcc.dg/gomp/pr29965-3.c: New test. * gcc.dg/gomp/pr29965-4.c: New test. * gcc.dg/gomp/pr29965-5.c: New test. * gcc.dg/gomp/pr29965-6.c: New test. * g++.dg/gomp/pr29965-1.C: New test. * g++.dg/gomp/pr29965-2.C: New test. * g++.dg/gomp/pr29965-3.C: New test. * g++.dg/gomp/pr29965-4.C: New test. * g++.dg/gomp/pr29965-5.C: New test. * g++.dg/gomp/pr29965-6.C: New test. * g++.dg/gomp/pr29965-7.C: New test. * g++.dg/gomp/pr29965-8.C: New test. * g++.dg/gomp/pr29965-9.C: New test. * g++.dg/gomp/pr29965-10.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr29965-1.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-10.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-2.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-3.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-4.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-5.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-6.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-7.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-8.C trunk/gcc/testsuite/g++.dg/gomp/pr29965-9.C trunk/gcc/testsuite/gcc.dg/gomp/pr29965-1.c trunk/gcc/testsuite/gcc.dg/gomp/pr29965-2.c trunk/gcc/testsuite/gcc.dg/gomp/pr29965-3.c trunk/gcc/testsuite/gcc.dg/gomp/pr29965-4.c trunk/gcc/testsuite/gcc.dg/gomp/pr29965-5.c trunk/gcc/testsuite/gcc.dg/gomp/pr29965-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug middle-end/29965] OpenMP vs always throw in a loop
--- Comment #5 from jakub at gcc dot gnu dot org 2006-12-04 10:23 --- Subject: Bug 29965 Author: jakub Date: Mon Dec 4 10:23:06 2006 New Revision: 119484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119484 Log: PR middle-end/29965 * omp-low.c (determine_parallel_type): Don't try to optimize combined parallels if region-exit or region-inner-exit is NULL. (expand_omp_parallel): Handle NULL region-exit even if cfg is already built. (expand_omp_for_generic): Handle NULL region-cond and region-exit. (expand_omp_for): Use expand_omp_for_generic if either region-cond or region-exit is NULL. (expand_omp_sections): Handle NULL region-cond or region-exit. (expand_omp_synch): * gcc.dg/gomp/pr29965-1.c: New test. * gcc.dg/gomp/pr29965-2.c: New test. * gcc.dg/gomp/pr29965-3.c: New test. * gcc.dg/gomp/pr29965-4.c: New test. * gcc.dg/gomp/pr29965-5.c: New test. * gcc.dg/gomp/pr29965-6.c: New test. * g++.dg/gomp/pr29965-1.C: New test. * g++.dg/gomp/pr29965-2.C: New test. * g++.dg/gomp/pr29965-3.C: New test. * g++.dg/gomp/pr29965-4.C: New test. * g++.dg/gomp/pr29965-5.C: New test. * g++.dg/gomp/pr29965-6.C: New test. * g++.dg/gomp/pr29965-7.C: New test. * g++.dg/gomp/pr29965-8.C: New test. * g++.dg/gomp/pr29965-9.C: New test. * g++.dg/gomp/pr29965-10.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-1.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-10.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-2.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-4.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-5.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-6.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-7.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-8.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/gomp/pr29965-9.C branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-2.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-3.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-4.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-5.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/gomp/pr29965-6.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/omp-low.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug middle-end/29947] OpenMP parallel for fails for reversed loop range
--- Comment #2 from jakub at gcc dot gnu dot org 2006-12-04 10:26 --- Subject: Bug 29947 Author: jakub Date: Mon Dec 4 10:26:00 2006 New Revision: 119485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119485 Log: PR libgomp/29947 * omp-low.c (expand_omp_for_static_nochunk, expand_omp_for_static_chunk): Do all arithmetics in signed rather than unsigned type. * loop.c (gomp_loop_init): Make parameters signed. Set ws-end to start if there shouldn't be any loop iterations. (gomp_loop_ordered_static_start): Remove start == end test. * testsuite/libgomp.c/pr29947-1.c: New test. * testsuite/libgomp.c/pr29947-2.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr29947-1.c trunk/libgomp/testsuite/libgomp.c/pr29947-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog trunk/libgomp/loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug middle-end/29947] OpenMP parallel for fails for reversed loop range
--- Comment #3 from jakub at gcc dot gnu dot org 2006-12-04 10:30 --- Subject: Bug 29947 Author: jakub Date: Mon Dec 4 10:30:11 2006 New Revision: 119486 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119486 Log: PR libgomp/29947 * omp-low.c (expand_omp_for_static_nochunk, expand_omp_for_static_chunk): Do all arithmetics in signed rather than unsigned type. * loop.c (gomp_loop_init): Make parameters signed. Set ws-end to start if there shouldn't be any loop iterations. (gomp_loop_ordered_static_start): Remove start == end test. * testsuite/libgomp.c/pr29947-1.c: New test. * testsuite/libgomp.c/pr29947-2.c: New test. Added: branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr29947-1.c branches/gcc-4_2-branch/libgomp/testsuite/libgomp.c/pr29947-2.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/omp-low.c branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug middle-end/29965] OpenMP vs always throw in a loop
--- Comment #6 from jakub at gcc dot gnu dot org 2006-12-04 10:36 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29965
[Bug middle-end/29947] OpenMP parallel for fails for reversed loop range
--- Comment #4 from jakub at gcc dot gnu dot org 2006-12-04 10:36 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29947
[Bug fortran/29916] Dimension of a function result as host association does not work
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-04 11:16 --- Subject: Bug 29916 Author: burnus Date: Mon Dec 4 11:16:12 2006 New Revision: 119489 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119489 Log: fortran/ 2006-12-04 Paul Thomas [EMAIL PROTECTED] PR fortran/29916 * resolve.c (resolve_symbol): Allow host-associated variables in the specification expression of an array-valued function. * expr.c (check_restricted): Accept host-associated dummy array indices. testsuite/ 2006-12-04 Paul Thomas [EMAIL PROTECTED] PR fortran/29916 * gfortran.dg/host_dummy_index_1.f90: Added additional test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/host_dummy_index_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29916
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #21 from rearnsha at gcc dot gnu dot org 2006-12-04 11:26 --- We can't apply this patch to the 4.1 branch if it would mean users had to use CVS versions of binutils. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug c++/30062] New: g++ does not distinguish functions with C and C++ linkage
Hello, I noticed that if I give g++ the prototypes for bsearch as listed in the 2003 standard, it errors out saying that the 2 declarations conflict: extern C void *bsearch(const void *key, const void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *)); extern C++ void *bsearch(const void *key, const void *base, size_t nmemb, size_t size, int (*compar)(const void *, const void *)); The same is true for qsort. I believe the compiler is supposed to distinguish between the 2 versions according to the linkage of compar. Even if you don't want to distinguish functions according to linkage, g++ should be able to accept a declaration that is written in the standard. -- Summary: g++ does not distinguish functions with C and C++ linkage Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marc dot glisse at normalesup dot org GCC host triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30062
Re: gcj: ICE on gcj -c seda.jar
Shaun Jackman writes:
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
seda/sandStorm/internal/AggTPSThreadManager.java:328: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
The line the compiler mentions is...
$ cat -n ./seda/src/seda/sandStorm/internal/ATTIC/AggTPSThreadManager.java
...
25 package seda.sandStorm.internal;
...
44 class AggTPSThreadManager implements ThreadManagerIF,
sandStormConst {
45
46 private static final boolean DEBUG = true;
47 private static final boolean DEBUG_VERBOSE = false;
...
327 public void run() {
328 if (DEBUG) System.err.println(AggTPSTM Governor:
starting);
329
...
$ gcj --version |head -1
gcj (GCC) 4.1.2 20061020 (prerelease) (Debian 4.1.1-17)
The binary and source files in question may be downloaded from a Debian
archive:
http://packages.debian.org/testing/libs/libseda-java
Thanks. This is caused because
seda.sandStorm.internal.AggTPSThreadManager$governorThread is in the
file
seda/sandStorm/internal/ATTIC/AggTPSThreadManager$governorThread.class
(In other words, it's not where gcj expects to find it.)
This is a bug in gcj. We probably shouldn't even attempt to generate
code when a class is not in the right place in an archive, and exit
with a compiler error.
zip -d usr/share/java/seda.jar seda/sandStorm/internal/ATTIC/\*
solves the problem.
Andrew.
[Bug middle-end/30063] New: It would be useful for __attribute__((deprecated)) to take an optional parameter
People are probably more likely to fix their code if they're told how -- it
would be useful to have
void new_function() { }
void __attribute__((deprecated(use new_function instead)) old_function() { }
int main(int argc, char **argv) {
old_function();
}
resulting in
test.cpp: 6: warning: 'old_function' is deprecated (declared at test.cpp:2, use
new_function instead)
--
Summary: It would be useful for __attribute__((deprecated)) to
take an optional parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30063
[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-12-04 14:27 --- The bug is not fixed; the gcc.c patch has not been reviewed. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-12-04 14:37 --- Created an attachment (id=12740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12740action=view) preprocessed source The sub-command that fails using --save-temps -v is: /home/amylaar/bld/2006-11-27/sh-elf/./gcc/cc1 -fpreprocessed error.i -quiet -dumpbase error.c -auxbase-strip error.o -g -O2 -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -std=gnu99 -version -o error.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug target/29997] various targets: GCC fails to encode epilogues in unwind-info
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-12-04 14:51 --- (In reply to comment #1) I think this is really a dup of bug 12990. Sort of, but not quite. 12990 does no cover the exception handling aspects, but it claims that the problem persists target-independently for debug. But this is not a problem for ia64. Since we have now the target-independent infrastructure and one target port that uses it to handle this problem, this has become a target problem; each target needs to be adjusted separately to create the proper epilogue information, so it makes sense to track progress (or lack thereof) for each target individually, while having one meta-bug to keep track of them all. Should I mark 12990 as blocking 29997, and 29998 as blocking 12990? OTOH, when you read the description of 12990, it sounds like the problem exists only for i[3456]86-*-*, so maybe we should add this to the target field of 12990 and only make 12990 as blocking 29997. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29997
[Bug target/28516] [4.2 regression] arm_unwind_emit_set, at config/arm/arm.c:15419 with -fexceptions
--- Comment #22 from pbrook at gcc dot gnu dot org 2006-12-04 15:10 --- I disagree. All code that requires new gas would previously ICE. Any code that currently compiles with 4.1 should be unaffected. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
[Bug c++/30062] g++ does not distinguish functions with C and C++ linkage
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-04 15:54 --- *** This bug has been marked as a duplicate of 2316 *** -- marc dot glisse at normalesup dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30062
[Bug c++/2316] g++ fails to overload on language linkage
--- Comment #15 from marc dot glisse at normalesup dot org 2006-12-04 15:54 --- *** Bug 30062 has been marked as a duplicate of this bug. *** -- marc dot glisse at normalesup dot org changed: What|Removed |Added CC||marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/30060] Error/warning on invalid code (duplicate identifier for enum/class) should be more specific
--- Comment #3 from bangerth at dealii dot org 2006-12-04 16:11 --- Confirmed. While there may not be much that can be done at the place where the current error is reported, the warning is definitely a valid request. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-12-04 16:11:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30060
[Bug target/30064] New: ICE in reload_cse_simplify_operands, at postreload.c:393
$ m68k-linux-gcc -v -m5307 -msep-data -O1 -c gcc-m68k-ice.c
Using built-in specs.
Target: m68k-linux
Configured with: ../gcc-4.3-20061202/configure --prefix=/home/ssoe/tmp/m68k
--target m68k-linux --disable-shared --disable-threads --enable-languages=c
--with-headers=/home/ssoe/tmp/m68k/m68k-linux/include
Thread model: single
gcc version 4.3.0 20061202 (experimental)
/home/ssoe/tmp/m68k/libexec/gcc/m68k-linux/4.3.0/cc1 -quiet -v
-D__HAVE_68881__ gcc-m68k-ice.c -quiet -dumpbase gcc-m68k-ice.c -m5307
-msep-data -auxbase gcc-m68k-ice -O1 -version -o /tmp/cchI2eF1.s
#include ... search starts here:
#include ... search starts here:
/home/ssoe/tmp/m68k/lib/gcc/m68k-linux/4.3.0/include
/home/ssoe/tmp/m68k/lib/gcc/m68k-linux/4.3.0/../../../../m68k-linux/sys-include
/home/ssoe/tmp/m68k/lib/gcc/m68k-linux/4.3.0/../../../../m68k-linux/include
End of search list.
GNU C version 4.3.0 20061202 (experimental) (m68k-linux)
compiled by GNU C version 4.1.1 20061011 (Red Hat 4.1.1-30).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c0f3be0098cca37cfe39087e559a1e7c
gcc-m68k-ice.c: In function f:
gcc-m68k-ice.c:28: error: insn does not satisfy its constraints:
(insn 81 205 207 9 (parallel [
(set (reg:SI 2 %d2)
(div:SI (reg:SI 2 %d2)
(mem/c:SI (plus:SI (reg/f:SI 14 %a6)
(reg:SI 9 %a1)) [0 column_width+0 S4 A8])))
(set (reg:SI 0 %d0 [80])
(mod:SI (reg:SI 2 %d2)
(mem/c:SI (plus:SI (reg/f:SI 14 %a6)
(reg:SI 9 %a1)) [0 column_width+0 S4 A8])))
]) 228 {*m68k.md:3000} (nil)
(nil))
gcc-m68k-ice.c:28: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
If any of the options -m5307, -msep-data, or -O1 is removed, the problem goes
away.
Reproduced on 4.1.1, 4.1-20061124, 4.2-20061128, 4.3-20061202. Couldn't
reproduce ICE on 3.4.6, but it could be generating incorrect code (no solid
evidence of that though).
--
Summary: ICE in reload_cse_simplify_operands, at postreload.c:393
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ssoe at kirktelecom dot com
GCC build triplet: i686-redhat-linux-gnu
GCC host triplet: i686-redhat-linux-gnu
GCC target triplet: m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30064
[Bug target/30064] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #1 from ssoe at kirktelecom dot com 2006-12-04 16:42 --- Created an attachment (id=12741) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12741action=view) Testcase Reduced version of shell/cmdedit.c from busybox-1.2.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30064
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #20 from sgk at troutmask dot apl dot washington dot edu 2006-12-04 16:44 --- Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library On Mon, Dec 04, 2006 at 09:09:51AM -, pault at gcc dot gnu dot org wrote: (In reply to comment #17) Created an attachment (id=12735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12735action=view) [edit] Compilable version of previous patch. FX and Eric, Thanks for plugging the hole there. If I've read the above patch correctlu, then it doesn't properly plugged the hole. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #21 from sgk at troutmask dot apl dot washington dot edu 2006-12-04 16:46 --- Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library On Mon, Dec 04, 2006 at 09:22:10AM -, ebotcazou at gcc dot gnu dot org wrote: Note that I'm complaining about one very specific issue, which is the implicit dependencies on C99 that regularly creep through the library. This one can be easily simulated by butchering the configure script. AFAIK, libgfortran has also assumed a C99 compiler/library is available (even though gcc isn't C99 compliant). You'd need to ping pbrook or stevenb about the details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
Re: gcj: ICE on gcj -c seda.jar
On 12/4/06, Andrew Haley [EMAIL PROTECTED] wrote: Thanks. This is caused because seda.sandStorm.internal.AggTPSThreadManager$governorThread is in the file seda/sandStorm/internal/ATTIC/AggTPSThreadManager$governorThread.class (In other words, it's not where gcj expects to find it.) This is a bug in gcj. We probably shouldn't even attempt to generate code when a class is not in the right place in an archive, and exit with a compiler error. zip -d usr/share/java/seda.jar seda/sandStorm/internal/ATTIC/\* solves the problem. Thanks, Andrew. I thought that ATTIC directory looked a little suspicious. Cheers, Shaun
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-12-04 17:06 --- AFAIK, libgfortran has also assumed a C99 compiler/library is available (even though gcc isn't C99 compliant). You'd need to ping pbrook or stevenb about the details. s/also/always? In either case, that's not true, the 4.1.1 compiler works fine on Solaris 2.5.1, which is not C99 compliant at all, while 4.1.2pre is broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #23 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 17:40 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in
libgfortran shared library
On Mon, Dec 04, 2006 at 05:06:37PM -, ebotcazou at gcc dot gnu dot org
wrote:
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-12-04 17:06
---
AFAIK, libgfortran has also assumed a C99 compiler/library is
available (even though gcc isn't C99 compliant). You'd need to
ping pbrook or stevenb about the details.
s/also/always? In either case, that's not true, the 4.1.1 compiler works fine
on Solaris 2.5.1, which is not C99 compliant at all, while 4.1.2pre is broken.
Yes, always. Ping pbrook or stevenb. c99_function.c was
included to provide missing c99 routines on platforms that
needed them. 4.1.1 worked because people were careful with
adding missing functions. For example, I added round[f,l].
When rth fixed gfortran's determination of kind types,
gfortran suddenly grew real(10) or real(16) on many
platforms. It is assumed that the *l math functions
are available (e.g., cosl()). These math functions aren't
available on {Free,Open,Net}BSD, which I've been slowly
implementing under the 2-clause BSD license.
BTW, the patch should use libgfortran's internal round[f,l]
functions to avoid the significant loss of precision in
the current patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29916] [4.1 and 4.2 only] Dimension of a function result as host association does not work
--- Comment #6 from pault at gcc dot gnu dot org 2006-12-04 17:53 --- (In reply to comment #5) Subject: Bug 29916 Tobias, Thank you! I had a bit of a surprise when I tried, a few minutes ago, to apply the patch... I thought that I was going even madder than usual, when it came back with the information that there was an unreversed patch in place! I suppose that this should float down to 4.2 before it is cleared? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29916
[Bug c++/29632] [4.0/4.1/4.2/4.3 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-12-04 18:00 --- Subject: Bug 29632 Author: mmitchel Date: Mon Dec 4 18:00:32 2006 New Revision: 119499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119499 Log: PR c++/29632 * call.c (add_builtin_candidate): Do not permit NULL pointer constants to be compared with template parameters. PR c++/29632 * g++.dg/template/error23.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/error23.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug fortran/29916] [4.1 and 4.2 only] Dimension of a function result as host association does not work
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-04 18:05 --- Thank you! I had a bit of a surprise when I tried, a few minutes ago, to apply the patch... I thought that I was going even madder than usual, when it came back with the information that there was an unreversed patch in place! I thought you saw the submission email (autoattached to this PR and thus also in your mailbox). I suppose that this should float down to 4.2 before it is cleared? Yes -- and maybe also to 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29916
[Bug c++/29733] [4.1/4.2/4.3 regression] ICE on initialization of function type
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-04 18:08 --- Subject: Bug 29733 Author: mmitchel Date: Mon Dec 4 18:08:11 2006 New Revision: 119500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119500 Log: PR c++/29733 * pt.c (tsubst_decl): Disallow variables of function type. PR c++/29733 * g++.dg/template/crash61.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash61.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #4 from pcarlini at suse dot de 2006-12-04 18:23 --- Damn windows.h ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug c++/14329] [4.1/4.2 only] badly formatted warnings for SRA replacements used uninitialized
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-12-04 18:32 --- Subject: Bug 14329 Author: pinskia Date: Mon Dec 4 18:31:40 2006 New Revision: 119501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119501 Log: 2006-12-04 Richard Henderson [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR C++/14329 * error.c (cp_printer) 'D': Handle DECL_DEBUG_EXPR. 2006-12-04 Richard Henderson [EMAIL PROTECTED] Andrew Pinski [EMAIL PROTECTED] PR C++/14329 * g++.dg/warn/unit-1.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/warn/unit-1.C - copied unchanged from r119478, trunk/gcc/testsuite/g++.dg/warn/unit-1.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/error.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14329
[Bug fortran/29916] [4.1 and 4.2 only] Dimension of a function result as host association does not work
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-12-04 18:38 --- Subject: Re: [4.1 and 4.2 only] Dimension of a function result as host association does not work Tobias, t you saw the submission email (autoattached to this PR and thus also in your mailbox). As I said yesterday, I am trying keep the ia64 clean of email :-) I just saw your message now. Thanks a lot! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29916
[Bug libstdc++/29989] missed #undef min/max in limits
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-04 18:41:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug rtl-optimization/30065] New: Could use indexed addressing to reduce const costs
Sometimes constants could be replaced by smaller, cheaper constants by making use of scaled indices. -- Summary: Could use indexed addressing to reduce const costs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-12-04 19:14 --- Created an attachment (id=12742) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12742action=view) tentative patch This patch implements this optimization, although it could be improved to consider more possible scaling factors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
[Bug c++/30066] New: option to make inline functions hidden
A user would like an option to mark all inline functions (foo in this case):
extern void bar();
inline void foo() { bar(); }
void doit() { foo(); }
as hidden, kinda like what -fvisibility-inlines-hidden does for inline methods.
I gather this is so that runtime binding is limited to make startup faster and
to improve codegen.
--
Summary: option to make inline functions hidden
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066
[Bug c++/30066] option to make inline functions hidden
--- Comment #1 from mrs at apple dot com 2006-12-04 19:27 --- radr://4405938 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066
[Bug fortran/29821] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:666ans-types.c:666
--- Comment #7 from pault at gcc dot gnu dot org 2006-12-04 19:30 --- Subject: Bug 29821 Author: pault Date: Mon Dec 4 19:30:33 2006 New Revision: 119504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119504 Log: 2006-12-04 Paul Thomas [EMAIL PROTECTED] PR fortran/29821 * resolve.c (resolve_operator): Only return result of gfc_simplify_expr if expression is constant. 2006-12-04 Paul Thomas [EMAIL PROTECTED] PR fortran/29821 * gfortran.dg/parameter_array_section_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_section_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29821
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-04 20:03 --- Subject: Bug 29962 Author: burnus Date: Mon Dec 4 20:02:43 2006 New Revision: 119505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119505 Log: fortran/ 2006-12-04 Tobias Burnus [EMAIL PROTECTED] PR fortran/29962 * expr.c (check_intrinsic_op): Allow noninteger exponents for F2003. testsuite/ 2006-12-04 Tobias Burnus [EMAIL PROTECTED] PR fortran/29962 * initialization_4.f90: Test noninteger exponents (-std=f95). * initialization_5.f90: New test for noninteger exponents with -std=f2003 Added: trunk/gcc/testsuite/gfortran.dg/initialization_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/30003] Expressions with side effects in array references
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-04 20:47 --- (In reply to comment #1) I thought I would have time to do something about this bug, but I will not; not in the next few weeks/months. I therefore unassign it from me. My appologies to those who expected to be fixed soon. That's a pity, Erik, but quite understandable. I started playing with it at lunchtime. It's quite an amusing little PR! As running the test below shows, an array reference 'start' or 'stride' is always handled correctly, whereas the 'end' is always handled incorrectly. This suggests that the way to fix this is to add an 'end' field to gfc_ss_info and to treat it exactly like start, even if it is not used in the scalarizer. Paul implicit none integer :: a(5), b(3), cnt b = [ 1, 2, 3 ] cnt = 0 a(bar(1):3) = b print *, a(start) = , cnt, calls cnt = 0 a(1:bar(3)) = b print *, a(end) = , cnt, calls cnt = 0 a(1:3:bar(1)) = b print *, a(stride) = , cnt, calls cnt = 0 a(1:3) = b(bar(1):3) print *, b(start) = , cnt, calls cnt = 0 a(1:3) = b(1:bar(3)) print *, b(end) = , cnt, calls cnt = 0 a(1:3) = b(1:3:bar(1)) print *, b(stride) = , cnt, calls contains integer function bar(n) integer, intent(in) :: n cnt = cnt + 1 bar = n end function bar end program foo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-12-04 20:54
---
Yes, always. Ping pbrook or stevenb. c99_function.c was
included to provide missing c99 routines on platforms that
needed them. 4.1.1 worked because people were careful with
adding missing functions. For example, I added round[f,l].
I know, I added trunc and truncf.
When rth fixed gfortran's determination of kind types,
gfortran suddenly grew real(10) or real(16) on many
platforms. It is assumed that the *l math functions
are available (e.g., cosl()). These math functions aren't
available on {Free,Open,Net}BSD, which I've been slowly
implementing under the 2-clause BSD license.
You cannot unilaterally decide that the Fortran compiler will suddenly
stop working on non C99-platforms, I think it's a SC-level decision.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #24 from pault at gcc dot gnu dot org 2006-12-04 20:55 --- OK, I'll put this in the pipeline for clean-up and submission. Paul However, one gets neither a warning nor an error for the following test case, which can be found in the Fortran 2003 standard, Section C.11.2: Would you raise a PR for BAD8 please, Tobias? It is quite separate from the issue with CP2K but it is 'BAD' stuff! I think that I know how to fix it but it will have to be another day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug c/30067] New: use of thread local storage causes code generator to fail
The following code fragment fails on gcc i386 3.4.5-2, but works on 4.0.
Compilation terminates normally when field x is removed from structure
declaration S.
The fragment is simple enough, but I could not find an open bug description for
it.
struct S
{
char x;
unsigned char v[2];
};
static __thread struct S G1;
void test_local (int i)
{
(((unsigned char *) G1.v)[i]) = ((unsigned char) 170U);
}
--
$ uname -a
Linux 2.4.21-37.ELhugemem #1 SMP Sat Nov 26 12:13:22 EST 2005 i686 athlon i386
GNU/Linux
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-49)
$ gcc x.c
x.c: In function `test_local':
x.c:17: unrecognizable insn:
(insn 9 17 11 (set (reg/f:SI 59)
(const:SI (plus:SI (symbol_ref:SI (%lG1))
(const_int 1 [0x1] -1 (nil)
(expr_list:REG_EQUAL (const:SI (plus:SI (symbol_ref:SI (%lG1))
(const_int 1 [0x1])))
(nil)))
x.c:17: Internal compiler error in extract_insn, at recog.c:2149
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla/ for instructions.
Preprocessed source stored into /tmp/cc6v1K6v.out file, please attach this to
your bugreport.
--
$ uname -a
Linux 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 athlon i386
GNU/Linux
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
$ gcc x.c
x.c: In function `test_local':
x.c:17: error: unrecognizable insn:
(insn 8 15 9 0 (set (reg/f:SI 59)
(const:SI (plus:SI (symbol_ref:SI (G1) [flags 0x22] var_decl
0xb7c69288 G1)
(const_int 1 [0x1] -1 (nil)
(nil))
x.c:17: internal compiler error: in extract_insn, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
--
Summary: use of thread local storage causes code generator to
fail
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: juulvanderspek at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30067
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #5 from paolo at gcc dot gnu dot org 2006-12-04 21:12 --- Subject: Bug 29989 Author: paolo Date: Mon Dec 4 21:11:52 2006 New Revision: 119510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119510 Log: 2006-12-04 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29989 (again) * include/bits/c++config: #undef min and max. * testsuite/18_support/numeric_limits/29989.cc: New. Added: trunk/libstdc++-v3/testsuite/18_support/numeric_limits/29989.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/c++config -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug fortran/30068] New: Ambigous interfaces not detected
Examples taken from the Fortran 2003 standard, Section C.11.2. They are not recognized as invalid. * * * INTERFACE BAD8 ! this interface is invalid ! ! despite the fact that it is unambiguous ! SUBROUTINE S8A(X,Y,Z) REAL,OPTIONAL :: X INTEGER :: Y REAL :: Z END SUBROUTINE S8A SUBROUTINE S8B(X,Z,Y) INTEGER,OPTIONAL :: X INTEGER :: Z REAL :: Y END SUBROUTINE S8B END INTERFACE BAD8 This interface fails rule (3) because there are no required arguments that can be distinguished from the positionally corresponding argument, but in order for the mismatch of the optional arguments not to be relevant, the later arguments must be specified as keyword arguments, so distinguishing by name does the trick. This interface is nevertheless invalid so a standard-conforming Fortran processor is not required to do such reasoning. The rules to cover all cases are too complicated to be useful. * * * module x INTERFACE BAD9 ! this interface is invalid ! ! despite the fact that it is unambiguous ! SUBROUTINE S9A(X) REAL :: X END SUBROUTINE S9A SUBROUTINE S9B(X) INTERFACE FUNCTION X(A) REAL :: X,A END FUNCTION X END INTERFACE END SUBROUTINE S9B SUBROUTINE S9C(X) INTERFACE FUNCTION X(A) REAL :: X INTEGER :: A END FUNCTION X END INTERFACE END SUBROUTINE S9C END INTERFACE BAD9 end module x The real data objects that would be valid arguments for S9A are entirely disjoint from procedures that are valid arguments to S9B and S9C, and the procedures that valid arguments for S9B are disjoint from the procedures that are valid arguments to S9C because the former are required to accept real arguments and the latter integer arguments. Again, this interface is invalid, so a standard-conforming Fortran processor need not examine such properties when deciding whether a generic collection is valid. Again, the rules to cover all cases are too complicated to be useful. -- Summary: Ambigous interfaces not detected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug libstdc++/29989] missed #undef min/max in limits
--- Comment #6 from pcarlini at suse dot de 2006-12-04 21:12 --- Finally fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29989
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04
21:13 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in
libgfortran shared library
When rth fixed gfortran's determination of kind types,
gfortran suddenly grew real(10) or real(16) on many
platforms. It is assumed that the *l math functions
are available (e.g., cosl()). These math functions aren't
available on {Free,Open,Net}BSD, which I've been slowly
implementing under the 2-clause BSD license.
You cannot unilaterally decide that the Fortran compiler will suddenly
stop working on non C99-platforms, I think it's a SC-level decision.
I support Eric on this.
I suspect the determination of kind types is at least partially broken
since both 32 and 64-bit PA targets on hpux have support for 128-bit
long doubles. However, I'm only seeing the fmodl problem on the 64-bit
target.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #25 from burnus at gcc dot gnu dot org 2006-12-04 21:15 --- OK, I'll put this in the pipeline for clean-up and submission. Thanks. At least the generic interface patch should be completely ok; for the other one, I'll try to dream up something which is not correctly covered (if any). Would you raise a PR for BAD8 please, Tobias? It is quite separate from the issue with CP2K but it is 'BAD' stuff! I think that I know how to fix it but it will have to be another day. Filled as PR30068, I realized it immediately after I hit submit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug rtl-optimization/29840] [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump)
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 21:26 --- Subject: Re: [4.3 Regression] build/genconditions ../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 Memory fault(coredump) I will test on a cross if it fixes the failure on hppa. It seemed not to be necessary on the trunk (it fixed a very early bootstrapping failure on x86-linux, as soon as building stage1 libgcc). It fixes the hppa failure. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. I've attached the change tested. Dave --- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 21:26 --- Created an attachment (id=12743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12743action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
[Bug libgomp/29949] implement argument checking for user accessable runtime routines
--- Comment #3 from dfranke at gcc dot gnu dot org 2006-12-04 21:35 --- Subject: Bug 29949 Author: dfranke Date: Mon Dec 4 21:35:19 2006 New Revision: 119511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119511 Log: PR libgomp/29949 * env.c (omp_set_num_threads): Set illegal thread count to 1. Modified: trunk/libgomp/ChangeLog trunk/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 21:37 ---
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in
libgfortran shared library
On Mon, Dec 04, 2006 at 08:54:40PM -, ebotcazou at gcc dot gnu dot org
wrote:
When rth fixed gfortran's determination of kind types,
gfortran suddenly grew real(10) or real(16) on many
platforms. It is assumed that the *l math functions
are available (e.g., cosl()). These math functions aren't
available on {Free,Open,Net}BSD, which I've been slowly
implementing under the 2-clause BSD license.
You cannot unilaterally decide that the Fortran compiler will suddenly
stop working on non C99-platforms, I think it's a SC-level decision.
Hopefully, that is a generic you because I haven't decided
anything. In fact, I requested that pault or fx backout the
offending patch. See
http://gcc.gnu.org/ml/fortran/2006-11/msg00523.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/29632] [4.0/4.1/4.2 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-04 22:14 --- Subject: Bug 29632 Author: mmitchel Date: Mon Dec 4 22:14:42 2006 New Revision: 119512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119512 Log: PR c++/29632 * call.c (add_builtin_candidate): Do not permit NULL pointer constants to be compared with template parameters. PR c++/29632 * g++.dg/template/error23.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/error23.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/call.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug c++/29733] [4.1/4.2 regression] ICE on initialization of function type
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-04 22:15 --- Subject: Bug 29733 Author: mmitchel Date: Mon Dec 4 22:15:24 2006 New Revision: 119513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119513 Log: PR c++/29733 * pt.c (tsubst_decl): Disallow variables of function type. PR c++/29733 * g++.dg/template/crash61.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/crash61.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug c++/29632] [4.0/4.1 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-12-04 22:16 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1 Regression] ICE on |on invalid code:|invalid code: |regenerate_decl_from_templat|regenerate_decl_from_templat |e, at cp/pt.c:10969 |e, at cp/pt.c:10969 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2006-12-04 22:18 --- Hopefully, that is a generic you because I haven't decided anything. In fact, I requested that pault or fx backout the offending patch. See http://gcc.gnu.org/ml/fortran/2006-11/msg00523.html Thanks for doing this. Note that we would need fmodf too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/30069] New: gcc rejects valid default template parameter
The test case below declares 3 global functions with exactly the
same signature, and another 3 member functions with the same signature.
The last of these is incorrectly rejected.
$ cat junk.cc
#include vector
using namespace std;
void foo11(const vectorchar = vectorchar());
void foo12(const vector char, allocator char=
vector char ());
void foo13(const vector char, allocator char=
vector char, allocator char ());
struct Foo {
void foo21(const vectorchar = vectorchar());
void foo22(const vector char, allocator char=
vector char ());
void foo23(const vector char, allocator char=
vector char, allocator char ());
};
$ /usr/local/gcc-4.3-20061104/bin/g++ -c junk.cc
junk.cc:16: error: expected ',' or '...' before '' token
junk.cc:16: error: template argument 1 is invalid
junk.cc:16: error: template argument 2 is invalid
junk.cc:16: error: default argument missing for parameter 2 of 'void
Foo::foo23(const std::vectorchar, std::allocatorchar ,
std::allocatorchar)'
--
Summary: gcc rejects valid default template parameter
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at charter dot net
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=30069
[Bug fortran/30003] Expressions with side effects in array references
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-04 22:44 --- Created an attachment (id=12744) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12744action=view) A fix for this PR This is most of the way there, using the idea in #2; except that, for reasons I do not understand, allocatable_function_1.f90 emits an extra gfc_internal_free. Erik, if you have a moment, could you see if you can understand where the extra free comes from? Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30003
[Bug c++/30069] gcc rejects valid default template parameter
--- Comment #1 from ppluzhnikov at charter dot net 2006-12-04 22:46 ---
It turns out that I've already seen this bug in MSVC-6.0,
and found a workaround.
This parses fine (note extra parenthesis) with gcc-3.4.0 and above:
struct Foo {
void foo23(const vector char, allocator char=
(vector char, allocator char ()));
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30069
[Bug fortran/30068] Ambigous interfaces not detected
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-04 22:46:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug c++/30069] gcc rejects valid default template parameter
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-04 22:51 --- This is not really a bug but a questionable one in the C++ standard. anyways this is a dup of bug 57. *** This bug has been marked as a duplicate of 57 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30069
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #32 from pinskia at gcc dot gnu dot org 2006-12-04 22:51 --- *** Bug 30069 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ppluzhnikov at charter dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug libfortran/29810] [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library
--- Comment #28 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-04 22:52 --- Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol fmodl in libgfortran shared library I suspect the determination of kind types is at least partially broken since both 32 and 64-bit PA targets on hpux have support for 128-bit long doubles. However, I'm only seeing the fmodl problem on the 64-bit target. I investigated the above a bit more and it seems to be an issue with the 32-bit linker. It's no longer printing warnings about unsatisfied shared library symbols unless I add -Wl,-v to the command. Then, I see the following: /usr/ccs/bin/ld: Unsatisfied shared library symbols: fmodl (first referenced in /home/gnu/gcc/objdir/hppa2.0w-hp-hpux11.00/./libgfortran/.libs/libgfortran.sl) (code) So, it's not a problem with determination of kind types. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
[Bug c++/29733] [4.1 regression] ICE on initialization of function type
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-04 23:20 --- Subject: Bug 29733 Author: mmitchel Date: Mon Dec 4 23:19:56 2006 New Revision: 119516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119516 Log: PR c++/29733 * pt.c (tsubst_decl): Disallow variables of function type. PR c++/29733 * g++.dg/template/crash61.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash61.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug c++/29733] [4.1 regression] ICE on initialization of function type
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29733
[Bug target/25295] unused register saved in function prolog
--- Comment #3 from michael dot meissner at amd dot com 2006-12-04 23:21 --- I've done some analysis on the test case. The current GCC 4.2 and mainline branches no longer generate the initial push of %r8, but instead do a subq $8,%rsp. I believe in the compiler you used it did the push to allocate 8 bytes of stack instead of the subtract. Note, the epilogue still uses a pop to remove the stack location. The core of the problem is that the compiler is allocating 8 bytes too much stack in this particular case. I think I understand whats going on, but I want to dig a bit more. -- michael dot meissner at amd dot com changed: What|Removed |Added CC||michael dot meissner at amd ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25295
[Bug c++/29632] [4.0/4.1 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21 --- Subject: Bug 29632 Author: mmitchel Date: Mon Dec 4 23:21:03 2006 New Revision: 119517 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119517 Log: PR c++/29632 * call.c (add_builtin_candidate): Do not permit NULL pointer constants to be compared with template parameters. PR c++/29632 * g++.dg/template/error23.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/error23.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/call.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug c++/29632] [4.0 Regression] ICE on invalid code: regenerate_decl_from_template, at cp/pt.c:10969
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-04 23:21 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 Regression] ICE on |[4.0 Regression] ICE on |invalid code: |invalid code: |regenerate_decl_from_templat|regenerate_decl_from_templat |e, at cp/pt.c:10969 |e, at cp/pt.c:10969 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29632
[Bug fortran/30034] pure subroutine requires intent for procedure argument
--- Comment #1 from pault at gcc dot gnu dot org 2006-12-04 23:31 --- Created an attachment (id=12745) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12745action=view) A fix for this PR Regtests on Cygwin_NT/amd64 -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30034
[Bug c/30051] Current gcc gets error compiling glibc with -std=gnu99
--- Comment #2 from ron3763 at msn dot com 2006-12-04 23:55 --- (In reply to comment #1) This is a bug in glibc. The mainline changed the way it handles inline to be the C99 way. Also see: http://sourceware.org/ml/libc-hacker/2006-11/msg1.html Ok, I read his patch, so are you telling me(us), to use the latest gcc-4.3, we have to grab glibc/libc6 CVS sources? I have done that, but haven't compiled against it yet. -- ron3763 at msn dot com changed: What|Removed |Added CC||ron3763 at msn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30051
[Bug libfortran/30005] Open errors (not/already exists etc.): show also the file name
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-12-05 00:51 --- Subject: Bug 30005 Author: jvdelisle Date: Tue Dec 5 00:51:26 2006 New Revision: 119530 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119530 Log: 2006-12-04 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/30005 * io/open.c: Add errno.h include. (new_unit): Add new error messages with file name for file open. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30005
Bizarre inlining type promotion effect
In the code snippet below, the function mul_8_8 compiles to use
exactly one `mul' instruction on the AVR. The function mul_16_8 calls
mul_8_8 twice. If mul_8_8 is a static inline function and inlined in
mul_16_8, each call generates three `mul' instructions! Why does
inlining mul_8_8 cause each 8x8 multiplication to be promoted to a
16x16 multiplication?
It seems that the inlining mechanism has a real bug if inlining can
cause such a major change in the code generated for a given function.
Cheers,
Shaun
$ avr-gcc --version |head -1
avr-gcc (GCC) 4.1.0
$ cat mul.c
#include stdint.h
static uint16_t mul_8_8(uint8_t a, uint8_t b)
{
return a * b;
}
uint32_t mul_16_8(uint16_t a, uint8_t b)
{
uint8_t a0 = a, a1 = a 8;
return ((uint32_t)mul_8_8(a1, b) 8) + mul_8_8(a0, b);
}
$ avr-gcc -c -g -O2 -mmcu=avr4 mul.c
$ avr-objdump -d mul.o
mul.o: file format elf32-avr
Disassembly of section .text:
mul_8_8:
0:86 9f mul r24, r22
2:c0 01 movwr24, r0
4:11 24 eor r1, r1
6:08 95 ret
0008 mul_16_8:
8:bf 92 pushr11
a:cf 92 pushr12
c:df 92 pushr13
e:ef 92 pushr14
10:ff 92 pushr15
12:0f 93 pushr16
14:1f 93 pushr17
16:6c 01 movwr12, r24
18:b6 2e mov r11, r22
1a:8d 2d mov r24, r13
1c:99 27 eor r25, r25
1e:f0 df rcall .-32; 0x0 mul_8_8
20:7c 01 movwr14, r24
22:00 27 eor r16, r16
24:11 27 eor r17, r17
26:10 2f mov r17, r16
28:0f 2d mov r16, r15
2a:fe 2c mov r15, r14
2c:ee 24 eor r14, r14
2e:6b 2d mov r22, r11
30:8c 2d mov r24, r12
32:e6 df rcall .-52; 0x0 mul_8_8
34:aa 27 eor r26, r26
36:bb 27 eor r27, r27
38:e8 0e add r14, r24
3a:f9 1e adc r15, r25
3c:0a 1f adc r16, r26
3e:1b 1f adc r17, r27
40:c8 01 movwr24, r16
42:b7 01 movwr22, r14
44:1f 91 pop r17
46:0f 91 pop r16
48:ff 90 pop r15
4a:ef 90 pop r14
4c:df 90 pop r13
4e:cf 90 pop r12
50:bf 90 pop r11
52:08 95 ret
$ sed -i 's/static/ inline/' mul.c
$ avr-gcc -c -g -O2 -mmcu=avr4 mul.c
$ avr-objdump -d mul.o
mul.o: file format elf32-avr
Disassembly of section .text:
mul_16_8:
0:ac 01 movwr20, r24
2:26 2f mov r18, r22
4:33 27 eor r19, r19
6:89 2f mov r24, r25
8:99 27 eor r25, r25
a:82 9f mul r24, r18
c:b0 01 movwr22, r0
e:83 9f mul r24, r19
10:70 0d add r23, r0
12:92 9f mul r25, r18
14:70 0d add r23, r0
16:11 24 eor r1, r1
18:88 27 eor r24, r24
1a:99 27 eor r25, r25
1c:98 2f mov r25, r24
1e:87 2f mov r24, r23
20:76 2f mov r23, r22
22:66 27 eor r22, r22
24:55 27 eor r21, r21
26:f9 01 movwr30, r18
28:e4 9f mul r30, r20
2a:90 01 movwr18, r0
2c:e5 9f mul r30, r21
2e:30 0d add r19, r0
30:f4 9f mul r31, r20
32:30 0d add r19, r0
34:11 24 eor r1, r1
36:44 27 eor r20, r20
38:55 27 eor r21, r21
3a:62 0f add r22, r18
3c:73 1f adc r23, r19
3e:84 1f adc r24, r20
40:95 1f adc r25, r21
42:08 95 ret
Re: Bizarre inlining type promotion effect
On 12/4/06, Shaun Jackman [EMAIL PROTECTED] wrote: In the code snippet below, the function mul_8_8 compiles to use exactly one `mul' instruction on the AVR. The function mul_16_8 calls mul_8_8 twice. If mul_8_8 is a static inline function and inlined in ... For comparison, a hand-coded 16x8 multiply function requires 11 instructions. Cheers, Shaun mul_16_8: mul r25, r22 mov r23, r0 mov r25, r1 mul r24, r22 eor r24, r24 mov r22, r0 add r23, r1 adc r24, r25 eor r25, r25 eor r1, r1 ret
[Bug c++/26943] [gomp] firstprivate not working properly with non-POD
--- Comment #11 from bergner at vnet dot ibm dot com 2006-12-05 02:06 --- The testcase pr26943-2.c fails intermittently for me using unpatched mainline. Is anyone else seeing that? I'm building on powerpc64-linux with -m32. If I run it a few times, it mainly passes, but every once in a while, I get the error below: (gdb) run Starting program: /home/bergner/gcc/indexed_load_store/build/gcc-mainline-rtlanal/powerpc64-linux/libgomp/testsuite/pr26943-2.exe Breakpoint 1 at 0x100111b4 [Thread debugging using libthread_db enabled] [New Thread 1074060096 (LWP 29281)] Breakpoint 1 at 0xfe04344 [New Thread 1082451136 (LWP 29282)] [New Thread 1090839744 (LWP 29283)] [New Thread 1099228352 (LWP 29284)] [Switching to Thread 1074060096 (LWP 29281)] Breakpoint 1, 0x0fe04344 in abort () from /lib/tls/libc.so.6 (gdb) where #0 0x0fe04344 in abort () from /lib/tls/libc.so.6 #1 0x16b8 in main () at /home/bergner/gcc/indexed_load_store/gcc-mainline-rtlanal/libgomp/testsuite/libgomp.c/pr26943-2.c:45 (gdb) list 42 37if (e[0] != 'a' + 6 || f[0] != 'b' + i || g[0] != 'g' + i) 38 j += 64; 39if (h[0] != 'h' + i) 40 j += 512; 41 } 42if (j || a != 8 + 6 || b != 12 || c != 3 || d != 20) 43 abort (); 44if (e[0] != 'a' + 6 || f[0] != 'b' || g[0] != 'g' + 3 || h[0] != 'd') 45 abort (); 46return 0; (gdb) p e[0] $10 = 101 'e' (gdb) p f[0] $11 = 98 'b' (gdb) p g[0] $12 = 106 'j' (gdb) p h[0] $13 = 100 'd' -- bergner at vnet dot ibm dot com changed: What|Removed |Added CC||bergner at vnet dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26943
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #30 from bergner at vnet dot ibm dot com 2006-12-05 04:22
---
Ok, the problem from comment #28 was due to a latent bug in
reload1.c:eliminate_regs_in_insn(). The bug is that eliminate_regs_in_insn()
calls single_set() on the passed in insn. This has been fine before, but now
with the patch, we end up passing in a parallel insn for a load with update and
the load portion of the parallel has the REG_UNUSED flag set. This causes
single_set() to return the update portion of the parallel instead of
returning NULL as it would do normally with parallels. This causes us to only
eliminate the update portion of the parallel and we skip eliminating the load
portion. The problem insn belfore eliminate_regs_in_insn() looks like:
(insn 12 62 13 2 (parallel [
(set (reg:SI 0 0 [125])
(mem/s/j:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [0 S4 A32]))
(set (reg/f:SI 9 9 [orig:124 D.965 ] [124])
(plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])))
]) 373 {*movsi_update1} (nil)
(expr_list:REG_UNUSED (reg:SI 0 0 [125])
(nil)))
After eliminate_regs_in_insn(), we have:
(insn 12 62 13 2 (parallel [
(set (reg:SI 0 0 [125])
(mem/s/j:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 8 [0x8])) [0 S4 A32]))
(set (reg/f:SI 9 9 [orig:124 D.965 ] [124])
(plus:SI (reg/f:SI 1 1)
(const_int 8 [0x8])))
]) 373 {*movsi_update1} (nil)
(expr_list:REG_UNUSED (reg:SI 0 0 [125])
(nil)))
However, calculate_needs_all_insns() ends up backing out the eliminated
(reg/f:SI 1 1) with the non eliminated (reg/f:SI 113 sfp) and (reg/f:SI 113
sfp) never gets eliminated after that and we generate bogus assembler.
In addition to the latest patch attached here, I added the following patch to
stop eliminate-regs_in_insn from calling single_set for parallel insns. It
fixed the bug here and bootstrapped and regtested with no errors. I'll post
the combined patch to gcc-patches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #31 from bergner at vnet dot ibm dot com 2006-12-05 04:41
---
...and here's the patch I mentioned in the previous comment:
Index: reload1.c
===
--- reload1.c (revision 119497)
+++ reload1.c (working copy)
@@ -2930,7 +2930,7 @@ eliminate_regs_in_insn (rtx insn, int re
int icode = recog_memoized (insn);
rtx old_body = PATTERN (insn);
int insn_is_asm = asm_noperands (old_body) = 0;
- rtx old_set = single_set (insn);
+ rtx old_set;
rtx new_body;
int val = 0;
int i;
@@ -2949,6 +2949,12 @@ eliminate_regs_in_insn (rtx insn, int re
return 0;
}
+ /* Guard against a PARALLEL with a REG_UNUSED note. */
+ if (GET_CODE (PATTERN (insn)) != PARALLEL)
+old_set = single_set (insn);
+ else
+old_set = 0;
+
if (old_set != 0 REG_P (SET_DEST (old_set))
REGNO (SET_DEST (old_set)) FIRST_PSEUDO_REGISTER)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
