[Bug rtl-optimization/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-13 06:59 --- The patch of comment #1 is not the right thing to do. What it means, is that recog_data finds an operand for which the insn has no df_ref. Caused by http://gcc.gnu.org/viewcvs?view=revision&revision=158187 -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-13 06:59:44 date|| Summary|web.c/union_match_dups |[4.6 Regression] |segfaults for a null *ref on|web.c/union_match_dups |sh-elf |segfaults for a null *ref on ||sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug target/43744] SH: Error: pcrel too far
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-04-13 06:56 --- Looks that Christian's patch pic-cp.patch http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794 in PR target/42841 can fix the problem. Could you please try it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug target/43744] SH: Error: pcrel too far
--- Comment #2 from kkojima at gcc dot gnu dot org 2010-04-13 06:34 --- Confirmd. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 GCC host triplet|sh4-unknown-linux-gnu | GCC target triplet||sh4-unknown-linux-gnu Known to fail||4.4.3 Known to work||4.3.4 4.5.0 4.6.0 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-04-13 06:34:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug c/43744] SH: Error: pcrel too far
--- Comment #1 from iwamatsu at nigauri dot org 2010-04-13 06:12 --- Created an attachment (id=20376) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20376&action=view) source code that can reproduce problem This is the source code that can reproduce a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug c/43744] New: SH: Error: pcrel too far
$ gcc-4.4 -c -D_GNU_SOURCE -D_REENTRANT -Wall -g -O2 -fPIC -DPIC db4.8-x.c ../dist/../lock/lock_deadlock.c: In function '__lock_detect': ../dist/../lock/lock_deadlock.c:123: warning: 'idmap' may be used uninitialized in this function ../dist/../lock/lock_deadlock.c:124: warning: 'bitmap' may be used uninitialized in this function ../dist/../lock/lock_deadlock.c:125: warning: 'nalloc' may be used uninitialized in this function ../dist/../lock/lock_deadlock.c:125: warning: 'nlockers' may be used uninitialized in this function /tmp/cc8awAVe.s: Assembler messages: /tmp/cc8awAVe.s:3023: Error: pcrel too far gcc-4.1 and gcc-4.3 work fine. $ gcc-4.4 -v Using built-in specs. Target: sh4-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --with-multilib-list=m4,m4-nofpu --with-cpu=sh4 --enable-checking=release --build=sh4-linux-gnu --host=sh4-linux-gnu --target=sh4-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-7) gcc-4.4 (4.4.3-7) unstable; urgency=low . * Update to SVN 20100401 from the gcc-4_4-branch (r157925). - Fix PR libfortran/43517, PR tree-optimization/43528, PR target/43524, PR middle-end/43600, PR other/43562, PR target/39254, PR target/42113, PR c/43381, PR c++/41185, PR c++/41786, PR fortran/43409, PR fortran/43409, PR libfortran/43265, PR fortran/43551, PR libfortran/43605. -- Summary: SH: Error: pcrel too far Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iwamatsu at nigauri dot org GCC host triplet: sh4-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #41 from davek at gcc dot gnu dot org 2010-04-13 06:01 --- Thanks everyone for all the help with testing and validation :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #40 from davek at gcc dot gnu dot org 2010-04-13 05:58 --- Submitted to -patches list at: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html -- davek at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug bootstrap/43737] Bootstrap broken at -O3
--- Comment #1 from spop at gcc dot gnu dot org 2010-04-13 05:41 --- This commit causes the bootstrap to fail at -O3. c26ce8a90a7c8ef9b6587959083d12f6edbc5e01 is first bad commit commit c26ce8a90a7c8ef9b6587959083d12f6edbc5e01 Author: rguenth Date: Wed Apr 7 12:31:32 2010 + 2010-04-07 Richard Guenther PR tree-optimization/43270 * tree-vrp.c (check_array_ref): Fix flexible array member detection. * tree-ssa-sccvn.h (fully_constant_vn_reference_p): Declare. * tree-ssa-pre.c (phi_translate_1): Adjust. (fully_constant_expression): Split out vn_reference handling to ... * tree-ssa-sccvn.c (fully_constant_vn_reference_p): ... here. Fold reads from constant strings. (vn_reference_lookup): Handle fully constant references. (vn_reference_lookup_pieces): Likewise. * Makefile.in (expmed.o-warn): Add -Wno-error. * g++.dg/warn/Warray-bounds-4.C: New testcase. * gcc.dg/Warray-bounds-7.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr...@158058 138bc75d-0d04-0410-961f-82ee72b054a4 -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug fortran/37355] Request runtime preconnected buffer option for gfortran
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-13 05:40 --- (In reply to comment #4) > Looking at latest gfortran, we have raw_init and buf_init functions which set > the style of I/O. I think it would be relatively easy now to create a Gnu > extension as an intrinsic procedure call that will force a flush on a unit The question is whether it needs to be some easily accessible intrinsic function or whether some __gfortran_set_* would be enough; cf. http://gcc.gnu.org/onlinedocs/gfortran/Non_002dFortran-Main-Program.html The latter, which just sets a variable would be also an option. Actually, one could think of adding an item to _gfortran_set_options -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37355
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-04-13 04:31 --- With current trunk (4.6) I see this: $ valgrind --leak-check=full f951 parameter_array_init_4.f90 --- snip --- ==12209== 48 bytes in 6 blocks are definitely lost in loss record 21 of 352 ==12209==at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==12209==by 0x36F3809F38: __gmp_default_allocate (in /usr/lib64/libgmp.so.3.5.0) ==12209==by 0x36F381A17D: __gmpz_init_set (in /usr/lib64/libgmp.so.3.5.0) ==12209==by 0x4B20C9: gfc_copy_shape (expr.c:373) ==12209==by 0x4B2353: gfc_copy_expr (expr.c:556) ==12209==by 0x4B5567: simplify_parameter_variable (expr.c:1633) ==12209==by 0x4B5317: gfc_simplify_expr (expr.c:1744) ==12209==by 0x4B5236: gfc_simplify_expr (expr.c:882) ==12209==by 0x4FE188: resolve_operator (resolve.c:3584) ==12209==by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209==by 0x4FDFF2: resolve_operator (resolve.c:3316) ==12209==by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== ==12209== 72 bytes in 9 blocks are definitely lost in loss record 202 of 352 ==12209==at 0x4A0515D: malloc (vg_replace_malloc.c:195) ==12209==by 0x36F3809F38: __gmp_default_allocate (in /usr/lib64/libgmp.so.3.5.0) ==12209==by 0x36F381A17D: __gmpz_init_set (in /usr/lib64/libgmp.so.3.5.0) ==12209==by 0x4B20C9: gfc_copy_shape (expr.c:373) ==12209==by 0x4B2353: gfc_copy_expr (expr.c:556) ==12209==by 0x4B5567: simplify_parameter_variable (expr.c:1633) ==12209==by 0x4B5317: gfc_simplify_expr (expr.c:1744) ==12209==by 0x4B5236: gfc_simplify_expr (expr.c:882) ==12209==by 0x4FE188: resolve_operator (resolve.c:3584) ==12209==by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209==by 0x4FE04B: resolve_operator (resolve.c:3307) ==12209==by 0x4F8C04: gfc_resolve_expr (resolve.c:5587) ==12209== ==12209== 158 bytes in 1 blocks are definitely lost in loss record 276 of 352 ==12209==at 0x4A04481: calloc (vg_replace_malloc.c:418) ==12209==by 0xC8DE48: xcalloc (xmalloc.c:162) ==12209==by 0x625854: init_emit (emit-rtl.c:5566) ==12209==by 0x6B9EC7: prepare_function_start (function.c:4183) ==12209==by 0x6B9F68: init_function_start (function.c:4231) ==12209==by 0x5373CD: trans_function_start (trans-decl.c:1928) ==12209==by 0x540976: gfc_generate_function_code (trans-decl.c:4292) ==12209==by 0x4ECC9B: gfc_parse_file (parse.c:4226) ==12209==by 0x521BF7: gfc_be_parse_file (f95-lang.c:239) ==12209==by 0x80A2BB: do_compile (toplev.c:1053) ==12209==by 0x80A9FD: toplev_main (toplev.c:2459) ==12209==by 0x36EE81EB1C: (below main) (libc-start.c:226) ==12209== ==12209== 158 bytes in 1 blocks are definitely lost in loss record 277 of 352 ==12209==at 0x4A04481: calloc (vg_replace_malloc.c:418) ==12209==by 0xC8DE48: xcalloc (xmalloc.c:162) ==12209==by 0x625854: init_emit (emit-rtl.c:5566) ==12209==by 0x6B9EC7: prepare_function_start (function.c:4183) ==12209==by 0x6B9F68: init_function_start (function.c:4231) ==12209==by 0x54122C: gfc_generate_function_code (trans-decl.c:4105) ==12209==by 0x4ECC9B: gfc_parse_file (parse.c:4226) ==12209==by 0x521BF7: gfc_be_parse_file (f95-lang.c:239) ==12209==by 0x80A2BB: do_compile (toplev.c:1053) ==12209==by 0x80A9FD: toplev_main (toplev.c:2459) ==12209==by 0x36EE81EB1C: (below main) (libc-start.c:226) ==12209== -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534
[Bug target/43743] Dumb use of SSE regs for MMX operation
--- Comment #1 from ian at airs dot com 2010-04-13 04:21 --- I forgot to mention that I was using -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
[Bug target/43743] New: Dumb use of SSE regs for MMX operation
On 32-bit x86 I compiled this test case with -msse2 -mmmx:
#include
__m64 foo (int *p)
{
__m64 m1 = _mm_cvtsi32_si64 (*p++);
__m64 m2 = _mm_cvtsi32_si64 (*p);
return _mm_unpacklo_pi8 (m1, m2);
}
Note that all operations are MMX functions defined in mmintrin.h. The
resulting assembler code includes the following:
movd(%eax), %xmm0
movq%xmm0, -8(%ebp)
movd4(%eax), %xmm0
movq-8(%ebp), %mm0
movq%xmm0, -16(%ebp)
punpcklbw -16(%ebp), %mm0
If I take off -msse2, I get this:
movd(%eax), %mm0
movd4(%eax), %mm1
punpcklbw %mm1, %mm0
That is not optimal--the 4(%eax) can appear directly in the punpcklbw
instruction--but it is much better than the first result. The mere presence of
-msse2 should not cause SSE registers to be used when only MMX operations are
requested.
--
Summary: Dumb use of SSE regs for MMX operation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43743
[Bug fortran/37355] Request runtime preconnected buffer option for gfortran
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-13 04:10 --- Looking at latest gfortran, we have raw_init and buf_init functions which set the style of I/O. I think it would be relatively easy now to create a Gnu extension as an intrinsic procedure call that will force a flush on a unit and then call raw_init or buf_init based on some parameter passed to the procedure. We would have to make sure the unit has the lock when doing this. We also have to make sure we have no pending asynchronous I/O happening. In other words, we force a WAIT as well. I will assign myself to this as a reminder. I may not get to it, so if someone else wishes to do so, take it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-11 19:30:14 |2010-04-13 04:10:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37355
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #43 from howarth at nitro dot med dot uc dot edu 2010-04-13
01:54 ---
Interestingly, if you examine clang/lib/Driver/Tools.cpp from the upcoming 2.7
release, you find...
// FIXME: For some reason GCC passes -lgcc before adding
// the default system libraries. Just mimic this for now.
CmdArgs.push_back("-lgcc");
in both auroraux::Link::ConstructJob() and openbsd::Link::ConstructJob(). I'll
ping one of the darwin linker developers about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug rtl-optimization/43742] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-04-13 01:40 --- Created an attachment (id=20375) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20375&action=view) A reduced test case It fails also on sh-elf with -m4 -O -funroll-loops. I've confirmed that the patch below can fix the failure, though I'm not sure that this is the right thing to do. -- * web.c (union_match_dups): Call FUN only if *REF is non null. diff -up ORIG/trunk/gcc/web.c trunk/gcc/web.c --- ORIG/trunk/gcc/web.c2010-04-12 09:52:37.0 +0900 +++ trunk/gcc/web.c 2010-04-12 11:14:13.0 +0900 @@ -123,7 +123,8 @@ union_match_dups (rtx insn, struct web_e if (DF_REF_LOC (*ref) == recog_data.operand_loc[op]) break; - (*fun) (use_entry + DF_REF_ID (*dupref), entry + DF_REF_ID (*ref)); + if (*ref != NULL) + (*fun) (use_entry + DF_REF_ID (*dupref), entry + DF_REF_ID (*ref)); } } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug rtl-optimization/43742] New: web.c/union_match_dups segfaults for a null *ref on sh-elf
sh4-unknown-linux-gnu failed to build during compiling libgfortran with /exp/ldroot/dodes/xsh-gcc-orig/./gcc/xgcc -B/exp/ldroot/dodes/xsh-gcc-orig/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem /usr/local/sh4-unknown-linux-gnu/include -isystem /usr/local/sh4-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../ORIG/trunk/libgfortran -iquote../../../ORIG/trunk/libgfortran/io -I../../../ORIG/trunk/libgfortran/../gcc -I../../../ORIG/trunk/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -mieee -ftree-vectorize -funroll-loops -g -O2 -MT matmul_i1.lo -MD -MP -MF .deps/matmul_i1.Tpo -c ../../../ORIG/trunk/libgfortran/generated/matmul_i1.c -fPIC -DPIC -o .libs/matmul_i1.o ../../../ORIG/trunk/libgfortran/generated/matmul_i1.c: In function 'matmul_i1': ../../../ORIG/trunk/libgfortran/generated/matmul_i1.c:374:1: internal compiler error: Segmentation fault It starts to fail after r158187 | bernds | 2010-04-10 21:30:29 +0900 (Sat, 10 Apr 2010) | 7 lines * Makefile.in (web.o): Depend on insn-config.h and $(RECOG_H). * web.c: Include "insn-config.h" and "recog.h". (union_match_dups): New function. (web_main): Call it. (union_defs): Don't try to recognize match_dups. and that segfault happens at the line (*fun) (use_entry + DF_REF_ID (*dupref), entry + DF_REF_ID (*ref)); of union_match_dups for a null *ref. -- Summary: web.c/union_match_dups segfaults for a null *ref on sh- elf Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug middle-end/43740] [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #2 from danglin at gcc dot gnu dot org 2010-04-13 01:30 --- Compiler must be miscompiled as stage1-gcc/cc1 doesn't have fault. Starting program: /mnt/gnu/gcc/objdir/gcc/cc1 -iprefix /mnt/gnu/gcc/objdir/gcc/../lib/gcc/hppa64-hp-hpux11.11/4.5.0/ -isystem /mnt/gnu/gcc/objdir/gcc/include -isystem /mnt/gnu/gcc/objdir/gcc/include-fixed /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c -quiet -dumpbase 20031015-1.c -auxbase-strip 20031015-1.s -O1 -version -fdump-tree-alias-vops -o 20031015-1.s warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. warning: Loadable segment ".tbss" outside of ELF segments warning: Loadable segment ".tbss" outside of ELF segments GNU C (GCC) version 4.5.0 20100411 (prerelease) [gcc-4_5-branch revision 158204] (hppa64-hp-hpux11.11) compiled by GNU C version 4.5.0 20100411 (prerelease) [gcc-4_5-branch revision 158204], GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.5.0 20100411 (prerelease) [gcc-4_5-branch revision 158204] (hppa64-hp-hpux11.11) compiled by GNU C version 4.5.0 20100411 (prerelease) [gcc-4_5-branch revision 158204], GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 524dd7bb1c7d8a97e70eedfe5581819e Program received signal SIGSEGV, Segmentation fault. 0x4034a3e0 in dump_gimple_stmt (buffer=0x8001000aedf8, gs=0x83fffdf9a360, spc=2, flags=576) at ../../gcc/gcc/gimple-pretty-print.c:77 77INDENT (spc); (gdb) disass 0x4034a3d0 0x4034a3f0 Dump of assembler code from 0x4034a3d0 to 0x4034a3f0: 0x4034a3d0 : ldw,s ret0(r19),ret0 0x4034a3d4 : ldd,s ret0(r31),ret0 0x4034a3d8 : cmpb,*= r0,ret0,0x4034b8a8 0x4034a3dc : add,l r6,ret0,ret0 0x4034a3e0 : ldd ret0(r11),r25 0x4034a3e4 : copy dp,r4 0x4034a3e8 : copy r5,r26 0x4034a3ec : copy r8,r24 $2 = Value can't be converted to integer. (gdb) p/x $r11 (gdb) p/x $ret0 $4 = 0x83fffdf9a3b0 Base and index registers are interchanged. Revision 157955 was ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug middle-end/43740] [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #1 from danglin at gcc dot gnu dot org 2010-04-13 01:17 --- asm processing is broken causing several tests to fail for the same reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug target/43741] sh-elf ICEs for libstdc++-v3/src/ios_init.cc with -m2a
--- Comment #1 from kkojima at gcc dot gnu dot org 2010-04-13 01:16 ---
Created an attachment (id=20374)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20374&action=view)
a reduced test case
xxx.ii: In constructor 'std::ios_base::Init::Init()':
xxx.ii:161:3: error: insn does not satisfy its constraints:
(insn 284 282 285 6 xxx.ii:113 (set (reg:SI 1 r1)
(reg/f:SI 319)) 176 {movsi_ie} (nil))
xxx.ii:161:3: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
which shows that the pseudo register remains after reload.
The .ira rtl dump looks that sh_legitimize_reload_address makes
a too complex reload for this case. I've confirmed the patch
below fix the above failure. I'll apply it if it survives
the usual tests and doesn't make the code quality worse with
CSiBE tests.
--- ORIG/trunk/gcc/config/sh/sh.c 2010-04-12 09:52:36.0 +0900
+++ trunk/gcc/config/sh/sh.c2010-04-13 08:55:31.0 +0900
@@ -9649,8 +9649,7 @@ sh_legitimize_reload_address (rtx *p, en
|| XEXP (*p, 0) == hard_frame_pointer_rtx))
{
rtx index_rtx = XEXP (*p, 1);
- HOST_WIDE_INT offset = INTVAL (index_rtx), offset_base;
- rtx sum;
+ HOST_WIDE_INT offset = INTVAL (index_rtx);
if (TARGET_SH2A && mode == DFmode && (offset & 0x7))
{
@@ -9665,24 +9664,6 @@ sh_legitimize_reload_address (rtx *p, en
BASE_REG_CLASS, Pmode, VOIDmode, 0, 0, opnum, type);
goto win;
}
- /* Instead of offset_base 128..131 use 124..127, so that
-simple add suffices. */
- if (offset > 127)
- offset_base = ((offset + 4) & ~60) - 4;
- else
- offset_base = offset & ~60;
- /* Sometimes the normal form does not suit DImode. We could avoid
-that by using smaller ranges, but that would give less optimized
-code when SImode is prevalent. */
- if (offset_base != 0
- && GET_MODE_SIZE (mode) + offset - offset_base <= 64)
- {
- sum = gen_rtx_PLUS (Pmode, XEXP (*p, 0), GEN_INT (offset_base));
- *p = gen_rtx_PLUS (Pmode, sum, GEN_INT (offset - offset_base));
- push_reload (sum, NULL_RTX, &XEXP (*p, 0), NULL,
- BASE_REG_CLASS, Pmode, VOIDmode, 0, 0, opnum, type);
- goto win;
- }
}
/* We must re-recognize what we created before. */
else if (GET_CODE (*p) == PLUS
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43741
[Bug target/43741] New: sh-elf ICEs for libstdc++-v3/src/ios_init.cc with -m2a
Unified build on sh-unknown-elf with enabling c++ ICEs during compiling libstdc++-v3/src/ios_init.cc with -m2a. It starts to fail my recent change r158208 | kkojima | 2010-04-12 07:59:36 +0900 (Mon, 12 Apr 2010) | 7 lines * config/sh/sh-protos.h (sh_legitimize_reload_address): Declare. * config/sh/sh.c: Include reload.h. (sh_legitimize_reload_address): New. * config/sh/sh.h (LEGITIMIZE_RELOAD_ADDRESS): Use sh_legitimize_reload_address. -- Summary: sh-elf ICEs for libstdc++-v3/src/ios_init.cc with -m2a Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kkojima at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43741
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #42 from iains at gcc dot gnu dot org 2010-04-13 01:07 --- actually, The logic in libgcc_s/libgcc_ext is working properly - libgcc_s.10.5 => /usr/libgcc_s.1.dylib => /usr/libSystem.dylib. The function is named in /usr/lib/libgcc_s.10.5. What is happening is Bad [at least IMO]; we have a "catch-all" -lgcc at the end of each REAL_LIBGCC_SPEC line - which I'm itching to remove (because, basically, it should not be necessary). In the case of the 'working - by removing lm' what seems to be happening is that the function is being picked up from the the static libgcc.a from that catch-all. in fact, the cases should fail regardless of -lm - since the function should be sourced from the system-library via the libgcc_s.10.5 stubs. [FWIW the libgcc_s.10.5 stubs should also be removed for D10 - since they don't add anything (except consumption of time) to the exercise.] I dunno: I realize that people would prefer tests to pass - but I worry about the tortuous way in which we are layering libraries (I'd really like to get rid of the catch-all -lgcc) [although it could always be applied temporarily ahead of the -lSystem in the LIB_SPEC for D10]. I guess the Right Thing is to XFAIL that test until the system lib is fixed... We should still control the use/placement of -lm --- I've not changed opinion on that. And we should still file a "-lm not needed on Darwin" with Dejagnu (in spite of nothing likely to happen quickly). A user who REALLY wants the functions from libgcc.a can always put it on the cl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug middle-end/43740] New: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c -O1 -fdump-tree-alias-v ops -S -o 20031015-1.s(timeout = 300) /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c: In function 'main': /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/20031015-1.c:9:1: internal compil er error: Segmentation fault -- Summary: [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error) Product: gcc Version: 4.5.0 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: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug testsuite/43739] New: FAIL: gcc.dg/pr43643.c (test for excess errors)
Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr43643.c -O2 -pg -lm -o ./pr43643.exe (timeout = 300) Warning: consider linking with `-static' as system libraries with profiling support are only provided in archive format ld: Unsatisfied symbol "pthread_attr_setdetachstate" in file /mnt/gnu/gcc/objdir /gcc/libgcc_eh.a[unwind-dw2-fde.o] ld: Unsatisfied symbol "pthread_mutex_unlock" in file /mnt/gnu/gcc/objdir/gcc/li bgcc_eh.a[unwind-dw2-fde.o] ld: Unsatisfied symbol "pthread_attr_destroy" in file /mnt/gnu/gcc/objdir/gcc/li bgcc_eh.a[unwind-dw2-fde.o] ld: Unsatisfied symbol "pthread_mutex_lock" in file /mnt/gnu/gcc/objdir/gcc/libg cc_eh.a[unwind-dw2-fde.o] 4 errors. collect2: ld returned 1 exit status -- Summary: FAIL: gcc.dg/pr43643.c (test for excess errors) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
--- Comment #1 from sherpya at netfarm dot it 2010-04-12 23:36 --- FIONREAD is defined by winsock header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/43738] basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug libstdc++/43738] New: basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32
basic_file_stdio.cc in __basic_file::showmanyc() uses ioctl with FIONREAD, but the equivalent on win32 is ioctlsocket, perhaps not usable here, because I think there is not support for socket here in gcc (I'm wrong?) anyway it does not compiles I solve this by commenting out that part int __r = ioctl(this->fd(), FIONREAD, &__num); if (!__r && __num >= 0) return __num; the problem still there since 4.3 iirc, I'm the only that noticed it? there is something wrong in my setup? my configure options: ../gcc/configure\ --prefix=/mingw \ --disable-bootstrap \ --with-gnu-ld \ --target=i686-pc-mingw32\ --with-tune=generic \ --with-cpu=i686 \ --disable-cpp \ --disable-win32-registry\ --disable-shared\ --enable-static \ --program-suffix=-4.6 \ --enable-version-specific-runtime-libs \ --enable-languages=c,c++\ --enable-cld\ --enable-__cxa_atexit \ --disable-werror\ --disable-checking \ --enable-multilib \ --enable-threads=posix \ --disable-libssp\ --with-dwarf2 \ --disable-nls \ --with-ppl \ --disable-cloog \ --enable-libgomp -- Summary: basic_file_stdio.cc uses ioctl on a fd, but not available on mingw32 Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43738
[Bug target/43729] MachO LTO support needed for darwin
--- Comment #4 from fang at csl dot cornell dot edu 2010-04-12 21:39 --- Plz? :) -- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug target/43722] ICE when passing NEON registers using const refrences
--- Comment #6 from mikpe at it dot uu dot se 2010-04-12 21:38 --- Created an attachment (id=20373) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20373&action=view) proposed 4.4 fix for PR43722 Turns out r147577 contains a few redundant changes wrt this bug. The attached patch backports just those bits needed to fix the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug objc/35996] ICE while building simple ObjC code with -fobjc-gc
--- Comment #9 from mrs at gcc dot gnu dot org 2010-04-12 21:32 --- Agreed. -- mrs at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
[Bug bootstrap/43737] New: Bootstrap broken at -O3
I was trying to bootstrap GCC rev. 158136 with a different BOOT_CFLAGS: --- a/Makefile.in +++ b/Makefile.in @@ -352,7 +352,7 @@ BUILD_PREFIX_1 = @BUILD_PREFIX_1@ # Flags to pass to stage2 and later makes. They are defined # here so that they can be overridden by Makefile fragments. -BOOT_CFLAGS= -g -O2 +BOOT_CFLAGS= -g -O3 -msse2 BOOT_LDFLAGS= BOOT_ADAFLAGS=-gnatpg -gnata The bootstrap stops during the compilation of builtins.c with this error: cc1: warnings being treated as errors ../../gcc/builtins.c: In function ‘builtin_strncpy_read_str’: ../../gcc/builtins.c:567:37: error: array subscript is above array bounds This is error comes from one of VRP's checks. -- Summary: Bootstrap broken at -O3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug middle-end/43365] [4.5 Regression] Destructor not called when returning in exception handler
--- Comment #6 from erik at ejohansson dot se 2010-04-12 20:50 --- Tested with latest Debian gcc-snapshot on the code where I originally saw the problem and it works now. Thank you very much. Tested with: gcc (Debian 20100408-1) 4.5.0 20100408 (prerelease) [gcc-4_5-branch revision 158131] -- erik at ejohansson dot se changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43365
[Bug middle-end/43718] march does not display --help=target enable/disable correctly
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 20:48 --- OVERRIDE_OPTIONS is called after the printing out the --help message. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Component|target |middle-end Keywords||diagnostic Summary|march doesn't conform to|march does not display -- |documentation |help=target enable/disable ||correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43718
[Bug c++/42844] const variable requires initializer / no explicitly declared default constructor
--- Comment #11 from fabien dot chene at gmail dot com 2010-04-12 20:45 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00604.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
[Bug middle-end/43736] Invalid uninitialized variable warning at -O3 -Wall
--- Comment #2 from dougsemler at gmail dot com 2010-04-12 20:44 --- FWIW: I realized that I have been playing around with newer ppl and the compiler is dynamically linking against ppl 0.11 and gmp 5 rather than ppl 0.10 and gmp 4. When I get rid of the experimental libs in my link path, it does not spew the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43736
[Bug target/43718] march doesn't conform to documentation
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 20:44 --- I think this is really an issue of how --help=target is displaying the enable/disable part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43718
[Bug target/43722] ICE when passing NEON registers using const refrences
--- Comment #5 from mikpe at it dot uu dot se 2010-04-12 20:35 --- Created an attachment (id=20372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20372&action=view) reduced test case in plain C Reduced test case. This one ICEs both 4.4 and 4.3 but not 4.5. Using the reduced test case a new bisection of trunk identified r147577 as the fix for this bug. r147577 added support for PRE_DEC in NEON memory operands, which makes sense given the pre_dec in the insn that gcc complains about. r147577 applies easily to 4.4 and eliminates the ICE. I'll start a full bootstrap and regression test on this combo in a few minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
[Bug middle-end/43736] Invalid uninitialized variable warning at -O3 -Wall
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 20:28 --- This is the standard if(a) x=,y=,z=; . if (a) use(x,y,z); uninitialized warning issue (I cannot find a bug about this really). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43736
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #5 from marcus at jet dot franken dot de 2010-04-12 20:25 --- gcc version 4.5.0 20100331 (experimental) [trunk revision 157870] (SUSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug c/43736] New: Invalid uninitialized variable warning at -O3 -Wall
Invalid warnings about uninitialized variables are given when compiling the
following code at -O3 with gcc 4.4.3 (I see it in 4.5 as well). If I remove
the loop then the warning disappears. This is a contrived example based on
binutils/dwarf.c (which errors out when building with -Werror -Wall -O3). The
order of the check in the !do_loc && do_types if statement is important.
Obviously, the do_types code path would be taken in both cases.
problem.c:
int do_types;
int do_loc;
unsigned char storage[8];
void testfunc(void)
{
int i;
int j;
unsigned char array[8];
for (j = 0; j < 1; j++)
{
if (do_types)
for (i = 0; i < 8; i++)
array[i] = storage[i];
if (!do_loc && do_types)
for (i = 0; i < 8; i++)
storage[i] = array[i];
}
}
EOF
prompt> gcc -c -O3 problem.c -Wall
problem.c: In function ‘testfunc’:
problem.c:9: warning: ‘array[7]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[6]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[5]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[4]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[3]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[2]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[1]’ may be used uninitialized in this function
problem.c:9: warning: ‘array[0]’ may be used uninitialized in this function
prompt> gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)
--
Summary: Invalid uninitialized variable warning at -O3 -Wall
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougsemler at gmail dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43736
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #17 from ubizjak at gmail dot com 2010-04-12 20:02 --- (In reply to comment #15) > GNU as 2.15 doesn't believe you :-) > > $ echo sahf > test.s > $ /usr/sfw/bin/gas test.s > $ /usr/sfw/bin/gas --64 test.s > test.s: Assembler messages: > test.s:1: Error: suffix or operands invalid for `sahf' Well - dear GNU as 2.15 - sahf doesn't have any operands. ;) This looks like a bug in binutils 2.15, because otherwise: $ as --64 tt.s tt.s: Assembler messages: tt.s:1: Error: no such instruction: `evil_nonexistent_insn' OTOH, the patch from comment #16 is a bad idea, it will cripple non-GAS assemblers (and as discussed elsewhere, it isn't effective for solaris anyway). I'd suggest you just upgrade your binutils... -march=core2 switches -mssse3 and 2.15 will be immediately out of luck for any vectorized code due to the usage of SSSE3 permute insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug c++/43641] [C++0x] internal compiler error: tree check: expected call_expr, have target_expr in maybe_add_lambda_conv_op
--- Comment #9 from jason at gcc dot gnu dot org 2010-04-12 19:59 --- Subject: Bug 43641 Author: jason Date: Mon Apr 12 19:58:49 2010 New Revision: 158241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158241 Log: PR c++/43641 * semantics.c (maybe_add_lambda_conv_op): Use build_call_a and tweak return value directly. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43641
[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.
--- Comment #13 from jason at gcc dot gnu dot org 2010-04-12 19:58 --- Subject: Bug 25811 Author: jason Date: Mon Apr 12 19:58:27 2010 New Revision: 158239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158239 Log: PR c++/25811 * cp-tree.h (diagnose_uninitialized_cst_or_ref_member): Declare. * init.c (build_new_1): Check for uninitialized const members and uninitialized reference members, when using new without new-initializer. Call diagnose_uninitialized_cst_or_ref_member. (diagnose_uninitialized_cst_or_ref_member): Define, call diagnose_uninitialized_cst_or_ref_member_1. (diagnose_uninitialized_cst_or_ref_member_1): New function. Added: trunk/gcc/testsuite/g++.dg/init/pr25811.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25811
[Bug middle-end/42509] [4.4 Regression] nonoverlapping_memrefs_p misinterprets NULL MEM_OFFSET as const0_rtx
-- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords|build |patch Summary|[4.4 Regression] bootstrap |[4.4 Regression] |failure in stage3 (integer |nonoverlapping_memrefs_p |overflow in preprocessor|misinterprets NULL |expression) |MEM_OFFSET as const0_rtx Target Milestone|4.5.0 |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug middle-end/42509] [4.4 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)
--- Comment #28 from steven at gcc dot gnu dot org 2010-04-12 19:56 --- Triggers in 4.4 with an out-of-tree port. See http://gcc.gnu.org/ml/gcc/2010-04/msg00243.html -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.4.3 Known to work||4.5.0 Resolution|FIXED | Summary|[4.5 Regression] bootstrap |[4.4 Regression] bootstrap |failure in stage3 (integer |failure in stage3 (integer |overflow in preprocessor|overflow in preprocessor |expression) |expression) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
[Bug middle-end/43735] New: [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
On Linux/ia32, revision 158227 gave: FAIL: gcc.dg/guality/inline-params.c -O2 -fwhopr execution test Revision 158222 is OK. Revision 158225: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00329.html may be the cause. -- Summary: [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c Product: gcc Version: 4.6.0 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43735
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #34 from mikpe at it dot uu dot se 2010-04-12 19:03 --- Created an attachment (id=20371) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20371&action=view) eliminate use of _Unwind_GetRegionStart on ARM, take 2 The previous patch to eliminate _Unwind_GetRegionStart on ARM suffered from major misalignment exceptions. The function pointers in the @LPStart fields weren't resolved by the linker but apparently required runtime fixup by glibc. Since they are always misaligned (the LSDA blob starts aligned with a format byte followed by the @LPStart pointer), each @LPStart value resulted in two alignment exceptions. Ouch. The new version of the patch makes the @LPStart pointers PC-relative which eliminates the runtime fixups and thus the alignment exceptions. -- mikpe at it dot uu dot se changed: What|Removed |Added Attachment #20333|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
--- Comment #8 from zsojka at seznam dot cz 2010-04-12 18:55 --- Created an attachment (id=20370) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20370&action=view) execution tests that FAIL with -fno-ira-share-spill-slots r158225, x86_64-linux, languages=c,c++,lto,fortran $ make check RUNTESTFLAGS="--target_board=unix/-fno-ira-share-spill-slots" $ cat gcc/testsuite/*/*.log | grep '^FAIL:' | grep 'exec' &> pr40386.txt Without duplicates, this is the list of files that at least once fail the execution test: c-c++-common/torture/complex-sign-mixed-div.c gcc.c-torture/execute/builtins/pr22237.c gcc.c-torture/execute/pr23135.c gcc.c-torture/execute/pr28982a.c gcc.c-torture/execute/pr28982b.c gcc.c-torture/execute/20020508-2.c gcc.c-torture/execute/20020508-3.c gcc.c-torture/execute/20021120-1.c gcc.dg/guality/inline-params.c gcc.dg/vect/vect-strided-u8-i8-gap4.c gcc.target/x86_64/abi/test_passing_floats.c gfortran.dg/alloc_comp_assign_2.f90 gfortran.dg/alloc_comp_assign_3.f90 gfortran.dg/eoshift_large_1.f90 gfortran.dg/func_derived_1.f90 gfortran.dg/reshape_rank7.f90 gfortran.fortran-torture/execute/intrinsic_cshift.f90 g++.old-deja/g++.eh/ia64-1.C There were no ICEs caused by this flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug testsuite/25766] objc.dg/stret-2.m fails on i686-darwin
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-12 18:53 --- see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00584.html for an updated patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25766
[Bug bootstrap/43714] missing check for zlib.h, fails to build lto-compress.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 18:50 --- Yes you say use the system zlib so if you don't have it installed, well you get what you deserve. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43714
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|lm32-rtems* ICE |[4.5/4.6 Regression] lm32- ||rtems* ICE Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/43727] undefined reference to `_restgpr_30_x'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #16 from ubizjak at gmail dot com 2010-04-12 18:42 --- Can you try this (untested) patch? Index: acinclude.m4 === --- acinclude.m4(revision 158225) +++ acinclude.m4(working copy) @@ -452,6 +452,9 @@ dnl Always pass --32 to ia32 Linux assembler. gcc_cv_as_flags="--32" ;; + x86_64-*-*) +gcc_cv_as_flags="--64" +;; *) gcc_cv_as_flags=" " ;; -- ubizjak at gmail dot com changed: What|Removed |Added Component|libfortran |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 18:38 --- And as of: gcc version 4.6.0 20100408 (experimental) [trunk revision 158138] (GCC) So confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-12 18:38:24 date|| Summary|internal compiler error: in |[4.5/4.6 Regression] |expand_builtin_interclass_ma|internal compiler error: in |thfn, at builtins.c:2313|expand_builtin_interclass_ma ||thfn, at builtins.c:2313 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug c/43730] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:34 --- Still ICEd as of 20100401. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #15 from redi at gcc dot gnu dot org 2010-04-12 18:21 --- (In reply to comment #14) > > Why is that instruction being issued when compiling amd64/libgfortran? > > Don't worry about this insn, it works for core2. GNU as 2.15 doesn't believe you :-) $ echo sahf > test.s $ /usr/sfw/bin/gas test.s $ /usr/sfw/bin/gas --64 test.s test.s: Assembler messages: test.s:1: Error: suffix or operands invalid for `sahf' configure only tests it the first way, which is 32-bit there should be a configure test using --64 if it's going to be issued in 64-bit mode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-12 18:20 --- Well -ffixed-reg-r20 is also broken the same way :) See the duplicated bug which has a patch which I have not looked into to see if it is the correct fix yet or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
[Bug c/43732] -ffixed-reg and register globals broken for MIPS
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 --- *** This bug has been marked as a duplicate of 43700 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43732
[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 --- *** Bug 43732 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lance604 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #14 from ubizjak at gmail dot com 2010-04-12 18:16 --- (In reply to comment #13) > I can't read or write assembler, but searching the interweb tells me that sahf > is not valid in 64-bit mode, e.g. > http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also > "Introduction to 80x86 Assembly Language and Computer Architecture" by Richard > C. Detmer > > Why is that instruction being issued when compiling amd64/libgfortran? Don't worry about this insn, it works for core2. The problem is that your ./configure claims that assembler supports this mnemonic (Comment #4) while in comment #11, it doesn't. Can you debug this a bit, I don't have binutils-2.15 here anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #13 from redi at gcc dot gnu dot org 2010-04-12 18:08 --- I can't read or write assembler, but searching the interweb tells me that sahf is not valid in 64-bit mode, e.g. http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also "Introduction to 80x86 Assembly Language and Computer Architecture" by Richard C. Detmer Why is that instruction being issued when compiling amd64/libgfortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug middle-end/43702] [4.6 regression] FAIL: g++.dg/other/pr35504.C execution test
--- Comment #2 from ktietz at gcc dot gnu dot org 2010-04-12 18:06 --- Committed at revision 158232. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43702
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #12 from redi at gcc dot gnu dot org 2010-04-12 18:05 --- (In reply to comment #3) > (In reply to comment #1) > > I'm currently trying another bootstrap without --with-arch=core2 > > That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and > arch=core2 that files oops - stupid fingers - I meant fails, not files! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #11 from redi at gcc dot gnu dot org 2010-04-12 18:02 --- (In reply to comment #10) > (In reply to comment #9) > > > Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while > > /usr/ccs/bin/ld > > doesn't? > > Well, /usr/ccs/bin/as, of course. > gas barfs on it, this is the from the output of manually running the failing xgcc command, with -v and -save-temps added: /usr/sfw/bin/gas -v -I. -I../../../../gcc-4.4.3/libgfortran -I. -I../../../../gcc-4.4.3/libgfortran/../gcc -I../../../../gcc-4.4.3/libgfortran/../gcc/config -I../../.././gcc --traditional-format -V -Qy --64 -s -o .libs/date_and_time.o date_and_time.s GNU assembler version 2.15 (i386-pc-solaris2.10) using BFD version 2.15 date_and_time.s: Assembler messages: date_and_time.s:1451: Error: suffix or operands invalid for `sahf' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug c++/43734] cerr related segmentation fault
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-12 17:58 --- What happens if you do: g++ -v -save-temps -G -o libfoo.so foo.C -fPIC aka add -fPIC when building the shared library? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #10 from ubizjak at gmail dot com 2010-04-12 17:57 --- (In reply to comment #9) > Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while > /usr/ccs/bin/ld > doesn't? Well, /usr/ccs/bin/as, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #9 from ubizjak at gmail dot com 2010-04-12 17:56 --- (In reply to comment #6) > running the failing command with -save-temps shows that sahf isused here: > > .LM312: > fprem > fnstsw %ax > sahf > jp .L103 > fstp%st(1) > fstpl -56(%rbp) > movsd -56(%rbp), %xmm1 > ucomisd %xmm1, %xmm1 > jp .L109 > jne .L109 > > > adding -v confirms that /usr/sfw/bin/gas is being used as the assembler, not > some other as Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while /usr/ccs/bin/ld doesn't? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #8 from ubizjak at gmail dot com 2010-04-12 17:47 --- (In reply to comment #3) > (In reply to comment #1) > > I'm currently trying another bootstrap without --with-arch=core2 > > That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and > arch=core2 that files -march=core2 is required to generate sahf. There are targets (generic k8) that die with SIGILL when they execute 0x9e opcode. Look for lahf_lm in /proc/cpuinfo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code
--- Comment #5 from bergner at gcc dot gnu dot org 2010-04-12 17:45 --- Subject: Bug 25972 Author: bergner Date: Mon Apr 12 17:44:59 2010 New Revision: 158231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158231 Log: Backport from ibm/gcc-4_3-branch 2009-06-11 Alan Modra PR target/25972 * config/rs6000/darwin-ldouble.c (longDblUnion): Delete. (pack): New inline function. Use throughout in place of packing a pair of doubles to long double via union. Modified: branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_4-branch/gcc/config/rs6000/darwin-ldouble.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25972
[Bug c++/43734] cerr related segmentation fault
--- Comment #2 from paul dot shaklan at solipsys dot com 2010-04-12 17:39 --- Created an attachment (id=20369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20369&action=view) .ii file associated with main.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
[Bug c++/43734] cerr related segmentation fault
--- Comment #1 from paul dot shaklan at solipsys dot com 2010-04-12 17:38 --- Created an attachment (id=20368) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20368&action=view) .ii file associated with foo.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
[Bug c++/43734] New: cerr related segmentation fault
Version of GCC:
4.4.3
System Type:
SunOS 5.10 Generic_139555-08 sun4u sparc SUNW,SPARC-Enterprise
Source Code:
// foo.C //
#include
// main.C /
#include
int main()
{
std::cerr << "Hello, World!" << std::endl;
return 0;
}
Build Options:
g++ -v -save-temps -G -o libfoo.so foo.C
g++ -v -save-temps main.C -o main -lfoo -L${PWD}
Compiler Output:
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.3/configure --prefix=/usr/local/gcc-4.4.3
--disable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-__cxa_atexit --with-gnu-as --with-as=/usr/local/binutils-2.20.1/bin/as
--with-gnu-ld --with-ld=/usr/local/binutils-2.20.1/bin/ld
Thread model: posix
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-G' '-o' 'libfoo.so' '-mcpu=v9'
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/cc1plus
-E -quiet -v -iprefix
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/
-D__sparcv8 foo.C -mcpu=v9 -fpch-preprocess -o foo.ii
ignoring nonexistent directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/include"
ignoring duplicate directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3"
ignoring duplicate directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3/sparc-sun-solaris2.10"
ignoring duplicate directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3/backward"
ignoring duplicate directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/include"
ignoring duplicate directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/include-fixed"
ignoring nonexistent directory
"/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../sparc-sun-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3/sparc-sun-solaris2.10
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../../include/c++/4.4.3/backward
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/include
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/include-fixed
/usr/local/include
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/../../include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-G' '-o' 'libfoo.so' '-mcpu=v9'
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v9 -auxbase foo -version -o
foo.s
GNU C++ (GCC) version 4.4.3 (sparc-sun-solaris2.10)
compiled by GNU C version 4.4.3, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5ef610e48486b83fe31fd3ba609e79bb
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-G' '-o' 'libfoo.so' '-mcpu=v9'
/usr/local/binutils-2.20.1/bin/as -v --traditional-format -V -Qy -s
-xarch=v8plus -o foo.o foo.s
GNU assembler version 2.20.1 (sparc-sun-solaris2.10) using BFD version (GNU
Binutils) 2.20.1.20100303
COMPILER_PATH=/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/:/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../libexec/gcc/:/usr/ccs/bin/
LIBRARY_PATH=/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/:/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/:/usr/ccs/lib/:/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-G' '-o' 'libfoo.so' '-mcpu=v9'
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../libexec/gcc/sparc-sun-solaris2.10/4.4.3/collect2
-V -G -Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -o libfoo.so
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/crt1.o
/net/tcnsrva/export/usr/local/SunOS/5.10/sun4/gcc-4.4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.4.3/crti.o
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-12 17:30 --- the failure is while building the 64bit libgfortran, is sahf valid in 64-bit mode? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-12 17:25 --- running the failing command with -save-temps shows that sahf isused here: .LM312: fprem fnstsw %ax sahf jp .L103 fstp%st(1) fstpl -56(%rbp) movsd -56(%rbp), %xmm1 ucomisd %xmm1, %xmm1 jp .L109 jne .L109 adding -v confirms that /usr/sfw/bin/gas is being used as the assembler, not some other as -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #5 from ubizjak at gmail dot com 2010-04-12 17:24 --- Looks to me that this is libgfortran messing with choosen assembler. The bootstrap would die way before libgfortran is touched otherwise. I'm changing component to libgfortran in the hope that fortraners will confirm (and eventually fix ;) this PR. -- ubizjak at gmail dot com changed: What|Removed |Added Component|bootstrap |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #15 from ramana at gcc dot gnu dot org 2010-04-12 17:21 --- (In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . Sigh, that should read 149170. > I don't think this is it. r149263 is bad and r149105 is ok. > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00659.html > http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00989.html Will try and debug some more given what Richi said earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-12 17:15 --- configure:22928: checking assembler for sahf mnemonic configure:22937: /usr/sfw/bin/gas -o conftest.o conftest.s >&5 configure:22940: $? = 0 configure:22951: result: yes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-12 17:15 --- (In reply to comment #1) > I'm currently trying another bootstrap without --with-arch=core2 That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and arch=core2 that files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #2 from ubizjak at gmail dot com 2010-04-12 17:11 ---
configure should detect if assembler supports sahf mnemonic.
In your build directory, check gcc/config.log for:
configure:23019: checking assembler for sahf mnemonic
configure:23028: /usr/local/x86_64-unknown-linux-gnu/bin/as-o conftest.o
conftest.s >&5
configure:23031: $? = 0
configure:23042: result: yes
Based on this result, gcc outputs:
(define_insn "x86_sahf_1"
[(set (reg:CC FLAGS_REG)
(unspec:CC [(match_operand:HI 0 "register_operand" "a")]
UNSPEC_SAHF))]
"TARGET_SAHF"
{
#ifdef HAVE_AS_IX86_SAHF
return "sahf";
#else
return ASM_BYTE "0x9e";
#endif
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug target/43729] MachO LTO support needed for darwin
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-12 17:11 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 also contains a short list of some of the required code changes for MachO LTO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 --- (In reply to comment #35) > So if I understand correctly, the "state of things" at the moment is this: > > Without LTO: > > Time: 419.938 sec (6 m 59 s) > > with LTO incl linker flags: > > Time: 443.047 sec (7 m 23 s) > > In other words, "with LTO" is ~6% slower than without. > > You say that "results aren't exactly as expected" but I think there is really > not much you can expect. > > First of all, as it is, in GCC 4.5 LTO/WHOPR does not do a whole lot at all. > It > is really only inlining across translation unit boundaries. > > Second, LTO doesn't miraculously increase the number of optimization > opportunities, and very often it makes things worse on register-starved > architectures like i686 (see > http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf for folklore vs. fact > in > re. interprocedural optimization). > > Third, for C/C++ programs the source code is usually already organized in such > a way to avoid requiring a whole-program view of the program for the compiler > to optimize well. Think .h header files, static inline functions, by-value > call > conventions, etc. And although I don't know clamav very well, I suspect it's > completely I/O bound so optimizing away memory latencies etc. (which is really > what LTO is mostly about) wouldn't help for clamav anyway. > > That doesn't mean that optimizing LTO should slow down your program. It would > be interesting to see if it's somehow possible to identify the part of the > program that got slower. > 6% slower for a new work in progress feature is ok for me, while 60% not :) clamav has a lot of io but also a lot of cpu so it can used for such tests but definitively this patch is usable and could provide more feedbacks to lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-12 16:51 --- P.S. I'm using in-tree gmp 4.4.3 and mpfr 2.4.2 I'm currently trying another bootstrap without --with-arch=core2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug bootstrap/43733] New: bootstrap fails building libgfortran on Solaris x86 with GNU as
../gcc-4.4.3/configure --prefix=/opt/gcc-4.4.3-64/gcc-4.4.3 --enable-languages=c,fortran --with-system-zlib --with-arch=core2 --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld Bootstrap fails with gmake[5]: Entering directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/amd64/libgfortran' gmake all-am gmake[6]: Entering directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/amd64/libgfortran' /bin/bash ./libtool --tag=CC --mode=link /var/tmp/gcc/tmp/./gcc/xgcc -B/var/tmp/gcc/tmp/./gcc/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/bin/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/lib/ -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/include -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/sys-include -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2-m64 -m64 -o libgfortranbegin.la -rpath /opt/gcc-4.4.3-64/gcc-4.4.3/lib/gcc/i386-pc-solaris2.10/4.4.3/amd64 -static fmain.lo libtool: link: ar cr .libs/libgfortranbegin.a fmain.o libtool: link: ranlib .libs/libgfortranbegin.a libtool: link: ( cd ".libs" && rm -f "libgfortranbegin.la" && ln -s "../libgfortranbegin.la" "libgfortranbegin.la" ) if /bin/bash ./libtool --tag=CC --mode=compile /var/tmp/gcc/tmp/./gcc/xgcc -B/var/tmp/gcc/tmp/./gcc/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/bin/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/lib/ -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/include -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.4.3/libgfortran -I. -iquote../../../../gcc-4.4.3/libgfortran/io -I../../../../gcc-4.4.3/libgfortran/../gcc -I../../../../gcc-4.4.3/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -m64 -MT date_and_time.lo -MD -MP -MF ".deps/date_and_time.Tpo" -c -o date_and_time.lo `test -f 'intrinsics/date_and_time.c' || echo '../../../../gcc-4.4.3/libgfortran/'`intrinsics/date_and_time.c; \ then mv -f ".deps/date_and_time.Tpo" ".deps/date_and_time.Plo"; else rm -f ".deps/date_and_time.Tpo"; exit 1; fi libtool: compile: /var/tmp/gcc/tmp/./gcc/xgcc -B/var/tmp/gcc/tmp/./gcc/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/bin/ -B/opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/lib/ -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/include -isystem /opt/gcc-4.4.3-64/gcc-4.4.3/i386-pc-solaris2.10/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.4.3/libgfortran -I. -iquote../../../../gcc-4.4.3/libgfortran/io -I../../../../gcc-4.4.3/libgfortran/../gcc -I../../../../gcc-4.4.3/libgfortran/../gcc/config -I../../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -g -O2 -m64 -MT date_and_time.lo -MD -MP -MF .deps/date_and_time.Tpo -c ../../../../gcc-4.4.3/libgfortran/intrinsics/date_and_time.c -fPIC -DPIC -o .libs/date_and_time.o /var/tmp//cc6vGz5w.s: Assembler messages: /var/tmp//cc6vGz5w.s:1451: Error: suffix or operands invalid for `sahf' gmake[6]: *** [date_and_time.lo] Error 1 gmake[6]: Leaving directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/amd64/libgfortran' gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/amd64/libgfortran' gmake[4]: *** [multi-do] Error 1 gmake[4]: Leaving directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/libgfortran' gmake[3]: *** [all-multi] Error 2 gmake[3]: Leaving directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/libgfortran' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10/libgfortran' gmake[1]: *** [all-target-libgfortran] Error 2 gmake[1]: Leaving directory `/var/tmp/gcc/tmp' gmake: *** [all] Error 2 The same configuration works fine with "--enable-languages=c" or without "--with-as=/usr/sfw/bin/gas --with-gnu-as" It only fails if building fortran and using GNU as CONFIG_SHELL=/usr/bin/bash GNU bash, version 3.00.16(1)-release (i386-pc-solaris2.10) Copyright (C) 2004 Free Software Foundation, Inc. $ /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490 $ /usr/ccs/bin/as -V as: SunOS 5.10 119961-05 Patch 03/16/2009 $ /usr/sfw/bin/gas --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i386-pc-solaris2.10'. $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-pc-solaris2.10 N.B. I have /usr/xpg4/bin first in
[Bug c/43732] New: -ffixed-reg and register globals broken for MIPS
With gcc 4.4.3 and 4.3.4 and MIPS target, code is incorrectly generated to
save/restore registers specified as "fixed" via the "-ffixed-reg" command-line
option to gcc. This also applies to register globals (which should be treated
as "fixed".)
Test code (test.c):
register int foo asm ("$23");
void test(void)
{
foo = 0;
}
Compiler invocation:
mips-unknown-linux-gnu-gcc -ffixed-s7 -O2 -c test.c
Disassembly of above code build with gcc 4.2.2 (correct):
4.2.2/test.o: file format elf32-tradbigmips
Disassembly of section .text:
:
0: 03e8jr ra
4: b821moves7,zero
...
Disassembly with gcc 4.4.3 (incorrectly saves/restores s7, optimizes away
assignment to register global):
4.4.3/test.o: file format elf32-tradbigmips
Disassembly of section .text:
:
0: 27bdfff8addiu sp,sp,-8
4: afb70004sw s7,4(sp)
8: 8fb70004lw s7,4(sp)
c: 03e8jr ra
10: 27bd0008addiu sp,sp,8
...
Patch that appears to fix this issue:
diff -Naur gcc-4.4.3.base/gcc/config/mips/mips.c
gcc-4.4.3/gcc/config/mips/mips.c
--- gcc-4.4.3.base/gcc/config/mips/mips.c 2010-04-09 14:10:00.235609702
-0400
+++ gcc-4.4.3/gcc/config/mips/mips.c2010-04-09 14:12:28.520998582 -0400
@@ -8495,7 +8495,7 @@
property here. */
return (regno == GLOBAL_POINTER_REGNUM
? TARGET_CALL_SAVED_GP
- : !call_really_used_regs[regno]);
+ : !call_really_used_regs[regno] && !fixed_regs[regno]);
}
/* Return true if the function body might clobber register REGNO.
Disassembled output with above patch applied:
4.4.3fix/test.o: file format elf32-tradbigmips
Disassembly of section .text:
:
0: 03e8jr ra
4: b821moves7,zero
...
--
Summary: -ffixed-reg and register globals broken for MIPS
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lance604 at gmail dot com
GCC build triplet: x86_64-build_pc-linux-gnu
GCC host triplet: x86_64-build_pc-linux-gnu
GCC target triplet: mips-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43732
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-12 16:38 --- Confirmed with mac os x gcc build. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-12 16:38:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug c/43728] Warning for redundant static function prototypes
--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-12 16:29 --- -Wredundant-decls is a non-default warning already, not enabled with -Wall nor -W and I certainly don't want to enable it by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
[Bug ada/43731] New: Missing ada multilib on i686-w64-mingw32 target
When compiling a Win64 i686-w64-mingw32 compiler with multilib, ada fails to build with similar errors as reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993 There is currently no selection on the i686 side for multilib, as the gcc/gcc-interface/ada Makefile assumes that no ix86 mingw* targets may be compiled multilib. This can be fixed with something similar to the following trivial patch: diff a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -1649,8 +1649,13 @@ ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),) LIBGNAT_TARGET_PAIRS += \ system.adshttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43731
[Bug c/43728] Warning for redundant static function prototypes
--- Comment #4 from jason at gcc dot gnu dot org 2010-04-12 16:16 --- ...and then after removing the prototype, compiling with -DD would fail. I don't object to having such a flag, but I don't think we want it in -Wall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
[Bug target/43729] MachO LTO support needed for darwin
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-12 16:15 --- For the Mach-O file format, follow this link: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html First step for Mach-O support would be figuring out where to store the LTO data. AFAIU, Mach-O has segments, which are bundles of sections. I don't know if GCC LTO should write a segment, or a section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug c/43730] New: internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
Compilation of this test file with versions of gcc-4.5 dated 20090528 to
20100107 produce a fatal internal compiler error; comparable versions of
gcc-4.3 and gcc-4.4 do not have this problem:
% cat bug003.c
extern int (isinfl)(long double);
int
bugfun(long double x, long double y)
{
int result;
if (isinfl(x))
result = isinfl(y);
else
{
int kx, ky;
kx = ky = 1;
result = (kx == ky);
}
return (result);
}
% gcc-4.5-20100107 -g -c bug003.c
bug003.c: In function 'bugfun':
bug003.c:9:9: internal compiler error: in expand_builtin_interclass_mathfn, at
builtins.c:2313
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
A test with gcc-4.5-20090528 on IA-32 (triplets i686-pc-linux-gnu)
produces a similar report:
% gcc-4.5-20090528 -g -c bug003.c
bug003.c: In function 'bugfun':
bug003.c:9: internal compiler error: in expand_builtin_interclass_mathfn, at
builtins.c:2297
--
Summary: internal compiler error: in
expand_builtin_interclass_mathfn, at builtins.c:2313
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: beebe at math dot utah dot edu
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=43730
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #38 from ro at gcc dot gnu dot org 2010-04-12 16:10 --- Could be interesting for Tru64 UNIX, which uses ECOFF, too. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-12 16:02 --- Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . I don't think this is it. r149263 is bad and r149105 is ok. http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00659.html http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg00989.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43729] MachO LTO support needed for darwin
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-12 15:59 --- >From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 : > Can we use a similar approach for Mach-O [as for PE-COFF]? I don't speak Mach-O, but yes, the approach should work. You'd start by saying lto_binary_reader=lto-mach-o in config.gcc and adding a new lto/lto-mach-o.c with the same handful of toplevel functions: open and close file, build section hash, and create section and append binary data to section. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-12 15:59 --- (In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator . > > 2009-07-02 Richard Guenther > > * tree-ssa-live.c (remove_unused_locals): Do not remove > heap variables. > * tree-ssa-structalias.c (handle_lhs_call): Delay setting > of DECL_EXTERNAL for HEAP variables. > (compute_points_to_sets): Set DECL_EXTERNAL for escaped > HEAP variables. Do not adjust RESTRICT vars. > (find_what_var_points_to): Nobody cares if something > points to READONLY. > > My tools were configured as > > /home/ramrad01/cross-build/src/gcc-trunk/configure > --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran > --with-cpu=cortex-a8 --with-fpu=vfp3 --with-float=softfp > > > In the middle of debugging further now to get to a reduced testcase given that > the failure is a miscompile somewhere deep inside libgfortran. The change shouldn't cause excessive changes, so if you compare object files with and without that revision you should get at most a single file I would guess. If the change reproduces with a cross compiler (please provide configuration and compiler command-line details) I can have a look. Note that there were later fixes to that patch I believe (like the fix for PR40617). Unless you are sure you are running exactly into the same problem bisection may lead you to false intermediate broken libgfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #37 from steven at gcc dot gnu dot org 2010-04-12 15:58 --- LTO for Mach-O is now being tracked in bug 43729. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||43729 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug target/43729] MachO LTO support needed for darwin
-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|*-apple-darwin* | GCC host triplet|*-apple-darwin* | Last reconfirmed|-00-00 00:00:00 |2010-04-12 15:55:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug target/43729] New: MachO LTO support needed for darwin
This bug report is a placeholder for discussing the changes required for LTO via collect2 on darwin. It exists to have a distinct discussion about darwin since we don't use either ELF or binutils. It would be optimal if the required changes would not involve modifications to the darwin linker since, even if those were obtained from Apple in some future Xcode, it is unlikely that they would ever be backported to the earlier OS releases. -- Summary: MachO LTO support needed for darwin Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers
--- Comment #12 from ramana at gcc dot gnu dot org 2010-04-12 15:50 --- A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . 2009-07-02 Richard Guenther * tree-ssa-live.c (remove_unused_locals): Do not remove heap variables. * tree-ssa-structalias.c (handle_lhs_call): Delay setting of DECL_EXTERNAL for HEAP variables. (compute_points_to_sets): Set DECL_EXTERNAL for escaped HEAP variables. Do not adjust RESTRICT vars. (find_what_var_points_to): Nobody cares if something points to READONLY. My tools were configured as /home/ramrad01/cross-build/src/gcc-trunk/configure --target=arm-none-linux-gnueabi --enable-languages=c,c++,fortran --with-cpu=cortex-a8 --with-fpu=vfp3 --with-float=softfp In the middle of debugging further now to get to a reduced testcase given that the failure is a miscompile somewhere deep inside libgfortran. -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43572
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #4 from froydnj at gcc dot gnu dot org 2010-04-12 15:41 --- FWIW, I cannot reproduce with 'gcc version 4.5.0 20100205'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug c/43728] Warning for redundant static function prototypes
--- Comment #3 from manu at gcc dot gnu dot org 2010-04-12 15:38 --- If you are going to add such a warning, please be more explicit. I suggest: "redundant prototype for static function %qD because it is never used before its definition" -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728
