[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 07:38 --- No, we need -msse for i686 here since vector floats have to go into xmm register. I will fix this. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 07:38:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:42 --- Subject: Bug 36056 Author: uros Date: Mon Apr 28 07:42:12 2008 New Revision: 134743 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134743 Log: PR testsuite/36056 * g++.dg/ext/vector14.C: Add -msse for 32bit x86 targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/vector14.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/36064] could not split insn with -O1 -march=nocona -m32
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 07:52 --- Subject: Bug 36064 Author: uros Date: Mon Apr 28 07:52:01 2008 New Revision: 134744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134744 Log: PR target/36064 * config/i386/i386.md (floatdiX87MODEF:mode2_i387_with_xmm splitters): Use match_scratch instead of match_operand for operands 3 and 4. testsuite/ChangeLog: PR target/36064 * gcc.target/i386/pr36064.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr36064.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36064
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:00 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02012.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/36064] could not split insn with -O1 -march=nocona -m32
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 08:01 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02013.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36064
[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:09 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
[Bug testsuite/36068] gcc.dg/vect/vect-118.c doesn't work on Linux/ia32
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-28 09:22 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36068
[Bug tree-optimization/34223] missed optimization - complete unrolling pass before the vectorizer
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:23 --- Subject: Bug 34223 Author: rguenth Date: Mon Apr 28 09:22:28 2008 New Revision: 134747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134747 Log: 2008-04-28 Richard Guenther [EMAIL PROTECTED] PR testsuite/34223 * gcc.dg/vect/vect-118.c: Rename to ... * gcc.dg/vect/O3-vect-pr34223.c: ... this. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-vect-pr34223.c - copied, changed from r134744, trunk/gcc/testsuite/gcc.dg/vect/vect-118.c Removed: trunk/gcc/testsuite/gcc.dg/vect/vect-118.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34223
[Bug tree-optimization/36066] [4.4 Regression] ICE with -O1 -finline-small-functions -ftree-vrp -funsafe-loop-optimizations
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 09:10 --- Subject: Bug 36066 Author: rguenth Date: Mon Apr 28 09:09:19 2008 New Revision: 134745 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134745 Log: 2008-04-28 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36066 * tree-vrp.c (execute_vrp): Cleanup the CFG only after finalizing SCEV and loop. * gcc.dg/torture/pr36066.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr36066.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36066
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #6 from jakub at gcc dot gnu dot org 2008-04-28 09:51 --- Subject: Bug 36060 Author: jakub Date: Mon Apr 28 09:50:31 2008 New Revision: 134751 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134751 Log: PR debug/36060 * dwarf2out.c (struct die_struct): Mark as chain_circular through die_sub field. * gengtype.c (walk_type, write_func_for_structure): Handle chain_circular. * doc/gty.texi: Document chain_circular. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/gty.texi branches/gcc-4_3-branch/gcc/dwarf2out.c branches/gcc-4_3-branch/gcc/gengtype.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #5 from jakub at gcc dot gnu dot org 2008-04-28 09:46 --- Subject: Bug 36060 Author: jakub Date: Mon Apr 28 09:45:26 2008 New Revision: 134750 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134750 Log: PR debug/36060 * dwarf2out.c (struct die_struct): Mark as chain_circular through die_sub field. * gengtype.c (walk_type, write_func_for_structure): Handle chain_circular. * doc/gty.texi: Document chain_circular. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/gty.texi trunk/gcc/dwarf2out.c trunk/gcc/fortran/ChangeLog trunk/gcc/gengtype.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug debug/36060] [4.3/4.4 Regression] Too big stack requirements of cc1plus during GC
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-28 09:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36060
[Bug middle-end/31738] Fortran dot product vectorization is restricted
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-04-28 09:39 --- For testvectdp2 we now miss to apply store-motion so the reduction is no longer recognized. This is the bad interaction between PRE and lim for which we have PR36009. If you add -fno-tree-pre vectorization fails because of t.f90:7: note: reduction: not commutative/associative: D.1011_34 even with -ffast-math. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||36009 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31738
[Bug c++/36069] New: Strange warning: suggest parentheses around assignment used as truth value with volatile/non volatile bools
When compiling the following file with g++ 4.3.0, with -Wall :
main.cpp
struct foo {
bool a;
volatile bool b,c; // removing 'volatile' here removes the warning.
foo() { a = b = c = false; }
};
int main() {
foo A;
}
-- end of main.cpp --
-bash-3.00$ g++ main.cpp -Wall
tata.cpp: In constructor 'foo::foo()':
tata.cpp:4: warning: suggest parentheses around assignment used as truth value
It seems that having an assignement between 'volatile' and non-volatile bools
activates the warning. I don't see any reason why it should behave like this.
Removing the volatile keyword (or adding it in the line above) removes the
warning.
--
Summary: Strange warning: suggest parentheses around assignment
used as truth value with volatile/non volatile bools
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: David dot Tschumperle at greyc dot ensicaen dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36069
[Bug c++/36069] Strange warning: suggest parentheses around assignment used as truth value with volatile/non volatile bools
--- Comment #1 from David dot Tschumperle at greyc dot ensicaen dot fr
2008-04-28 10:55 ---
Also, removing the warning without adding or removing 'volatile' can be
achieved by writting :
foo() { a = (b = (c = false)); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36069
[Bug libgcj/24403] --enable-java-awt=qt fails to build
--- Comment #16 from bero at arklinux dot org 2008-04-28 10:59 --- ping... This missed 4.3 again, it should probably get in now before 4.4 enters freeze mode... Re the moc - moc-qt4 change suggested in comment #14: This should be detected by the configure script, moc-qt4 is a nonstandard way some distributions use to tell moc 3.x apart from moc 4.x, other candidates for the correct moc include moc4 and simply launching moc from a different path (/usr/lib/qt4/bin/moc) if the default moc is from 3.x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24403
[Bug c/36070] New: m68k/coldfire gcc build breaks due to sc_fpstate, sc_fpregs reference
In gcc/config/m68k/linux-unwind.h, the function m68k_fallback_frame_state() has
the following:
if (*(int *) sc-sc_fpstate)
{
int *fpregs = (int *) sc-sc_fpregs;
fs-regs.reg[16].how = REG_SAVED_OFFSET;
fs-regs.reg[16].loc.offset = (long) fpregs[0] - cfa;
fs-regs.reg[17].how = REG_SAVED_OFFSET;
fs-regs.reg[17].loc.offset = (long) fpregs[M68K_FP_SIZE/4] - cfa;
}
The variable sc is of type struct sigcontext, which is defined the linux
kernel headers in asm/sigcontext.h. For asm-m68k, the sigcontext structure has
members sc_fpregs, sc_fpcntl, and sc_fpstate. For asm-m68knommu, the sigcontext
structure does not have the sc_fp... members. This causes the gcc build to
break in libgcc when the asm-m68knommu kernel headers are used. This is so with
the uClinux 2.4 kernel and the vanilla linux 2.6 kernel.
I'm not too familiar with the code in linux-unwind.h, but one solution might be
to wrap the above code in an #ifdef __mcffpu__.
--
Summary: m68k/coldfire gcc build breaks due to sc_fpstate,
sc_fpregs reference
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kendallc at vxitech dot com
GCC target triplet: m68k-unknown-uclinux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070
[Bug fortran/35997] [4.3/4.4 regression]Used function interface bug
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-28 11:55 --- Created an attachment (id=15541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15541action=view) Fix for this PR This seems to do the job. The problem arises because the present version of module.c does not add a new symtree that is not renamed if the symbol is already present. The test in module.c(find_symbol) was failing to resolve the case where the renaming is already done in the module that is being use associated. This patch accomplishes this by looking for a symtree with the same name as the symbol and, upon failure, checking that the symbol is not renamed; this can only correspond to the unresolved case. I will develop a proper testcase and submit later on today. -- 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=35997
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-28 11:56 --- Can you reproduce it with a newer snapshot? Can you find out which change between 0219 and 0227 caused it? There were very few changes that might affect it at all, I'd say just PR35071, PR35265, PR34971 and PR35390, the rest of the changes were either specific to other targets, or testsuite/documentation, or C++/Fortran, or outside of the gcc/ subdirectory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug testsuite/36056] g++.dg/ext/vector14.C doesn't work for ia32
--- Comment #5 from uros at gcc dot gnu dot org 2008-04-28 12:18 --- Subject: Bug 36056 Author: uros Date: Mon Apr 28 12:17:27 2008 New Revision: 134752 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134752 Log: PR testsuite/36056 * g++.dg/ext/vector14.C: Add -msse for 32bit x86 targets. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/vector14.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36056
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #2 from riku dot voipio at iki dot fi 2008-04-28 12:26 --- Newer arm builds of gcc-4.3 in debian have succeeded fine, so I'd say this bug can be closed. One theory could be that this build machine simply ran out of Memory during the build (although a later build on similar machine succeeded fine). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug fortran/34199] segfault for TRANSFER integer to TYPE(C_PTR)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-04-28 12:34 --- Further reports: They might show the same problem, or also different ones. I did not check them all: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c553e0034bab977c * * * Patch by FX: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00546.html My review: http://gcc.gnu.org/ml/fortran/2008-03/msg00232.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
[Bug middle-end/36071] New: [4.4 Regression] segmentation fault
2 days old trunk fails on CVS CP2K [see PR29975] with gfortran -c -v -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH=\Linux-x86-64-gfortran\ -D__COMPILE_DATE=\Mon Apr 28 14:33:23 CEST 2008\ -D__COMPILE_HOST=\pcihopt3\ -D__COMPILE_LASTCVS=\/termination.F/1.32/Mon Apr 28 07:20:29 2008//\ /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.4.0 20080426 (experimental) [trunk revision 134695] (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-ffree-form' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH=Linux-x86-64-gfortran' '-D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008' '-D__COMPILE_HOST=pcihopt3' '-D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008//' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH=Linux-x86-64-gfortran -D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008 -D__COMPILE_HOST=pcihopt3 -D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008// /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -ffast-math -funroll-loops -ftree-vectorize -ffree-form -O2 -o /tmp/ccxHLZQc.f ignoring nonexistent directory /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /data03/vondele/gcc_trunk/build/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-c' '-v' '-O2' '-ffast-math' '-funroll-loops' '-ftree-vectorize' '-ffree-form' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH=Linux-x86-64-gfortran' '-D__COMPILE_DATE=Mon Apr 28 14:33:23 CEST 2008' '-D__COMPILE_HOST=pcihopt3' '-D__COMPILE_LASTCVS=/termination.F/1.32/Mon Apr 28 07:20:29 2008//' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 /tmp/ccxHLZQc.f -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase hfx_libint_interface.F -auxbase hfx_libint_interface -O2 -version -ffast-math -funroll-loops -ftree-vectorize -ffree-form -fpreprocessed -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccwowsgg.s GNU Fortran (GCC) version 4.4.0 20080426 (experimental) [trunk revision 134695] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080426 (experimental) [trunk revision 134695], GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F: In function evaluate_eri_screen: /data03/vondele/clean/cp2k/src/../src/hfx_libint_interface.F:41: 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. I'll see if can get more info. gfortran should really have an option to generate a single 'preprocessed' file, without module dependencies. It would simplify test case generation. -- Summary: [4.4 Regression] segmentation fault Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #149 from jv244 at cam dot ac dot uk 2008-04-28 12:45 --- new ICE, PR36071. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-28 12:48 --- trace rogram received signal SIGSEGV, Segmentation fault. 0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420, arg1=0x2b9220c5b240, flags=0) at /data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037 3037 if (TYPE_UNSIGNED (TREE_TYPE (arg0)) != TYPE_UNSIGNED (TREE_TYPE (arg1))) (gdb) bt #0 0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420, arg1=0x2b9220c5b240, flags=0) at /data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037 #1 0x007f7d70 in simplify_replace_tree (expr=0x2b9220d76420, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1347 #2 0x007f7e72 in simplify_replace_tree (expr=0x2b9221320840, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1358 #3 0x007f7e72 in simplify_replace_tree (expr=0x2b9221320880, old=0x2b9220c5b240, new_tree=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:1358 #4 0x007f80ad in substitute_in_loop_info (loop=0x2b9220bac5a0, name=0x90, val=0x0) at /data03/vondele/gcc_trunk/gcc/gcc/tree-ssa-loop-niter.c:3070 #5 0x00703be4 in replace_uses_by (name=0x2b9220c5b240, val=0x2b922099d960) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:1273 #6 0x007132db in tree_merge_blocks (a=0x2b9220d9d900, b=0x2b9220e0e360) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:1337 #7 0x00ac4206 in merge_blocks (a=0x2b9220d9d900, b=0x2b9220e0e360) at /data03/vondele/gcc_trunk/gcc/gcc/cfghooks.c:660 #8 0x0071b660 in cleanup_tree_cfg_bb (bb=0x2b9220d9d900) at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfgcleanup.c:568 #9 0x0071bca8 in cleanup_tree_cfg () at /data03/vondele/gcc_trunk/gcc/gcc/tree-cfgcleanup.c:616 #10 0x00896715 in execute_vrp () at /data03/vondele/gcc_trunk/gcc/gcc/tree-vrp.c:6758 #11 0x00677c26 in execute_one_pass (pass=0xf86c60) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1132 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-28 12:55 --- revision 134754 seems to pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug target/35399] [4.3 regression] bootstrap error, ICE in free_list, at lists.c:52
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-28 13:32 --- Closing then, if you manage to reproduce it again, please reopen with more details. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35399
[Bug middle-end/36071] [4.4 Regression] segmentation fault
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-28 13:56 --- assuming fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
[Bug fortran/36072] New: missing symbols in gfortran
When linking a program build with gfortran 4.3.0 to lapack, I get /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r8_i4' /opt/atlas-gnu_4.3.0/3.8.1/lib64/liblapack.so: undefined reference to `_gfortran_pow_r4_i4' -- Summary: missing symbols in gfortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in gfortran
--- Comment #1 from sliwa at cft dot edu dot pl 2008-04-28 14:47 --- See http://forums.amd.com/devforum/messageview.cfm?catid=217threadid=90399messid=881726parentid=856116FTVAR_FORUMVIEWTMP=Branch for a similar complaint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug fortran/36072] missing symbols in libgfortran
--- Comment #2 from sliwa at cft dot edu dot pl 2008-04-28 15:02 --- OK, the LAPACK library was probably compiled with 4.1.2. -- sliwa at cft dot edu dot pl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36072
[Bug target/36073] New: ICE with -ffast-math and -mfpmath=sse,387
This is my first ever bug report; if I get something wrong, please tell me so I
don't do it again!
When the following is compiled using mainline (as of 28th April 2008) with -O
-march=nocona -mfpmath=sse,387 -ffast-math I get an ICE. It's a different ICE
with omitting the -O2.
-
Code:
-
extern double log(double x);
extern int f(void);
void g(void)
{
static double cached_value = 0.0;
cached_value = log(f());
}
int main(void)
{
g();
return 0;
}
---
Result:
---
$ gcc-4.4 -O -ffast-math -march=nocona -mfpmath=sse,387 bug.c
bug.c: In function g:
bug.c:9: error: insn does not satisfy its constraints:
(insn 24 23 25 2 bug.c:8 (set (reg:DF 8 st [61])
(float:DF (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int 4 [0x4])) [0 S4 A8]))) 215
{*floatsidf2_sse_interunit} (nil))
bug.c:9: internal compiler error: in copyprop_hardreg_forward_1, at
regrename.c:1590
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE with -ffast-math and -mfpmath=sse,387
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ejb48 at cam dot ac dot uk
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #1 from ejb48 at cam dot ac dot uk 2008-04-28 15:07 --- Sorry, forgot to include: $gcc-4.4 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --enable-languages=c --program-suffix=-4.4 --disable-multilib --enable-__cxa_atexit Thread model: posix gcc version 4.4.0 20080428 (experimental) [trunk revision 134754] (GCC) -- ejb48 at cam dot ac dot uk changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.1 4.2.1 4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug libfortran/36044] user-requested backtrace
--- Comment #2 from jaydub66 at gmail dot com 2008-04-28 15:44 --- (In reply to comment #1) I think compiling with -fbacktrace and calling the STOP intrinsic should emit a backtrace. I don't think it does. Anyway I'm looking for a solution that keeps the program running after the backtrace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug middle-end/36074] New: [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
Gcc 4.4 revision 134755 failed to compile 447.dealII in SPEC CPU 2006
on Linux Intel64 with -O2 -ffast-math
In file included from
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/vector:74,
from include/base/tensor_base.h:25,
from include/base/tensor.h:18,
from include/base/polynomials_bdm.h:19,
from polynomials_bdm.cc:14:
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/vector.tcc:
In member function 'void std::vector_Tp,
_Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratortypename
std::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp,
_Alloc , size_t, const _Tp) [with _Tp = Tensor2, 2, _Alloc =
std::allocatorTensor2, 2 ]':
/usr/gcc-4.4/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/bits/vector.tcc:350:
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.
specmake[5]: *** [polynomials_bdm.o] Error 1
(gdb) r -fpreprocessed x.ii -quiet -dumpbase x.ii -mtune=generic -auxbase x
-O2 -version -ffast-math -o x.s
Starting program:
/usr/gcc-4.4/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed
x.ii -quiet -dumpbase x.ii -mtune=generic -auxbase x -O2 -version -ffast-math
-o x.s
GNU C++ (GCC) version 4.4.0 20080428 (experimental) [trunk revision 134755]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20080428 (experimental) [trunk revision
134755], GMP version 4.2.2, MPFR version 2.3.0-p4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 37249754a30773432dac8305adbf4674
Program received signal SIGSEGV, Segmentation fault.
execute_ssa_ccp (store_ccp=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-ssa-ccp.c:405
405 val-lattice_val = VARYING;
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) p val
No symbol val in current context.
(gdb) list
400 static inline void
401 set_value_varying (tree var)
402 {
403 prop_value_t *val = const_val[SSA_NAME_VERSION (var)];
404
405 val-lattice_val = VARYING;
406 val-value = NULL_TREE;
407 val-mem_ref = NULL_TREE;
408 }
409
(gdb) bt
#0 execute_ssa_ccp (store_ccp=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-ssa-ccp.c:405
#1 0x006165ff in execute_one_pass (pass=0xf2a7a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1133
#2 0x00616815 in execute_pass_list (pass=0xf2a7a0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1192
#3 0x0061682d in execute_pass_list (pass=0xea8a40)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/passes.c:1193
#4 0x006c635f in tree_rest_of_compilation (fndecl=0x2aaab1f23a90)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/tree-optimize.c:420
#5 0x007d2a82 in cgraph_expand_function (node=0x2aaab231a200)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1157
#6 0x007d45dc in cgraph_optimize ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cgraphunit.c:1220
#7 0x0044e80d in cp_write_global_declarations ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/cp/decl2.c:3524
#8 0x0068d744 in toplev_main (argc=value optimized out,
argv=value optimized out)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/toplev.c:971
#9 0x2aee9074 in __libc_start_main () from /lib64/libc.so.6
#10 0x00402aea in _start ()
(gdb)
Revision 134716 is OK. This regression may be introduced by
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00959.html
http://gcc.gnu.org/ml/gcc-cvs/2008-04/msg00974.html
--
Summary: [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to
compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #2 from ubizjak at gmail dot com 2008-04-28 16:20 --- Mine. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 16:20:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug libfortran/36044] user-requested backtrace
--- Comment #3 from burnus at gcc dot gnu dot org 2008-04-28 16:41 --- I think compiling with -fbacktrace and calling the STOP intrinsic should emit a backtrace. I think it should not. For abort(), I think a backtrace is ok, but for STOP there should be no backtrace. Using stop is a quite normal way to stop a program because a condition has not be met, e.g stop 'Could not file inp' If one finds afterwards dozens of lines of backtrace the actual message is no longer visible. In my opinion, ifort shows too often a backtrace. I don't think it does. Try abort(). (Though I do not recall whether it works, I think it does.) Anyway I'm looking for a solution that keeps the program running after the backtrace. This can be sometimes indeed be handy, though I have never used it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #1 from hjl dot tools at gmail dot com 2008-04-28 17:22 --- Revision 134730 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34223 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
-- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.0 Target Milestone|--- |4.4.0 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug c++/36023] [4.1/4.3/4.4 regression] ICE with cast to variable-sized object
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02045.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 17:50:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36023
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #3 from uros at gcc dot gnu dot org 2008-04-28 17:50 --- Subject: Bug 36073 Author: uros Date: Mon Apr 28 17:49:51 2008 New Revision: 134757 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134757 Log: PR target/36073 * config/i386/i386.md (*floatSSEMODEI24:modeMODEF:mode2_mixed_interunit): Change operand 1 predicate to nonimmediate_operand. testsuite/ChangeLog: PR target/36073 * gcc.target/i386/pr36073.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr36073.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug target/36073] ICE with -ffast-math and -mfpmath=sse,387
--- Comment #4 from ubizjak at gmail dot com 2008-04-28 17:54 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||04/msg02048.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36073
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-28 18:31 --- I bet this is fixed with revision 134745. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-28 18:37 --- (In reply to comment #2) I bet this is fixed with revision 134745. In my initial bug report, I said Gcc 4.4 revision 134755 failed to compile ^^^ 447.dealII in SPEC CPU 2006 on Linux Intel64 with -O2 -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug middle-end/36074] [4.4 Regression]: 447.dealII in SPEC CPU 2006 failed to compile
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-28 19:19 --- A preprocessed testcase is always appreciated ;) But yes, I have access to spec 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36074
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #7 from sjhowe at dial dot pipex dot com 2008-04-28 20:17 --- Roger I agree with your analysis. I am slightly crestfallen as I was suspicious that Barriato, Hofri etc's paper never mentioned worst case only approximate case. And I have now seen BFPRT73 paper where it mentions for the number of columns (c) Note, however, that we must have c = 5 for PICK to run in linear time. So yes, median-of median of 5 seems best you can do for worst case. The only point in shifting to a different algorithm for the worse case is if (i) It is cheaper in terms of total comparisons, swaps, assignments etc (ii) It is still linear in N in the worse case Cheers Stephen Howe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug tree-optimization/15255] [tree-ssa] a * 2 + a * 2 is not converted to a * 4
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:19 --- 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 Last reconfirmed|2006-02-20 18:43:31 |2008-04-28 20:19:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15255
[Bug tree-optimization/14792] ((int)b 1) != 0 is not folded to b 1 != 0
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-04-28 20:28 --- The testcase from comment #1 is fixed on the trunk. The original testcase still shows (int)a 1 != 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14792
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
--- Comment #36 from jason at gcc dot gnu dot org 2008-04-28 20:44 --- Subject: Bug 57 Author: jason Date: Mon Apr 28 20:43:27 2008 New Revision: 134762 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134762 Log: PR c++/57 * parser.c (cp_parser_parameter_declaration): Handle ambiguity in default arguments. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.old-deja/g++.pt/defarg8.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #9 from pault at gcc dot gnu dot org 2008-04-28 21:03 --- This is not critical in the gcc sense - I would change it back to normal if I were you. After all, this feature of F95 has never worked correctly:) Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug ada/36007] [4.4 regression] verify_gimple failed
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:16 --- Subject: Bug 36007 Author: ebotcazou Date: Mon Apr 28 21:15:41 2008 New Revision: 134766 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134766 Log: PR ada/36007 * decl.c (gnat_to_gnu_entity) object: Do not promote alignment of aliased objects with an unconstrained nominal subtype. Cap the promotion to the effective alignment of the word mode. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
[Bug ada/36007] [4.4 regression] verify_gimple failed
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-04-28 21:18 --- This should be OK now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36007
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #10 from tkoenig at gcc dot gnu dot org 2008-04-28 21:34 --- Created an attachment (id=15542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15542action=view) proposed patch This fixes the test case. Regression-test and submission probably tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug libfortran/36044] user-requested backtrace
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-04-28 21:36 --- Confirmed, this would indeed be useful. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-28 21:36:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #3 from ianw at vmware dot com 2008-04-28 22:14 --- As another data-point, if ( (a=10) ) ; also doesn't warn. I'm not sure what the standard says on that, but other contemporary compilers do give the an assignment used as truth value warning for the example above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #4 from ianw at vmware dot com 2008-04-28 22:16 --- Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis hide the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-28 22:17 --- (In reply to comment #4) Oh, just to be clear, my point was if (a=10) warns, but the extra parenthesis hide the warning. That is by design. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug c/25733] missed diagnostic about assignment used as truth value.
--- Comment #6 from ianw at vmware dot com 2008-04-28 22:28 ---
(In reply to comment #5)
(In reply to comment #4)
Oh, just to be clear, my point was if (a=10) warns, but the extra
parenthesis
hide the warning.
That is by design.
Ok, I did try looking but is that documented anywhere?
It would seem to have ramifications for people that do things like make an
ASSERT statement something like
#define ASSERT(v) {if (!(v))}
A quick search on google codesearch showed this was a very common idiom...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25733
[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3
--- Comment #7 from rwild at gcc dot gnu dot org 2008-04-28 22:28 --- Subject: Bug 35169 Author: rwild Date: Mon Apr 28 22:27:22 2008 New Revision: 134768 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134768 Log: gcc/ PR bootstrap/35169 * optc-gen.awk: Work around HP-UX/IA awk bug. Modified: trunk/gcc/ChangeLog trunk/gcc/optc-gen.awk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- Comment #6 from manus at eiffel dot com 2008-04-28 22:34 ---
I can reproduce this problem with gcc 4.2.3 that comes with Ubuntu 8.04 on
PowerPC with the following command line:
gcc -Wall -mlongcall -fPIC -c foo.c
Removing either `-fPIC' or `-mlongcall' succeeds, it is when used together that
it fails with:
lisbon [Manu] : gcc -Wall -mlongcall -fPIC -c foo.c
foo.c: In function 'idrf_reset_pos':
foo.c:23: error: unrecognizable insn:
(call_insn 10 9 12 3 (parallel [
(call (mem:SI (symbol_ref:SI (idr_setpos) [flags 0x1]
function_decl 0x48169700 idr_setpos) [0 S4 A8])
(const_int 0 [0x0]))
(use (const_int 8 [0x8]))
(clobber (scratch:SI))
]) -1 (nil)
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 30 30))
(expr_list:REG_DEP_TRUE (use (reg:SI 4 4))
(expr_list:REG_DEP_TRUE (use (reg:SI 3 3))
(nil)
foo.c:23: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
where foo.c is simply:
#include stdlib.h
typedef struct idr {
int i_op;
size_t i_size;
char *i_buf;
char *i_ptr;
} IDR;
typedef struct idrs {
IDR i_encode;
IDR i_decode;
} IDRF;
void idr_setpos(IDR *idrs, size_t pos)
{
}
void idrf_reset_pos(IDRF *idrf)
{
idr_setpos(idrf-i_encode, 0);
idr_setpos(idrf-i_decode, 0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug middle-end/36075] New: [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20021119-1.c -w -O2 -fno-show -column -lm -o /mnt/gnu/gcc/objdir/gcc/testsuite/gcc/20021119-1.x2 (timeou t = 300) PASS: gcc.c-torture/execute/20021119-1.c compilation, -O2 Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gcc FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2 Revision 134604 was ok. -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.1 --with-gmp=/opt/gnu/gcc/gcc-4.3.1 --enable-threads=posix --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.3.1 20080427 (prerelease) [gcc-4_3-branch revision 134730] (GCC) -- Summary: [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119- 1.c execution, -O2 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36075
[Bug fortran/35993] [4.3/4.4 regression] wrong answer for all array intrinsics with scalar mask
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-04-29 03:14 --- The patch fixes sum, product, and minloc. Regression tests OK on x86-64. Thanks for patch. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35993
[Bug middle-end/36041] Speed up builtin_popcountll
--- Comment #6 from intvnut at gmail dot com 2008-04-29 03:42 --- (In reply to comment #5) It should be possible to have an alternate implementation in libgcc2.c by means of just selecting on a proper architecture define or the size of the argument mode. I see where it would go in libgcc2.c, but I don't know the appropriate architecture defines to key off of, since I really do know nothing about GCC's internals. Since the method I used above is likely to be a strict improvement over the table driven method on 32-bit and 64-bit targets, is it enough to, say, key off of #if W_TYPE_SIZE == 32 and #if W_TYPE_SIZE == 64? Is there some documentation I can read to know how best to propose a patch? (I'm just a motivated user, not a compiler developer, in case you couldn't tell.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
[Bug libstdc++/35887] stl parallel includes installed for --disable-libgomp
--- Comment #9 from bkoz at gcc dot gnu dot org 2008-04-29 04:41 --- Subject: Bug 35887 Author: bkoz Date: Tue Apr 29 04:40:08 2008 New Revision: 134776 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134776 Log: 2008-04-28 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35887 * acinclude.m4 (GLIBCXX_ENABLE_PARALLEL): Revert back to just checking for omp.h. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35887
[Bug target/35100] [4.1/4.2/4.3 regression] internal compiler error: in extract_insn, at recog.c:1990
--- Comment #7 from manus at eiffel dot com 2008-04-29 04:51 --- Just adding the version information of gcc: lisbon [Manu] : gcc -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --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.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) It would be nice to reopen the case since it is definitely reproducible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug fortran/36058] Not allowing pointers to derived types in COMMON
--- Comment #4 from burnus at gcc dot gnu dot org 2008-04-29 05:21 --- Close as INVALID. Richard Maine wrote in c.l.f (see link above): -- Contrary to you, my reading is that this applies also to a pointer to a derived type. I can read it either way, I don't really see how. I strongly agree with Tobias here. I think you are confusing an important aspect of Fortran pointers with C ones. In Fortran, pointer is an attribute. It does *NOT* make a separate type. If the common-block-object has (derived) type x, then adding the pointer attribute doesn't change the type. It is still of the same type and thus the above restriction still applies. If you try to read such words any other way, I think you'll find that large parts of the standard fall apart - at least if one tries to apply the same reading throughout the standard. -- -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36058
