[Bug target/43417] SH: 4.4 ICE in final_scan_insn, at final.c:2604
--- Comment #3 from iwamatsu at nigauri dot org 2010-03-19 06:11 --- (In reply to comment #2) Looks the same issue in http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00747.html though I can't reproduce the problem with my gcc-4.4.3 and 4.4 head compilers for the test case in #1. Could you try the patch in the above URL? I tested this patch. The problem was revised. gcc-4.4.3 of debian(20,100,226 SVN / r157081 base) revision was not taken in. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43417
[Bug c/43438] New: possible wrong code bug
The -O0 result looks right. This behavior observed on x86 using r157445 and
x64 using r157542.
reg...@john-home:~$ current-gcc -O0 small.c -o small -Wall
reg...@john-home:~$ ./small
1
reg...@john-home:~$ current-gcc -O1 small.c -o small -Wall
reg...@john-home:~$ ./small
0
reg...@john-home:~$ cat small.c
extern int printf (__const char *__restrict __format, ...);
static unsigned char g_2 = 1;
static int g_9;
static int *l_8 = g_9;
static void func_12(int p_13)
{
int * l_17 = g_9;
*l_17 = 0 p_13;
}
int main(void)
{
unsigned char l_11 = 254;
*l_8 |= g_2;
l_11 |= *l_8;
func_12(l_11);
printf(%d\n, g_9);
return 0;
}
reg...@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r157445-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r157445-install
--program-prefix=r157445- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100314 (experimental) (GCC)
--
Summary: possible wrong code bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug c/43438] possible wrong code bug
--- Comment #1 from sezeroz at gmail dot com 2010-03-19 06:51 --- Happened on x86_64-pc-linux and my gcc-4.4 was affected too, gcc-3.4.6 seemed fine. -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug ada/43106] gnat optimization error in a case statement
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:19 --- Subject: Bug 43106 Author: ebotcazou Date: Fri Mar 19 07:18:47 2010 New Revision: 157558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157558 Log: PR ada/43106 * gnat.dg/case_optimization2.adb: New test. * gnat.dg/case_optimization_pkg2.ad[sb]: New helper. Added: trunk/gcc/testsuite/gnat.dg/case_optimization2.adb trunk/gcc/testsuite/gnat.dg/case_optimization_pkg2.adb trunk/gcc/testsuite/gnat.dg/case_optimization_pkg2.ads Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43106
[Bug ada/43106] optimization error in a case statement
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-19 07:22 --- Presumably by the overhaul of the subtypes support. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|gnat optimization error in a|optimization error in a case |case statement |statement Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43106
[Bug tree-optimization/36439] [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
--- Comment #13 from kurt at garloff dot de 2010-03-19 08:03 --- Well for 4.5, make sure you configured with --enable-checking=release; otherwise it is not a fair comparison. Did not change anything unfortunately :-( (I have enabled --enable-lto in case this matters, though I have not used any compile time flag to make use of it ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug c/43438] possible wrong code bug
--- Comment #2 from mikpe at it dot uu dot se 2010-03-19 09:46 --- 4.2.4/4.3.4/4.4.3 are affected, 4.1.2 and older seem to be Ok. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug debug/43439] New: Dwarf:Wrong location information of function argument
I think gcc produce wrong location information of function argument.
/* sample source sub.c **/
int test(int first, int second)
{
return second;
}
//
The sample source is compiled as follows.
==
tan...@r48:/usr/local/te/bappl/test/$
/usr/local/te/tool/Linux-i686/bin/arm-unknown-elf-gcc -v -Wa,-v -g -c sub.c
Using built-in specs.
Target: arm-unknown-elf
Configured with:
/usr/local/te/tool/build/gnu/gcc-4.4.3-tkernel/gcc-4.4.3/configure
--prefix=/usr/local/te/tool/Linux-i686 --target=arm-unknown-elf --with-gnu-as
--with-gnu-ld --with-gmp-include=/usr/local/te/tool/Linux-i686/include-libs
--with-gmp-lib=/usr/local/te/tool/Linux-i686/lib
--with-mpfr-include=/usr/local/te/tool/Linux-i686/include-libs
--with-mpfr-lib=/usr/local/te/tool/Linux-i686/lib --enable-threads
--enable-languages=c,c++ --enable-version-specific-runtime-libs
--disable-libstdcxx-pch --disable-hosted-libstdcxx --disable-libada
Thread model: single
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-g' '-c'
/usr/local/te/tool/Linux-i686/libexec/gcc/arm-unknown-elf/4.4.3/cc1 -quiet -v
-D__USES_INITFINI__ sub.c -quiet -dumpbase sub.c -auxbase sub -g -version -o
/tmp/ccqF2DxV.s
ignoring nonexistent directory
/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/../../../../arm-unknown-elf/include
#include ... search starts here:
#include ... search starts here:
/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/include
/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/include-fixed
/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/../../../../arm-unknown-elf/sys-include
End of search list.
GNU C (GCC) version 4.4.3 (arm-unknown-elf)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu4), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64255
Compiler executable checksum: 20ebd17b34fa094008992b6e0117d9b5
COLLECT_GCC_OPTIONS='-v' '-g' '-c'
/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/../../../../arm-unknown-elf/bin/as
-v -v -o sub.o /tmp/ccqF2DxV.s
GNU assembler version 2.20.1 (arm-unknown-elf) using BFD version (GNU Binutils)
2.20.1.20100303
COMPILER_PATH=/usr/local/te/tool/Linux-i686/libexec/gcc/arm-unknown-elf/4.4.3/:/usr/local/te/tool/Linux-i686/libexec/gcc/arm-unknown-elf/4.4.3/:/usr/local/te/tool/Linux-i686/libexec/gcc/arm-unknown-elf/:/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/:/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/:/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/../../../../arm-unknown-elf/bin/
LIBRARY_PATH=/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/:/usr/local/te/tool/Linux-i686/lib/gcc/arm-unknown-elf/4.4.3/../../../../arm-unknown-elf/lib/
COLLECT_GCC_OPTIONS='-v' '-g' '-c'
tan...@r48:/usr/local/te/bappl/test/$
==
The complied object file is disassembled as follows.
==
/usr/local/te/tool/Linux-i686/bin/arm-unknown-elf-objdump -S sub.o
sub.o: file format elf32-littlearm
Disassembly of section .text:
test:
int test(int first, int second)
{
0: e52db004push{fp}; (str fp, [sp, #-4]!)
4: e28db000add fp, sp, #0
8: e24dd008sub sp, sp, #8
c: e50b0004str r0, [fp, #-4]
10: e50b1008str r1, [fp, #-8]
return second;
14: e51b3008ldr r3, [fp, #-8]
}
18: e1a3mov r0, r3
1c: e28bd000add sp, fp, #0
20: e8bd0800pop {fp}
24: e12fff1ebx lr
==
Next is .debug_info.
DW_AT_location of argument second is (DW_OP_fbreg: -12).
I think DW_OP_fbreg must be -8.
Gdb shows wrong value for the argument.
Is there a patch for this problem.
==
/usr/local/te/tool/Linux-i686/bin/arm-unknown-elf-readelf --debug-dump=info
sub.o
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length:0x63 (32-bit)
Version: 2
Abbrev Offset: 0
Pointer Size: 4
0b: Abbrev Number: 1 (DW_TAG_compile_unit)
c DW_AT_producer: (indirect string, offset: 0x26): GNU C 4.4.3
10 DW_AT_language: 1(ANSI C)
11 DW_AT_name: (indirect string, offset: 0x37): sub.c
15 DW_AT_comp_dir: (indirect string, offset: 0xd):
/usr/local/te/bappl/test
19 DW_AT_low_pc : 0x0
1d DW_AT_high_pc : 0x28
21 DW_AT_stmt_list : 0x0
125: Abbrev Number: 2 (DW_TAG_subprogram)
26 DW_AT_external: 1
27 DW_AT_name: (indirect string, offset: 0x32): test
2b DW_AT_decl_file : 1
2c DW_AT_decl_line : 1
2d DW_AT_prototyped : 1
[Bug middle-end/43251] [4.4 Regression] Erroneous code with -ftree-vectorize
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-03-19 09:56 --- (In reply to comment #13) Hi! I was wondering if this bug is likely to be fixed in the next GCC release; is this likely to be the case? Unlikely. Backporting the one-line change will cause massive performance problems elsewhere (with scalar times complex multiplication). There is more to be backported. The question is if the Fortran standard allows C*CX(IX) to be unconditionally implemented as C * __real CX(IX) + _I * C * __imag CX(IX) or not. It would be also interesting to know what vectorization makes for a difference here, as it shouldn't change semantics. Thus, did anyone analyze why only the vectorized variant exhibits the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43251
[Bug tree-optimization/36439] [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
--- Comment #14 from rguenther at suse dot de 2010-03-19 10:09 --- Subject: Re: [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry On Fri, 19 Mar 2010, kurt at garloff dot de wrote: --- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 --- (In reply to comment #10) GCC 4.3.4 is being released, adjusting target milestone. Very non-scientific benchmark: Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make -j8 and compile flags: -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops -ftree-vectorize Times (in seconds, user, elapsed): 4.3.5: 1263u, 377e w/ -fno-tree-pre: 755u, 202e 4.4.4: 1022u, 311e w/ -fno-tree-pre: 996u, 284e 4.5.0: 2325u, 615e w/ -fno-tree-pre: 1974u, 543e Note that this is in contrast to earlier observations that 4.4/4.5 did do much better than 4.3. Don't know whether that's caused by changed gmic code or whether we have regressed in 4.5. Let me know if you want me to pick one file that takes particularly long to compile and investigate further. This bug was about PRE causing compile-time issues at -O2 which is what was investigated and fixed for the testcases attached to this PR. I see, for -O2 and the CImg.C testcase (just using openSUSE packages from devel:gcc): 4.3.4 (r152973): stopped after 4min 4.4.2 (r155966): 68s 4.5.0 (r157384): 74s also see PR43415 for a similar problem where I am about to commit a patch. If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] being slow it would be appropriate to open a new bugreport for it. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code
--- Comment #18 from jamborm at gcc dot gnu dot org 2010-03-19 10:14 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
[Bug tree-optimization/36439] [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-03-19 10:15 --- (In reply to comment #14) Subject: Re: [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry On Fri, 19 Mar 2010, kurt at garloff dot de wrote: --- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 --- (In reply to comment #10) GCC 4.3.4 is being released, adjusting target milestone. Very non-scientific benchmark: Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make -j8 and compile flags: -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops -ftree-vectorize Times (in seconds, user, elapsed): 4.3.5: 1263u, 377e w/ -fno-tree-pre: 755u, 202e 4.4.4: 1022u, 311e w/ -fno-tree-pre: 996u, 284e 4.5.0: 2325u, 615e w/ -fno-tree-pre: 1974u, 543e Note that this is in contrast to earlier observations that 4.4/4.5 did do much better than 4.3. Don't know whether that's caused by changed gmic code or whether we have regressed in 4.5. Let me know if you want me to pick one file that takes particularly long to compile and investigate further. This bug was about PRE causing compile-time issues at -O2 which is what was investigated and fixed for the testcases attached to this PR. I see, for -O2 and the CImg.C testcase (just using openSUSE packages from devel:gcc): 4.3.4 (r152973): stopped after 4min 4.4.2 (r155966): 68s 4.5.0 (r157384): 74s also see PR43415 for a similar problem where I am about to commit a patch. If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] being slow it would be appropriate to open a new bugreport for it. Oh, and btw check if you build with debuginfo enabled. With GCC 4.5 we can spend quite some extra time producing good debug information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
[Bug tree-optimization/43415] [4.4/4.5 Regression] Consumes large amounts of memory and time in PRE at -O3
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 --- Subject: Bug 43415 Author: rguenth Date: Fri Mar 19 10:18:25 2010 New Revision: 157562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157562 Log: 2010-03-19 Richard Guenther rguent...@suse.de PR tree-optimization/43415 * tree-ssa-pre.c (phi_translate): Split out worker to ... (phi_translate_1): ... this. (phi_translate): Move all caching here. Cache all NARY and REFERENCE translations. * gcc.c-torture/compile/pr43415.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43415.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
[Bug tree-optimization/43415] [4.4 Regression] Consumes large amounts of memory and time in PRE at -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 10:18 --- Fixed for 4.5 sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.3 4.5.0 |4.4.3 Known to work|4.4.2 |4.4.2 4.5.0 Summary|[4.4/4.5 Regression]|[4.4 Regression] Consumes |Consumes large amounts of |large amounts of memory and |memory and time in PRE at - |time in PRE at -O3 |O3 | Target Milestone|4.5.0 |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43415
[Bug ada/42554] Can't build GNAT tools
--- Comment #13 from mrs at gcc dot gnu dot org 2010-03-19 10:20 --- Subject: Bug 42554 Author: mrs Date: Fri Mar 19 10:19:52 2010 New Revision: 157563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157563 Log: PR ada/42554 * configure.ac: Only pass -c to ranlib for darwin9 and earlier. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554
[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations
--- Comment #47 from rguenth at gcc dot gnu dot org 2010-03-19 10:26 --- (In reply to comment #46) The answer to the question (b) in comment #35: (b) why !optimize_size has been replaced with optimize_insn_for_speed_p ()? seems to be this patch replace some of optimize_size tests by optimize_insn_for_speed_p predicate so we can make decisions on per-BB granuality. from http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00121.html (revision 138565 by hubicka, Sun Aug 3 12:04:49 2008 UTC). Why is there any need to expand pow(x,n) on per-BB granularity? is not !optimize_size enough for this case? optimize_insn_for_speed_p is more precise in that it allows hot functions to be optimized for speed even with -Os. This is quite important for embedded targets where you generally want to optimize for size but want performance sensitive parts to be optimized for speed. I think there are two good solutions to this PR. 1) re-work how the profile is computed for deep loop nests 2) improve the code-size estimate of these expanders (a simple convincing heuristic is that if the target has an optab for sqrt then x * sqrt (x) is not going to be larger than pow(x, 1.5)). 2) would fix the air case but not really the underlying problem which is 1). 2) would be easy to implement and appropriate for 4.5 - I can't see how to address 1) with a reasonably sized patch. Note that this PR isn't too serious as -fwhole-file isn't the default for Fortran so we do not run into this unfortunate interaction of profile estimation and inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations
--- Comment #48 from rguenth at gcc dot gnu dot org 2010-03-19 10:35
---
Untested patch doing 2):
Index: builtins.c
===
--- builtins.c (revision 157561)
+++ builtins.c (working copy)
@@ -2980,10 +2980,16 @@ expand_builtin_pow (tree exp, rtx target
((flag_unsafe_math_optimizations
optimize_insn_for_speed_p ()
powi_cost (n/2) = POWI_MAX_MULTS)
- /* Even the c==0.5 case cannot be done unconditionally
+ /* Even the c == 0.5 case cannot be done unconditionally
when we need to preserve signed zeros, as
pow (-0, 0.5) is +0, while sqrt(-0) is -0. */
- || (!HONOR_SIGNED_ZEROS (mode) n == 1)))
+ || (!HONOR_SIGNED_ZEROS (mode) n == 1)
+ /* For c == 1.5 we can assume that x * sqrt (x) is always
+smaller than pow (x, 1.5) if sqrt will not be expanded
+as a call. */
+ || (n == 2
+ (optab_handler (sqrt_optab, mode)-insn_code
+ != CODE_FOR_nothing
{
tree call_expr = build_call_nofold (fn, 1, narg0);
/* Use expand_expr in case the newly built call expression
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug c/43438] [4.3/4.4/4.5 Regression] possible wrong code bug
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-19 11:02 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu |i?86-*-* x86_64-*-* Keywords||wrong-code Known to fail||4.3.4 4.4.3 4.5.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2010-03-19 11:02:13 date|| Summary|possible wrong code bug |[4.3/4.4/4.5 Regression] ||possible wrong code bug Target Milestone|--- |4.3.5 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug rtl-optimization/43438] [4.3/4.4/4.5 Regression] possible wrong code bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 11:29 --- Combine breaks this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug rtl-optimization/43438] [4.3/4.4/4.5 Regression] possible wrong code bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-19 11:35 ---
It combines
(insn 6 5 7 2 t.c:16 (parallel [
(set (reg:SI 59 [ D.2732 ])
(ior:SI (reg:SI 67 [ g_9 ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 394 {*iorsi_1} (expr_list:REG_DEAD (reg:SI 67 [ g_9 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ior:SI (mem/c/i:SI (symbol_ref:DI (g_9)
[flags 0x2] var_decl 0x75ae50a0 g_9) [0 g_9+0 S4 A32])
(const_int 1 [0x1]))
(nil)
(insn 7 6 8 2 t.c:10 (parallel [
(set (reg:QI 68)
(ior:QI (subreg:QI (reg:SI 59 [ D.2732 ]) 0)
(const_int -2 [0xfffe])))
(clobber (reg:CC 17 flags))
]) 398 {*iorqi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 8 7 9 2 t.c:10 (parallel [
(set (reg:SI 69)
(zero_extend:SI (reg:QI 68)))
(clobber (reg:CC 17 flags))
]) 119 {*zero_extendqisi2_movzbl_and} (expr_list:REG_DEAD (reg:QI 68)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
and somewhere forgets to apply the zero-extension:
Successfully matched this instruction:
(set (reg:SI 59 [ D.2732 ])
(ior:SI (reg:SI 67 [ g_9 ])
(const_int 1 [0x1])))
Successfully matched this instruction:
(set (reg:SI 69)
(const_int -1 [0x]))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug target/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #4 from ramana at gcc dot gnu dot org 2010-03-19 12:04 --- Yes - haven't thought about it much, maybe the backend could give an error if a frame were allocated for a naked function rather than ICE'ing in an awkward place. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||error-recovery, ice-on- ||invalid-code Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-03-19 12:04:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug rtl-optimization/43438] [4.3/4.4/4.5 Regression] possible wrong code bug
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-19 12:06 --- Breakpoint 7, combine_simplify_rtx (x=0x75ae6e58, op0_mode=VOIDmode, in_dest=0) at /space/rguenther/src/svn/trunk/gcc/combine.c:4861 4861 enum rtx_code code = GET_CODE (x); (set (reg:SI 69) (and:SI (subreg:SI (ior:QI (subreg:QI (ior:SI (reg:SI 67 [ g_9 ]) (const_int 1 [0x1])) 0) (const_int -2 [0xfffe])) 0) (const_int 255 [0xff]))) (gdb) finish Value returned is $19 = (struct rtx_def *) 0x75ae6e58 (gdb) call debug_rtx ($19) (set (reg:SI 69) (const_int -1 [0x])) but combine_simplify_rtx didn't simplify the subexpressions without the set. Hm. -- 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|2010-03-19 11:02:13 |2010-03-19 12:06:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 --- Subject: Bug 43305 Author: matz Date: Fri Mar 19 12:37:28 2010 New Revision: 157567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157567 Log: PR 43305 * builtins.c (expand_builtin_interclass_mathfn, expand_builtin_signbit): Use maybe_emit_unop_insn, emit libcalls if that fails. testsuite/ * gcc.dg/pr43305.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr43305.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug target/43305] [4.4/4.5 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug rtl-optimization/43438] [4.3/4.4/4.5 Regression] possible wrong code bug
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-03-19 12:40 --- make_extraction (mode=SImode, inner=0x75b48ac8, pos=0, pos_rtx=0x0, len=8, unsignedp=1, in_dest=0, in_compare=0) at /space/rguenther/src/svn/trunk/gcc/combine.c:6648 6648 enum machine_mode is_mode = GET_MODE (inner); (gdb) call debug_rtx (inner) (subreg:SI (ior:QI (subreg:QI (ior:SI (reg:SI 67 [ g_9 ]) (const_int 1 [0x1])) 0) (const_int -2 [0xfffe])) 0) if (CONST_INT_P (new_rtx)) return gen_int_mode (INTVAL (new_rtx), mode); misses the nececssary truncation. Dropping the special casing works (but doesn't optimize). Fixing the appearantly many issues works as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43438
[Bug tree-optimization/43436] Missed vectorization: unhandled data-ref
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43436
[Bug tree-optimization/43434] Missed vectorization: not vectorized: data ref analysis: pointer incremented by a parameter
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-19 12:53 --- (In reply to comment #2) Oh it might also need the patch for PR 29751 which I hope to submit for 4.6. Note the patch in there still works and has been tested as of earlier this week. New mem-ref will make that one unnecessary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434
[Bug target/43426] dlsym: invalid version 5 (max 0)
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 --- *** Bug 43429 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43426
[Bug c/43429] dlsym: invalid version 5 (max 0)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-19 13:07 --- *** This bug has been marked as a duplicate of 43426 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43429
[Bug target/43440] New: Overwriting neon quad register does not clobber all included single registers
Function:
float y;
float foo(float x)
{
y = x * x + x;
asm volatile (vmov.i8 q0, #0 ::: q0);
asm volatile (vmov.i8 q1, #0 ::: q1);
asm volatile (vmov.i8 q2, #0 ::: q2);
asm volatile (vmov.i8 q3, #0 ::: q3);
asm volatile (vmov.i8 q4, #0 ::: q4);
asm volatile (vmov.i8 q5, #0 ::: q5);
asm volatile (vmov.i8 q6, #0 ::: q6);
asm volatile (vmov.i8 q7, #0 ::: q7);
return y;
}
being compiled with -O -Wall -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
always returns 0.
The cause of incorrect behaviour is that in function foo y is allocated on s15
which is not considered clobbered by asm volatile (vmov.i8 q3, #0 :::
q3);. Mentioning in clobber lists s1 s2 and s3 alongside q0, s5 s6 and s7
alongside q1 and so on solves the problem: clobbered register got spilled.
Omitting any of them makes GCC allocate y on this register and do not spill it.
I also noticed that only d8, d10, d12 and d14 got saved at the beginning of the
function though all d8-d15 should be saved. This was mentioned in bug #42321
comment #1 also.
I tried this example on 4.4.3 and today's trunk.
--
Summary: Overwriting neon quad register does not clobber all
included single registers
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: batuzovk at ispras dot ru
GCC target triplet: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
[Bug c/43405] sinl is not computed correctly
--- Comment #8 from eli dot osherovich at gmail dot com 2010-03-19 13:27 --- (In reply to comment #6) Also: 1e22 is not exactly representable as a floating point number. By consequence, 1e22 is different numbers when stored as a double or a long double, and we should expect different results when applying the sine to it. W. This is *not* a problem of binary representation. I tried to use exactly the same argument (one time double, another time *promoted* to long double). The function is not implemented correctly, or, at least for some numbers in legal range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
[Bug target/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #5 from rearnsha at gcc dot gnu dot org 2010-03-19 13:27 --- I think the compiler should throw an error if there are any statements in the naked function other than asm statements. All such asms should be treated as volatile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug c/43405] sinl is not computed correctly
--- Comment #9 from eli dot osherovich at gmail dot com 2010-03-19 13:29 --- (In reply to comment #7) Subject: Re: sinl is not computed correctly On Thu, 18 Mar 2010, bangerth at gmail dot com wrote: Also: 1e22 is not exactly representable as a floating point number. By 5**22 is smaller than 2**53, so 1e22 (= 5**22 * 2**22) *is* exactly representable in double or formats with more bits than double. 1e22 is not representable exactly in the binary format. Not because of its magnitude, just because most numbers cannot be represented exactly in computers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #12 from danglin at gcc dot gnu dot org 2010-03-19 13:30 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug target/43440] Overwriting neon quad register does not clobber all included single registers
--- Comment #1 from ramana at gcc dot gnu dot org 2010-03-19 13:32 --- Yes, there is no easy way of describing the container relationship of the Neon registers to the compiler at the minute. Thus the only work around at the moment is to indicate that all the registers contained as part of this register name are clobbered in the explicit asm statement. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-03-19 13:32:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
[Bug testsuite/43441] New: pr42427.c:5:21: fatal error: complex.h: No such file or directory
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O2 -fexceptions -fnon-call-exceptions -fpeel-loops -c -o pr42427.o
/test/gnu/gc
c/gcc/gcc/testsuite/gcc.dg/pr42427.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c:5:21: fatal error: complex.h:
N
o such file or directory
compilation terminated.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c:5:21: fatal error: complex.h:
N
o such file or directory
compilation terminated.
FAIL: gcc.dg/pr42427.c (test for excess errors)
-bash-3.2$ less /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr42427.c
/* { dg-do assemble } */
/* { dg-options -O2 -fexceptions -fnon-call-exceptions -fpeel-loops } */
/* { dg-require-effective-target ilp32 } */
#include complex.h
--
Summary: pr42427.c:5:21: fatal error: complex.h: No such file or
directory
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: 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=43441
[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)
--- Comment #1 from nightstrike at gmail dot com 2010-03-19 14:25 --- This is probably due to the way you built GCC. To have a completely relocatable toolchain, you need to use the --with-sysroot option to configure, and you need to set it equal to prefix or below prefix in the directory structure. I don't think this is a bug with GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42886
[Bug target/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #6 from marti at juffo dot org 2010-03-19 14:46 --- (In reply to comment #5) I think the compiler should throw an error if there are any statements in the naked function other than asm statements. This would break a lot of code; there are use cases where you want to save/restore the stack frame yourself, but still use C code in the middle. And on ARM you can go a long way without needing to spill over to the stack. For example: * Nut/OS context switching code, http://www.ethernut.de/api/context_8c-source.html#l00156 * Interrupt handlers that use macros which also push r0-r3 and spsr, which otherwise not stored in GCC's stack frame: http://www.ethernut.de/api/ih__at91ssc_8c-source.html#l00068 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug target/42495] redundant memory load
--- Comment #3 from ramana at gcc dot gnu dot org 2010-03-19 15:12 --- Is this for Thumb1 or Thumb2 ? Can you check with trunk today ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug target/43216] Use high registers to reduce code size and improve performance when targeting thumb2
--- Comment #2 from ramana at gcc dot gnu dot org 2010-03-19 15:21 --- Confirmed with trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2010-03-19 15:21:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43216
[Bug c++/43116] [4.3/4.4/4.5 Regression] ICE when using attributes in a function alias declaration
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 23:25:51 |2010-03-19 15:33:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations
--- Comment #49 from dominiq at lps dot ens dot fr 2010-03-19 15:40 --- A few remarks about comments #47 and #48 Note that this PR isn't too serious as -fwhole-file isn't the default for Fortran so we do not run into this unfortunate interaction of profile estimation and inlining. The test in comment #31 shows that you don't need -fwhole-file nor inlining to trigger this PR. + || (n == 2 Isn't it n==3? I have done some tests of replacing 1.5 in the test in comment #31 with some other values (up to 15.5, but not in a systematic way). On x86_64-apple-darwin10, the multiplications are always a win for size (based on the size of a.out) over the call to pow. Is my metric flawed? If yes, what should I use? If no could embedded system experts have a look at this kind of optimization? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-19 15:46 --- Well, just fixed on the trunk. This fix looks simple enough that it should be backportable. -- jakub 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 4.3.0 Resolution|FIXED | Summary|[4.4/4.5 Regression] ICE: in|[4.4 Regression] ICE: in |emit_unop_insn, at |emit_unop_insn, at |optabs.c:3838 with -Os -|optabs.c:3838 with -Os - |ffast-math and ilogbl() |ffast-math and ilogbl() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #2 from aldyh at gcc dot gnu dot org 2010-03-19 15:48 --- Created an attachment (id=20141) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20141action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #3 from aldyh at gcc dot gnu dot org 2010-03-19 15:58 --- Reproduce with: ./cc1 -g -O a.i -mscore3 -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-19 15:58:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #13 from ramana at gcc dot gnu dot org 2010-03-19 15:58 --- Subject: Bug 43399 Author: ramana Date: Fri Mar 19 15:58:37 2010 New Revision: 157574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157574 Log: Fix PR target/43399 2010-03-19 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/43399 * config/arm/arm.c (emit_multi_reg_push): Update comments. Use PRE_MODIFY instead of PRE_DEC. (emit_sfm): Use PRE_MODIFY instead of PRE_DEC. (vfp_emit_fstmd): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug debug/43442] New: .debug_loc is unnecessarily large
While looking at PR43058, I've noticed that we generate tons of completely useless location list elements. E.g. on the pr43058.c testcase with X2 instead of X4 X4 and without the PR43058 patch applied, we generate extremely long location list for the first a variable and then each loclist is 2 entries shorter. Most of the ranges in the list don't overlap with any DW_AT_ranges in the containing DW_TAG_lexical_block though. -- Summary: .debug_loc is unnecessarily large Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43442
[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #10 from zsojka at seznam dot cz 2010-03-19 16:08 --- How does the test work, would it fail on non-patched trunk? - extern int printf(const char *format, ...); - printf(%d\n, foo(100)); + if (foo(100) != 6) + __builtin_abort (); I *think* this would do the job, but I really don't know (and I can't test it now). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug target/40722] [4.5 Regression] ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls
--- Comment #4 from nightstrike at gmail dot com 2010-03-19 16:16 --- Can we fix this before 4.5 is released? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722
[Bug c++/43081] [4.3/4.4/4.5 regression] ICE with invalid in-class initializer
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-23 01:50:47 |2010-03-19 16:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43081
[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 --- I'm not sure what you're asking. When the unpatched compiler the testcase (with the printf or the x!=6-abort) will ICE with a checking compiler, and produce wrong output (0 or an abort) with a nonchecking compiler. With a patched compiler the printf testcase will print 6, and the abort testcase will not abort. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug target/43305] [4.4 Regression] ICE: in emit_unop_insn, at optabs.c:3838 with -Os -ffast-math and ilogbl()
--- Comment #12 from zsojka at seznam dot cz 2010-03-19 16:34 --- Thank you for the answer. I didn't realise check is usually done only with compilers built with checking. (and thank you for fixing the issue, of course) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43305
[Bug c++/43116] [4.3/4.4/4.5 Regression] ICE when using attributes in a function alias declaration
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 --- Subject: Bug 43116 Author: matz Date: Fri Mar 19 16:37:27 2010 New Revision: 157578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157578 Log: PR c++/43116 * attribs.c (decl_attributes): When rebuilding a function pointer type use the same qualifiers as the original pointer type. testsuite/ * g++.dg/other/pr43116.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/other/pr43116.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug debug/43442] .debug_loc is unnecessarily large
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 16:38 --- Created an attachment (id=20142) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20142action=view) gcc45-pr43442.patch Untested patch that cures the size of .debug_loc on the reduced pr43058.c testcase even without the PR43058 patch. Going to bootstrap/regtest it to also see how much actual saving it provides on real-world programs like cc1. -- 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 | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43442
[Bug c++/43116] [4.3/4.4 Regression] ICE when using attributes in a function alias declaration
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 --- Fixed for 4.5. Unassigning myself. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Known to fail|4.5.0 4.2.3 4.3.2 |4.2.3 4.3.2 Known to work|4.1.3 |4.1.3 4.5.0 Summary|[4.3/4.4/4.5 Regression] ICE|[4.3/4.4 Regression] ICE |when using attributes in a |when using attributes in a |function alias declaration |function alias declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug tree-optimization/42963] [4.5 Regression] Redundant switch labels not cleaned up anymore
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 --- Actually I have a patch for this, need to polish it somewhat. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-05 10:15:46 |2010-03-19 16:55:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 --- How about not calling cselib_process_insn on DEBUG_INSNs (or better make cselib_process_insn ignore them). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 17:01 --- Well, we have to call cselib_process_insn on DEBUG_INSNs at least during var-tracking. As for other passes, such as DSE, haven't thought about the impliciations of not doing so. Alex? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #14 from ramana at gcc dot gnu dot org 2010-03-19 17:04 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug debug/43443] New: We should yank ASM_OPERANDS locs from var-tracking preserved cselib VALUEs
__attribute__((noinline))
void bar (void)
{
asm volatile ( : : : memory);
}
int
main (void)
{
int i = 6;
bar ();
i++;
asm ( : +r (i));
i++;
return i;
}
on x86_64-linux -g -O2 has bogosity in VAR_LOCATION note:
(note 33 13 21 2 (var_location i (expr_list:REG_DEP_TRUE (plus:SI
(asm_operands:SI () (=r) 0 [
(const_int 7 [0x7])
]
[
(asm_input:SI (0) (null):0)
]
[] dm.c:16)
(const_int 1 [0x1]))
This is because the register that was set by this non-volatile asm was
clobbered and ASM_OPERANDS definitely is not something we can emit into the
debug info.
And, if it wasn't there, vt_expand_loc could see that this doesn't lead to
useful location and try another one, in particular the one provided by
reverse_op stuff. With the patch I'm going to attach on this testcase we end
up with:
(note 33 13 21 2 (var_location i (expr_list:REG_DEP_TRUE (reg:SI 0 ax [63])
note instead, with assembly diff:
@@ -70,6 +70,10 @@ main:
.byte0x70# DW_OP_breg0
.sleb128 1
.byte0x9f# DW_OP_stack_value
+.quad.LVL3-.Ltext0# Location list begin address (*.LLST0)
+.quad.LFE1-.Ltext0# Location list end address (*.LLST0)
+.value0x1# Location expression size
+.byte0x50# DW_OP_reg0
.quad0x0# Location list terminator begin (*.LLST0)
.quad0x0# Location list terminator end (*.LLST0)
.section.debug_info
--
Summary: We should yank ASM_OPERANDS locs from var-tracking
preserved cselib VALUEs
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43443
[Bug debug/43443] We should yank ASM_OPERANDS locs from var-tracking preserved cselib VALUEs
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-19 17:12 --- Created an attachment (id=20143) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20143action=view) gcc45-pr43443.patch Fix. -- 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 | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43443
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-19 17:35 ---
Ah, I see. We have
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 12 r12))
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 13 r13))
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 14 r14))
(set/f (mem:SI (pre_dec:SI (reg/f:SI 0 r0)) [0 S4 A32])
(reg:SI 15 r15))
]) 159 {*score.md:3032} (expr_list:REG_DEAD (reg:SI 15 r15)
(expr_list:REG_DEAD (reg:SI 14 r14)
(expr_list:REG_DEAD (reg:SI 13 r13)
(expr_list:REG_DEAD (reg:SI 12 r12)
(nil))
and adjust_insn turns that into:
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (plus:SI (reg/f:SI 54 _frame)
(const_int -20 [0xffec])) [0 S4 A32])
(reg:SI 12 r12))
(set/f (mem:SI (plus:SI (reg/f:SI 54 _frame)
(const_int -20 [0xffec])) [0 S4 A32])
(reg:SI 13 r13))
(set/f (mem:SI (plus:SI (reg/f:SI 54 _frame)
(const_int -20 [0xffec])) [0 S4 A32])
(reg:SI 14 r14))
(set/f (mem:SI (plus:SI (reg/f:SI 54 _frame)
(const_int -20 [0xffec])) [0 S4 A32])
(reg:SI 15 r15))
(set (reg/f:SI 0 r0)
(plus:SI (reg/f:SI 0 r0)
(const_int -4 [0xfffc])))
(set (reg/f:SI 0 r0)
(plus:SI (reg/f:SI 0 r0)
(const_int -4 [0xfffc])))
(set (reg/f:SI 0 r0)
(plus:SI (reg/f:SI 0 r0)
(const_int -4 [0xfffc])))
(set (reg/f:SI 0 r0)
(plus:SI (reg/f:SI 0 r0)
(const_int -4 [0xfffc])))
]) 159 {*score.md:3032} (expr_list:REG_DEAD (reg:SI 15 r15)
(expr_list:REG_DEAD (reg:SI 14 r14)
(expr_list:REG_DEAD (reg:SI 13 r13)
(expr_list:REG_DEAD (reg:SI 12 r12)
(nil))
I was assuming more than one autoinc with the same reg doesn't appear in any
port, apparently it does. Guess adjust_insn could detect this and merge all
the adjustments against the same reg into one.
--
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 |
Status|NEW |ASSIGNED
Last reconfirmed|2010-03-19 15:58:32 |2010-03-19 17:35:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-19 17:40 --- (In reply to comment #4) size.1 is always kind=4 so we may need some error checks if someone tries to stuff a large file size into a small space. Thus, we should change the ABI at some point (e.g. when doing the array desc. update). For too large files, one can meanwhile return -1 (If the file size cannot be determined). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43409
[Bug target/43444] New: ICE in adjust_mems at var-tracking.c:789
ICE while building cross-compiler for ARM. $ /usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-build/./gcc/ -B/usr/src/armtest/arm-none-eabi/bin/ -B/usr/src/armtest/arm-none-eabi/lib/ -isystem /usr/src/armtest/arm-none-eabi/include -isystem /usr/src/armtest/arm-none-eabi/sys-include-g -O2 -mfloat-abi=hard -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -Wno-missing-prototypes -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-4.5-20100318/libgcc -I../../../../gcc-4.5-20100318/libgcc/. -I../../../../gcc-4.5-20100318/libgcc/../gcc -I../../../../gcc-4.5-20100318/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.5-20100318/libgcc/../gcc/libgcc2.c -save-temps ../../../../gcc-4.5-20100318/libgcc/../gcc/libgcc2.c: In function â__muldi3â: ../../../../gcc-4.5-20100318/libgcc/../gcc/libgcc2.c:562:1: internal compiler error: in adjust_mems, at var-tracking.c:789 Environment: System: Linux rechot 2.6.33 #2 SMP PREEMPT Thu Mar 11 15:47:34 CET 2010 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux Gentoo on x86 SMP. $ /lib/libc.so.6 GNU C Library stable release version 2.10.1, by Roland McGrath et al. Copyright (C) 2009 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. Compiled by GNU CC version 4.3.4. Compiled on a Linux 2.6.32.2 system on 2010-01-30. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 6 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al Support for some architectures added on, not maintained in glibc core. BIND-8.2.3-T5B host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: arm-none-eabi configured with: ../gcc-4.5-20100318/configure --prefix /usr/src/armtest --target=arm-none-eabi How-To-Repeat: build gcc-4.5-20100318 snapshot for arm-none-eabi target -- Summary: ICE in adjust_mems at var-tracking.c:789 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mirq-gccboogs at rere dot qmqm dot pl GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43444
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #7 from bernds at gcc dot gnu dot org 2010-03-19 18:19 --- Subject: Bug 42258 Author: bernds Date: Fri Mar 19 18:18:54 2010 New Revision: 157581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157581 Log: gcc/ PR rtl-optimization/42258 * ira-lives.c (check_and_make_def_conflict): Ignore conflict for a use that may match DEF. testsuite/ PR rtl-optimization/42258 * gcc.target/arm/thumb1-mul-moves.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/thumb1-mul-moves.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-lives.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug target/43444] ICE in adjust_mems at var-tracking.c:789
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 18:19 --- Just fixed after this morning (which was done after the snapshot was done). *** This bug has been marked as a duplicate of 43399 *** -- 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=43444
[Bug target/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-03-19 18:19 --- *** Bug 43444 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mirq-gccboogs at rere dot ||qmqm dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug rtl-optimization/40956] Constants are never candidates for hoisting
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-19 18:39 ---
Comment #3 makes no sense: There is no such thing as target specific GIMPLE
canonicalization. And also there is no hoisting for GIMPLE so the form of the
IR given in comment #3 wouldn't make a difference.
Even without -frename-registers, the extra insn is there. GCC trunk revision
157579 generates the following code with -Os -mthumb -march=armv5te:
foo:
push{lr}
cmp r0, #9
beq .L2
mov r3, #0
str r3, [r1]
b .L3
.L2:
mov r3, #0
str r3, [r1, #4]
.L3:
mov r0, #3
@ sp needed for prologue
pop {pc}
Here the mov r3, #0 after .L2: and after beq .L2 could be unified e.g.
with hoisting or with head-merging (inverse of tail merging).
Just before the RTL hoisting pass, the code looks like this (.152r.cprop1
dump):
5 NOTE_INSN_BASIC_BLOCK
2 r135:SI=r0:SI
REG_DEAD: r0:SI
3 r136:SI=r1:SI
REG_DEAD: r1:SI
4 NOTE_INSN_FUNCTION_BEG
7 pc={(r135:SI==0x9)?L13:pc}
REG_DEAD: r135:SI
REG_BR_PROB: 0xec6
8 NOTE_INSN_BASIC_BLOCK
9 r137:SI=0x0
10 [r136:SI]=r137:SI
REG_EQUAL: 0x0
REG_DEAD: r137:SI
REG_DEAD: r136:SI
L13:
14 NOTE_INSN_BASIC_BLOCK
15 r138:SI=0x0
16 [r136:SI+0x4]=r138:SI
REG_EQUAL: 0x0
REG_DEAD: r138:SI
REG_DEAD: r136:SI
L17:
18 NOTE_INSN_BASIC_BLOCK
23 r0:SI=0x3
26 use r0:SI
Note the insns 9 r137:SI=0x0 and 15 r138:SI=0x0. This could be hoisted in
the RTL HOIST pass. But this doesn't happen because the hoisting pass doesn't
record constants as hoisting candidates. The expression passes in gcse.c (PRE
and HOIST) ignore all instructions of the form (set (reg) (const)) because
want_to_gcse_p() returns false for them. This is a deliberate decision in the
implementation.
Thus, there is nothing target specific about this problem. The analysis of
comment #3 makes no sense, but this is also not really a dup of bug 23286.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||33828
nThis||
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
GCC build triplet|i686-linux |
GCC host triplet|i686-linux |
Last reconfirmed|-00-00 00:00:00 |2010-03-19 18:39:40
date||
Summary|GCSE opportunity in if |Constants are never
|statement |candidates for hoisting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40956
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #5 from aldyh at gcc dot gnu dot org 2010-03-19 18:41 --- Err, I was just going to say that. Curse you Jakub. Let me know when you're looking at something so we don't duplicate efforts. Wait, am I not supposed to say curse on a PR? Oh well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug target/40697] inefficient code to extract least bits from an integer value
--- Comment #5 from bernds at gcc dot gnu dot org 2010-03-19 18:41 --- Subject: Bug 40697 Author: bernds Date: Fri Mar 19 18:41:22 2010 New Revision: 157582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157582 Log: gcc/ PR target/40697 * optabs.c (avoid_expensive_constant): Use rtx_cost to find out the cost of loading the constant rather than assuming COSTS_N_INSNS (1). * config/arm/arm.c (thumb1_rtx_costs) case CONST_INT: If the outer code is AND, do the same tests as the andsi3 expander and return COSTS_N_INSNS (1) if and is cheap. testsuite/ PR target/40697 * gcc.target/arm/thumb-andsi.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/thumb-andsi.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40697
[Bug target/42879] Replace tst r3, 1 with lsl r3, r3, 31 in thumb2
-- steven at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16996 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879
[Bug fortran/43409] I/O: INQUIRE for SIZE does not work.
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-19 20:25 --- On 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|2010-03-19 03:24:02 |2010-03-19 20:25:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43409
[Bug preprocessor/39213] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #1 from ro at gcc dot gnu dot org 2010-03-19 20:32 --- Fails on 64-bit Solaris 10, 11/SPARC, too. I get the following stacktrace: #0 0xfee7248c in abort () from /lib/libc.so.1 #1 0x08859957 in _cpp_process_line_notes (pfile=0x8b5c468, in_comment=0) at /vol/gcc/src/hg/trunk/solaris/libcpp/lex.c:318 #2 0x0886153a in _cpp_scan_out_logical_line (pfile=0x8b5c468, macro=0x0) at /vol/gcc/src/hg/trunk/solaris/libcpp/traditional.c:384 #3 0x08861d53 in _cpp_read_logical_line_trad (pfile=0x8b5c468) at /vol/gcc/src/hg/trunk/solaris/libcpp/traditional.c:306 #4 0x0815e515 in scan_translation_unit_trad (pfile=0x8b5c468) at /vol/gcc/src/hg/trunk/solaris/gcc/c-ppoutput.c:289 #5 preprocess_file (pfile=0x8b5c468) at /vol/gcc/src/hg/trunk/solaris/gcc/c-ppoutput.c:95 #6 0x0815935b in c_common_init () at /vol/gcc/src/hg/trunk/solaris/gcc/c-opts.c:1235 #7 0x08161ee8 in c_objc_common_init () at /vol/gcc/src/hg/trunk/solaris/gcc/c-objc-common.c:74 #8 0x083f1a00 in lang_dependent_init (argc=18, argv=0x8047160) at /vol/gcc/src/hg/trunk/solaris/gcc/toplev.c:2279 #9 do_compile (argc=18, argv=0x8047160) at /vol/gcc/src/hg/trunk/solaris/gcc/toplev.c:2404 #10 toplev_main (argc=18, argv=0x8047160) at /vol/gcc/src/hg/trunk/solaris/gcc/toplev.c:2447 #11 0x0817d4ef in main (argc=18, argv=0x8047160) at /vol/gcc/src/hg/trunk/solaris/gcc/main.c:35 gdb claims note-type = 10 -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-pc-solaris2.11 |*-*-solaris2* GCC host triplet|i386-pc-solaris2.11 |*-*-solaris2* GCC target triplet|i386-pc-solaris2.11 |*-*-solaris2* Known to fail|4.4.0 |4.4.0 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-03-19 20:32:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-19 20:37 --- Created an attachment (id=20144) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20144action=view) gcc45-pr43437.patch Possible patch. Except that note_uses (and note_stores) walk parallels from end to start, so as first the side effects for r15 store are replaced etc. Not sure what the insn really does, if it expects the storing to be done first parallel goes to r0 - 4, second to r0 - 8, third to r0 - 12 and fourth to r0 - 16, or first to r0 - 16, second to r0 - 12, third to r0 - 8 and fourth to r0 - 4. To me this sounds very much like multiple side-effects in one statement in C, I'd say doing this should be invalid RTL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug other/43445] New: Toplevel Makefile needs to export ABI variants of LD_LIBRARY_PATH
During a libjava build on i386-pc-solaris2.11, I noticed the following error:
ld.so.1: gcj-dbtool: fatal:
/vol/gcc/obj/gcc-4.5.0-20100208/11-gcc-gld/./gcc/libgcc_s.so.1: wrong ELF
class: ELFCLASS32
/bin/ksh: 29209 Killed
This happens when trying to execute the 64-bit gcj-dbtool. gcj-dbtool itself
is a libtool wrapper script, which allows it to find the dependend libtool
libraries, but for libgcc_s.so.1, it relies on HOST_EXPORTS in the toplevel
Makefile to export LD_LIBRARY_PATH via RPATH_ENVVAR, it refers to
TARGET_LIB_PATH and HOST_LIB_PATH, but none of them is multilib aware.
The toplevel Makefile probably needs to set all of LD_LIBRARY_PATH{, _32, _64}
and their IRIX and Darwin equivalents. See
gcc/testsuite/lib/target-libpath.exp
for the full list.
--
Summary: Toplevel Makefile needs to export ABI variants of
LD_LIBRARY_PATH
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43445
[Bug target/43446] New: libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
build fails in configure-target-libiberty with: checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Anyway, Probably libiberty should not be built anyway for this target. The same goes for libssp (can be disabled) and zlib. -- Summary: libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mirq-gccboogs at rere dot qmqm dot pl GCC build triplet: arm-none-eabi GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 20:45 --- How did you configure GCC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug libgcj/43447] New: TestLeak.exe test consumes all available memory on 64-bit Solaris 2
At least on Solaris 10 and 11, both SPARC and x86, the 64-bit TestLeak.exe test consumes all available memory, possibly bringing the machine to a complete halt. The problem seems to be far more severe if gcc is built to use GNU ld instead of Sun ld. -- Summary: TestLeak.exe test consumes all available memory on 64- bit Solaris 2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: *-*-solaris2* GCC host triplet: *-*-solaris2* GCC target triplet: *-*-solaris2* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43447
[Bug other/43448] New: gccbug should be removed
gccbug hasn't worked in months if not years. Bug reports submitted using it are silently dropped, which is the worse that can happen: submitters being ignored and possibly even losing their submission are far less likely to report bugs in the future. Since it seems highly unlikely that a volunteer shows up to make this work again, we should instead remove gccbug wholesale and have mail to gcc-gn...@gcc.gnu.org bounce with an appropriate error message so anyone trying to submit bugs using old versions of gccbug with keep a copy of his submission and be alerted to the demise of gccbug. -- Summary: gccbug should be removed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43448
[Bug other/43449] New: sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
We found a problem in sbitmap.c:
bool
sbitmap_range_empty_p (const_sbitmap bmap, unsigned int start, unsigned int n)
{
unsigned int i = start / SBITMAP_ELT_BITS;
SBITMAP_ELT_TYPE elm;
...
/* The bits are totally contained in a single element. */
if (shift + n SBITMAP_ELT_BITS)
elm = ((1 n) - 1);
depending on configuration, SBITMAP_ELT_TYPE can be wider than the int type.
The masking above will mistakenly strip off top bits from elm. The correct
code should be written as:
/* The bits are totally contained in a single element. */
if (shift + n SBITMAP_ELT_BITS)
elm = (((SBITMAP_ELF_BITS) 1 n) - 1);
The same problem appears in another location of the same function. The broken
code is in both 4.4.0 and trunk.
--
Summary: sbitmap is broken if gcc is built with -m32 on a 64-bit
machine.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dougkwan at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu (with -m32)
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
[Bug debug/43442] .debug_loc is unnecessarily large
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-19 20:56 --- The patch has been bootstrapped/regtested on x86_64-linux and i686-linux and apparently has huge effect on the debug info size. i686 cc1 before: DW_AT_location count 305862 [28] .debug_info PROGBITS 1002ada 139b947 00 0 0 1 [33] .debug_locPROGBITS 29059e7 f6b1fb 00 0 0 1 i686 cc1 after: DW_AT_location count 295969 [28] .debug_info PROGBITS 1002ada 1391ec0 00 0 0 1 [33] .debug_locPROGBITS 28fc1b3 893583 00 0 0 1 I guess I should verify some random DIEs from that 1 set of DIEs that lost DW_AT_location attribute if really all location list parts were outside of the containing block DW_AT_ranges, and similarly for some location lists that got shorter. On the simple testcase it worked well, but more verification doesn't hurt. If the patch really doesn't throw useful debug info on the floor, having .debug_loc shrink by 50% would be quite nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43442
[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-19 21:02 --- SBITMAP_ELT_TYPE is defined as HOST_WIDEST_FAST_INT. And HOST_WIDEST_FAST_INT (added by me) is either long or long long. Yes there should be a cast but it cannot be an issue really with -m32 really because long is the same size as int there. The host is LP32 as you described so long is the same size as int. If HOST_WIDEST_FAST_INT is long long there, there is bug in the configuration as that will slow down the compiler anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-19 21:05 --- This is the comment from hwint.h (which I know I did :) ): /* Define HOST_WIDEST_FAST_INT to the widest integer type supported efficiently in hardware. (That is, the widest integer type that fits in a hardware register.) Normally this is long but on some hosts it should be long long or __int64. This is no convenient way to autodetect this, so such systems must set a flag in config.host; see there for details. */ Only two hosts use it as long long, x86_64-mingw and ia64-hpux. Now I think you are lying to configure that the host is x86_64-linux-gnu anyways if you are using -m32. I think the host (and build should be i686-linux-gnu). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
[Bug fortran/43450] New: -fwhole-file: ICE in gfc_create_module_variable, at fortran/trans-decl.c:3386
Moved from PR 40011 comment 40 into an extra PR. Joost reported that the following ICEs in gfc_create_module_variable, at fortran/trans-decl.c:3386 The failing assert is: gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE || TYPE_CONTEXT (decl) == sym-ns-proc_name-backend_decl); debugging shows: p sym-backend_decl-type.context $6 = (tree) 0x2cba85c0 p sym-ns-proc_name-backend_decl-type.context $7 = (tree) 0x0 where: (gdb) p sym-ns-proc_name-name $2 = 0x2cc37e70 ep_types (gdb) p sym-name $3 = 0x2cc5e588 replica_env_type MODULE replica_types TYPE replica_env_type END TYPE replica_env_type CONTAINS SUBROUTINE rep_env_create(rep_env, para_env, input, nrep, prep, sync_v,keep_wf_history,row_force) END SUBROUTINE rep_env_create SUBROUTINE rep_envs_add_rep_env(rep_env) TYPE(replica_env_type), POINTER :: rep_env END SUBROUTINE rep_envs_add_rep_env END MODULE replica_types MODULE ep_types USE replica_types TYPE ep_env_type TYPE(replica_env_type), POINTER :: mol_envs END TYPE ep_env_type TYPE ep_env_p_type TYPE(ep_env_type), POINTER :: ep_env END TYPE ep_env_p_type TYPE(ep_env_p_type), DIMENSION(:), POINTER :: ep_envs CONTAINS SUBROUTINE ep_force_release() END SUBROUTINE ep_force_release END MODULE ep_types -- Summary: -fwhole-file: ICE in gfc_create_module_variable, at fortran/trans-decl.c:3386 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43450
[Bug target/43437] ICE in CSE, during libgcc build
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-19 21:14 ---
I really think it is score backend that should be fixed here.
Say the store multiple should be represented with
(insn/f 93 8 94 2 pr43437.c:4 (parallel [
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int -4
[0xfffc])) [0 S4 A32])
(reg:SI 12 r12))
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int -8
[0xfff8])) [0 S4 A32])
(reg:SI 13 r13))
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int -12
[0xfff4])) [0 S4 A32])
(reg:SI 14 r14))
(set/f (mem:SI (plus:SI (reg/f:SI 0 r0) (const_int -16
[0xfff0])) [0 S4 A32])
(reg:SI 15 r15))
(set/f (reg/f:SI 0 r0) ((plus:SI (reg/f:SI 0 r0) (const_int -16
[0xfff0])))
]) 159 {*score.md:3032} (expr_list:REG_DEAD (reg:SI 15 r15)
(expr_list:REG_DEAD (reg:SI 14 r14)
(expr_list:REG_DEAD (reg:SI 13 r13)
(expr_list:REG_DEAD (reg:SI 12 r12)
(nil))
assuming the regs are meant to be pushed in that order (or the other order of
the adjustments). No single insn should have more than one side-effect on one
register.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||liqin at gcc dot gnu dot org
AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
||dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
[Bug debug/43442] .debug_loc is unnecessarily large
--- Comment #3 from jakub at gcc dot gnu dot org 2010-03-19 21:50 --- Similar effects on x86_64 cc1plus: before: DW_AT_location count 312834, cc1plus size 83M [28] .debug_info PROGBITS 10eb517 149edb3 00 0 0 1 [32] .debug_locPROGBITS 2a6b054 1e2fba8 00 0 0 1 after: DW_AT_location count 302437, cc1plus size 70M [28] .debug_info PROGBITS 10eb517 1494b6b 00 0 0 1 [32] .debug_locPROGBITS 2a61051 10f1b5c 00 0 0 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43442
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #2 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:56 --- I'm building a compiler for Cortex-M3 based microcontroller, so i used this configure options: ../gcc/configure --prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c --disable-libssp There are no --disable options for libiberty nor zlib, so I manually removed *-target-libiberty dependencies from maybe-*-target-libiberty (and the same for zlib) in the main Makefile. Then the build and install finished correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #3 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 21:57 --- I forgot to add, that the configure error is the same as in bug #37634 for libgfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #4 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 22:03 --- I just noticed, that I switched target/build triplets when reporting. That's fixed now. BTW, ./arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=./arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/src/gcc-armtest/libexec/gcc/arm-none-eabi/4.5.0/lto-wrapper Target: arm-none-eabi Configured with: ../gcc/configure --prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c --disable-libssp Thread model: single gcc version 4.5.0 20100319 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug libstdc++/43451] New: [C++0x] atomic integral methods missing volatile overloads
Since the resolution of LWG 1147, most of the methods on the atomic integral types should have two overloads, a volatile and a non-volatile version. However, it appears that since r155377, the volatile overloads are missing from the atomic integral types altogether. -- Summary: [C++0x] atomic integral methods missing volatile overloads Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: veloso at verylowsodium dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43451
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-19 22:08 --- Are you building a combined tree? Or are you doing the building in different steps? For a combined tree, it should just work and if you are building a combined tree please attach the config.log from libiberty subdirectory in the target subdirectory. If you are not building a combined tree then you need to do: --without-headers --with-newlib Also Then build newlib and then rebuild GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug libstdc++/43451] [C++0x] atomic integral methods missing volatile overloads
--- Comment #1 from paolo dot carlini at oracle dot com 2010-03-19 22:15 --- Yes. To be clear, Bugzilla isn't the proper tool for this kind of issue: it is for *bug* tracking - not for managing the development of new projects - and the whole C++0x is indeed a new project, and an experimental one. Of course, *many* bits of C++0x are not implemented yet in GCC, implemented incompletely, or not implemented according to the latest WD, but a Bugzilla entry for each is not the way we want to go. Thus, please be patient, and at some point somebody will of course work on this too. You are also welcome to contribute. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43451
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #6 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 22:23 --- I haven't looked at newlib yet, as I needed just the C compiler. Source tree is a vanilla svn checkout from svn://gcc.gnu.org/svn/gcc/trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug libstdc++/43451] [C++0x] atomic integral methods missing volatile overloads
--- Comment #2 from paolo dot carlini at oracle dot com 2010-03-19 22:25 --- Benjamin, I'm adding you in CC, I don't know which plans do we have wrt to this issue for 4.5.0... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43451
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-19 22:24 --- So please try with the flags I offered for configuring. Since those are the options which are needed to build a cross without newlib built (or a combined tree). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug c/43211] [4.5 Regression] ICE with incomplete type in function argument
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 --- Subject: Bug 43211 Author: pinskia Date: Fri Mar 19 22:52:41 2010 New Revision: 157585 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157585 Log: 2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com PR C/43211 * c-decl.c (grokparms): Set arg_types to NULL_TREE if there was an error. 2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com PR C/43211 * gcc.dg/pr43211.c: New test. * gcc.dg/pr18809-1.c: Don't expect an error when calling foo. Added: trunk/gcc/testsuite/gcc.dg/pr43211.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr18809-1.c --- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug c/43211] [4.5 Regression] ICE with incomplete type in function argument
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 --- Subject: Bug 43211 Author: pinskia Date: Fri Mar 19 22:52:41 2010 New Revision: 157585 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157585 Log: 2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com PR C/43211 * c-decl.c (grokparms): Set arg_types to NULL_TREE if there was an error. 2010-03-19 Andrew Pinski andrew_pin...@caviumnetworks.com PR C/43211 * gcc.dg/pr43211.c: New test. * gcc.dg/pr18809-1.c: Don't expect an error when calling foo. Added: trunk/gcc/testsuite/gcc.dg/pr43211.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr18809-1.c --- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-19 22:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #8 from mirq-gccboogs at rere dot qmqm dot pl 2010-03-19 23:01 --- ../gcc/configure --without-headers --with-newlib --prefix=/usr/src/gcc-armtest --target arm-none-eabi --enable-languages=c --disable-libssp Now make fails with: /usr/src/gcc-build/./gcc/xgcc -B/usr/src/gcc-build/./gcc/ -B/usr/src/gcc-armtest/arm-none-eabi/bin/ -B/usr/src/gcc-armtest/arm-none-eabi/lib/ -isystem /usr/src/gcc-armtest/arm-none-eabi/include -isystem /usr/src/gcc-armtest/arm-none-eabi/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/regex.c -o regex.o ../../../gcc/libiberty/regex.c:51:25: fatal error: sys/types.h: No such file or directory compilation terminated. make[2]: *** [regex.o] Error 1 make[2]: Leaving directory `/usr/src/gcc-build/arm-none-eabi/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/usr/src/gcc-build' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug target/43446] libiberty for target failing to build with error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-03-19 23:04 --- Can you revert all your patches and try again? Because this used to work for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43446
[Bug other/43449] sbitmap is broken if gcc is built with -m32 on a 64-bit machine.
--- Comment #3 from dougkwan at google dot com 2010-03-19 23:09 --- Yes, I lied to configure. So this is not a real bug. -- dougkwan at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43449
