[Bug c/34993] [4.1/4.2 regression] ICE with attribute for array with unknown bound
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-31 08:17 --- Fixed on the trunk, thanks. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.0 Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with attribute for array|with attribute for array |with unknown bound |with unknown bound http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34993
[Bug target/34982] [4.3 regression] calling a function with undefined parameters causes segmentation fault at -O1 or higher
--- Comment #24 from ubizjak at gmail dot com 2008-01-31 08:21 --- Author: hubicka Date: Wed Jan 30 23:25:35 2008 New Revision: 131969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131969 Log: * gcc.c-torture/execute/pr34982.c: Add forgotten return 0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/execute/pr34982.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-31 08:30 --- (In reply to comment #4) Reply to comment two: There is front-endery code to do cond ? a : b in the handling of missing optional dummy arguments. You can borrow from that. I know about the TREE_SSA expressions - what I need is a frontend, ie. a gfc_expr that delivers this functionality. The bit of code that needs sorting is manipulating gfc_expressions. The reason that this is necessary, is that the conditional operators carry over the magnitude of the conditional expression: i = 4 = (i 0) * f = 4*f when implemented with gfc binops. In writing this, I realise that I never tried to convert the (i 0) to logical but I do not think that it would make any difference. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 09:26 --- Subject: Bug 34995 Author: rsandifo Date: Thu Jan 31 09:25:52 2008 New Revision: 131976 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131976 Log: gcc/ PR rtl-optimization/34995 * reload.c (alternative_allows_const_pool_ref): Take an rtx parameter and return a bool. If the rtx parameter is nonnull, check that it satisfies an EXTRA_MEMORY_CONSTRAINT. (find_reloads): Update call accordingly. Pass the new operand if it needed no address reloads, otherwise pass null. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug target/34995] [4.3 Regression] MIPS16 ICE in gcc.c-torture/compile/pr34856.c
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-01-31 09:28 --- Patch applied. Thanks to Ian for the review. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34995
[Bug tree-optimization/17863] [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??)
--- Comment #39 from rguenther at suse dot de 2008-01-31 09:39 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??) On Wed, 30 Jan 2008, stevenb dot gcc at gmail dot com wrote: --- Comment #37 from stevenb dot gcc at gmail dot com 2008-01-30 20:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as much??) Those seems to be all just array manipulations. AFAICT, they are exactly in the form that some targets like it (e.g. auto-inc/dec and SMALL_REGISTER_CLASS targets). They also don't operate on arrays, so we cannot use ARRAY_REF in the IL. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17863
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 09:49 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||ABI, wrong-code Last reconfirmed|2008-01-30 22:18:24 |2008-01-31 09:49:21 date|| Summary|Has any one managed to run |[4.3 Regression] Has any one |the libjava test suite on |managed to run the libjava |powerpc-apple-darwin9? |test suite on powerpc-apple- ||darwin9? Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug c/35039] New: ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
Hello, I'd like to report that there is the ICE happened when the linux-2.6.23 NFS code is compiled using gcc-4.0.0: CC fs/nfs/nfs4proc.o fs/nfs/nfs4proc.c: In function 'nfs4_proc_readdir': fs/nfs/nfs4proc.c:2237: error: unrecognizable insn: (insn:HI 205 202 207 12 (set (reg:SI 126 [ D.22481 ]) (mem/s/f/j:SI (subreg:SI (reg:DI 190) 4) [0 variable.vm_mm+0 S4 A32])) -1 (nil) (expr_list:REG_EQUAL (mem/s/j:SI (const_int 0 [0x0]) [0 variable.vm_mm+0 S4 A32]) (nil))) fs/nfs/nfs4proc.c:2237: internal compiler error: in extract_insn, at recog.c:2020 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Some observations: (a) if I make the _nfs4_proc_readdir() function (or the nfs4_setup_readdir() one which is called from it) in fs/nfs/nfs4proc.c as noinline then gcc-4.0.0 compiles the nfs4proc.c file without problems; (b) there are no problems for gcc-4.0.0 to compile fs/nfs/nfs4proc.c from the 2.6.24 kernel (some changes were made to this file since 2.6.23, but these are not concerned to the function which produces the ICE); (c) gcc-4.2.2 successfully compiles the 2.6.23 kernel, i.e. there's no this ICE happened with this compiler. I guess, the problem is concerned with the following RTX: mem/s/f/j:SI (subreg:SI (reg:DI 190) 4) I've dumped the results of compiler's RTL passes for all the kernel files (including fs/nfs/nfs4proc.c) in the cases of using both gcc-4.0.0 and gcc-4.2.2, and found that: - gcc-4.0.0 produces similar RTXs in the nfs4proc.c case only; - gcc-4.2.2 never produces similar RTXs through all the Linux kernel files (in the RTX, which produces the error, the gcc-4.2.2 compiler keeps the expression reg:SI XXX instead of subreg:SI (reg:DI YYY) 4 through all the RTL iterations). The Linux kernel I compiled is the DENX-v2.6.23-stable branch of the git://www.denx.de/git/linux-2.6-denx.git tree. The gcc-4.0.0 compiler is the part of ELDK 4.1. The target system is stx_gp3ssa. # git-checkout DENX-v2.6.23-stable # make ARCH=ppc CROSS_COMPILE=ppc_85xx- stx_gp3ssa_defconfig # make ARCH=ppc CROSS_COMPILE=ppc_85xx- uImage Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com -- Summary: ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross- compile with gcc-4.0.0 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yur at emcraft dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: ppc_85xx-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-31 10:11 --- Created an attachment (id=15062) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15062action=view) patch final patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 10:12 --- Testing on ppc-darwin appreciated ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-31 10:01 --- After applying the patch in comment #2 on top of rev. 131968, I am not having hanging so far, but apparently all the executables are timed out (?) after having taken ~40s: ... Executing on host: /opt/gcc/darwin_buildw/gcc/xgcc -B/opt/gcc/darwin_buildw/gcc/ /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jni/bytebuffer.c -dynamiclib -fPIC -I. -I.. -I/opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jni -fdollars-in-identifiers -Wmissing-prototypes -I/opt/gcc/gcc-4.3-work/libjava/testsuite/../include -I/opt/gcc/gcc-4.3-work/libjava/testsuite/../classpath/include -lm -o libbytebuffer.dylib(timeout = 300) PASS: bytebuffer.c compilationset_ld_library_path_env_vars: ld_library_path=.:/opt/gcc/darwin_buildw/powerpc-apple-darwin9/./libjava/.libsExecuting on host: /opt/gcc/darwin_buildw/powerpc-apple-darwin9/libjava/testsuite/../libtool --silent --tag=GCJ --mode=link /opt/gcc/darwin_buildw/gcc /gcj -B/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libjava/ -B/opt/gcc/darwin_buildw/gcc/ --encoding=UTF-8 -B/opt/gcc/darwin_buildw/powerpc-apple-darwin9/libjava/testsuite/../ /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jni/bytebuffer.jar -w -no-install -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute -fjni --main=bytebuffer -g -L/opt/gcc/darwin_buildw/powerpc-apple-darwin9/./libjava/.libs -lm -o bytebuffer(timeout = 300) PASS: linking bytebuffer set_ld_library_path_env_vars: ld_library_path=.:/opt/gcc/darwin_buildw/powerpc-apple-darwin9/./libjava/.libs Setting LD_LIBRARY_PATH to .:/opt/gcc/darwin_buildw/powerpc-apple-darwin9/./libjava/.libs:.:/opt/gcc/darwin_buildw/powerpc-apple-darwin9/./libjava/.libs Exception during runtime initialization FAIL: bytebuffer run UNTESTED: bytebuffer output ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug c/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
--- Comment #1 from yur at emcraft dot com 2008-01-31 09:59 --- Created an attachment (id=15060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15060action=view) This is the file, which produces the ICE described -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug c/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
--- Comment #2 from yur at emcraft dot com 2008-01-31 10:00 --- Created an attachment (id=15061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15061action=view) This is the dump of GCC-4.0.0 iterations when compiles the file which produce the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 10:35 ---
I suppose the static function
static const unsigned char *
read_uleb128 (const unsigned char *p, _uleb128_t *val)
{
in unwind-pe.h should be marked 'inline', otherwise it will be emitted
multiple times to the asm file by -combine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug gcov-profile/35038] GCOV - using --coverage results in libgcov.a(_gcov.o) is referenced by DSO
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 10:39 --- Coverage and shared libraries do not mix easily. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35038
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-31 10:44 --- The static size_of_encoded_value's are supposed to be mangled when --combine, like size_of_encoded_value.12521 and on a simple testcase with --combine on x86_64-linux/trunk they are. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-31 10:35 --- After applying the patch in comment #2 on top of rev. 131968, After a check, I realized that I applied the patch in the wrong directory, so the behavior reported in comment #4 is for the unpatched rev. 131968. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug fortran/35040] New: usage of init expression in its own definition
REAL, DIMENSION(2,2), PARAMETER :: xyz = RESHAPE((/ 1,2,3,4 /), SHAPE(xyz)) END This is accepted by gfortran and all other compilers Tobias tested. However, neither of us is sure whether it's valid or not. For any invalid example, see also: PR34495. -- Summary: usage of init expression in its own definition Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug bootstrap/33781] [4.3 Regression] Arg list too long building libgcc.a
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2008-01-31 10:38 --- (In reply to comment #8) I'll respond to Jakub's latest comments before trying DJ's more recent patch. Running getconf ARG_MAX on my IRIX box, returns 20480, which is 20K. I believe this is the default, out of the box setting for my machine which is running IRIX 6.5.19m. I've had the same problem, and it indeed goes away if you set your ARG_MAX to something higher (I have 262144, which is the maximum possible value). It is even mentioned in the target specific installation notes, though it says there it is only required for Java. Maybe the target notes should be updated? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33781
[Bug rtl-optimization/34773] [4.3 Regression] miscompilation of vfprintf_r
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 10:40 --- Regressions should have a target milestone. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression]|[4.3 Regression] |miscompilation of vfprintf_r|miscompilation of vfprintf_r Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34773
[Bug c/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 10:43 --- We need preprocessed source of nfs4proc.c which you'll get as nfs4proc.i if you add -save-temps to the gcc command-line. Also please try 4.0.4 or a still maintained release like 4.2.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug c/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
--- Comment #4 from yur at emcraft dot com 2008-01-31 10:54 --- Richard, The gcc 4.2.2 successfully compiles this code without ICEs (see the item (c) in my description of the ICE). As far as the preprocessed source of nfs4proc.c is concerned, here it is... Regards, Yuri -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug c/35039] ICE in Linux-2.6.23 (fs/nfs/nfs4proc.c) when cross-compile with gcc-4.0.0
--- Comment #5 from yur at emcraft dot com 2008-01-31 10:55 --- Created an attachment (id=15063) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15063action=view) The preprocessed source of file which produces the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35039
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #8 from andreast at gcc dot gnu dot org 2008-01-31 11:12 --- bootstrap started on ppc-darwin. -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug fortran/35040] usage of init expression in its own definition
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-31 12:22 --- I think this is valid. One has to read carefully what specification-part and entity-decl means. I think after integer(8) the kind is known and in the next specification part (e.g. for the dimension) one may use it; similar for your example: After the bounds are known in the specification (i.e. before ::) one may use it in the entry decl. However, the following is circular and thus invalid: REAL(8), PARAMETER :: xyz(size(xyz)) = 1 which is rejected by NAG f95: Error: Shape enquiry on PARAMETER XYZ before its array declarator is complete but gfortran wrongly accepts it. I wonder whether the following is valid or not: REAL(8), dimension(kind(xyz)) :: xyz NAG f95 and gfortran say yes, ifort says no. That dimension depends on the kind is ok, the problem is whether one may already use xyz or not. From 7.1.7 Initialization expression (F2003): If an initialization expression includes a specification inquiry that depends on a type parameter or an array bound of an entity specified in the same specification-part, the type parameter or array bound shall be specified in a prior specification of the specification-part. The prior specification may be to the left of the specification inquiry in the same statement, but shall not be within the same entity-decl. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-31 12:28 --- bootstrap started on ppc-darwin. After having applied the patch in the right directory and an incremental make on Darwin9, I still ahve the same failures: FAIL: PR9577 run FAIL: longfield run FAIL: shortfield run Running /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jar/jar.exp ... FAIL: TestClosureGC run FAIL: /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jar/TestClosureGC.jar execution - gij test FAIL: simple run FAIL: /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jar/simple.jar execution - gij test Running /opt/gcc/gcc-4.3-work/libjava/testsuite/libjava.jni/jni.exp ... FAIL: PR15133 run FAIL: PR18116 run FAIL: PR28178 run FAIL: bytebuffer run FAIL: calls run FAIL: cxxtest run FAIL: directbuffer run FAIL: field run FAIL: final_method run FAIL: findclass run FAIL: findclass2 run FAIL: iface run FAIL: init run I am now starting a fresh build (~12 hours). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug fortran/35036] illegal E format descriptor produces wrong output
--- Comment #10 from burnus at gcc dot gnu dot org 2008-01-31 12:46 --- (In reply to comment #9) Sun f95 gives: Error 1078: scale factor out of range ifort gives: g95 and openf95 give the same result as ifort: While NAG f95 follows sunf95 by giving the run-time error: Scale factor 0 out of range for d=0 This is for write(*, '(E8.0)') 1e5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
[Bug fortran/35040] usage of init expression in its own definition
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-31 12:39 --- I asked at comp.lang.fortran: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a05b8b177f2eb7b1/ -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug fortran/34910] [4.2/4.3 Regression] ICE on invalid assignments in doubly-contained functions
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-31 12:39 --- Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00373.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #10 from andreast at gcc dot gnu dot org 2008-01-31 12:51 --- You'd need at least a fresh build of libstdc++ and libjava. An incremental build failed for me as well. So I have rm -rf'ed the two libraries. And I saved a complete bootstrap :) That was for yesterdays trial. Right now in building runtime libs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #11 from andreast at gcc dot gnu dot org 2008-01-31 13:30 --- Applying the patch from #5 on r131976 Results here: /Volumes/development/gcc/head/gcc/libjava/jni.cc: In function 'T extract_from_jvalue(const jvalue) [with T = jboolean]': /Volumes/development/gcc/head/gcc/libjava/jni.cc:470: internal compiler error: in emit_move_insn, at expr.c:3379 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [jni.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-target-libjava] Error 2 make: *** [bootstrap] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
Our remedies oft in ourselves do.
Andexpertness in wars or.
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-31 14:19 --- I guess this should be P1, ppc-darwin is still a secondary platform and we shouldn't break its libjava ABI. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug fortran/35037] VOLATILE attribute not being honored with common block variable
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-31 13:59 ---
trans-decl has:
if (sym-attr.volatile_)
{
TREE_THIS_VOLATILE (decl) = 1;
new = build_qualified_type (TREE_TYPE (decl), TYPE_QUAL_VOLATILE);
TREE_TYPE (decl) = new;
}
However, variables which are in COMMON blocks have their symbols generated in
trans-common.c.
One should try to mark as little as possible as VOLATILE to allow more
optimization. (Fortran 2003 allows a use/host-associated variable to be marked
as volatile, i.e. if it is used elsewhere it is not volatile.)
As vendor extension (incl. g77) one can mark also a complete common block as
volatile: PR 34928.
EQUIVALENT should be checked as well.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|i686-pc-cygwin |
GCC target triplet|i686-pc-cygwin |
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-01-31 13:59:37
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35037
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-01-31 14:14 --- Created an attachment (id=15064) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15064action=view) patch D*mn. Try this one. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #15062|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug libstdc++/35000] #include sometimes fails in namespaces
--- Comment #3 from bangerth at dealii dot org 2008-01-31 14:53 --- This way you make the compiler believe that all the functions are in a namespace when the compiler that compiled these functions into a .dll assumed that they are not. This can't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35000
[Bug middle-end/35041] [4.3 Regression] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-31 14:47 --- Eh, how is this a regression? Was struct-reorg in 4.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
[Bug middle-end/35041] New: ICE in tree-ssa-ccp.c with -fipa-struct-reorg
The following testcase fails for me when compiled with -O3 -fwhole-program
-fdump-ipa-all -combine -fipa-type-escape -fipa-struct-reorg
#include stdlib.h
typedef struct test_struct
{
int a;
int b;
} type_struct;
typedef type_struct **struct_pointer2;
struct_pointer2 str1;
int main()
{
int i, j;
str1 = malloc (2 * sizeof (type_struct*));
for (i=0; i=1; i++)
str1[i] = malloc (2 * sizeof (type_struct));
return 0;
}
The failure is:
try11.c: In function 'main':
try11.c:23: internal compiler error: in create_general_new_stmt, at
ipa-struct-reorg.c:1323
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in tree-ssa-ccp.c with -fipa-struct-reorg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alond at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
[Bug c/35034] [4.3 Regression] assembler errors when building gcc/unwind-*.c at -O0 or -O1
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-31 15:05 --- Works with gcc-4.1.2 (if one prunes the 'static' of the weakref; They were required to be public back then): $ gcc-4.1 pr35034-1.c pr35034-2.c -O0 -S -o - -combine -pipe .file pr35034-1.c .text .globl size_of_encoded_value .type size_of_encoded_value, @function size_of_encoded_value: pushl %ebp movl%esp, %ebp popl%ebp ret .size size_of_encoded_value, .-size_of_encoded_value .weakref__gthrw_pthread_once,pthread_once .ident GCC: (GNU) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) .section.note.GNU-stack,,@progbits -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 Summary|assembler errors when |[4.3 Regression] assembler |building gcc/unwind-*.c at -|errors when building |O0 or -O1 |gcc/unwind-*.c at -O0 or -O1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug middle-end/35041] [4.3 Regression] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 14:39 --- Confirmed. ICEs with -O -fwhole-program -fipa-type-escape -fipa-struct-reorg -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-31 14:39:22 date|| Summary|ICE in tree-ssa-ccp.c with -|[4.3 Regression] ICE in |fipa-struct-reorg |tree-ssa-ccp.c with -fipa- ||struct-reorg Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-31 14:47 ---
Smaller testcase:
---
$ cat pr35034-1.c
/* PR 35034 - fails to mangle function names for different TUs. */
/* { dg-do compile } */
/* { dg-options -combine -O0 } */
/* { dg-additional-sources pr35034-2.c } */
typedef int int_t;
static void
size_of_encoded_value (void)
{
};
extern int pthread_once (int_t *__once_control,
void (*__init_routine) (void));
static __typeof(pthread_once) __gthrw_pthread_once __attribute__
((__weakref__(pthread_once)));
---
$ cat pr35034-2.c
void size_of_encoded_value (void)
{
};
---
Gives with current trunk:
$ gcc-4.3-HEAD pr35034-1.c pr35034-2.c -O0 -c -o foo.o -combine -pipe
{standard input}: Assembler messages:
{standard input}:12: Error: symbol `size_of_encoded_value' is already defined
$ gcc-4.3-HEAD pr35034-1.c pr35034-2.c -O0 -S -o - -combine -pipe
.file pr35034-1.c
.text
.type size_of_encoded_value, @function
size_of_encoded_value:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size size_of_encoded_value, .-size_of_encoded_value
.globl size_of_encoded_value
.type size_of_encoded_value, @function
size_of_encoded_value:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.size size_of_encoded_value, .-size_of_encoded_value
.weakref__gthrw_pthread_once,pthread_once
.ident GCC: (GNU) 4.3.0 20080131 (experimental)
.section.note.GNU-stack,,@progbits
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, wrong-code
Known to fail||4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1 with IMA
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-31 15:10 --- Fails with 4.1.2 for me as well, with the static. w/o 4.1 complains t1.c:5: error: '__gthrw_pthread_once' defined both normally and as an alias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug middle-end/35041] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #4 from olga at gcc dot gnu dot org 2008-01-31 15:18 ---
The following test fixes the problem. Under the testing now.
Index: ipa-struct-reorg.c
===
--- ipa-struct-reorg.c (revision 131976)
+++ ipa-struct-reorg.c (working copy)
@@ -887,7 +887,9 @@
tree ref = r_pos-ref;
tree t = *tp;
- if (t == ref)
+ if (t == ref ||
+ (TREE_CODE (t) == SSA_NAME
+SSA_NAME_VAR (t) == ref))
{
r_pos-pos = tp;
return t;
Olga
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1 with IMA
--- Comment #9 from aldot at gcc dot gnu dot org 2008-01-31 15:18 --- (In reply to comment #7) Fails with 4.1.2 for me as well, with the static. w/o 4.1 complains t1.c:5: error: '__gthrw_pthread_once' defined both normally and as an alias Works flawlessly for me (without the static, on debian with the debian-patched cc): $ gcc-4.1 pr35034-1.c pr35034-2.c -O0 -c -o foo.o -combine -pipe ; echo $? 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1 with IMA
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-01-31 15:20 --- That's a accepts-invalid problem on 4.1, try the same thing with the reduced testcase from comment #6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug middle-end/35041] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #3 from olga at gcc dot gnu dot org 2008-01-31 15:11 --- (In reply to comment #2) Eh, how is this a regression? Was struct-reorg in 4.2? Of course not. Olga -- olga at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] ICE in |ICE in tree-ssa-ccp.c with - |tree-ssa-ccp.c with -fipa- |fipa-struct-reorg |struct-reorg| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35041
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1 with IMA
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-31 15:08 ---
Confirmed. The following also fails with optimization:
t1.c:
static void __attribute__((used))
size_of_encoded_value (void)
{
};
static int __gthrw_pthread_once __attribute__ ((__weakref__(pthread_once)));
t2.c:
void size_of_encoded_value (void)
{
};
Not a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to work|4.1.2 |
Last reconfirmed|-00-00 00:00:00 |2008-01-31 15:08:10
date||
Summary|[4.3 Regression] assembler |assembler errors when
|errors when building|building gcc/unwind-*.c at -
|gcc/unwind-*.c at -O0 or -O1|O0 or -O1 with IMA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug c/35034] assembler errors when building gcc/unwind-*.c at -O0 or -O1 with IMA
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-31 15:11 ---
(In reply to comment #2)
I suppose the static function
static const unsigned char *
read_uleb128 (const unsigned char *p, _uleb128_t *val)
{
in unwind-pe.h should be marked 'inline', otherwise it will be emitted
multiple times to the asm file by -combine.
unwind-pe.h as a header should provide an interface to and not implementations
of the required functions. Apart from fixing the functions in IMA, unwind-pe.h
should split it's implementations off into a e.g. unwind-pe.c that exports the
common helpers.
Does somebody know if it is really intended that dwarf2asm.c has grown (or
kept) a different impl of size_of_encoded_value() than all the rest?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35034
[Bug other/35042] New: Documentation for -finline-limit is incorrect
Documentation states that the default value of -finline-limit is 600. However, if -finline-limit=600 is actually used with -O3, the code size is much bigger than if it weren't used with -O3. The real default value seems to be closer to 180. Default values specified for max-inline-insns-single (450) and max-inline-insns-auto(90) are not consistent with being -finline-limit / 2. This is important to fix for people who want to play around with -finline-limit value -- it's good to know what your base is before you change it. -- Summary: Documentation for -finline-limit is incorrect Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ddenisen at altera dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 15:54 --- -finline-limit=N should be deprecated. It is an alias for --param max-inline-insns-single=N/2 --param max-inline-insns-auto=N/2. There is no real default, instead the defaults for max-inline-insns-single is 450, the one for max-inline-insns-auto is 90. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-31 15:54:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug fortran/34868] ICE with -ff2c for function returning a complex number
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-31 15:36 --- That one is not a regression. It happens because, when the a argument is an assumed-shape array, gfc_return_by_reference() return 0 because sym-attr.always_explicit is set for the function. There are two interesting comments about that in trans-types.c: /* Possibly return complex numbers by reference for g77 compatibility. We don't do this for calls to intrinsics (as the library uses the -fno-f2c calling convention), nor for calls to functions which always require an explicit interface, as no compatibility problems can arise there. */ /* Special case: f2c calling conventions require that (scalar) default REAL functions return the C type double instead. f2c compatibility is only an issue with functions that don't require an explicit interface, as only these could be implemented in Fortran 77. */ So I guess the answer is: assumed-shape array and f2c calling conventions are mutually incompatible. From that point, a few courses of action are possible. The best of all, IMHO, is to document the fact and error out when someone tries that thing. F2C callings conventions aren't, by definition, usable for F95 code. PS: this is not a regression, the ICE was already in 4.1.2 and 4.2.2. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Known to fail||4.1.2 4.2.2 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34868
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #5 from ddenisen at altera dot com 2008-01-31 16:13 ---
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
more aggressive inlining and what is not.
Why don't you make max-inline-insns-single = 5*n/2 and max-inline-insns-auto =
n/2? This way, we have a default that is consistent with current settings and
setting -finline-limit=180 gives you exactly the default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #6 from rguenther at suse dot de 2008-01-31 16:22 ---
Subject: Re: Documentation for -finline-limit is incorrect
On Thu, 31 Jan 2008, ddenisen at altera dot com wrote:
--- Comment #4 from ddenisen at altera dot com 2008-01-31 16:12 ---
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
more aggressive inlining and what is not.
Why don't you make max-inline-insns-single = 5*n/2 and max-inline-insns-auto =
n/2? This way, we have a default that is consistent with current settings and
setting -finline-limit=180 gives you exactly the default.
Actually this would be a change in behavior (the current behavior is at
least present since gcc 3.3). We can retain a hint at in which range
the default value lies for functions explicitly marked as inline (around
900).
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 16:05 ---
I agree, just the switch will have different effects with different releases.
I will correct the documentation to something like
@item [EMAIL PROTECTED]
@opindex finline-limit
By default, GCC limits the size of functions that can be inlined. This flag
allows coarse control of this limit. @var{n} is the size of functions that
can be inlined in number of pseudo instructions.
Inlining is actually controlled by a number of parameters, which may be
specified individually by using @option{--param @[EMAIL PROTECTED]
The @[EMAIL PROTECTED] option sets some of these parameters
as follows:
@table @gcctabopt
@item max-inline-insns-single
is set to @var{n}/2.
@item max-inline-insns-auto
is set to @var{n}/2.
@end table
See below for a documentation of the individual
parameters controlling inlining and for the defaults of these parameters.
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
@emph{Note:} pseudo instruction represents, in this particular context, an
abstract measurement of function's size. In no way does it represent a count
of assembly instructions and as such its exact meaning might change from one
release to an another.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-31 15:54:43 |2008-01-31 16:04:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #2 from ddenisen at altera dot com 2008-01-31 15:59 --- (In reply to comment #1) -finline-limit=N should be deprecated. It is an alias for --param max-inline-insns-single=N/2 --param max-inline-insns-auto=N/2. There is no real default, instead the defaults for max-inline-insns-single is 450, the one for max-inline-insns-auto is 90. Having a single knob to control inlining is more user-friendly. If possible, consider keeping it (GCC already has way too many options and parameters to control). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #4 from ddenisen at altera dot com 2008-01-31 16:12 ---
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
more aggressive inlining and what is not.
Why don't you make max-inline-insns-single = 5*n/2 and max-inline-insns-auto =
n/2? This way, we have a default that is consistent with current settings and
setting -finline-limit=180 gives you exactly the default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
--- Comment #12 from rth at gcc dot gnu dot org 2008-01-31 16:34 --- Looks like a bad REG_EQUAL note -- it's got a wrong (or confusing) mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-30 18:33:12 |2008-01-31 16:31:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug other/35042] Documentation for -finline-limit is incorrect
--- Comment #7 from ddenisen at altera dot com 2008-01-31 16:40 --- If the default behaviour has to stay, then I think the option should be removed. Having no option is better than having an option with an unreproducible default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
[Bug middle-end/35043] ICE in tree-data-ref because signed_type_for_types returns NULL
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-31 17:23 ---
Reduced testcase:
typedef long unsigned int size_t;
typedef struct {
long double dat[2];
} gsl_complex_long_double;
typedef struct {
size_t size;
size_t stride;
long double *data;
} gsl_vector_complex_long_double;
void gsl_vector_complex_long_double_set_zero (gsl_vector_complex_long_double *
v)
{
long double * const data = v-data;
const size_t n = v-size;
const size_t stride = v-stride;
const gsl_complex_long_double zero = { { 0.0L,0.0L} } ;
size_t i;
for (i = 0; i n; i++)
*(gsl_complex_long_double *) (data + 2 * i * stride) = zero;
}
tree.c:signed_or_unsigned_type_for doesn't handle bit_size_type specially
which has TImode and a precision of 68.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-31 17:23:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35043
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
--- Comment #13 from rth at gcc dot gnu dot org 2008-01-31 17:23 --- Created an attachment (id=15066) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15066action=view) proposed fix There's two things we can do. First, we could modify loop-iv.c to cope with a CCmode REG_EQUAL note associated with an integral register as a part of a libcall. Certainly there's nothing about the FP comparison that's going to interest the rest of that function. Second, we can assume that the tree optimizers have done all the CSE that's really going to happen and eliminate the libcall notes at the rtl level as obsolete. Certainly the later option is safer, as it affects no one but Alpha, and it eliminates a potentially confusing reg note. This fixes the testcase for cross-compile. I'm trying to build it natively now, but as the machine has locked up once already I'm affeared my last Alpha machine is on it's last legs. Someone else should try to build it as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug tree-optimization/35043] New: ICE in tree-data-ref because signed_type_for_types returns NULL
1510 type = signed_type_for_types (TREE_TYPE (chrec_a), TREE_TYPE (chrec_b)); 1511 chrec_a = chrec_convert (type, chrec_a, NULL_TREE); (gdb) p type $4 = (tree) 0x0 and we then ICE in #0 0x0064bc08 in fold_convert (type=0x0, arg=0x2aad7d1bb570) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:2496 (gdb) call debug_tree (chrec_a) integer_cst 0x2aad7d1bb570 type integer_type 0x2aad7d1ae0c0 bit_size_type constant invariant 1 (gdb) call debug_tree (chrec_b) integer_cst 0x2aad7d1bb390 type integer_type 0x2aad7d1ae0c0 bit_size_type constant invariant 0 -- Summary: ICE in tree-data-ref because signed_type_for_types returns NULL Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35043
[Bug tree-optimization/35043] ICE in tree-data-ref because signed_type_for_types returns NULL
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-31 17:15 --- Created an attachment (id=15065) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15065action=view) testcase -O -ftree-vectorize a cross from x86_64 is enough to trigger the ICE. reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35043
[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934
-- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug middle-end/35043] ICE in tree-data-ref because signed_type_for_types returns NULL
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-31 17:30 --- Mine. I have a patch, defered for 4.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-31 17:23:03 |2008-01-31 17:30:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35043
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #61 from alond at il dot ibm dot com 2008-01-31 18:07 --- Done. Still have same fails on hppa2.0w-hp-hpux11.11. Dave, can you please perform an initial debugging? I think it will make it easier to loacte the bug if we had some debugging information, like where is the failure etc. If you can also check the sizeof: HOST_WIDE_INT, int, unsigned HOST_WIDE_INT. Thank you for the cooperation, Alon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug rtl-optimization/35044] New: resource.c:find_dead_or_set_registers doesn't grok COND_EXEC
find_dead_or_set_registers uses mark_set_resources to determine if a register is set, and if it is, it concludes that the register is before that set. A register is also considered set when the set is inside a COND_EXEC, thus delay slot scheduling can clobber values in registers that are supposed to remain untouched when a COND_EXEC is not executed. I have a patch for this, which changes find_dead_or_set_registers to not call mark_set_resources for COND_EXEC patterns when the purpose is to find registers that are killed. I can't post this patch, or the target port we are using, at the moment since we don't have a copyright assignment on file yet. Another approach would be to change mark_set_resources to take a parameter to tell it if the conservative assumption is that the register is set or if it that the register is not set, and change all callers to provide an appropriate value. -- Summary: resource.c:find_dead_or_set_registers doesn't grok COND_EXEC Product: gcc Version: 4.2.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: arc-elf32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044
[Bug rtl-optimization/35044] resource.c:find_dead_or_set_registers doesn't grok COND_EXEC
--- Comment #1 from amylaar at gcc dot gnu dot org 2008-01-31 18:45 --- Created an attachment (id=15067) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15067action=view) Test case This is a test case, extracted from an ARC linux kernel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35044
[Bug c/32455] [4.1/4.2/4.3 regression] ICE with modified va_list, allows declaration of __builtin_*
-- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-27 20:38:18 |2008-01-31 18:52:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32455
[Bug java/35035] [4.3 Regression] Has any one managed to run the libjava test suite on powerpc-apple-darwin9?
--- Comment #14 from andreast at gcc dot gnu dot org 2008-01-31 18:39 --- With the patch from #12: === libjava Summary === # of expected passes2550 Thanks again! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
[Bug inline-asm/34833] rejects i(var) with -fpic -m32
--- Comment #6 from rth at gcc dot gnu dot org 2008-01-31 19:06 --- Yes, closing as not-a-bug for 32-bit i386. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
[Bug target/34900] target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-01-31 19:27 --- Created an attachment (id=15068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15068action=view) Patch that I intend to commit Thanks for the testing. I went ahead and made the changes I mentioned in comment #2, and the new version seems to work too. Unfortunately, I've missed the boat for 4.2.3, but here's the patch I intend to commit for 4.2.4. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Attachment #15019|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34900
[Bug c++/34715] always_inline with templates and not declared as always_inline but definition has it
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-31 19:51 ---
Hi, namespace has nothing to do with the issue,
The problem can be summarized as follows:
if you have a declaration of the template function without always_inline and
the definition with, the instationation does not get always_inline.
Take this testcase:
template class T
const T min(const T a, const T b);
template class T
inline __attribute__ ((always_inline)) const T
min(const T a, const T b)
{
return a b ? a : b;
}
int main()
{
int a, b;
return min(a, b);
}
We don't inline min into main if we remove the declaration, we do.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |c++
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-01-31 19:51:49
date||
Summary|always_inline does not seem |always_inline with templates
|to force inlining when used |and not declared as
|only in the definition of a |always_inline but definition
|function in a namespace |has it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34715
[Bug target/34900] target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 19:28 --- Subject: Bug 34900 Author: rsandifo Date: Thu Jan 31 19:28:03 2008 New Revision: 131983 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131983 Log: gcc/ PR target/34900 * config/mips/mips.c (gen_load_const_gp): New function, taking a comment from... (mips16_gp_pseudo_reg): ...here. * config/mips/mips.md (load_const_gp): Replace with... (load_const_gp_mode): ...this :P-based insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/config/mips/mips.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34900
[Bug target/34900] [4.2 Regression] target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-01-31 19:36 --- For the record, the patch logged by the previous comment was to 4.3.0. It adds the missing mode I mentioned in comment #2. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.2 Known to work||4.3.0 Summary|target mips64vrel-elf. |[4.2 Regression] target |Internal compiler error (in |mips64vrel-elf. Internal |reload_cse_simplify_operands|compiler error (in |, at postreload.c:392) while|reload_cse_simplify_operands |building libiberty |, at postreload.c:392) while ||building libiberty http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34900
[Bug c++/34936] ICE with double and attribute may_alias
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 --- Subject: Bug 34936 Author: dgregor Date: Thu Jan 31 20:06:33 2008 New Revision: 131984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131984 Log: 2008-01-31 Douglas Gregor [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR c++/34935 PR c++/34936 * typeck.c (structural_comptypes): Handle comparisons of VOID_TYPE, BOOLEAN_TYPE, INTEGER_TYPE, FIXED_POINT_TYPE, and REAL_TYPE nodes. * mangle.c (write_builtin_type): Map down to the canonical type, which will be one of the predefined type nodes. 2008-01-31 Douglas Gregor [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR c++/34935 PR c++/34936 * g++.dg/ext/alias-canon.C: New. * g++.dg/ext/alias-mangle.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/alias-canon.C trunk/gcc/testsuite/g++.dg/ext/alias-mangle.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34936
[Bug c++/34935] [4.3 regression] ICE with attribute may_alias
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 --- Subject: Bug 34935 Author: dgregor Date: Thu Jan 31 20:06:33 2008 New Revision: 131984 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131984 Log: 2008-01-31 Douglas Gregor [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR c++/34935 PR c++/34936 * typeck.c (structural_comptypes): Handle comparisons of VOID_TYPE, BOOLEAN_TYPE, INTEGER_TYPE, FIXED_POINT_TYPE, and REAL_TYPE nodes. * mangle.c (write_builtin_type): Map down to the canonical type, which will be one of the predefined type nodes. 2008-01-31 Douglas Gregor [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR c++/34935 PR c++/34936 * g++.dg/ext/alias-canon.C: New. * g++.dg/ext/alias-mangle.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/alias-canon.C trunk/gcc/testsuite/g++.dg/ext/alias-mangle.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34935
[Bug c++/34935] [4.3 regression] ICE with attribute may_alias
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-31 20:07 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34935
[Bug c++/34936] ICE with double and attribute may_alias
--- Comment #6 from dgregor at gcc dot gnu dot org 2008-01-31 20:08 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34936
[Bug libfortran/35001] shape for negative sizes
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-31 21:10 ---
A patch for when trunk reopens.
Index: m4/shape.m4
===
--- m4/shape.m4 (revision 131915)
+++ m4/shape.m4 (working copy)
@@ -46,6 +46,7 @@ shape_'rtype_kind` ('rtype` * const rest
{
int n;
index_type stride;
+ index_type extent;
stride = ret-dim[0].stride;
@@ -54,8 +55,8 @@ shape_'rtype_kind` ('rtype` * const rest
for (n = 0; n GFC_DESCRIPTOR_RANK (array); n++)
{
- ret-data[n * stride] =
-array-dim[n].ubound + 1 - array-dim[n].lbound;
+ extent = array-dim[n].ubound + 1 - array-dim[n].lbound;
+ ret-data[n * stride] = extent 0 ? extent : 0 ;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35001
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #2 from thomas at maier-komor dot de 2008-01-31 21:20 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at gcc dot gnu dot org schrieb: --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08 --- I'm not sure how we can make progress on this. It almost seems like the compiler has been miscompiled. What CC is cc: SUN's compiler or gcc? I'm not sure, it's been some time back now. So I reproduced it and got the following: $ ../gcc-4.1.2/configure --target=mipsel-elf --prefix=/opt/local --disable-lib --enable-languages=c [ output skipped ] $ gmake [ a whole bunch of output skipped ] gmake[3]: Entering directory `/opt/local/src/gcc-mipsel/mipsel-elf/libssp' if /bin/sh ./libtool --mode=compile /opt/local/src/gcc-mipsel/./gcc/xgcc -B/opt/local/src/gcc-mipsel/./gcc/ -B/opt/local/mipsel-elf/bin/ -B/opt/local/mipsel-elf/lib/ -isystem /opt/local/mipsel-elf/include -isystem /opt/local/mipsel-elf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.2/libssp -I.-Wall -O2 -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c -o ssp.lo ../../../gcc-4.1.2/libssp/ssp.c; \ then mv -f .deps/ssp.Tpo .deps/ssp.Plo; else rm -f .deps/ssp.Tpo; exit 1; fi /opt/local/src/gcc-mipsel/./gcc/xgcc -B/opt/local/src/gcc-mipsel/./gcc/ -B/opt/local/mipsel-elf/bin/ -B/opt/local/mipsel-elf/lib/ -isystem /opt/local/mipsel-elf/include -isystem /opt/local/mipsel-elf/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.2/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c ../../../gcc-4.1.2/libssp/ssp.c -o ssp.o ../../../gcc-4.1.2/libssp/ssp.c: In function '__guard_setup': ../../../gcc-4.1.2/libssp/ssp.c:70: warning: implicit declaration of function 'open' ../../../gcc-4.1.2/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:70: error: (Each undeclared identifier is reported only once ../../../gcc-4.1.2/libssp/ssp.c:70: error: for each function it appears in.) ../../../gcc-4.1.2/libssp/ssp.c:73: error: 'ssize_t' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:73: error: expected ';' before 'size' ../../../gcc-4.1.2/libssp/ssp.c:75: warning: implicit declaration of function 'close' ../../../gcc-4.1.2/libssp/ssp.c:76: error: 'size' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c: At top level: ../../../gcc-4.1.2/libssp/ssp.c:89: error: expected declaration specifiers or '...' before 'size_t' ../../../gcc-4.1.2/libssp/ssp.c: In function 'fail': ../../../gcc-4.1.2/libssp/ssp.c:100: error: 'O_WRONLY' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:104: error: 'size_t' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:104: error: expected ';' before 'progname_len' ../../../gcc-4.1.2/libssp/ssp.c:107: error: 'progname_len' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:107: warning: implicit declaration of function 'strlen' ../../../gcc-4.1.2/libssp/ssp.c:107: warning: incompatible implicit declaration of built-in function 'strlen' ../../../gcc-4.1.2/libssp/ssp.c:108: error: 'len' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:108: error: 'msg1len' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:109: warning: implicit declaration of function 'alloca' ../../../gcc-4.1.2/libssp/ssp.c:109: warning: incompatible implicit declaration of built-in function 'alloca' ../../../gcc-4.1.2/libssp/ssp.c:111: warning: implicit declaration of function 'memcpy' ../../../gcc-4.1.2/libssp/ssp.c:111: warning: incompatible implicit declaration of built-in function 'memcpy' ../../../gcc-4.1.2/libssp/ssp.c:119: error: 'ssize_t' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:119: error: expected ';' before 'wrote' ../../../gcc-4.1.2/libssp/ssp.c:120: error: 'wrote' undeclared (first use in this function) ../../../gcc-4.1.2/libssp/ssp.c:151: warning: implicit declaration of function '_exit' ../../../gcc-4.1.2/libssp/ssp.c:151: warning: incompatible implicit declaration of built-in function '_exit' ../../../gcc-4.1.2/libssp/ssp.c: In function '__stack_chk_fail': ../../../gcc-4.1.2/libssp/ssp.c:161: warning: incompatible implicit declaration of built-in function 'strlen' ../../../gcc-4.1.2/libssp/ssp.c:161: warning: passing argument 2 of 'fail' makes pointer from integer without a cast ../../../gcc-4.1.2/libssp/ssp.c:161: error: too many arguments to function 'fail' ../../../gcc-4.1.2/libssp/ssp.c: In function '__chk_fail': ../../../gcc-4.1.2/libssp/ssp.c:168: warning: incompatible implicit declaration of built-in function 'strlen' ../../../gcc-4.1.2/libssp/ssp.c:168: warning: passing argument 2 of 'fail' makes pointer from integer without a cast ../../../gcc-4.1.2/libssp/ssp.c:168: error: too many arguments to function 'fail' gmake[3]: *** [ssp.lo] Error 1 gmake[3]: Leaving directory `/opt/local/src/gcc-mipsel/mipsel-elf/libssp' gmake[2]: *** [all]
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #3 from thomas at maier-komor dot de 2008-01-31 22:18 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at gcc dot gnu dot org schrieb: --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08 --- I'm not sure how we can make progress on this. It almost seems like the compiler has been miscompiled. What CC is cc: SUN's compiler or gcc? I've seem to have missed --disable-libssp. Using this configure flag, gcc-mipsel compiles with Sun's native cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31577
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #64 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:18 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Then, in the second loop, we load p[968].a and convert it to a float value of 3. We do a floating-point compare of this value with p[968].b + 1.0 = 3.0049336, and the compare fails. Test passes if the comparison is changed. For example, if (p[i].a != (int) (p[i].b + 1)) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug fortran/34910] [4.2/4.3 Regression] ICE on invalid assignments in doubly-contained functions
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-31 22:21 --- Subject: Bug 34910 Author: pault Date: Thu Jan 31 22:20:47 2008 New Revision: 131985 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131985 Log: 2008-01-31 Paul Thomas [EMAIL PROTECTED] PR fortran/34910 * expr.c (gfc_check_assign): It is an error to assign to a sibling procedure. 2008-01-31 Paul Thomas [EMAIL PROTECTED] PR fortran/34910 * gfortran.dg/proc_assign_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_assign_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug fortran/34910] [4.2/4.3 Regression] ICE on invalid assignments in doubly-contained functions
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-31 22:23 --- Fixed on trunk. Thanks for the hint, Daniel! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug fortran/35040] usage of init expression in its own definition
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-31 22:25 --- Answer (see link): All these are wrong per answer to an interpretation request: 6. INTEGER :: B = BIT_SIZE(B) 7. INTEGER :: B(BIT_SIZE(B)) 8. INTEGER :: D = DIGITS(D) 9. INTEGER :: D(DIGITS(D)) 10. REAL :: X = EPSILON(X) 2. INTEGER(selected_int_kind(4)) :: A(KIND(A)) 3. INTEGER :: A(2,2*SIZE(A,1)+1) 4. CHARACTER :: C(10)*(SIZE(C,1)) 5. INTEGER :: P(10) = LBOUND(P,1) 1. INTEGER :: P(complicated_expression_for_lower_bound_1: complicated_expression_for_upper_bound_1, complicated_expression_for_lower_bound_2: complicated_expression_for_upper_bound_2) = RESHAPE( (/ 11, 21, 12, 22 /), SHAPE(P) ) And I also believe all our examples in this PR are wrong. While we really have to reject REAL(8), PARAMETER :: xyz(size(xyz)) = 1 we could allow the others as extension (i.e. only reject using -std=f*) - or we reject them all. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-31 22:25:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #62 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:00 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 On Thu, 31 Jan 2008, alond at il dot ibm dot com wrote: --- Comment #61 from alond at il dot ibm dot com 2008-01-31 18:07 --- Done. Still have same fails on hppa2.0w-hp-hpux11.11. Dave, can you please perform an initial debugging? I have attached a somewhat annotated assembler output for the wo_prof_global_var.c test. The test aborts in the second loop at i = 968. In the first loop, malloc gives us p[968].b == 0x400050d4 or 2.00493336. We add 1.0, convert it a fixed value of 3, and save it in p[968].a. Then, in the second loop, we load p[968].a and convert it to a float value of 3. We do a floating-point compare of this value with p[968].b + 1.0 = 3.0049336, and the compare fails. If you can also check the sizeof: HOST_WIDE_INT, int, unsigned HOST_WIDE_INT. These should all be 4 on hppa2.0w-hp-hpux11.11. They should be 8 on hppa64-hp-hpux11.11. Don't think the problem is here. Dave --- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-31 22:00 --- Created an attachment (id=15069) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15069action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug fortran/34910] [4.2/4.3 Regression] ICE on invalid assignments in doubly-contained functions
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-01-31 22:29 --- Thanks for fixing :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34910
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 22:35 --- thomas at maier-komor dot de [EMAIL PROTECTED] writes: --- Comment #3 from thomas at maier-komor dot de 2008-01-31 22:18 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at gcc dot gnu dot org schrieb: --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08 --- I'm not sure how we can make progress on this. It almost seems like the compiler has been miscompiled. What CC is cc: SUN's compiler or gcc? I've seem to have missed --disable-libssp. Using this configure flag, gcc-mipsel compiles with Sun's native cc. Glad to hear it, and thanks for reporting back. For the record, (in response to comment #2) there isn't a --disable-lib option; --disable-lib would just get silently ignored. I'm not sure if your message above meant that you'd misspelt --disable-libssp as --disable-lib or whether it meant that you were now using both options together. Also, if you want to build gcc and libgcc without building anything else, you can use make all-gcc and make install-gcc instead of make and make install. (In 4.3, you need make all-gcc all-target-libgcc and make install-gcc install-target-libgcc instead.) I realise that what you've got now is probably more convenient though. Anyway, it sounds like things are working now, so I'll go ahead and close the bug. Feel free to open a new one (or reopen this one) if you think I've done wrong. Richard -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31577
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #5 from thomas at maier-komor dot de 2008-01-31 22:38 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at gcc dot gnu dot org schrieb: --- Comment #4 from rsandifo at gcc dot gnu dot org 2008-01-31 22:35 --- thomas at maier-komor dot de [EMAIL PROTECTED] writes: --- Comment #3 from thomas at maier-komor dot de 2008-01-31 22:18 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at gcc dot gnu dot org schrieb: --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-01-25 10:08 --- I'm not sure how we can make progress on this. It almost seems like the compiler has been miscompiled. What CC is cc: SUN's compiler or gcc? I've seem to have missed --disable-libssp. Using this configure flag, gcc-mipsel compiles with Sun's native cc. Glad to hear it, and thanks for reporting back. For the record, (in response to comment #2) there isn't a --disable-lib option; --disable-lib would just get silently ignored. I'm not sure if your message above meant that you'd misspelt --disable-libssp as --disable-lib or whether it meant that you were now using both options together. Also, if you want to build gcc and libgcc without building anything else, you can use make all-gcc and make install-gcc instead of make and make install. (In 4.3, you need make all-gcc all-target-libgcc and make install-gcc install-target-libgcc instead.) I realise that what you've got now is probably more convenient though. Anyway, it sounds like things are working now, so I'll go ahead and close the bug. Feel free to open a new one (or reopen this one) if you think I've done wrong. Richard Thanks Richard for the clarifications. All is fine, you can close this bug. One final question: can you tell me, what libssp is? Thanks, Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31577
[Bug c/35045] New: gcc-4.3 generates wrong code on i386 with -O3
The attached code, coming from the GNU libc (test-ifloat.c and s_cacoshf.c) gives wrong results when compiled with gcc-4.3 and -O3. The results are correct with gcc-4.3 and lower optimizations, or with gcc-4.2. Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian 4.3-20080127-1) -- Summary: gcc-4.3 generates wrong code on i386 with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aurelien at aurel32 dot net GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3
--- Comment #1 from aurelien at aurel32 dot net 2008-01-31 22:52 --- Created an attachment (id=15070) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15070action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #6 from rsandifo at nildram dot co dot uk 2008-01-31 22:55 --- Subject: Re: mipsel-elf fails to build on Solaris 10 thomas at maier-komor dot de [EMAIL PROTECTED] writes: One final question: can you tell me, what libssp is? It's the run-time support for the stack-smashing protector. Wikipedia has a good description: http://en.wikipedia.org/wiki/Stack-smashing_protection Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31577
[Bug middle-end/35045] gcc-4.3 generates wrong code on i386 with -O3
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-31 22:55 --- Does -fno-gcse-after-reload fix the miscompiling? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
[Bug bootstrap/31577] mipsel-elf fails to build on Solaris 10
--- Comment #7 from thomas at maier-komor dot de 2008-01-31 22:56 --- Subject: Re: mipsel-elf fails to build on Solaris 10 rsandifo at nildram dot co dot uk schrieb: --- Comment #6 from rsandifo at nildram dot co dot uk 2008-01-31 22:55 --- Subject: Re: mipsel-elf fails to build on Solaris 10 thomas at maier-komor dot de [EMAIL PROTECTED] writes: One final question: can you tell me, what libssp is? It's the run-time support for the stack-smashing protector. Wikipedia has a good description: http://en.wikipedia.org/wiki/Stack-smashing_protection Richard Thanks! - Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31577
[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3
--- Comment #3 from aurelien at aurel32 dot net 2008-01-31 22:58 --- Oops, the bug actually exist on *i386*, not on x86_64. I used the value from my main installation and not from my i386 chroot. Here are the correct specs: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080127-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.0 20080127 (experimental) [trunk revision 131882] (Debian 4.3-20080127-1) -- aurelien at aurel32 dot net changed: What|Removed |Added Severity|normal |major Component|middle-end |c GCC build triplet|x86_64-unknown-linux-gnu|i486-pc-linux-gnu GCC host triplet|x86_64-unknown-linux-gnu|i486-pc-linux-gnu GCC target triplet|x86_64-unknown-linux-gnu|i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
[Bug c/35045] gcc-4.3 generates wrong code on i386 with -O3
--- Comment #4 from aurelien at aurel32 dot net 2008-01-31 22:59 --- (In reply to comment #2) Does -fno-gcse-after-reload fix the miscompiling? Yes that fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
[Bug fortran/32760] [4.3 Regression] Error defining subroutine named PRINT
--- Comment #26 from pault at gcc dot gnu dot org 2008-01-31 22:59 --- Created an attachment (id=15071) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15071action=view) A fix for the PR This is regtesting as I write. It fixes the first three PRs but not that of comment #25. I believe that this will turn out to be a problem in patching allocate because write (*, *, iostat = isat) hello is OK. 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=32760
[Bug bootstrap/35046] New: Toplevel compile script is not executable
# ls -l compile -rw-r--r-- 1 bin bin 3707 Jul 13 2005 compile Causes gcc configure tests to fail. -- Summary: Toplevel compile script is not executable Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: vax-dec-ultrix4.3 GCC host triplet: vax-dec-ultrix4.3 GCC target triplet: vax-dec-ultrix4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35046
