[Bug bootstrap/24998] New: Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf
Undefined first referenced symbol in file __floatunsitf libgcc/./_floatditf_s.o ld: fatal: Symbol referencing errors. No output written to ./libgcc_s.so.1.tmp collect2: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/tmp/gfortran-20051123/ibin/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/tmp/gfortran-20051123/ibin/gcc' This is with a "../gcc/configure --enable-languages=c,fortran --disable-libssp --disable-libmudflap --disable-nls && gmake". It happened with mainline on 20051122 and 20051123, but not on 20051121 and before. -- Summary: Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug bootstrap/24998] Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf
--- Comment #1 from andreast at gcc dot gnu dot org 2005-11-23 09:00 --- happens also on sparc-sun-solaris2.8. This patch is responsible for: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107345 -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 09:00:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug ada/24946] [4.1/4.2 Regression] make[7]: rc: Command not found
--- Comment #5 from charlet at gcc dot gnu dot org 2005-11-23 09:02 --- So closing as not a GCC bug (likely a GNU make bug). Arno -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24946
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-23 09:10 --- Created an attachment (id=10321) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10321&action=view) gcc41-pr24991.patch Does the attached patch cure it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug c++/24907] [3.4/4.0/4.1/4.2 Regression] "int x, ;" accepted
--- Comment #4 from machata at post dot cz 2005-11-23 10:26 --- (In reply to comment #3) > Testcase is in patch, make check-g++ passed on i686-pc-linux-gnu. > I'll do bootstrap and more thorough test tomorrow, and send the patch to > gcc-patches then. Ok, done today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24907
[Bug target/19421] [4.0/4.1/4.2 regression] ICE with soft-float on m68k
--- Comment #17 from corsepiu at gcc dot gnu dot org 2005-11-23 10:30 --- Vanilla 4.0.2 with no further patches applied still fails for me: # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 -msoft-float pr19421-1.c: In function 'paranoia': pr19421-1.c:2084: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.0.1 |4.0.0 4.0.1 4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug bootstrap/24998] Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |critical GCC build triplet|sparc-sun-solaris2.9|sparc-sun-solaris2.* GCC host triplet|sparc-sun-solaris2.9|sparc-sun-solaris2.* GCC target triplet|sparc-sun-solaris2.9|sparc-sun-solaris2.* Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug ada/24994] raised STORAGE_ERROR : stack overflow or erroneous memory access
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2005-11-23 11:10 --- On PowerPC, I get with tree checking: +===GNAT BUG DETECTED==+ | 4.1.0 20051123 (prerelease) (powerpc-apple-darwin8) GCC error: | | tree check: expected class 'expression', have 'exceptional' | |(constructor) in get_base_var, at ipa-utils.c:224 | | Error detected at make.adb:7541:23 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2005-11-23 11:11 --- > with patch from http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html Probably not the correct long-term fix. Might be good enough for 4.1 though. > finally, ada is actually dead. Not very constructive, I'm afraid. Care to devise a fix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #29 from debian-gcc at lists dot debian dot org 2005-11-23 11:47 --- Created an attachment (id=10322) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10322&action=view) preprocessed source The original file still fails on at least hppa-linux, both on 4.0 2005 and 4.1 20051112, works with 3.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #30 from rguenth at gcc dot gnu dot org 2005-11-23 11:55 --- I also still see these problems: gcc-4.1.0_20051116-4 armv4l 10 ICEs 5 Segmentation fault 1 in insert_save, at caller-save.c:719 4 in cp_expr_size, at cp/cp-objcp-common.c:101 hppa10 ICEs 9 verify_flow_info failed 1 in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/kvim: gui_kde_widget.cc:1431: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/katalog: /usr/src/packages/BUILD/katalog-0.3/katalogdcop/katalogdcop.moc:106: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/konversation: /usr/src/packages/BUILD/konversation-0.18/konversation/src/konvdcop.moc:469: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/armv4l/TeXmacs: ./Edit/Modify/edit_dynamic.cpp:614: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 /work/built/info/failed/hppa/arts: dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 re-opening. Tell me, if you need another testcase for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #31 from debian-gcc at lists dot debian dot org 2005-11-23 11:57 --- The original file still fails on at least hppa-linux, both on 4.0 2005 and 4.1 20051112, works with 3.4. no results for arm and m68k yet. Matthias g++ -c -fpreprocessed libmcop_la.all_cc.ii -g -O2 -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99 -fPIC /scratch/packages/tmp/arts-1.4.3/./mcop/dynamicskeleton.cc: In member function 'std::string Arts::Object_skel::_ZTv0_n104_N4Arts11Object_skel9_addChildENS_6ObjectERKSs(Arts::Object, const std::string&)': /scratch/packages/tmp/arts-1.4.3/./mcop/dynamicskeleton.cc:205: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #9 from amodra at gcc dot gnu dot org 2005-11-23 12:05 --- Subject: Bug 24950 Author: amodra Date: Wed Nov 23 12:05:41 2005 New Revision: 107417 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107417 Log: PR middle-end/24950 * expmed.c (store_bit_field): Don't attempt to insv a field larger than the reg. Merge from trunk 2005-11-14 Dale Johannesen <[EMAIL PROTECTED]> * expmed.c (store_bit_field): Add offset unconditionally for memory targets. (extract_bit_field): Don't force extzv or extv operand into a register if field is too big. 2004-12-01 Richard Henderson <[EMAIL PROTECTED]> * expmed.c (store_bit_field): Use simplify_gen_subreg instead of gen_rtx_SUBREG directly. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #10 from amodra at gcc dot gnu dot org 2005-11-23 12:07 --- Subject: Bug 24950 Author: amodra Date: Wed Nov 23 12:07:14 2005 New Revision: 107418 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107418 Log: PR middle-end/24950 Copy from trunk 2005-11-14 Dale Johannesen <[EMAIL PROTECTED]> * gcc.c-torture/execute/20051113-1.c: New. Added: branches/gcc-3_4-branch/gcc/testsuite/gcc.c-torture/execute/20051113-1.c - copied unchanged from r106920, trunk/gcc/testsuite/gcc.c-torture/execute/20051113-1.c Modified: branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug bootstrap/24998] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-23 12:12 --- Similar failures on arm: libbackend.a(timevar.o)(.text+0x1e4): In function `get_time': /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to `__floatunsidf' libbackend.a(timevar.o)(.text+0x200):/work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:204: undefined reference to `__floatunsidf' libbackend.a(timevar.o)(.text+0x220):/work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:205: undefined reference to `__floatunsidf' -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|sparc-sun-solaris2.*|sparc-sun-solaris2.* arm-* Summary|Build failure on sparc-sun- |Build failure on sparc-sun- |solaris2.9: undefined symbol|solaris2.9/arm: undefined |__floatunsitf |symbol __floatunsitf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug java/24999] New: [4.0.2 regression] symbol lookup failure
Running gcj -C org/eclipse/jdt/internal/compiler/lookup/LocalTypeBinding.java in the attached test code results in ./org/eclipse/jdt/internal/compiler/lookup/TagBits.java: In class 'org.eclipse.jdt.internal.compiler.lookup.LocalTypeBinding': ./org/eclipse/jdt/internal/compiler/lookup/TagBits.java: In constructor '(org.eclipse.jdt.internal.compiler.lookup.ClassScope,org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding,org.eclipse.jdt.internal.compiler.ast.CaseStatement)': ./org/eclipse/jdt/internal/compiler/lookup/TagBits.java:20: error: Undefined variable or class name: 'ASTNode.Bit3'. final int IsNestedType = ASTNode.Bit3; ^ 1 error ASTNode.Bit3 is defined though, and the same command on the same code works with 4.0.1. -- Summary: [4.0.2 regression] symbol lookup failure Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24999
[Bug java/24999] [4.0.2 regression] symbol lookup failure
--- Comment #1 from bero at arklinux dot org 2005-11-23 12:17 --- Created an attachment (id=10323) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10323&action=view) test code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24999
[Bug tree-optimization/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #1 from amodra at bigpond dot net dot au 2005-11-23 12:20 --- Please attach preprocessed source. -- amodra at bigpond dot net dot au changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug tree-optimization/25000] New: [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
We fail to compile OpenOffice at the moment due to > g++ -S -O sbunoobj.min.ii sbunoobj.min.ii:119: internal compiler error: in coalesce_abnormal_edges, at tree-outof-ssa.c:646 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-23 12:27 --- Created an attachment (id=10324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10324&action=view) testcase reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2005-11-23 12:57 --- Created an attachment (id=10325) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10325&action=view) Almost complete patch for handling CRLF correctly Attached patch corrects the problem reported here as well as most other problems related to CRLF. There is still a slight issue with the handling of T format descriptors. When this is resolved, I'll submit the patch properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug libfortran/24919] CRLF support in libgfortran
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Summary|GFORTRAN input and carriage |CRLF support in libgfortran |returns | Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 13:15 --- Hmm, r9, wtf. Any ways, we need the .i file :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Component|tree-optimization |middle-end Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|blocker Component|bootstrap |middle-end Keywords||link-failure Summary|Build failure on sparc-sun- |[4.2 Regression] Build |solaris2.9/arm: undefined |failure on sparc-sun- |symbol __floatunsitf|solaris2.9/arm: undefined ||symbol __floatunsitf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 13:31 --- Conflict pRes_1(ab) and pRes_8(ab) across an abnormal edge from BB4->BB15 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug c++/21983] [3.4/4.0 Regression] multiple diagnostics
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-23 13:53 --- Subject: Bug 21983 Author: jakub Date: Wed Nov 23 13:53:15 2005 New Revision: 107420 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107420 Log: PR c++/21983 * class.c (find_final_overrider): Move diagnostic about no unique final overrider to... (update_vtable_entry_for_fn): ... here. * g++.dg/warn/pr21983.C: New test. Added: branches/gcc-3_4-branch/gcc/testsuite/g++.dg/warn/pr21983.C Modified: branches/gcc-3_4-branch/gcc/cp/ChangeLog branches/gcc-3_4-branch/gcc/cp/class.c branches/gcc-3_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21983
[Bug java/25001] New: dos equis
GCJ produces incorrect byte- and native code for a variation of
2-expressive-puzzlers/puzzle-8/DosEquis.java
from
http://www.javapuzzlers.com/java-puzzlers.zip
Specifically,
| $ cat DosEquis.java
| public class DosEquis {
| public static void main(String[] _) {
| char x = 'X';
| final int i = 0;
| System.out.print (true ? x : 0);
| System.out.println(false ? i : x);
| }
| }
This should print out XX, as it does under Sun's JVM:
| $ java -version
| java version "1.4.2_08"
| Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
| Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
| $ javac DosEquis.java
| $ java -cp . DosEquis
| XX
Under GCJ, I get X88 instead:
| $ gcj --version
| gcj (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
| Copyright (C) 2005 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions. There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
| $ gcj -C DosEquis.java
| $ gij DosEquis
| X88
| $ gcj -o dos-equis --main=DosEquis DosEquis.java
| $ ./dos-equis
| X88
Eclipse compiler gets it right:
| $ rm DosEquis.class
| $ ecj -v
| Eclipse Java Compiler v_579_R31x, 3.1.1 release, Copyright IBM Corp \
| 2000, 2005. All rights reserved.
| $ ecj DosEquis.java
| $ gij DosEquis
| XX
GCJ violates the following JLS clause:
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#290293
| 15.25 Conditional Operator ? :
|
| The type of a conditional expression is determined as follows:
|
| * If one of the operands is of type T where T is byte, short, or
| char, and the other operand is a constant expression of type int
| whose value is representable in type T, then the type of the
| conditional expression is T.
Since i is declared final in the above example, it is a constant
expression of type int. Therefore, the above clause applies in this
case.
--
Summary: dos equis
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vadimn at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25001
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #3 from joseph at codesourcery dot com 2005-11-23 14:07 --- Subject: Re: New: Build failure on sparc-sun-solaris2.9: undefined symbol __floatunsitf On Wed, 23 Nov 2005, fxcoudert at gcc dot gnu dot org wrote: > Undefined first referenced > symbol in file > __floatunsitf libgcc/./_floatditf_s.o What did the assembly code look like before and after my patch? If it previously used __floatsitf, where did it get the definition of that symbol? If not, I suspect a bug in the optabs.c changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #2 from dir at lanl dot gov 2005-11-23 14:09 --- I applied the patch to what I had yesterday and did a make and install. I build a program with it but the program would not run. I got - [dranta:~/sage/ibar/ibarOne] dir% rage2005GF.x ibarOne.input dyld: lazy symbol binding failed: Symbol not found: ___gthrw_pthread_mutex_lock Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib Expected in: flat namespace dyld: Symbol not found: ___gthrw_pthread_mutex_lock Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib Expected in: flat namespace Trace/BPT trap [dranta:~/sage/ibar/ibarOne] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.3.0 Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.2.0 20051122 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #4 from joseph at codesourcery dot com 2005-11-23 14:09 --- Subject: Re: Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to > `__floatunsidf' ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? Did the code previously use __floatsidf, and if so where did it get __floatsidf from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug java/25001] dos equis
--- Comment #1 from vadimn at redhat dot com 2005-11-23 14:12 --- > Since i is declared final in the above example, it is a constant > expression of type int. Therefore, the above clause applies in this > case. See also http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#5313 | 15.28 Constant Expression | | A compile-time constant expression is an expression denoting a | value of primitive type or a String that is composed using only | the following: | | [...] | | * Simple names that refer to final variables whose initializers | are constant expressions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25001
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #5 from rearnsha at gcc dot gnu dot org 2005-11-23 14:22 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 2005-11-23 at 14:09, joseph at codesourcery dot com wrote: > On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > > > /work/rearnsha/gnusrc/gcc/trunk/gcc/timevar.c:203: undefined reference to > > `__floatunsidf' > > ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? > Did the code previously use __floatsidf, and if so where did it get > __floatsidf from? Because this is NetBSD, which doesn't use ieee754-df.S. And the C library only provides __floatsidf. Sorry, I hadn't realized this was restricted only to arm-netbsdelf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug fortran/15809] ICE Using Pointer Functions
--- Comment #18 from paul dot richard dot thomas at cea dot fr 2005-11-23
14:26 ---
(In reply to comment #15)
> I cannot tell why, but it seems to me that Paul Thomas' test case is no valid
Hej Sven!
You quite correctly picked up that it does not have an explicit interface and
so will give nonsense. Making it contained or writing an interface converts my
rubbish into legal code.
I have made progress in converting pointer arrays into references to pointer
arrays:
The patch below works for pointer assignments with integers and characters and
returns pointer dummy arguments correctly.
There is still a problem (seg fault) with assignments of characters. This comes
about because dtype does not contain the size, as is apparent from the code at
the end of the message. (see the dtypes in the subroutine).
There are also some issues with alignment during pointer assignments.
This damn thing is going to work, legal fortran or not
Both the examples below work.
Paul Thomas 23rd Nov 2005
Danger: Cygwin source => whitespace issues.
*** trunk/gcc/fortran/trans-array.c Wed Nov 23 14:44:18 2005
--- trunk/gcc/fortran/trans-array.c.origWed Nov 23 14:45:15 2005
*** gfc_trans_deferred_array (gfc_symbol * s
*** 4173,4179
gfc_init_block (&fnblock);
! gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL);
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.cl->backend_decl))
gfc_trans_init_string_length (sym->ts.cl, &fnblock);
--- 4173,4181
gfc_init_block (&fnblock);
! gcc_assert (TREE_CODE (sym->backend_decl) == VAR_DECL
! || TREE_CODE (sym->backend_decl) == PARM_DECL);
!
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.cl->backend_decl))
gfc_trans_init_string_length (sym->ts.cl, &fnblock);
*** trunk/gcc/fortran/trans-expr.c Wed Nov 23 14:55:20 2005
--- trunk/gcc/fortran/trans-expr.c.orig Wed Nov 23 14:56:37 2005
*** gfc_conv_variable (gfc_se * se, gfc_expr
*** 396,401
--- 396,404
|| !sym->attr.dimension))
se->expr = gfc_build_indirect_ref (se->expr);
}
+
+ if (sym->attr.pointer && sym->attr.dummy && sym->attr.dimension)
+ se->expr = gfc_build_indirect_ref (se->expr);
ref = expr->ref;
}
*** gfc_conv_function_call (gfc_se * se, gfc
*** 1608,1614
&& !formal->sym->attr.pointer
&& formal->sym->as->type != AS_ASSUMED_SHAPE;
f = f || !sym->attr.always_explicit;
! gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
}
}
--- 1611,1619
&& !formal->sym->attr.pointer
&& formal->sym->as->type != AS_ASSUMED_SHAPE;
f = f || !sym->attr.always_explicit;
! gfc_conv_array_parameter (&parmse, arg->expr, argss, f);
! if (formal != NULL && formal->sym->attr.pointer &&
formal->sym->attr.dimension)
! parmse.expr = gfc_build_addr_expr (NULL, parmse.expr);
}
}
*** trunk/gcc/fortran/trans-types.c Wed Nov 23 13:48:37 2005
--- trunk/gcc/fortran/trans-types.c.origWed Nov 23 13:49:06 2005
*** gfc_sym_type (gfc_symbol * sym)
*** 1333,1338
--- 1333,1342
}
else
type = gfc_build_array_type (type, sym->as);
+
+ if (sym->attr.pointer && sym->attr.dummy)
+ type = build_reference_type (type);
+
}
else
{
!=
module global
CHARACTER(14), DIMENSION(2), target :: t
end module global
program oh_no_not_pr15908_again
CHARACTER(12), DIMENSION(:), POINTER :: ptr
allocate (ptr(2))
ptr = "xyz"
call a (ptr, 12)
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN", size(ptr,1), len (ptr), ptr
END IF
contains
SUBROUTINE A(p, l)
use global
CHARACTER(l), DIMENSION(:), POINTER :: p
t = "abc"
IF ( .NOT. ASSOCIATED(p) ) THEN
p => t
print *, "not associated in A ", size(p,1), len (p), p
else
print *, "associated in A ", size(p,1), len (p), p
t = "lmn"
p => t
END IF
END SUBROUTINE A
end program oh_no_not_pr15908_again
!=integer version=
module global
integer, DIMENSION(2), target :: t
end module global
integer, DIMENSION(:), POINTER :: ptr
allocate (ptr(2))
ptr = 123
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN", size(ptr,1), ptr
END IF
call a (ptr, 12)
IF ( .NOT. ASSOCIATED(ptr) ) THEN
print *, "not associated in MAIN"
else
print *, "associated in MAIN", siz
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #6 from joseph at codesourcery dot com 2005-11-23 14:28 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote: > > ARM should be getting __floatunsidf from ieee754-df.S. Why isn't it? > > Did the code previously use __floatsidf, and if so where did it get > > __floatsidf from? > > Because this is NetBSD, which doesn't use ieee754-df.S. And the C > library only provides __floatsidf. In that case the obvious solution is for the NetBSD configuration to start using that one function from ieee754-df.S. (I checked that the implementations in GCC of __float* already had corresponding implementations of __floatun* as required - missing rs6000/ppc64-fp.c in the process - but couldn't check for any case where these functions came from libc.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 14:31:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
Re: [Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Wed, 2005-11-23 at 14:28, joseph at codesourcery dot com wrote: > In that case the obvious solution is for the NetBSD configuration to start > using that one function from ieee754-df.S. (I checked that the > implementations in GCC of __float* already had corresponding > implementations of __floatun* as required - missing rs6000/ppc64-fp.c in > the process - but couldn't check for any case where these functions came > from libc.) Not that simple, because the implementation of __floatunsidf is tightly integrated with the implementation of __adddf3. And we don't want to override that because the ieee754-df.S implementation does not support raising signals. R.
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #7 from rearnsha at gcc dot gnu dot org 2005-11-23 14:44 --- Subject: Re: [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf On Wed, 2005-11-23 at 14:28, joseph at codesourcery dot com wrote: > In that case the obvious solution is for the NetBSD configuration to start > using that one function from ieee754-df.S. (I checked that the > implementations in GCC of __float* already had corresponding > implementations of __floatun* as required - missing rs6000/ppc64-fp.c in > the process - but couldn't check for any case where these functions came > from libc.) Not that simple, because the implementation of __floatunsidf is tightly integrated with the implementation of __adddf3. And we don't want to override that because the ieee754-df.S implementation does not support raising signals. R. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #8 from joseph at codesourcery dot com 2005-11-23 14:54 ---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Wed, 23 Nov 2005, rearnsha at gcc dot gnu dot org wrote:
> Not that simple, because the implementation of __floatunsidf is tightly
> integrated with the implementation of __adddf3. And we don't want to
> override that because the ieee754-df.S implementation does not support
> raising signals.
In that case there's the possibility of a trivial C implementation along
the lines of
double __floatunsidf (unsigned i)
{
double r = (double)(int)i;
if ((int)i < 0)
r += 0x1p32f;
return r;
}
(with a bit more complexity for correct rounding in the "float" case, as
expand_float does). Adding such implementations to libgcc2.c is the
simplest workaround for this bug, but I'd hope that most issues can be
resolved separately so such implementations are only needed in the case of
__float* in libc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug bootstrap/25002] New: build breaks if no `NAN'
This gcc version always requires that system have at least one floating value that is usable as `NAN' - in its own headers or specified in build configuration. In this system with this compiler it is not the case. Can not obtain `NAN' value at all. When trying to compute it dynamically, the process just gets signal, so can not even obtain the value in it and copy into `NAN' definition. Environment: System: OSF1 . V5.1 2650 alpha Machine: Using native `CC=cc', `CFLAGS='-pthread -g''. host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: ../gcc-4.0.2/configure --disable-nls --disable-libgcj --enable-languages=c,c++,objc How-To-Repeat: gmake[1]: Entering directory `gcc-4.0.2-e/build-alpha-dec-osf5.1b/libiberty' make bootstrap cc -c -DHAVE_CONFIG_H -pthread -g -I. -I../../../gcc-4.0.2/libiberty/../include ../../../gcc-4.0.2/libiberty/floatformat.c -o floatformat.o cc: Error: ../../../gcc-4.0.2/libiberty/floatformat.c, line 319: In this statement, the libraries on this platform do not yet support compile-time evaluation of the constant expression "0.0/0.0". (constfoldns) dto = NAN; --^ gmake[1]: *** [floatformat.o] Error 1 The preprocessed line 319 is as follows. dto = ( 0.0 / 0.0 ) ; --- Comment #1 from gin at mo dot msk dot ru 2005-11-23 15:02 --- Fix: Do not have patch currently. Most likely gcc has to check whether `NAN' value exists, and compile some code in `floatformat.c' only if it is the case. Or at least allow to disable compiling that code in build configuration. -- Summary: build breaks if no `NAN' Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: critical Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gin at mo dot msk dot ru GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25002
[Bug bootstrap/25002] build breaks if no `NAN'
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 15:04 --- This is a dup of bug 16787, the problem is that you need to supply -ieee to the compiler. *** This bug has been marked as a duplicate of 16787 *** -- 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=25002
[Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-23 15:04 --- *** Bug 25002 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gin at mo dot msk dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16787
[Bug fortran/25003] New: Non-standard-conforming behaviour on pointer association special case.
The following test case should print F as per the discussion on http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/b77f60c2874b4e83/5fdaff5b1edaf688?hl=en#5fdaff5b1edaf688 gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20051112/configure --prefix=/usr/local/gfortran/ Thread model: posix gcc version 4.1.0 20051112 (experimental) [EMAIL PROTECTED] sfilippo]$ gfortran -o testp testp.f90 [EMAIL PROTECTED] sfilippo]$ ./testp T -- Summary: Non-standard-conforming behaviour on pointer association special case. Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25003
[Bug fortran/25003] Non-standard-conforming behaviour on pointer association special case.
--- Comment #1 from sfilippone at uniroma2 dot it 2005-11-23 15:25 --- Created an attachment (id=10326) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10326&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25003
[Bug tree-optimization/25000] [4.1/4.2 Regression] ICE in coalesce_abnormal_edges, at tree-outof-ssa.c:646
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-23 15:41 ---
Reduced testcase:
int * f(void);
void g(int*);
bool h(void);
void Find( )
{
int * pRes = f();
if( !pRes ) {
if( h()){
if( h()){
try
{
pRes = new int();
f();
}catch(int& e1 ){}
}
if( !pRes )
f();
}
g(pRes);
}
}
-
This is jump threading related.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||law at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25000
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #3 from jakub at gcc dot gnu dot org 2005-11-23 15:45 --- Can you configure with objc as well to see if you see similar problem in libobjc? In any case, preprocessed source (with -E -dD in place of -c) for one of the files that include io.h (say environ.c) would be helpful. This sounds like weakref attribute not working for you. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug bootstrap/25002] build breaks if no `NAN'
--- Comment #3 from gin at mo dot msk dot ru 2005-11-23 15:58 --- Subject: Re: build breaks if no `NAN' Did that. This particular translation unit compiles. With warning telling the same. For this particular system there is a workaround, but does it have to be on any system? If it has neither `NAN' nor equivalent value, what standard does it violate, so that one can file a complaint? If there is no such standard, it is still safer to be able to inhibit using `NAN'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25002
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #3 from phython at gcc dot gnu dot org 2005-11-23 16:05 --- Created an attachment (id=10327) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10327&action=view) preprocessed source Here is the preprocessed source. Sorry, I haven't had a change to run delta on it yet, nor can I reproduce this ICE without using -O3 -ftree-vectorize. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #4 from bonzini at gcc dot gnu dot org 2005-11-23 16:05 --- This is actually not a cross build, but a build with srcdir == builddir. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
-- phython at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 16:06:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug other/25004] New: elfutils misscompilation (testuite failure).
gcc-4.1.0-20051113 (rev 106863) misscompiles elfutils-0.116. elfutils testsuite fails on: (...) PASS: run-elflint-test.sh section [37] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x10011998 does not match .got section address 0x10011990 with gcc-3.3.6 it works fine. i'll try to reduce testcase ASAP. -- Summary: elfutils misscompilation (testuite failure). Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: ppc GCC host triplet: ppc GCC target triplet: ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25004
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-23 16:14 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug other/25004] elfutils misscompilation (testuite failure).
--- Comment #1 from pluto at agmk dot net 2005-11-23 16:16 --- > PASS: run-elflint-test.sh ^^^ should be a FAIL: run-elflint-self.sh > section [37] '.symtab': _GLOBAL_OFFSET_TABLE_ symbol value 0x10011998 >does not match .got section address 0x10011990 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25004
[Bug other/25004] elfutils misscompilation (testuite failure).
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 16:27 --- Can you first try after revision 107117 because I think that might had fixed the problem by looking at the numbers which don't match? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25004
[Bug target/25005] New: [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
With the code I'm going to attach in a second, I get this:
deal.II/deal.II> c++ -c -O3 -funroll-loops grid_generator.ii
grid_generator.ii:6838: warning: '__malloc__' attribute ignored
grid_generator.ii: In static member function 'static void
GridGenerator::hyper_ball(Triangulation<3>&, const Point<3>&, double)':
grid_generator.ii:65800: error: insn does not satisfy its constraints:
(insn 3454 3452 3453 (set (reg:DI 38 r9 [orig:801 D.166645 ] [801])
(mult:DI (reg:DI 7 sp [626])
(const_int 2 [0x2]))) 196 {*lea_2_rex64} (nil)
(nil))
grid_generator.ii:65800: internal compiler error: in
extract_constrain_insn_cached, at recog.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This is with today's svn, Revision: 107421.
W.
--
Summary: [4.1/4.2 regression] ICE in
extract_constrain_insn_cached, at recog.c:2002
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #1 from bangerth at dealii dot org 2005-11-23 16:53 --- Created an attachment (id=10328) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10328&action=view) Failing file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug libfortran/24919] CRLF support in libgfortran
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2005-11-23 16:58 --- Complete patch submitted for review. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2005-11/msg00617.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-23 17:01 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug java/24999] [4.0.2 regression] symbol lookup failure
--- Comment #2 from bero at arklinux dot org 2005-11-23 17:12 --- I've just checked post-4.0.2 gcc-4_0-branch (svn 107418), works there -- bero at arklinux dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24999
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #3 from bangerth at dealii dot org 2005-11-23 17:12 ---
Here's a much shorter testcase:
-
#include
struct Point {
Point (const Point &);
Point (const double x);
double values[3];
};
Point::Point (const double x) {
this->values[0] = x;
}
Point::Point (const Point &p) {
for (unsigned int i=0; i<3; ++i) values[i] = p.values[i];
}
struct X {
void bar (const std::vector &vertices);
};
void foo (X &x) {
const Point vertices[2] = { Point(1), Point(1), };
x.bar (std::vector(&vertices[0], &vertices[2]));
}
--
deal.II/deal.II> c++ -c -O3 -funroll-loops x.cc
x.cc: In function 'void foo(X&)':
x.cc:25: error: insn does not satisfy its constraints:
(insn 556 554 555 (set (reg:DI 1 dx [orig:153 D.13205 ] [153])
(mult:DI (reg:DI 7 sp [118])
(const_int 2 [0x2]))) 196 {*lea_2_rex64} (nil)
(nil))
x.cc:25: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
long function name
Hey,
I know it's not that urgent and as a matter of fact only a theoretical
problem, but still..
g++ crashes for a very long function name ;)
consider this perl program to generate such a stupid-evil source file:
a.pl:
#v+
my $name = "a"x(1024*1024*8);
open( FD, "> test.cpp" ) or die "ohmygawd";
print FD <
void $name(){
std::cout << "cheers\\n";
}
int main( int argc, char** argv ) {
$name();
return 0;
}
EOF
;
print "Compiling..\n";
system "g++ -c test.cpp -o test -Wall -ansi";
#v-
outpus:
Compiling..
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
On my system it crashes for 8*1024*1024 chars. I guess this number is
very depended on the actual pc configuration.
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit
--enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release
i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)
I know it's stupid but java for instance does not simply allow longer
names than 65535 (iirc).
--
Cheers,
Kornel
[Bug c++/24996] [4.0/4.1/4.2 Regression] ICE on throw code
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-11-23 17:37
---
Testcase with simpler class hierarchy:
==
struct A
{
~A();
};
struct B
{
B(A);
};
void foo(bool b)
{
throw b ? B(A()) : B(A());
}
==
This testaces also crashes GCC 3.4.0, but not 3.4.1 - 3.4.4.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0 4.2.0 3.4.0
Known to work|3.4.0 |3.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #5 from dir at lanl dot gov 2005-11-23 17:47 --- Nothing called gthrw_pthread_mutex_lock (Darwin only has pthread_mutex_lock)is in any of the libraries as a terminator. If I run gcc directly, I do not know how to get all the flags set correctly to get a meaningful preprocessed output from environ.c - is there some macro that will pick up all the required parameters for this configuration ? When I touched environ.c and did another make - I found some warning messages in the output about the thread routines. can't find atom for N_GSYM stabs compile_options:G(0,5)=(0,6)=s8warn_std:(0,4),0,32;allow_std:(0,4),32,32;; in .libs/compile_options.o can't find atom for N_GSYM stabs options:G(0,25)=(0,26)=s80stdin_unit:(0,8),0,32;stdout_unit:(0,8),32,32;stderr_unit:(0,8),64,32;optional_plus:(0,8),96,32;allocate_init_flag:(0,8),128,32;allocate_init_value:(0,8),160,32;locus:(0,8),192,32;separator_len:(0,8),224,32;separator:(0,5),256,64;mem_check:(0,8),320,32;use_stderr:(0,8),352,32;all_unbuffered:(0,8),384,32;default_recl:(0,8),416,32;fpu_round:(0,8),448,32;fpu_precision:(0,8),480,32;fpe:(0,8),512,32;sighup:(0,8),544,32;sigint:(0,8),576,32;; in .libs/environ.o can't find atom for N_GSYM stabs l8_to_l4_offset:G(0,2) in .libs/main.o ld: warning weak symbol references not set in output with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 ld: warning weak referenced symbols: _pthread_cancel _pthread_mutex_lock _pthread_mutex_trylock _pthread_mutex_unlock can't find atom for N_GSYM stabs max_offset:G(0,30) in .libs/unit.o can't find atom for N_GSYM stabs unit_root:G(0,1) in .libs/unit.o can't find atom for N_GSYM stabs unit_lock:G(0,35) in .libs/unit.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug fortran/25003] Non-standard-conforming behaviour on pointer association special case.
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-23 17:48 --- Confirmed. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-11-23 17:48:15 date|| Summary|Non-standard-conforming |Non-standard-conforming |behaviour on pointer|behaviour on pointer |association special case. |association special case. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25003
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-23 17:53 --- Can you build from a clean directory? It sounds like you are building in a non clean one which might cause these issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug bootstrap/25002] build breaks if no `NAN'
--- Comment #4 from gin at mo dot msk dot ru 2005-11-23 18:08 --- Subject: Re: build breaks if no `NAN' Know at least one more system that has no `NAN' and which native `cc' normally generates code that causes program to terminate abnormally: Arithmetic Exception (core dumped) The system is i586-pc-sco3.2v5.0.2. When specified `-K noieee', `( 0.0 / 0.0 )' static initializer works and generates value that is converted by `printf' to `0.00'. Unlikely to make much sense. Perhaps other systems have other tricky options, with unpredictable results. Still think that allowing to disable use of `NAN' is not needed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25002
[Bug other/25004] elfutils misscompilation (testuite failure).
--- Comment #3 from pluto at agmk dot net 2005-11-23 18:31 --- i'm currently bootstraping rev107414... btw. i'm observing several warnings for some time... (...) build/genrecog ../../gcc/config/rs6000/rs6000.md > tmp-recog.c ../../gcc/config/rs6000/rs6000.md:13543: warning: operand 0 missing mode? ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? ../../gcc/config/rs6000/altivec.md:1776: warning: operand 1 missing mode? ../../gcc/config/rs6000/altivec.md:1783: warning: operand 1 missing mode? ../../gcc/config/rs6000/altivec.md:2086: warning: destination missing a mode? ../../gcc/config/rs6000/altivec.md:2086: warning: operand 0 missing mode? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25004
[Bug c++/25006] New: failure "using" a name contained in a class
The following code fails to compile:
namespace Foo {
struct Bar {
struct FooBar {};
};
}
using ::Foo::Bar::FooBar; // line 7
The error message being:
using.cpp:7: error: `Foo::Bar' is not a namespace
In the ISO C++ grammar [7.3.3], the using-declaration references a
"nested-name-specifier unqualified-id", not stating any restrictions
on the nested-name-specifier, which is composed of a sequence of
class-or-namespace-name [5.1].
--
Summary: failure "using" a name contained in a class
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fp at mc dot com
GCC build triplet: mingw-special
GCC host triplet: mingw-special
GCC target triplet: mingw-special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25006
[Bug target/25005] [4.1/4.2 regression] ICE in extract_constrain_insn_cached, at recog.c:2002
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-23 18:48 ---
Reduced (maybe too much as there is an uninitialized variable now):
typedef long unsigned int size_t;
namespace std {
template struct vector {
vector(){
size_t __n;
static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
}
};
};
struct Point {
Point ();
double values[3];
};
void hyper_L (){
const Point vertices[3] = {};
std::vector a;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-23 18:48:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25005
[Bug c++/25006] failure "using" a name contained in a class
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-23 18:51 --- ICC rejects it as invalid too: t.cc(7): error: a class-qualified name is not allowed using ::Foo::Bar::FooBar; // line 7 So does Comeau with the same error message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25006
[Bug other/25004] elfutils misscompilation (testuite failure).
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-23 18:53 --- (In reply to comment #3) > build/genrecog ../../gcc/config/rs6000/rs6000.md > tmp-recog.c > ../../gcc/config/rs6000/rs6000.md:13543: warning: operand 0 missing mode? > ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? > ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? > ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? > ../../gcc/config/rs6000/altivec.md:1706: warning: operand 3 missing mode? > ../../gcc/config/rs6000/altivec.md:1776: warning: operand 1 missing mode? > ../../gcc/config/rs6000/altivec.md:1783: warning: operand 1 missing mode? > ../../gcc/config/rs6000/altivec.md:2086: warning: destination missing a mode? > ../../gcc/config/rs6000/altivec.md:2086: warning: operand 0 missing mode? Those are nothing to worry about, in a way they are an issue but right now there is no way to fix those warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25004
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-23 18:54 --- I will finish reducing this after class (I stopped and started reducing a different testcase anyways). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #33 from pluto at agmk dot net 2005-11-23 19:16 --- (In reply to comment #32) > > with patch from http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html > > Probably not the correct long-term fix. Might be good enough for 4.1 though. this fix doesn't help for current 4.1. workaround from #c23 doesn;t help either. > > finally, ada is actually dead. > > Not very constructive, I'm afraid. Care to devise a fix? sorry, i don't known too much about compiler's infrastructure. i'm just a software developer and packager. i can test builds/fixes and provide backtraces on PPC970FX but nothing more... $ gdb stage1/gnat1 (gdb) set args -I- -I. -Iada -I../../gcc/ada -quiet -dumpbase a-except.adb -O2 -O1 -fsigned-char -fno-inline -ggdb -gnatpg -gnata -g -gnatO ada/a-except.o ../../gcc/ada/a-except.adb -o /tmp/ccaqK3JS.s (gdb) r Starting program: /home/users/builder2/rpm/BUILD/gcc/obj-ppc-pld-linux/gcc/stage1/gnat1 -I- -I. -Iada -I../../gcc/ada -quiet -dumpbase a-except.adb -O2 -O1 -fno-inline -ggdb -gnatpg -gnata -g -gnatO ada/a-except.o ../../gcc/ada/a-except.adb -o /tmp/ccaqK3JS.s Breakpoint 3 at 0xfee33e8 Breakpoint 4 at 0xfee1d90 Program received signal SIGSEGV, Segmentation fault. 0x109c6418 in get_base_var (t=0x0) at ../../gcc/ipa-utils.c:218 218 while (!SSA_VAR_P (t) (gdb) bt #0 0x109c6418 in get_base_var (t=0x0) at ../../gcc/ipa-utils.c:218 #1 0x10840d1c in look_for_address_of (t=0x303cc720) at ../../gcc/ipa-reference.c:345 #2 0x10840da4 in check_rhs_var (local=0x0, t=0x303cc720) at ../../gcc/ipa-reference.c:360 #3 0x108413e4 in scan_for_static_refs (tp=0x303cb344, walk_subtrees=0x7084, data=0x0) at ../../gcc/ipa-reference.c:553 #4 0x1079e554 in walk_tree (tp=0x303cb344, func=0x1084117c , data=0x0, pset=0x11086c80) at ../../gcc/tree.c:7115 #5 0x1079ecd4 in walk_tree (tp=0x303ea6cc, func=0x1084117c , data=0x0, pset=0x11086c80) at ../../gcc/tree.c:7286 #6 0x10841b78 in analyze_variable (vnode=0x304653f0) at ../../gcc/ipa-reference.c:774 #7 0x108423a4 in static_execute () at ../../gcc/ipa-reference.c:901 #8 0x107c8ea0 in execute_one_pass (pass=0x10bc1470) at ../../gcc/passes.c:828 #9 0x107c9038 in execute_ipa_pass_list (pass=0x10bc1470) at ../../gcc/passes.c:874 #10 0x1083bb80 in ipa_passes () at ../../gcc/cgraphunit.c:1223 #11 0x1083bc6c in cgraph_optimize () at ../../gcc/cgraphunit.c:1257 #12 0x1001c77c in gnat_parse_file (set_yydebug=0) at ../../gcc/ada/misc.c:245 #13 0x10786bbc in compile_file () at ../../gcc/toplev.c:990 #14 0x10788ecc in do_compile () at ../../gcc/toplev.c:1948 #15 0x10788f60 in toplev_main (argc=21, argv=0x75f4) at ../../gcc/toplev.c:1980 #16 0x103f0300 in main (argc=21, argv=0x75f4) at ../../gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug c++/25006] failure "using" a name contained in a class
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-23 19:36 --- Subject: Re: failure "using" a name contained in a class "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | ICC rejects it as invalid too: | t.cc(7): error: a class-qualified name is not allowed | using ::Foo::Bar::FooBar; // line 7 | | So does Comeau with the same error message. The construct is ill-formed -- sorry, someone needs to quote chapter and verse. I'll do that later if no one beats me at it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25006
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-11-23 19:36 --- > this fix doesn't help for current 4.1. It works (or worked) on s390 at least and fix the first problem on PPC though. Did you try to compile make.adb at -O1 or -O0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug other/22313] [4.1/4.2 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap without -g
--- Comment #19 from papadako at csd dot uoc dot gr 2005-11-23 19:37 --- I don't know if this is related, but I can't compile make profiledbootstrap on a x86 Linux. Stops in attribs.c. I don't know if it is related to this bug but you can find more info in http://gcc.gnu.org/ml/gcc/2005-11/msg00906.html -- papadako at csd dot uoc dot gr changed: What|Removed |Added CC||papadako at csd dot uoc dot ||gr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #7 from dir at lanl dot gov 2005-11-23 19:45 --- I did a complete rebuild with the same results - mkdir gfortran cd gfortran svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc cd gcc patch -p0 < /Users/dir/Desktop/gcc41-pr24991.patch configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 make -j 4 make install [dranta:~/sage/ibar/ibarOne] dir% rage2005GF.x ibarOne.input dyld: lazy symbol binding failed: Symbol not found: ___gthrw_pthread_mutex_lock Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib Expected in: flat namespace dyld: Symbol not found: ___gthrw_pthread_mutex_lock Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib Expected in: flat namespace Trace/BPT trap I built a new version last week and it works fine - [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.3.0 Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20051114 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #35 from pluto at agmk dot net 2005-11-23 19:47 ---
(In reply to comment #34)
> Did you try to compile make.adb at -O1 or -O0?
i always do a full bootstrap with different flags for stage1 and 2+.
make bootstrap \
BOOT_CFLAGS="%{rpmcflags}" \
STAGE1_CFLAGS="%{rpmcflags} -O0" \
stage1 (with -O0) builds, stage2 fails.
(rpmcflags == -O2 + additional options).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #8 from jakub at gcc dot gnu dot org 2005-11-23 20:24 --- touch libgfortran/runtime/environ.c make all-target-libgfortran > LOG then either cut'n'paste the line that compiled environ.c and replace -c with -E -dD and -o /environ.o with -o /tmp/environ.i and run that command, or do the same with sed or something similar and pipe it to shell. __gthrw_* routines are recently introduced routines in gthr*.h, which either have the new weakref attribute or through __asm () are redirected to the real routines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug target/21098] .note.GNU-stack emitted
--- Comment #7 from jakub at gcc dot gnu dot org 2005-11-23 20:47 --- Subject: Bug 21098 Author: jakub Date: Wed Nov 23 20:47:12 2005 New Revision: 107432 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107432 Log: 2005-05-04 Jakub Jelinek <[EMAIL PROTECTED]> Revert: 2005-04-29 Alan Modra <[EMAIL PROTECTED]> PR target/21098 * config/rs6000/rs6000.c (rs6000_elf_end_indicate_exec_stack): New. * config/rs6000/linux64.h (TARGET_ASM_FILE_END): Use the above. 2004-09-20 Jakub Jelinek <[EMAIL PROTECTED]> * config/rs6000/ppc-asm.h: Add .note.GNU-stack section also on ppc64-linux. * config/ia64/lib1funcs.asm: Add .note.GNU-stack section on ia64-linux. * config/ia64/crtbegin.asm: Likewise. * config/ia64/crtend.asm: Likewise. * config/ia64/crti.asm: Likewise. * config/ia64/crtn.asm: Likewise. 2004-05-14 Jakub Jelinek <[EMAIL PROTECTED]> * config/ia64/linux.h (TARGET_ASM_FILE_END): Define. boehm-gc/ 2005-02-08 Jakub Jelinek <[EMAIL PROTECTED]> * ia64_save_regs_in_stack.s: Moved to... * ia64_save_regs_in_stack.S: ... this. Add .note.GNU-stack on Linux. libffi/ 2005-02-08 Jakub Jelinek <[EMAIL PROTECTED]> * src/alpha/osf.S: Add .note.GNU-stack on Linux. * src/s390/sysv.S: Likewise. * src/powerpc/linux64.S: Likewise. * src/powerpc/linux64_closure.S: Likewise. * src/powerpc/ppc_closure.S: Likewise. * src/powerpc/sysv.S: Likewise. * src/x86/unix64.S: Likewise. * src/x86/sysv.S: Likewise. * src/sparc/v8.S: Likewise. * src/sparc/v9.S: Likewise. * src/m68k/sysv.S: Likewise. * src/ia64/unix.S: Likewise. * src/arm/sysv.S: Likewise. Added: branches/redhat/gcc-4_1-branch/boehm-gc/ia64_save_regs_in_stack.S - copied, changed from r107414, branches/redhat/gcc-4_1-branch/boehm-gc/ia64_save_regs_in_stack.s Removed: branches/redhat/gcc-4_1-branch/boehm-gc/ia64_save_regs_in_stack.s Modified: branches/redhat/gcc-4_1-branch/boehm-gc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/config/ia64/crtbegin.asm branches/redhat/gcc-4_1-branch/gcc/config/ia64/crtend.asm branches/redhat/gcc-4_1-branch/gcc/config/ia64/crti.asm branches/redhat/gcc-4_1-branch/gcc/config/ia64/crtn.asm branches/redhat/gcc-4_1-branch/gcc/config/ia64/lib1funcs.asm branches/redhat/gcc-4_1-branch/gcc/config/ia64/linux.h branches/redhat/gcc-4_1-branch/gcc/config/rs6000/linux64.h branches/redhat/gcc-4_1-branch/gcc/config/rs6000/ppc-asm.h branches/redhat/gcc-4_1-branch/gcc/config/rs6000/rs6000.c branches/redhat/gcc-4_1-branch/libffi/ChangeLog branches/redhat/gcc-4_1-branch/libffi/src/alpha/osf.S branches/redhat/gcc-4_1-branch/libffi/src/arm/sysv.S branches/redhat/gcc-4_1-branch/libffi/src/ia64/unix.S branches/redhat/gcc-4_1-branch/libffi/src/m68k/sysv.S branches/redhat/gcc-4_1-branch/libffi/src/powerpc/linux64.S branches/redhat/gcc-4_1-branch/libffi/src/powerpc/linux64_closure.S branches/redhat/gcc-4_1-branch/libffi/src/powerpc/ppc_closure.S branches/redhat/gcc-4_1-branch/libffi/src/powerpc/sysv.S branches/redhat/gcc-4_1-branch/libffi/src/s390/sysv.S branches/redhat/gcc-4_1-branch/libffi/src/sparc/v8.S branches/redhat/gcc-4_1-branch/libffi/src/sparc/v9.S branches/redhat/gcc-4_1-branch/libffi/src/x86/sysv.S branches/redhat/gcc-4_1-branch/libffi/src/x86/unix64.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21098
[Bug libfortran/24794] problem with namelist input of character array
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2005-11-23 20:57 --- Fixed in 4.1 and 4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
[Bug libgcj/24798] classmap.db should reside in /var/lib/gcj/
-- fitzsim at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fitzsim at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 21:01:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24798
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #9 from dir at lanl dot gov 2005-11-23 21:18 --- Created an attachment (id=10329) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10329&action=view) The preprocessed output for environ.c The preprocessed output for environ.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug middle-end/24997] [4.1/4.2 regression] ICE with -ftree-vectorize
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-23 21:38 --- Actually this bug is too funny to reduce, reload is too funny for the life of me. Compiling with -da with a semi reduced testcases makes it pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24997
[Bug target/25008] New: problems with "S" constraint in asms
The following testcase compiles with gcc-4.0, but generates an error with
optimization with gcc-4.1.
int *
sub (int *i, int k)
{
int j;
for (j = 0; j < 16; j++)
{
asm volatile ("foo %0" : "=S" (*i));
i += k;
}
return i;
}
aretha$ ./xgcc -B./ -O2 -S -da tmp.c
tmp.c: In function sub:
tmp.c:7: error: asm operand requires impossible reload
This was broken by my patch that defined EXTRA_MEMORY_CONSTRAINT.
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00714.html
I didn't have a testcase for that at the time, but now that I've run into
trouble, I went to the effort of creating of creating one. It required adding
two letters, and deleting one. The following testcase fails when compiled
without optimization with gcc-4.0.
int *
sub (int *i, int k)
{
int j;
for (j = 0; j < 16; j++)
{
asm volatile ("foo %0" : : "S" (*i));
i += k;
}
return i;
}
aretha$ ./xgcc -B./ -S -da tmp2.c
tmp2.c: In function sub:
tmp2.c:7: error: impossible constraint in asm
The reason why defining EXTRA_MEMORY_CONSTRAINT fails for the first example is
because asm_operand_ok has code that says any memory operand is OK if
EXTRA_MEMORY_CONSTRAINT is true because it can be reloaded to fit. This is
true in theory. Unfortunately, reload doesn't know how to fix a MEM with a
POST_MODIFY address. It fixes all MEMs that didn't quite match a MEM
constraint where an offsettable address is OK by reloading the address.
else if (goal_alternative_matched[i] == -1
&& goal_alternative_offmemok[i]
&& MEM_P (recog_data.operand[i]))
{
operand_reloadnum[i]
= push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,...
So if we have an operand (MEM (POST_MODIFY ...)) it is fixed by emitting an
insn (set (reg) (POST_MODIFY ...)) which fails to be recognized triggering the
error. find_reloads_address knows how to fix this, but of course did not do
anything because this address is accepted by GO_IF_LEGITIMATE_ADDRESS.
The second example fails without EXTRA_MEMORY_CONSTRAINT defined because of
parse_input_constraint in stmt.c. If EXTRA_CONSTRAINT_STR is not defined, then
it decides that no operand is acceptable. When I posted the earlier patch, I
mentioned that it looked like we had a misplaced #endif, since the default here
should be to just accept all operands if we can't handle the constraint letter.
Unfortunately, taking a second look, I see that a parse_input_constraint change
doesn't work, because gimplify_asm_expr gives me the MEM operand I need only if
!allows_reg.
So it looks like I have to try to fix reload if I want this to work.
--
Summary: problems with "S" constraint in asms
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25008
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #10 from jakub at gcc dot gnu dot org 2005-11-23 21:57 --- That looks sane, using __weakref__ attribute and on powerpc64-linux -> powerpc-apple-darwin8.3.0 cross I verified it creates also reasonable assembly. So, can you look through all object files that are linked into libgfortran.1.dylib and see with say nm which object actually references ___gthrw_* routines? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug target/24961] No constraint letter for destination_operand
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-23 22:05 --- Confirmed. I believe 25008 will have to be fixed before we can add a working constraint letter for this. It should be possible to generate a testcase for this by taking the example from 25008, changing the "S" to an "m", and then changing foo to a valid store instruction syntax so as to get the desired assembler error. I'll worry about that later when I need a testcase. -- wilson at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25008 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 22:05:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24961
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #11 from dir at lanl dot gov 2005-11-23 22:09 --- Created an attachment (id=10330) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10330&action=view) nm of the gfortran libraries References to the "gthrw" routines seem to be everywhere. (I am out of here till next Monday) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #12 from jakub at gcc dot gnu dot org 2005-11-23 22:12 --- Before you leave, can you still preprocess say unit.c or unix.c the same way you did it for environ.c? Or, if it is too late, can anyone else with access to ppc darwin reproduce it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #11 from amodra at gcc dot gnu dot org 2005-11-23 22:15 --- Subject: Bug 24950 Author: amodra Date: Wed Nov 23 22:15:16 2005 New Revision: 107433 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107433 Log: PR middle-end/24950 * expmed.c (store_bit_field): Don't attempt to insv a field larger than the reg. Merge from trunk 2005-11-14 Dale Johannesen <[EMAIL PROTECTED]> * expmed.c (store_bit_field): Add offset unconditionally for memory targets. (extract_bit_field): Don't force extzv or extv operand into a register if field is too big. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #12 from amodra at bigpond dot net dot au 2005-11-23 22:16 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #13 from amodra at gcc dot gnu dot org 2005-11-23 22:31 --- Subject: Bug 24950 Author: amodra Date: Wed Nov 23 22:31:26 2005 New Revision: 107434 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107434 Log: PR middle-end/24950 Copy from trunk 2005-11-14 Dale Johannesen <[EMAIL PROTECTED]> * gcc.c-torture/execute/20051113-1.c: New. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.c-torture/execute/20051113-1.c - copied unchanged from r106920, trunk/gcc/testsuite/gcc.c-torture/execute/20051113-1.c Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #13 from bonzini at gcc dot gnu dot org 2005-11-23 22:34 --- I can try tomorrow. To trigger this it's enough to do a in-srcdir c,fortran,objc build, right? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug fortran/23912] MOD function requires same kind arguments
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-23 22:51 --- Patch submitted for that bug. Waiting for approval. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2005-11/ Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-09-17 02:05:23 |2005-11-23 22:51:17 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23912
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #36 from ebotcazou at gcc dot gnu dot org 2005-11-23 23:28 --- > i always do a full bootstrap with different flags for stage1 and 2+. That doesn't cover the Ada tools. They build for me at -O0 on PowerPC so with Andrew's FE patch + a possible tweak in the Makefile, you should have an Ada compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug ada/22533] [4.1/4.2 regression] Ada ICE during bootstrap on many platforms
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2005-11-23 23:29 --- Created an attachment (id=10331) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10331&action=view) Andrew's FE patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533
[Bug c++/21123] [4.0/4.1 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #32 from jason at gcc dot gnu dot org 2005-11-23 23:56 ---
My earlier patch fixed all the reduced testcases, but not the unreduced one.
Here's a reduced testcase that still fails (adding a by-value parm to the
virtual function):
struct A
{
A(const A &a);
const A& operator=(const A& a);
};
struct B
{
virtual A f(A);
};
struct C : virtual B
{
virtual A f(A);
};
A C::f(A a)
{
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug bootstrap/24873] gcc 4.0.2 bootstrap report compare fail
--- Comment #3 from gaojianbin at 263 dot net 2005-11-24 00:22 --- ../gcc-4.0.2/configure --prefix=/swtdata/emv_emu/emu1/jbgao/gccbin --enable-threads=aix --enable-languages="c ,c++" --with-included-gettext --enable-shared --disable-multilib make bootstrap use the cc compiler;ibm visual age version 6 here is the output. // echo timestamp > stage3_build echo stage3_build > stage_last Bootstrap complete - make "quickstrap" to redo last build, "restage1" through "restage3" to rebuild specific stages, "restrap" to redo the bootstrap from stage1, or "cleanstrap" to redo the bootstrap from scratch. make[1]: Leaving directory `/swtdata/emv_emu/emu1/jbgao/gccbin/gcc' Comparing stage2 and stage3 of the compiler make[1]: Entering directory `/swtdata/emv_emu/emu1/jbgao/gccbin/gcc' rm -f .bad_compare case "slowcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo slowcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1,'` ;; esac; \ for dir in . cp build; do \ if [ "`echo $dir/*.o`" != "$dir/*.o" ] ; then \ for file in $dir/*.o; do \ case "slowcompare" in \ slowcompare* ) \ tail +16c ./$file > tmp-foo1; \ tail +16c stage$stage/$file > tmp-foo2 \ && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $file differs >> .bad_compare) || true; \ ;; \ fastcompare* ) \ cmp $file stage$stage/$file 16 16 > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ gnucompare* ) \ cmp --ignore-initial=16 $file stage$stage/$file > /dev/null 2>&1; \ test $? -eq 1 && echo $file differs >> .bad_compare || true; \ ;; \ esac ; \ done; \ else true; fi; \ done rm -f tmp-foo* case "slowcompare" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo slowcompare | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1,'` ;; esac; \ if [ -f .bad_compare ]; then \ echo "Bootstrap comparison failure!"; \ cat .bad_compare; \ exit 1; \ else \ case "slowcompare" in \ *-lean ) rm -rf stage$stage ;; \ *) ;; \ esac; true; \ fi Bootstrap comparison failure! ./fold-const.o differs make[1]: *** [slowcompare] Error 1 make[1]: Leaving directory `/swtdata/emv_emu/emu1/jbgao/gccbin/gcc' make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24873
[Bug libfortran/24794] problem with namelist input of character array
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-24 00:49 --- Fixed in 4.1 and 4.2, if someone has a dieing need for this in 4.0 let me know and I will commit the fix there as well. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24794
