[PATCH] gcc mcount-nofp was Re: BUG: GCC-4.4.x changes the function frame on some functions
Steven Rostedt rost...@goodmis.org writes:
And frame pointers do add a little overhead as well. Too bad the mcount
ABI wasn't something like this:
function:
callmcount
[...]
This way, the function address for mcount would have been (%esp) and the
parent address would be 4(%esp). Mcount would work without frame
pointers and this whole mess would also become moot.
I did a patch to do this in x86 gcc some time ago. The motivation
was indeed the frame pointer overhead on Atom with tracing.
Unfortunately it also requires glibc changes (I did those too). For
compatibility and catching mistakes the new function was called
__mcount_nofp.
I haven't tried it with current gcc and last time I missed the
gcc feature merge window with this.
But perhaps you find it useful. Of course it would need more
kernel changes to probe for the new option and handle it.
Here's the old patch. I haven't retested it with a current
gcc version, but I think it still applies at least.
If there's interest I can polish it up and submit formally.
-Andi
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 149140)
+++ gcc/doc/tm.texi (working copy)
@@ -1884,6 +1884,12 @@
of words in each data entry.
@end defmac
+...@defmac TARGET_FUNCTION_PROFILE
+Define if the target has a custom function_profiler function.
+The target should not set this macro, it is implicitely set from
+the PROFILE_BEFORE_PROLOGUE macro.
+...@end defmac
+
@node Registers
@section Register Usage
@cindex register usage
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 149140)
+++ gcc/doc/invoke.texi (working copy)
@@ -593,7 +593,7 @@
-momit-leaf-frame-pointer -mno-red-zone -mno-tls-direct-seg-refs @gol
-mcmod...@var{code-model} -ma...@var{name} @gol
-m32 -m64 -mlarge-data-thresho...@var{num} @gol
--mfused-madd -mno-fused-madd -msse2avx}
+-mfused-madd -mno-fused-madd -msse2avx -mmcount-nofp}
@emph{IA-64 Options}
@gccoptlist{-mbig-endian -mlittle-endian -mgnu-as -mgnu-ld -mno-pic @gol
@@ -11749,6 +11749,11 @@
@opindex msse2avx
Specify that the assembler should encode SSE instructions with VEX
prefix. The option @option{-mavx} turns this on by default.
+
+...@item -mmcount-nofp
+Don't force the frame counter with @option{-pg} function profiling.
+Instead call a new @code{__mcount_nofp} function before a stack
+frame is set up.
@end table
These @samp{-m} switches are supported in addition to the above
Index: gcc/target.h
===
--- gcc/target.h(revision 149140)
+++ gcc/target.h(working copy)
@@ -1132,6 +1132,9 @@
*/
bool arm_eabi_unwinder;
+ /* True when the function profiler code is outputted before the prologue. */
+ bool profile_before_prologue;
+
/* Leave the boolean fields at the end. */
};
Index: gcc/final.c
===
--- gcc/final.c (revision 149140)
+++ gcc/final.c (working copy)
@@ -1520,10 +1520,8 @@
/* The Sun386i and perhaps other machines don't work right
if the profiling code comes after the prologue. */
-#ifdef PROFILE_BEFORE_PROLOGUE
- if (crtl-profile)
+ if (targetm.profile_before_prologue crtl-profile)
profile_function (file);
-#endif /* PROFILE_BEFORE_PROLOGUE */
#if defined (DWARF2_UNWIND_INFO) defined (HAVE_prologue)
if (dwarf2out_do_frame ())
@@ -1565,10 +1563,8 @@
static void
profile_after_prologue (FILE *file ATTRIBUTE_UNUSED)
{
-#ifndef PROFILE_BEFORE_PROLOGUE
- if (crtl-profile)
+ if (!targetm.profile_before_prologue crtl-profile)
profile_function (file);
-#endif /* not PROFILE_BEFORE_PROLOGUE */
}
static void
Index: gcc/gcc.c
===
--- gcc/gcc.c (revision 149140)
+++ gcc/gcc.c (working copy)
@@ -797,6 +797,12 @@
# define SYSROOT_HEADERS_SUFFIX_SPEC
#endif
+/* Target can override this to allow -pg/-fomit-frame-pointer together */
+#ifndef TARGET_PG_OPTION_SPEC
+#define TARGET_PG_OPTION_SPEC \
+%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}
+#endif
+
static const char *asm_debug;
static const char *cpp_spec = CPP_SPEC;
static const char *cc1_spec = CC1_SPEC;
@@ -866,8 +872,8 @@
/* NB: This is shared amongst all front-ends, except for Ada. */
static const char *cc1_options =
-%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
- %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\
+ TARGET_PG_OPTION_SPEC
+ %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*}\
%{fcompare-debug-second:%:compare-debug-auxbase-opt(%b)} \
%{!fcompare-debug-second:%{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase
%b}}}%{!c:%{!S:-auxbase %b}} \
%{g*} %{O*} %{W*pedantic*} %{w} %{std*ansitrigraphs}\
Index: gcc/target-def.h
Re: BUG: GCC-4.4.x changes the function frame on some functions
Thomas Gleixner wrote: While testing various kernel configs we found out that the problem comes and goes. Finally I started to compare the gcc command line options and after some fiddling it turned out that the following minimal deltas change the code generator behaviour: Bad: -march=pentium-mmx-Wa,-mtune=generic32 Good: -march=i686-mtune=generic -Wa,-mtune=generic32 Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32 I'm not supposed to understand the logic behind that, right ? I don't either. I'm seeing: timer_stats_update_stats: timer_stats_update_stats: pushl %edi leal8(%esp), %edi andl$-16, %esp pushl -4(%edi) pushl %ebppushl %ebp movl%esp, %ebp movl %esp, %ebp pushl %edi | andl $-16, %esp pushl %esi | subl $112, %esp pushl %ebx | movl %ebx, 100(%esp) subl$108, %esp| movl %esi, 104(%esp) movl %edi, 108(%esp) callmcount call mcount where the only difference is -mtune=generic. I'm investigating. Andrew.
Call func address spill out
Hi, I have a problem about function call insn. in CALL @LABEL, only can jump backward/forward 32k SPACE. So if it overflows, the function symbol_ref could move a register, then CALL Ri (i represent 0 ~ 15). But the question is gcc doesn't know the function symbol_ref 's address before ld taking care. Now there is only one solution I could choose: to force all the function call symbol_ref into register and CALL insn calls the register. But I think this will cost more cpu time while routine is less than 32k space. You know the instruction space is limited, so code size becomes the key point. Can somebody give me some advice? Thanks very much. Best Wishes! daniel.tian
Re: BUG: GCC-4.4.x changes the function frame on some functions
Andrew Haley wrote: Thomas Gleixner wrote: While testing various kernel configs we found out that the problem comes and goes. Finally I started to compare the gcc command line options and after some fiddling it turned out that the following minimal deltas change the code generator behaviour: Bad: -march=pentium-mmx-Wa,-mtune=generic32 Good: -march=i686-mtune=generic -Wa,-mtune=generic32 Good: -march=pentium-mmx -mtune-generic -Wa,-mtune=generic32 I'm not supposed to understand the logic behind that, right ? I don't either. I'm seeing: timer_stats_update_stats: timer_stats_update_stats: pushl %edi leal8(%esp), %edi andl$-16, %esp pushl -4(%edi) pushl %ebppushl %ebp movl%esp, %ebp movl %esp, %ebp pushl %edi | andl $-16, %esp pushl %esi | subl $112, %esp pushl %ebx | movl %ebx, 100(%esp) subl$108, %esp| movl %esi, 104(%esp) movl %edi, 108(%esp) callmcount call mcount where the only difference is -mtune=generic. I'm investigating. Forget that, I see from the gcc-bugs list that hj has tracked it down to the use of DRAP, and for some reason the mtune options affect that. He's the best person to fix this. Andrew.
Re: [PATCH] gcc mcount-nofp was Re: BUG: GCC-4.4.x changes the function frame on some functions
On Fri, 2009-11-20 at 10:57 +0100, Andi Kleen wrote: Steven Rostedt rost...@goodmis.org writes: And frame pointers do add a little overhead as well. Too bad the mcount ABI wasn't something like this: function: callmcount [...] This way, the function address for mcount would have been (%esp) and the parent address would be 4(%esp). Mcount would work without frame pointers and this whole mess would also become moot. I did a patch to do this in x86 gcc some time ago. The motivation was indeed the frame pointer overhead on Atom with tracing. Yes, I remember you talking about this but I don't remember how far it went. Unfortunately it also requires glibc changes (I did those too). For compatibility and catching mistakes the new function was called __mcount_nofp. Actually, could you change the name? I really hate the mcount name, it is legacy and with a new feature, it should be abandoned. Something like __fentry__ would be nicer. I haven't tried it with current gcc and last time I missed the gcc feature merge window with this. But perhaps you find it useful. Of course it would need more kernel changes to probe for the new option and handle it. Here's the old patch. I haven't retested it with a current gcc version, but I think it still applies at least. If there's interest I can polish it up and submit formally. I would definitely be interested, and I would also be willing to test it. Thanks! -- Steve
GCC 4.5 is uncompilable
An attempt to build either gcc-trunk or the most recent snapshot (20091119) with Cygwin (the build compiler is either GCC 4.4.0 or 4.5-20090604), configured as: $ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap --enable-ve rsion-specific-runtime-libs --enable-shared --enable-shared-libgcc --with-gnu-l d --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --wi th-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c ++ fails with the following message: [...] mv ./shlib/libgcc_s.dll.a.tmp ./shlib/libgcc_s.dll.a /usr/bin/ld: unrecognized -a option `ware' collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dll] Error 1 make[3]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir/i 686-pc-cygwin/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make: *** [all] Error 2
Re: GCC 4.5 is uncompilable
2009/11/20 Piotr Wyderski piotr.wyder...@gmail.com: An attempt to build either gcc-trunk or the most recent snapshot (20091119) with Cygwin (the build compiler is either GCC 4.4.0 or 4.5-20090604), configured as: $ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap --enable-ve rsion-specific-runtime-libs --enable-shared --enable-shared-libgcc --with-gnu-l d --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --wi th-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c ++ fails with the following message: [...] mv ./shlib/libgcc_s.dll.a.tmp ./shlib/libgcc_s.dll.a /usr/bin/ld: unrecognized -a option `ware' collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dll] Error 1 make[3]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir/i 686-pc-cygwin/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make: *** [all] Error 2 This error you get is more related to used binutils version.The warning you get looks more like a cripled '-Wl,--tsaware'. Which binutils version you are using? Cheers, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination
Re: GCC 4.5 is uncompilable
Kai Tietz wrote: This error you get is more related to used binutils version.The warning you get looks more like a cripled '-Wl,--tsaware'. Thanks, that looks like a good explanation. Which binutils version you are using? $ ld -v GNU ld (GNU Binutils) 2.18.50.20080625 I'll try to upgrade binutils and then repeat the build process. Best regards Piotr Wyderski
Worth balancing the tree before scheduling?
From some simple experiments (see below), it appears as though GCC aims
to
create a lop-sided tree when there are constants involved (func1 below),
but a balanced tree when there aren't (func2 below).
Our assumption is that GCC likes having constants all near to each other
to
aid with tree-based optimisations, but I'm fairly sure that, when it
comes
to scheduling, it would be better to have a balanced tree, so sched has
more
choices about what to schedule next?
The impact of limiting sched's options can be seen if we look at the
pseudo-assembly produced by GCC for our architecture:
func1:
LSHIFT $c3,$c1,3 # tmp137, a,
ADD $c2,$c2,$c3 # tmp138, b, tmp137
ADD $c1,$c2,$c1 #, tmp138, a
We think it would be better to avoid using the temporary:
func1:
ADD $c2,$c1,$c2 # tmp137, a, b
LSHIFT $c1,$c1,3 # tmp138, a,
ADD $c1,$c2,$c1 # result, tmp137, tmp138
As it currently stands, sched doesn't have the option to do this because
its input (shown in func.c.172r.asmcons below) is arranged such that the
first add depends on the shift and the second add depends on the first
add.
If the tree were balanced, sched would have the option to do the add
first.
And, providing the logic was there in sched, we could make it choose to
schedule such that we limit the number of temporaries used.
Maybe one of the RTL passes prior to scheduling has the potential to
balance the tree/RTL, but just isn't on our architecture?
==
func.c:
--
int func1 (int a, int b)
{
/* the original expression */
return a + b + (a 3);
}
int func2 (int a, int b, int c)
{
/* the original expression */
return a + b + (a c);
}
==
==
func.c.129t.supress_extend:
--
;; Function func1 (func1)
func1 (int a, int b)
{
bb 2:
return (b + (a 3)) + a;
}
func2 (int a, int b, int c)
{
bb 2:
return (b + a) + (a c);
}
==
==
func.c.172r.asmcons:
--
;; Function func1 (func1)
;; Pred edge ENTRY [100.0%] (fallthru)
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 func.c:2 (set (reg/v:SI 134 [ a ])
(reg:SI 1 $c1 [ a ])) 45 {*movsi} (expr_list:REG_DEAD (reg:SI 1
$c1 [ a ])
(nil)))
(note 3 2 4 2 NOTE_INSN_DELETED)
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 8 2 func.c:2 (set (reg:SI 137)
(ashift:SI (reg/v:SI 134 [ a ])
(const_int 3 [0x3]))) 80 {ashlsi3} (nil))
(insn 8 7 9 2 func.c:2 (set (reg:SI 138)
(plus:SI (reg:SI 2 $c2 [ b ])
(reg:SI 137))) 65 {*addsi3} (expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 2 $c2 [ b ])
(nil
(note 9 8 14 2 NOTE_INSN_DELETED)
(insn 14 9 20 2 func.c:5 (set (reg/i:SI 1 $c1)
(plus:SI (reg:SI 138)
(reg/v:SI 134 [ a ]))) 65 {*addsi3} (expr_list:REG_DEAD
(reg:SI 138)
(expr_list:REG_DEAD (reg/v:SI 134 [ a ])
(nil
(insn 20 14 0 2 func.c:5 (use (reg/i:SI 1 $c1)) -1 (nil))
;; Function func2 (func2)
;; Pred edge ENTRY [100.0%] (fallthru)
(note 6 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 6 3 2 func.c:8 (set (reg/v:SI 134 [ a ])
(reg:SI 1 $c1 [ a ])) 45 {*movsi} (expr_list:REG_DEAD (reg:SI 1
$c1 [ a ])
(nil)))
(note 3 2 4 2 NOTE_INSN_DELETED)
(note 4 3 5 2 NOTE_INSN_DELETED)
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 func.c:8 (set (reg:SI 138)
(plus:SI (reg:SI 2 $c2 [ b ])
(reg/v:SI 134 [ a ]))) 65 {*addsi3} (expr_list:REG_DEAD
(reg:SI 2 $c2 [ b ])
(nil)))
(insn 9 8 10 2 func.c:8 (set (reg:SI 139)
(ashift:SI (reg/v:SI 134 [ a ])
(reg:SI 3 $c3 [ c ]))) 80 {ashlsi3} (expr_list:REG_DEAD
(reg/v:SI 134 [ a ])
(expr_list:REG_DEAD (reg:SI 3 $c3 [ c ])
(nil
(note 10 9 15 2 NOTE_INSN_DELETED)
(insn 15 10 21 2 func.c:11 (set (reg/i:SI 1 $c1)
(plus:SI (reg:SI 138)
(reg:SI 139))) 65 {*addsi3} (expr_list:REG_DEAD (reg:SI 139)
(expr_list:REG_DEAD (reg:SI 138)
(nil
(insn 21 15 0 2 func.c:11 (use (reg/i:SI 1 $c1)) -1 (nil))
==
Cheers,
Ian
Re: Worth balancing the tree before scheduling?
On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com wrote: From some simple experiments (see below), it appears as though GCC aims to create a lop-sided tree when there are constants involved (func1 below), but a balanced tree when there aren't (func2 below). Our assumption is that GCC likes having constants all near to each other to aid with tree-based optimisations, but I'm fairly sure that, when it comes to scheduling, it would be better to have a balanced tree, so sched has more choices about what to schedule next? I think this would depend on the target architecture and instruction set: CISC vs RISC, many registers vs few registers, etc. I do not believe that GCC intentionally is trying to optimize for either, but I do not think there is a single, right answer. David
Re: Worth balancing the tree before scheduling?
On Fri, Nov 20, 2009 at 4:18 PM, David Edelsohn dje@gmail.com wrote: On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com wrote: From some simple experiments (see below), it appears as though GCC aims to create a lop-sided tree when there are constants involved (func1 below), but a balanced tree when there aren't (func2 below). Our assumption is that GCC likes having constants all near to each other to aid with tree-based optimisations, but I'm fairly sure that, when it comes to scheduling, it would be better to have a balanced tree, so sched has more choices about what to schedule next? I think this would depend on the target architecture and instruction set: CISC vs RISC, many registers vs few registers, etc. I do not believe that GCC intentionally is trying to optimize for either, but I do not think there is a single, right answer. Indeed. I think the scheduler should maybe learn about re-association possibilities - do existing papers cover that? Richard. David
Re: Worth balancing the tree before scheduling?
On Fri, 2009-11-20 at 10:18 -0500, David Edelsohn wrote: On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com wrote: From some simple experiments (see below), it appears as though GCC aims to create a lop-sided tree when there are constants involved (func1 below), but a balanced tree when there aren't (func2 below). Our assumption is that GCC likes having constants all near to each other to aid with tree-based optimisations, but I'm fairly sure that, when it comes to scheduling, it would be better to have a balanced tree, so sched has more choices about what to schedule next? I think this would depend on the target architecture and instruction set: CISC vs RISC, many registers vs few registers, etc. I do not believe that GCC intentionally is trying to optimize for either, but I do not think there is a single, right answer. David Hmm, GCC currently does tree reassociation in order to unbalance the tree. Apparently this gives better CSE -- see -fno-tree-reassoc R.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Ingo, Thomas and Linus, I know Thomas did a patch to force the -mtune=generic, but just in case gcc decides to do something crazy again, this patch will catch it. Should we try to get this in now? -- Steve On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote: commit c7715fb611c69ac4b7f722a891de08b206fb7686 Author: Steven Rostedt srost...@redhat.com Date: Thu Nov 19 23:41:02 2009 -0500 tracing/x86: Add check to detect GCC messing with mcount prologue Latest versions of GCC create a funny prologue for some functions. Instead of the typical: push %ebp mov%esp,%ebp and$0xffe0,%esp [...] call mcount GCC may try to align the stack before setting up the frame pointer register: push %edi lea0x8(%esp),%edi and$0xffe0,%esp pushl -0x4(%edi) push %ebp mov%esp,%ebp [...] call mcount This crazy code places a copy of the return address into the frame pointer. The function graph tracer uses this pointer to save and replace the return address of the calling function to jump to the function graph tracer's return handler, which will put back the return address. But instead instead of the typical return: mov%ebp,%esp pop%ebp ret The return of the function performs: lea-0x8(%edi),%esp pop%edi ret The function graph tracer return handler will not be called at the exit of the function, but the parent function will call it. Because we missed the return of the child function, the handler will replace the parent's return address with that of the child. Obviously this will cause a crash (Note, there is code to detect this case and safely panic the kernel). The kicker is that this happens to just a handful of functions. And only with certain gcc options. Compiling with: -march=pentium-mmx will cause the problem to appear. But if you were to change pentium-mmx to i686 or add -mtune=generic, then the problem goes away. I first saw this problem when compiling with optimize for size. But it seems that various other options may cause this issue to arise. Instead of completely disabling the function graph tracer for i386 builds this patch adds a check to recordmcount.pl to make sure that all functions that contain a call to mcount start with push %ebp. If not, it will fail the compile and print out the nasty warning: CC kernel/time/timer_stats.o Your version of GCC breaks the function graph tracer Please disable CONFIG_FUNCTION_GRAPH_TRACER Failed function was timer_stats_update_stats The script recordmcount.pl is given a new parameter do_check. If this is negative, the script will only perform this check without creating the mcount caller section. This will be executed for x86_32 when CONFIG_FUNCTION_GRAPH_TRACER is enabled and CONFIG_DYNAMIC_FTRACE is not. If the arch is x86_32 and $do_check is greater than 1, it will perform the check while processing the mcount callers. If $do_check is 0, then no check will be performed. This is for non x86_32 archs and when compiling without CONFIG_FUNCTION_GRAPH_TRACER enabled, even on x86_32. Reported-by: Thomas Gleixner t...@linutronix.de LKML-Reference: alpine.lfd.2.00.0911191423190.24...@localhost.localdomain Signed-off-by: Steven Rostedt rost...@goodmis.org
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On 11/20/2009 09:00 AM, Steven Rostedt wrote: Ingo, Thomas and Linus, I know Thomas did a patch to force the -mtune=generic, but just in case gcc decides to do something crazy again, this patch will catch it. Should we try to get this in now? Sounds like a very good idea to me. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Re: Call func address spill out
On 11/20/2009 04:21 AM, daniel tian wrote: But the question is gcc doesn't know the function symbol_ref 's address before ld taking care. Now there is only one solution I could choose: to force all the function call symbol_ref into register and CALL insn calls the register. But I think this will cost more cpu time while routine is less than 32k space. You know the instruction space is limited, so code size becomes the key point. Can somebody give me some advice? The typical mechanism is to provide enough relocations into the generated code such that the linker can relax the code to the more efficient form. The exact set of relocations that you will need to provide are very dependent on both your ISA and ABI. Typically these relocations mark the insns that perform the load of the address into the register, and mark the call insn that uses the register, and may tie the two relocations together so that you are provided some amount of data flow information in the linker. Grep 'bfd_elf.*_bfd_relax_section' binutils/bfd/*.c shows that there are 26 targets that implement some form of linker relaxation. Have a browse through and get some ideas for how you might want to implement things for your target. Do consider posting your proposed method to the binutils list, so that folks can review your method and give you some feedback. r~
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
On 11/20/2009 11:46 AM, Steven Rostedt wrote: Yes a gcc test suite will help new instances of gcc. But we need to worry about the instances of gcc that people have on their desktops now. This test case will catch the discrepancy between gcc and the function graph tracer. I'm not 100% convince that just adding -mtune=generic will help in all cases. If we miss another instance, then the function graph tracer may crash someone's kernel. Furthermore, for future gcc instances what we really want is the early interception support anyway. -hpa
Re: GCC 4.5 is uncompilable
Piotr Wyderski wrote: Kai Tietz wrote: This error you get is more related to used binutils version.The warning you get looks more like a cripled '-Wl,--tsaware'. Thanks, that looks like a good explanation. Yes, I added this to HEAD recently Which binutils version you are using? $ ld -v GNU ld (GNU Binutils) 2.18.50.20080625 I'll try to upgrade binutils and then repeat the build process. If that doesn't fix it please let me know. BTW I'm currently bootstrapping r.154370 and it's got as far as building the target libraries post stage 3 without any sign of this problem, so you should be ok. cheers, DaveK
Re: Supporting decimal float on additional platforms
Joseph S. Myers jos...@codesourcery.com writes: On Wed, 18 Nov 2009, Rainer Orth wrote: be added on legacy platforms like IRIX and Tru64 UNIX, and even on Solaris probably won't show up until DFP is fully standardized. I'd have expected the Solaris maintainers to care more about whether Solaris customers are asking for DFP support, than about whether it is an ISO/IEC Technical Report Type 2 (as at present - TR 24732:2009 published 2009-01-05) or an International Standard. I wasn't aware of that. Buying the TR from ISO is prohibitive, to I stayed with the (last?) draft, N1312 for now. I've asked the Sun compiler guys about their plans for decimal float support, but no answer so far: http://mail.opensolaris.org/pipermail/tools-compilers/2009-November/000907.html As Janis says, the psABI needs to be aware of decimal floating point, so if there is any group or community for a particular target concerned with its ABI for interoperability between multiple implementations, you should work with them on establishing the ABI for decimal floating point for that target. While the i386 and amd64 psABIs already exist (although I haven't found the i386 specification yet), for SPARC that would be SPARC International, I think. Since I expect neither SGI nor HP to implement decimal float in libc on IRIX 6 or Tru64 UNIX, MIPS and Alpha are irrelevant from my point of view. Much the same applies if anyone wishes to add fixed point (TR 18037) support for more targets. I'll have a look at the last draft (N1169) for now. Right now, only MIPS support is in GCC, so there seems to be less traction so far. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Supporting decimal float on additional platforms
On Fri, 20 Nov 2009, Rainer Orth wrote: Much the same applies if anyone wishes to add fixed point (TR 18037) support for more targets. I'll have a look at the last draft (N1169) for now. Right now, only MIPS support is in GCC, so there seems to be less traction so far. Each of these extensions is aimed at a specific class of programs, and users of such programs are much more likely to use some processors than others - various embedded processors have fixed point instructions of one form or another (not necessarily all mapping neatly to the TR 18037 types), while some Power and S390 processors have hardware support for decimal floating point. The TRs may eventually result in those classes of programs becoming more portable, in which case people might eventually want to include free software using these extensions in general-purpose operating system distributions - which may drive porting the feature as people wish to build those distributions for many different processors - but the limited application domains for these features seem likely to exacerbate the chicken-and-egg effect that applies to any new language feature (no demand for the feature in compilers without applications using it, no applications using it without compilers implementing it). Implementing a feature without having any applications for it is of course one way of addressing that effect, as is implementing a feature you'd like to use yourself in programs you write in future; it seems a fine improvement to the compiler to contribute as long as you work with any ABI maintainers to avoid it causing future compatibility problems. (Though I made decimal floating point work on e500 processors - to eliminate the test failures seen in such configurations given that it's enabled by default for Power GNU/Linux and already worked for other Power processors - it's quite possible that no-one has ever used that functionality other than for testcases. There were no ABI compatibility issues there since e500 uses the same ABI as soft-float Power processors.) Note that the fixed point implementation for MIPS substantially slows down the build of libgcc for MIPS targets because of a huge number of libgcc functions for fixed point that need to be built, so people may not care for their libgcc builds being slowed down for other targets without any applications for the new feature. -- Joseph S. Myers jos...@codesourcery.com
GNU MPFR 2.4.2 Release Candidate 2
The release of GNU MPFR 2.4.2 (andouillette sauce moutarde patch level 2) is imminent. Please help to make this release as good as possible by downloading and testing this second release candidate: http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.xz http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.bz2 http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.gz http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.zip The MD5's: 7abdddf1d476cbe032c7dbe0a4a88413 mpfr-2.4.2-rc2.tar.bz2 def8c961b95f08f052b8e3bd2f8d2f1d mpfr-2.4.2-rc2.tar.gz 5b3ced46cf3c4e2d13dc12e2cdcd49cb mpfr-2.4.2-rc2.tar.xz 2cc5cb31e872a5cb04841a36adc1313f mpfr-2.4.2-rc2.zip The signatures: http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.xz.asc http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.bz2.asc http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.gz.asc http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.zip.asc Sorry for the delay between the first release candidate and the second one. All the problems with the RC1 should now be fixed. Changes from version 2.4.1 to version 2.4.2: - Security fix in formatted output functions (buffer overflow). - Formatted output functions: 6 is now the default value for empty precision field with %Rf. - Better portability of configure script. - Detection of intmax_t and uintmax_t types. - Improved documentation: mpfr_get_z_exp, mpfr_strtofr, mpfr_get_str and formatted output functions. - Improved message in case of assertion failure. - Test coverage: 97.0% lines of code. - Updated tcmp_ld test to really test the long double. - Some documentation files are installed in $docdir. - Removed mpfr_init_cache (unused and undocumented function). - Bug fixes. Please send success and failure reports with ./config.guess output to m...@loria.fr. If no problems are found, GNU MPFR 2.4.2 should be released around 2009-11-30. Regards, -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: GCC 4.5 is uncompilable
On Fri, Nov 20, 2009 at 9:06 PM, Dave Korn dave.korn.cyg...@googlemail.com wrote: Piotr Wyderski wrote: Kai Tietz wrote: This error you get is more related to used binutils version.The warning you get looks more like a cripled '-Wl,--tsaware'. Thanks, that looks like a good explanation. Yes, I added this to HEAD recently Which binutils version you are using? $ ld -v GNU ld (GNU Binutils) 2.18.50.20080625 I'll try to upgrade binutils and then repeat the build process. If that doesn't fix it please let me know. BTW I'm currently bootstrapping r.154370 and it's got as far as building the target libraries post stage 3 without any sign of this problem, so you should be ok. You should add the minimal required binutils version for cycwin to the install section of the manual. Richard.
Re: GNU MPFR 2.4.2 Release Candidate 2
On 11/20/2009 11:58 PM, Vincent Lefevre wrote: The release of GNU MPFR 2.4.2 (andouillette sauce moutarde Humm, not to all tastes... ;) Paolo.
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #8 from sfilippone at uniroma2 dot it 2009-11-20 08:32 --- (In reply to comment #6) Richard Guenther wrote: Well, within eval there's nothing really obvious to me. The innermost loop is exactly the same: But it is a very inefficient way of vectorizing, because the inner loop's body is either executed twice or three times per outer loop (depending on the value of i). While I agree that I would code in a different way, still there is the change in compiler's behaviour. Although comment 7 indicates it's probably only at 64bits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #14 from singler at gcc dot gnu dot org 2009-11-20 09:53 --- Created an attachment (id=19064) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19064action=view) Functional patch for parallel fill and fill_n. -- singler at gcc dot gnu dot org changed: What|Removed |Added Attachment #19053|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #15 from singler at gcc dot gnu dot org 2009-11-20 09:56 --- There is slowdown, also for large inputs, for the most simple case, namely filling constant integer values. If assignment is more expensive, thing will get better. Please try with your application. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2009-01-16 15:51:05 |2009-11-20 09:56:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug c++/29017] %s substituted with different untranslated words can't be properly translated
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-20 10:05 --- Subject: Bug 29017 Author: paolo Date: Fri Nov 20 10:05:37 2009 New Revision: 154360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154360 Log: /cp 2009-11-20 Shujing Zhao pearly.z...@oracle.com PR c++/29017 * cp-tree.h (composite_pointer_operation): New type. (composite_pointer_type): Adjust prototype with new argument. * typeck.c (composite_pointer_type): Accept composite_pointer_operation as argument and emit diagnostic to be visible to gettext and checked at compile time. (composite_pointer_type_r): Likewise. (common_pointer_type): Update call to composite_pointer_type. (cp_build_binary_op): Likewise. * call.c (build_conditional_expr): Likewise. /testsuite 2009-11-20 Shujing Zhao pearly.z...@oracle.com * g++.old-deja/g++.jason/rfg20.C: Make expected dg-error strings explicit. * g++.old-deja/g++.rfg/00321_01-.C: Likewise. * g++.old-deja/g++.rfg/00324_02-.C: Likewise. * g++.old-deja/g++.law/typeck1.C: Likewise. * g++.old-deja/g++.bugs/900324_02.C: Likewise. * g++.dg/conversion/ptrmem9.C: Likewise. * g++.dg/expr/cond2.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/conversion/ptrmem9.C trunk/gcc/testsuite/g++.dg/expr/cond2.C trunk/gcc/testsuite/g++.old-deja/g++.bugs/900324_02.C trunk/gcc/testsuite/g++.old-deja/g++.jason/rfg20.C trunk/gcc/testsuite/g++.old-deja/g++.law/typeck1.C trunk/gcc/testsuite/g++.old-deja/g++.rfg/00321_01-.C trunk/gcc/testsuite/g++.old-deja/g++.rfg/00324_02-.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #3 from ubizjak at gmail dot com 2009-11-20 10:06 --- Both files compile OK with 4.5 cross from x86_64-pc-linux-gnu. Probably a target specific patch should be backported from mainline to 4.3 and 4.4 branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c++/29017] %s substituted with different untranslated words can't be properly translated
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-20 10:07 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #4 from ubizjak at gmail dot com 2009-11-20 10:42 --- Confirmed with 4.4 cross. -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 10:42:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug rtl-optimization/42116] New: ice on valid code (unrecognizable insn)
Compiling an ARC cross compiler gives ICE: [lu...@localhost gcc]$/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/xgcc -v -save-temps -B/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/ -nostdinc -B/home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/ -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include -B/opt/arc-tools/arc-elf32/bin/ -B/opt/arc-tools/arc-elf32/lib/ -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ../../src/gcc/config/arc/gmon -O2 -Wall -g -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mno-sdata -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -c -o gmon.o ../../src/gcc/config/arc/gmon/gmon.c -Wno-extra # suppress inane warning about missing initializer. Reading specs from /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/specs Target: arc-elf32 Configured with: ../src/configure --prefix=/opt/arc-tools --target=arc-elf32 --program-prefix=arc- --with-build-time-tools=/opt/arc-tools/bin --with-newlib --with-headers --enable-multilib --enable-languages=c,c++ Thread model: single gcc version 4.2.1 (ARC_2.2) /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/cc1 -E -quiet -nostdinc -v -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -iprefix /home/luben/ware/arc_gcc_rel2.2/gcc/build/gcc/../lib/gcc/arc-elf32/4.2.1/ -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/include -D__A5__ -DIN_GCC -DCROSS_COMPILE -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ../../src/gcc/config/arc/gmon -isystem ./include ../../src/gcc/config/arc/gmon/gmon.c -mno-sdata -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-extra -fworking-directory -O2 -fpch-preprocess -o gmon.i ignoring nonexistent directory /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include ignoring nonexistent directory /opt/arc-tools/arc-elf32/include ignoring nonexistent directory /opt/arc-tools/arc-elf32/sys-include ignoring duplicate directory ./include ignoring duplicate directory . ignoring duplicate directory ../../src/gcc/. #include ... search starts here: #include ... search starts here: . ../../src/gcc ../../src/gcc/../include ../../src/gcc/../libcpp/include ../../src/gcc/../libdecnumber ../libdecnumber /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/include /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include ../../src/gcc/config/arc/gmon End of search list. /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/cc1 -fpreprocessed gmon.i -quiet -dumpbase gmon.c -mno-sdata -auxbase-strip gmon.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-extra -version -o gmon.s GNU C version 4.2.1 (ARC_2.2) (arc-elf32) compiled by GNU C version 4.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4a0a315b8c704b68e64bbad6f09259fc ../../src/gcc/config/arc/gmon/gmon.c: In function '__monstartup': ../../src/gcc/config/arc/gmon/gmon.c:197: error: unrecognizable insn: (insn 38 37 39 3 ../../src/gcc/config/arc/gmon/gmon.c:137 (set (reg:SI 180) (const_int -1 [0x])) -1 (nil) (nil)) ../../src/gcc/config/arc/gmon/gmon.c:197: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ice on valid code (unrecognizable insn) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltuikov at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #1 from ltuikov at yahoo dot com 2009-11-20 10:56 --- Created an attachment (id=19065) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19065action=view) Preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #2 from ltuikov at yahoo dot com 2009-11-20 10:57 --- Created an attachment (id=19066) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19066action=view) Assembly output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 10:58 --- Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 10:58:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] |Internal Compiler error with|Internal Compiler error with |-O3, breaking commit known |-O3, breaking commit known Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-20 11:01 --- GCC 4.2 is no longer maintained, please try a newer release. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arc-elf32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug c++/42060] [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 11:14:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #4 from ltuikov at yahoo dot com 2009-11-20 11:24 --- The source I'm trying to compile I got directly from arc. I'll try 4.4.2 from GNU. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug middle-end/41883] [4.5 Regression] ICE from '-O -fprofile-arcs -fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks'
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-20 12:23
---
Confirmed. Reduced testcase (crashes with -fprofile-arcs
-fsched2-use-superblocks -fschedule-insns2 -freorder-blocks -O):
int foo(int i)
{
if (i)
return 0;
__builtin_alloca(4);
return 0;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2009-11-20 12:23:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
[Bug tree-optimization/42117] New: VRP fails to get rid of compares
The vrp47 testcase currently fails on i386 and S/390. The ssa code before vrp
looks different for both compared to x86_64 due to a different value
returned by BRANCH_COST. (Branches on S/390 are relatively cheap due
to a sophisticated branch prediction unit.) Therefore during
gimplification fold_truthop (line 5866) uses more branches for
function h in vrp47.c than the x86_64 variant.
The problem can also be reproduced on x86 when compiling for a cpu with low
branch costs defined in i386.c as e.g. -march=i386.
int h(int x, int y)
{
if ((x = 0 x = 1) (y = 0 y = 1))
return x y;
else
return -1;
}
Compile the testcase above with:
cc1 -m32 -O2 vrp47.c -fdump-tree-vrp -march=i386
The vrp pass is not able to get rid of the comparisons in this case
(069t.vrp1 from i386):
h (int x, int y)
{
int D.2021;
unsigned int y.1;
unsigned int x.0;
bb 2:
x.0_4 = (unsigned int) x_3(D);
if (x.0_4 = 1)
goto bb 3;
else
goto bb 7;
bb 3:
y.1_6 = (unsigned int) y_5(D);
if (y.1_6 = 1)
goto bb 4;
else
goto bb 7;
bb 4:
if (x_3(D) != 0)
goto bb 5;
else
goto bb 6;
bb 5:
if (y_5(D) != 0)
goto bb 7;
else
goto bb 6;
bb 6:
bb 7:
# D.2021_1 = PHI 0(6), -1(3), -1(2), 1(5)
return D.2021_1;
}
--
Summary: VRP fails to get rid of compares
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krebbel at gcc dot gnu dot org
GCC build triplet: i386-gnu-linux, s390x-ibm-linux
GCC host triplet: i386-gnu-linux, s390x-ibm-linux
GCC target triplet: i386-gnu-linux, s390x-ibm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42117
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #5 from ubizjak at gmail dot com 2009-11-20 12:58 ---
This reduced testcase fails also on 4.5:
--cut here--
int make_file (int a, int b)
{
int foo = a * sizeof (int);
if (b)
foo += sizeof (int);
return foo;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug tree-optimization/42117] VRP should do if-conversion
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 13:12 ---
Confirmed. We do see
x_2: [0, 1] EQUIVALENCES: { x_3(D) } (1 elements)
y_11: [0, 1] EQUIVALENCES: { y_5(D) } (1 elements)
but have no code that actually makes use of this information in
bb 4:
if (x_3(D) != 0)
goto bb 5;
else
goto bb 6;
bb 5:
if (y_5(D) != 0)
goto bb 7;
else
goto bb 6;
bb 6:
bb 7:
# D.2047_1 = PHI 0(6), -1(3), -1(2), 1(5)
return D.2047_1;
which we want to if-convert to
bb 4:
tmp = x_3 y_5;
bb 7:
# D.2047_1 = PHI tmp(4), -1(3), -1(2)
but there is no code in VRP that does if-conversion.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-20 13:12:34
date||
Summary|VRP fails to get rid of |VRP should do if-conversion
|compares|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42117
[Bug fortran/42118] New: Slow forall
I think that forall statement must be at least as fast as equivalent do- -end do construction. But the next program (variant of LU-decomposition) shows that fragment containing forall statement is approximately at 2.5(!) times slower then fragment with do-end do. program test implicit none integer, parameter :: n = 2000 integer i, j double precision, dimension (n, n) :: a, a1 double precision, dimension (n) :: work real time_begin, time_end integer, dimension(1) :: max_loc intrinsic random_number, maxloc, CPU_TIME call random_number(a) a1=a CALL CPU_TIME(time_begin) do i = 1, n-1 max_loc = maxloc(abs(a(i:,i))) j = max_loc(1) + i - 1 if (a(j,i) == 0.0) stop 'Zero pivot' if (i /= j) then work(i:n) = a(i,i:n) a(i,i:n) = a(j,i:n) a(j,i:n) = work(i:n) end if a(i+1:,i) = a(i+1:,i) / a(i,i) do j = i+1, n a(i+1:,j) = a(i+1:,j) - a(i,j) * a(i+1:,i) end do end do CALL CPU_TIME(time_end) print *, 'Time of operation was ', time_end - time_begin, ' seconds' a=a1 CALL CPU_TIME(time_begin) do i = 1, n-1 max_loc = maxloc(abs(a(i:,i))) j = max_loc(1) + i - 1 if (a(j,i) == 0.0) stop 'Zero pivot' if (i /= j) then work(i:n) = a(i,i:n) a(i,i:n) = a(j,i:n) a(j,i:n) = work(i:n) end if a(i+1:,i) = a(i+1:,i) / a(i,i) forall (j = i+1:n) a(i+1:,j) = a(i+1:,j) - a(i,j) * a(i+1:,i) end do CALL CPU_TIME(time_end) print *, 'Time of operation was ', time_end - time_begin, ' seconds' end program test GCC version 4.4.2. Windows Vista SP2, CPU: Intel Core 2 Quad Q6600, RAM: 3 GB Gfortran O3 file_name.f95 -- Summary: Slow forall Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gretsov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #6 from ubizjak at gmail dot com 2009-11-20 13:40 ---
Created an attachment (id=19067)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19067action=view)
patch to fix mode of scratch register in *cmp_s{add,sub}_si{,di}
This patch fixes wrong modes of scratch register in *cmp_s{add,sub}_si{,di}
patterns.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #9 from dominiq at lps dot ens dot fr 2009-11-20 13:45 --- I am rather confused by some comments: (1) Although I am not fluent with x86 assembly, I am pretty sure that no code in eval is vectorized (assembly taken from this pr or from the original post http://gcc.gnu.org/ml/fortran/2009-11/msg00163.html). (2) If I am not mistaken, the k loop always handle 3 elements for i, i+n, and i+2*n. (3) On a core2duo 2.1Ghz, I only see small changes in the timing between 4.3.4 to trunk, -O1 to -O3, and 32 or 64 bit mode. Now if I do the following change: --- pr42108_1_db.f902009-11-20 14:14:05.0 +0100 +++ pr42108_1_db_1.f90 2009-11-20 14:15:24.0 +0100 @@ -7,12 +7,10 @@ subroutine eval(foo1,foo2,foo3,foo4,x,n do i=2,n foo3(i)=foo2*foo4(i) do j=1,i-1 - temp=0.0d0 - jmini=j-i - do k=i,nnd,n -temp=temp+(x(k)-x(k+jmini))**2 - end do - temp = sqrt(temp+foo1) + temp = sqrt( (x(i) - x(j))**2 + +(x(i+n) - x(j+n))**2 + +(x(i+2*n)-x(j+2*n))**2 + +foo1) foo3(i)=foo3(i)+temp*foo4(j) foo3(j)=foo3(j)+temp*foo4(i) end do I go from 9.2s to 5.5s for n=2. So the k loop is not automatically unrolled even with -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #10 from sfilippone at uniroma2 dot it 2009-11-20 14:03 --- (In reply to comment #9) I am rather confused by some comments: (1) Although I am not fluent with x86 assembly, I am pretty sure that no code in eval is vectorized (assembly taken from this pr or from the original post http://gcc.gnu.org/ml/fortran/2009-11/msg00163.html). (2) If I am not mistaken, the k loop always handle 3 elements for i, i+n, and i+2*n. Yup, in the test case, in the original application the factor might be different from 3. And yes, it may be better to declare the array as 2D -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/42118] Slow forall
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 14:03 --- Confirmed. GFortran seems to split the loops differently and uses a larger temporary for the forall case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 14:03:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #11 from sfilippone at uniroma2 dot it 2009-11-20 14:12 --- (In reply to comment #10) Again, I am no asking for help in writing a better code (I think I know how to handle this, and I will convince my colleague), I just thought it was worth mentioning that the optimizer has apparently done a worse job lately (at least on the platform I am using). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-11-20 14:13
---
The loop is not unrolled because the frontend presents us with very funny
obfuscated code:
do k=i,nnd,n
temp=temp+(x(k)-x(k+jmini))**2
end do
gets translated to
{
character(kind=4) countm1.6;
integer(kind=4) D.1551;
integer(kind=4) D.1550;
integer(kind=4) D.1549;
D.1549 = i;
D.1550 = *nnd;
D.1551 = *n;
k = D.1549;
if (D.1551 0)
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 -
D.1549) / (character(kind=4)) D.1551;;
}
else
{
if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 -
D.1550) / (character(kind=4)) -D.1551;;
}
while (1)
{
{
real(kind=8) D.1556;
real(kind=8) D.1555;
D.1555 = (((*x)[(integer(kind=8)) k + -1] - (*x)[(integer(kind=8)) (k
+ jmini) + -1]));
D.1556 = D.1555 * D.1555;
temp = temp + D.1556;
}
L.5:;
k = k + D.1551;
if (countm1.6 == 0) goto L.6;
countm1.6 = countm1.6 + 4294967295;
}
L.6:;
}
WTF!?
The funny conditional initialization of countm1.6 makes the analysis of
the number of iterations of this loop impossible (not to mention the
conversions to character(kind=4)).
Why does the frontend do induction variable optimization at all and
not simply generate a loop with a non-unit counting IV?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #23 from yipiha2008 at gmail dot com 2009-11-20 14:16 --- Forget #22, as expected it does not work (kernel compiled with a patched GCC as per #22 does not boot) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42118] Slow forall
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-20 14:20 --- (In reply to comment #0) I think that forall statement must be at least as fast as equivalent do- -end do construction. The Fortran standardization committee thought likewise, however, as it turned out in practice, it is sometimes not trivial for the compiler to see whether there is any dependence on the RHS (right-hand side) with regards to the LHS and thus it might use a temporary array even if none is needed - and temporary arrays are slow (and memory hungry). Thus, a DO loop should be always faster or as fast as a FORALL (assignment) statement (unless, one does something really stupid in the DO loop). [At least that is what I gathered from the comments at comp.lang.fortran and which matches my knowledge regarding how it is done in gfortran.] Having said that, gfortran still should try to make your program as fast for FORALL as it is for the DO loop. But the next program (variant of LU-decomposition) shows that fragment containing forall statement is approximately at 2.5(!) times slower then fragment with do-end do. You could check using -fdump-tree-original how the two versions are handled; my guess is that the FORALL version uses a temporary array. (-fdump-tree-original creates a file.f90.004* which contains a dump of the internal representation of your code, which looks similar to C.) Seemingly, Richard already looked at the dump and confirmed my suspicion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug fortran/42112] overloaded function with allocatable result problem
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-20 14:22 ---
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = gen_g() ! does not work
That looks OK if gen_g returns a size-1 array or a scalar - and with Fortran
2003 it should also be valid if the array has a different size (automatic
(re)allocation on assignment).
generates
f ()
{
g (loc_ar);
}
loc_ar has been allocated and the pointer to it is passed
to g() where is becomes associated with the result variable j.
You then try to allocate j, which is already allocated.
That sounds completely wrong for Fortran 95 but also for 2003. There is
absolutely no valid reason to mess around with the LHS argument, i.e.
C_LOC(loc_ar(1)) should be the same before and after the assignment (unless in
F2003 if the array size of LHS/RHS does not match or if loc_ar was before not
allocated).
To me it sounds as if there is the problem that the attributes of the specific
function belonging to the generic function are not properly used.
That is: expr-symtree-n.sym-attr vs. expr-value.function.esym-attr. (Cf.
PR 41777 )
--
burnus 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 |2009-11-20 14:22:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug c/42098] gcc does not honor alignment specification, gives different alignment than g++
--- Comment #2 from jepler at unpythonic dot net 2009-11-20 14:45 --- (In reply to comment #0) Given the declaration: typedef volatile double D __attribute__((aligned(16))); That should have been aligned(8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098
[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result
--- Comment #8 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41919 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41919
[Bug c++/42055] [4.5 Regression] ICE with ambiguous template specialization
--- Comment #3 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 42055 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug c/41935] [4.4/4.5 Regression] ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41935 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41935
[Bug fortran/41907] [4.5 Regression] 465.tonto in SPEC CPU 2006 runtime failure
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41907 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41907
[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41926 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41928 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41928
[Bug tree-optimization/41841] segfault using '-O -fipa-cp -fipa-struct-reorg -fwhole-program -fprofile-generate'
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41841 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41841
[Bug tree-optimization/41750] [4.5 Regression] IPA-SRA is broken
--- Comment #27 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41750 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #24 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-20 15:07 --- I do not think that the non working kernel is caused by the patch, but that there are yet more regressions for the iwmmxt arch and that this arch has never been tested with gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42119] New: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
Test file (Test.f90): - module Test use ISO_C_BINDING contains subroutine Callback(arg) bind(C) integer(C_INT) :: arg end subroutine Callback subroutine Check(proc) type(C_FUNPTR) :: proc end subroutine Check end module Test program Main use Test type(C_FUNPTR) :: proc call Check(C_FUNLOC(Callback)) ! This works fine: ! proc = C_FUNLOC(Callback) ! call Check(proc) end program Main - Compiler output: - sm...@ubuntu:~/Code$ gfortran -v Test.f90 Driving: gfortran -v Test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8' --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-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/f951 Test.f90 -quiet -dumpbase Test.f90 -mtune=generic -auxbase Test -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.4.1/finclude -o /tmp/ccn1uZ8e.s GNU Fortran (Ubuntu 4.4.1-4ubuntu8) version 4.4.1 (x86_64-linux-gnu) compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Test.f90: In function main: Test.f90:21: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. -- Summary: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nvab at ibrae dot ac dot ru GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec
-- brunorex at gmail dot com changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 15:33 --- Confirmed. Sth as simple as Index: gcc/expr.c === --- gcc/expr.c (revision 154364) +++ gcc/expr.c (working copy) @@ -6834,7 +6834,8 @@ expand_expr_addr_expr_1 (tree exp, rtx t /* ??? This should be considered a front-end bug. We should not be generating ADDR_EXPR of something that isn't an LVALUE. The only exception here is STRING_CST. */ - if (CONSTANT_CLASS_P (exp)) + if (CONSTANT_CLASS_P (exp) + || (TREE_CODE (exp) == ADDR_EXPR TREE_CONSTANT (exp))) return XEXP (expand_expr_constant (exp, 0, modifier), 0); /* Everything must be something allowed by is_gimple_addressable. */ might fix it, though the recursion in this function for CONST_DECLs make it a bit convoluted to call it obvious. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-11-20 15:33:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #25 from yipiha2008 at gmail dot com 2009-11-20 15:45 --- Further tests show that you're right about the non working kernel. Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would make it clear that this arch is untested/not supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-20 15:51 --- The runtime problem and the obsolete comment in the manual are fixed now. So the only issue left is the wrong static declaration reported in comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug c++/42121] New: g++ should warn or error on internal 0 size array in struct
Currently g++ requires the -pedantic flag to give a warning on a zero sized
array that is not the last field in a struct. As far as I can see, this is
actually always a significant error if it is not the trailing field in the
struct...
Demonstration:
temp(510)$ cat zero-size-array.cpp
#include iostream
#include cstddef
struct bogus
{
int a;
char b[];
int c;
} bogus;
int main(void)
{
std::cout size of struct bogus = sizeof(bogus) std::endl;
std::cout offset of field b = offsetof(struct bogus, b)
std::endl;
std::cout offset of field c = offsetof(struct bogus, b)
std::endl;
return 0;
}
temp(511)$ g++ -Wall -o zero-size-array
zero-size-array.cppsize-array.cppe-array.cpp
temp(512)$ zero-size-array
size of struct bogus =8
offset of field b =4
offset of field c =4
temp(513)$ g++ -Wall -pedantic -o zero-size-array
zero-size-array.cppize-array.cpp
zero-size-array.cpp:7: error: ISO C++ forbids zero-size array 'b'
temp(514)$ g++ --version
g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)
-David
--
Summary: g++ should warn or error on internal 0 size array in
struct
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot resnick at comverse dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug bootstrap/42093] bootstrap hangs in stage2 run of build/gengtype
--- Comment #2 from ramana at gcc dot gnu dot org 2009-11-20 16:00 --- (In reply to comment #1) only seen when configuring with --with-mode=thumb, disabling scheduling for thumb2 shows the same endless loop. Confirmed unless there's a miscompilation in libc that we are missing. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 16:00:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug c++/42060] [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
--- Comment #1 from paolo at gcc dot gnu dot org 2009-11-20 16:03 --- Subject: Bug 42060 Author: paolo Date: Fri Nov 20 16:03:19 2009 New Revision: 154371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154371 Log: cp/ 2009-11-20 Paolo Carlini paolo.carl...@oracle.com PR c++/42060 * except.c (build_throw): Check the tree returned by decay_conversion for error_mark_node. testsuite/ 2009-11-20 Paolo Carlini paolo.carl...@oracle.com PR c++/42060 * g++.dg/cpp0x/initlist28.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug c++/42060] [4.4 Regression] [c++0x] ICE throwing array with initializer list
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-20 16:05 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.4/4.5 Regression] [c++0x]|[4.4 Regression] [c++0x] ICE |ICE throwing array with |throwing array with |initializer list|initializer list Target Milestone|4.4.3 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug fortran/42122] New: -fdump-tree-original shows wrong static decl for functions with procptr argument
Follow-up to PR42072. Consider this simple program:
contains
subroutine setpointer (p)
procedure(), pointer :: p
end subroutine
end
Compiling this with -fdump-tree-original shows:
setpointer (void (*T62) (void) * p)
{
(void) 0;
}
MAIN__ ()
{
static void setpointer (void (*T62) (void));
(void) 0;
}
As one can see, the static declaration inside MAIN__ differs from the actual
declaration of 'setpointer'.
--
Summary: -fdump-tree-original shows wrong static decl for
functions with procptr argument
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-20 16:08 --- (In reply to comment #7) So the only issue left is the wrong static declaration reported in comment #3. This is now PR 42122. Closing this one. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug target/42123] New: dll{im,ex}port attributes don't (yet) work on namespaces.
As per subject, the dll attributes can't be applied to c++ namespaces - this in
fact applies to all windows platforms, not just cygwin. This would be a
desirable mechanism for eliminating the use of auto-import by using explicit
dllimport attributes, without having to uglify every header in the whole
library to do so.
--
Summary: dll{im,ex}port attributes don't (yet) work on
namespaces.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug target/42123] dll{im,ex}port attributes don't (yet) work on namespaces.
--- Comment #1 from davek at gcc dot gnu dot org 2009-11-20 16:11 --- Created an attachment (id=19068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19068action=view) work-in-progress This patch is a bit overly keen in how far it propagates dllimport, leading to the regression of g++.dg/ext/dllimport8.C without even using -D_GLIBCXX_IMPORT. (This is the old don't-import-a-static-class-member-if-you've-seen-a-definition issue.) So, not ready for primetime just yet... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug target/42123] dll{im,ex}port attributes don't (yet) work on namespaces.
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 16:11:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #6 from olga at gcc dot gnu dot org 2009-11-20 16:57 --- Subject: Bug 39960 Author: olga Date: Fri Nov 20 16:57:35 2009 New Revision: 154374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154374 Log: 2009-11-17 Olga Golovanevsky o...@il.ibm.com PR middle-end/39960 * ipa-struct-reorg.c (find_pos_in_stmt): New parameter. (ref_pos): New field in structure. (insert_new_var_in_stmt): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-struct-reorg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #10 from sje at cup dot hp dot com 2009-11-20 16:59 --- Does freebsd use glibc? Does freebsd have a system libunwind? I am going to guess yes to the first question and no to the second in which case you need to edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file list. That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-20 17:10 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED macro on __gthread_mutex_destroy argument. It is perfectly fine on __gthread_key_delete. You're right, of course. I should have looked closer. Testing and comparison with pthread results found two other bugs, one of which I could already fix in gthr-solaris.h. I've tried to debug the other (objc) testcase, but gdb 6.6 cannot fully handle it, and I couldn't yet get a gdb 7.0 to debug a 64-bit binary. Given that this is a bootstrap failure, I'll submit and install the fix now and check the remainder later. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #11 from ro at gcc dot gnu dot org 2009-11-20 17:17 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC|ro at techfak dot uni- | |bielefeld dot de| AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 17:17:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug fortran/42045] [F03] passing a procedure pointer component to a procedure pointer dummy
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-20 17:24 ---
With this patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154369)
+++ gcc/fortran/resolve.c (working copy)
@@ -1321,6 +1321,8 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p
e-rank = comp-as-rank;
e-expr_type = EXPR_FUNCTION;
}
+ if (gfc_resolve_expr (e) == FAILURE)
+ return FAILURE;
goto argument_list;
}
@@ -2519,6 +2521,10 @@ resolve_function (gfc_expr *expr)
if (expr-symtree)
sym = expr-symtree-n.sym;
+ /* If this is a procedure pointer component, it has already been resolved.
*/
+ if (gfc_is_proc_ptr_comp (expr, NULL))
+return SUCCESS;
+
if (sym sym-attr.intrinsic
resolve_intrinsic (sym, expr-where) == FAILURE)
return FAILURE;
@@ -10219,8 +10225,9 @@ resolve_fl_derived (gfc_symbol *sym)
}
else if (c-attr.proc_pointer c-ts.type == BT_UNKNOWN)
{
- c-ts = *gfc_get_default_type (c-name, NULL);
- c-attr.implicit_type = 1;
+ /* Since PPCs are not implicitly typed, a PPC without an explicit
+interface must be a subroutine. */
+ gfc_add_subroutine (c-attr, c-name, c-loc);
}
/* Procedure pointer components: Check PASS arg. */
the only remaining regression is proc_ptr_comp_2.f90, which is invalid with
respect to the interpretation in
http://www.j3-fortran.org/doc/year/09/09-236r1.txt.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-20 17:24:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42045
[Bug target/42081] big-endian arm MULTILIB_DEFAULTS hard-coded to little-endian
--- Comment #1 from tom at giftssoft dot com 2009-11-20 17:26 ---
It looks like this bug is related to bug 16350, which was created on 2004-07-03
and resulted in patch 800-arm-bigendian.patch being applied on 2007-11-07 to
gcc 4.3.0. Prior to this patch, gcc defaulted to little-endian mode on both
big-endian and little-endian arm targets, and had to be explicitly told to
compile in big-endian mode. This patch modified gcc to detault to big-endian
mode on big-endian arm targets and little-endian mode on littlr-endian arm
targets. However, the hunk of the patch that replaced:
{ marm, mlittle-endian, mhard-float, mno-thumb-interwork }
with:
{ marm, TARGET_ENDIAN_OPTION, mhard-float, mno-thumb-interwork }
was somehow not applied. Therefore, this bug can be restated as follows:
The patch to resolve bug 16350 was only partially applied and resulted in an
inconsistent linux-elf.h file in which part of it still assumes little-endian
on all arm targets (the old behavor) and part of it assumes big-endian on
big-endian arm targets (the new behavior).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #16 from ro at gcc dot gnu dot org 2009-11-20 17:53 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-06-17 19:42:47 |2009-11-20 17:53:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #2 from mikael at gcc dot gnu dot org 2009-11-20 17:59 --- This is the same as PR 38530 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug fortran/38530] ICE with the example for c_funloc
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 --- *** Bug 42119 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nvab at ibrae dot ac dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 --- *** This bug has been marked as a duplicate of 38530 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-20 18:09 --- Looks like this is for compatibility with GNU C, which allows it, but only in the form char b[0] not char b[] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-20 18:10 --- (In reply to comment #10) Does freebsd use glibc? Does freebsd have a system libunwind? I am going to guess yes to the first question and no to the second in which case you need to edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file list. That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to no. FreeBSD does not use glibc; never has and never will. FreeBSD does not have a libunwind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
-- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg01115.html Target Milestone|4.4.3 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #2 from david dot resnick at comverse dot com 2009-11-20 18:38 --- (In reply to comment #1) Looks like this is for compatibility with GNU C, which allows it, but only in the form char b[0] not char b[] b[] seems simply broken unless last in an array for the C99 flexible array member type stuff, no? I'm not really convinced about the merits/utility of b[0] as an internal struct field either, it is an odd way to make a union maybe? In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, per constraint in section 6.7.5.2 indicating: Constraints [#1] The [ and ] may delimit an expression or *. If [ and ] delimit an expression (which specifies the size of an array), it shall have an integer type. If the expression is a constant expression then it shall have a value greater than zero. The element type shall not be an incomplete or function type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 18:49 --- (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #4 from david dot resnick at comverse dot com 2009-11-20 18:56 --- (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. -David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-11-20 18:59 --- I have some additional comments from the dsymutils maintainer... 7397601 is a bug in dsymutils. It was not handling the case when the dwarf debug info contained an AT_location with form DW_FORM_block1 with zero length. It may also be possible to have the compiler not emit that as a work around. Clarification: The fix was made for any block form (DW_FORM_block1, DW_FORM_block2, DW_FORM_block4, DW_FORM_block) variant that had zero length. One other question. Does dwarf debug info on an AT_location with form DW_FORM_block1 that has zero length have any real meaning or is that likely just accidental noise on the dwarf debug output? It is probably accidental noise, or a bug. The variable should be checked to make sure it really doesn't have a location, and if it doesn't just don't emit the DW_AT_location attribute. If it does have a valid location, then a lenght of zero is probably a bug. If zero length dwarf debug info, is either invalid or effectively a noop, we may just be suffering from the fact binutils is immune to such flaws in the dwarf output. Then, darwin might actually be useful in helping identify bogus dwarf info being emitted. Thanks in advance for any clarifications. I have modified dwarfdump to properly dump the information and I did check the DWARF spec, and it seems that it is ok to have DW_FORM_blockXXX forms with zero length, so it isn't invalid DWARF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42124] New: warning: array subscript is below array bounds
CPP code:
#include malloc.h
#include errno.h
const int INT_INVALID = 0x8000;
template class T, int N class TOPLIST
{
int ind[N], n, lim;
T vals[N];
public:
TOPLIST() { n = 0; lim = N; }
void reset() { n = 0; }
void add(int index, T value)
{
int m;
if(n==lim) { if(vals[n-1]=value) return; } else n++;
for(m=n-1; m0 vals[m-1]value; m--) {
vals[m] = vals[m-1];
ind[m] = ind[m-1];
}
vals[m] = value;
ind[m] = index;
}
T val(int index) {
if(index0 || index=n) return T(0);
else return vals[index];
}
int indx(int index) {
if(index0 || index=n) return INT_INVALID;
else return ind[index];
}
bool IsValid(void) const { return n0; }
};
const char C39PAT[4][11] = {
0111221211, 121122, 211222, 321221
};
int ReadC39()
{
TOPLISTint, 3 T;
int c;
for(c=0; c4; c++) T.add(c, c);
for(c=0; c4; c++)
if(C39PAT[c][T.indx(0)+1]=='2')
break;
return (c4) ? C39PAT[c][0] : '?';
}
int main()
{
return 0;
}
Command which produces the above mentioned warning:
g++ -v --save-temp xxx.cpp -O3 -Wall
And the *.ii files.
# 1 xxx.cpp
# 1 built-in
# 1 command-line
# 1 xxx.cpp
# 1 /usr/include/malloc.h 1 3 4
# 24 /usr/include/malloc.h 3 4
# 1 /usr/include/features.h 1 3 4
# 347 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 353 /usr/include/sys/cdefs.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 354 /usr/include/sys/cdefs.h 2 3 4
# 348 /usr/include/features.h 2 3 4
# 371 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 5 /usr/include/gnu/stubs.h 2 3 4
# 1 /usr/include/gnu/stubs-32.h 1 3 4
# 8 /usr/include/gnu/stubs.h 2 3 4
# 372 /usr/include/features.h 2 3 4
# 25 /usr/include/malloc.h 2 3 4
# 1 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 1 3 4
# 149 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 3 4
typedef int ptrdiff_t;
# 211 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 3 4
typedef unsigned int size_t;
# 26 /usr/include/malloc.h 2 3 4
# 1 /usr/include/stdio.h 1 3 4
# 30 /usr/include/stdio.h 3 4
extern C {
# 1 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 1 3 4
# 35 /usr/include/stdio.h 2 3 4
# 1 /usr/include/bits/types.h 1 3 4
# 28 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/wordsize.h 1 3 4
# 29 /usr/include/bits/types.h 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 131 /usr/include/bits/types.h 3 4
# 1 /usr/include/bits/typesizes.h 1 3 4
# 132 /usr/include/bits/types.h 2 3 4
__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef void * __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;
__extension__ typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 /usr/include/stdio.h 2 3 4
# 45 /usr/include/stdio.h 3 4
struct _IO_FILE;
typedef struct _IO_FILE FILE;
# 65 /usr/include/stdio.h 3 4
[Bug c++/42124] warning: array subscript is below array bounds
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-20 19:12 --- D.2919_10 = C39PAT[0][-2147483647]; Well there is an array subscript is below array bounds. It is hard for GCC to figure out that is dead code really without full unrolling ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42124
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #13 from toon at moene dot org 2009-11-20 19:45 --- The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Why does the frontend do induction variable optimization at all and not simply generate a loop with a non-unit counting IV? It's not trying to be funny - it just follows the text of the Fortran Standard (hey, what a concept !): 12 8.1.6.6.1Loop initiation 13 1 When the DO statement is executed, the DO construct becomes active. If loop-control is 14 2 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 15 3 the following steps are performed in sequence. 16 (1)The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter m3 are 17 of type integer with the same kind type parameter as the do-variable. Their values are established 18 by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , respectively, including, if ne- 19 cessary, conversion to the kind type parameter of the do-variable according to the rules for numeric 20 conversion (Table 7.11). If scalar-int-expr 3 does not appear, m3 has the value 1. The value of m3 21 shall not be zero. 22 (2)The DO variable becomes defined with the value of the initial parameter m1 . 23 (3)The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , unless that 24 value is negative, in which case the iteration count is 0. Only interprocedural analysis can tell us that this is a simple loop only executed 3 times (I got this wrong at first - it's *always* executed 3 times). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c++/42124] warning: array subscript is below array bounds
--- Comment #2 from djszapi at archlinux dot us 2009-11-20 19:59 --- (In reply to comment #1) D.2919_10 = C39PAT[0][-2147483647]; Well there is an array subscript is below array bounds. It is hard for GCC to figure out that is dead code really without full unrolling ... If you look at the code you can see 'there is an array subscript is below array bounds' situation can't be occured! So it's a gcc bug I think so definetely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42124
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #5 from joseph at codesourcery dot com 2009-11-20 20:57 --- Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c/42097] Reference operator () error from included file.
--- Comment #4 from bradhomer at gbis dot com 2009-11-20 21:20 --- Subject: Re: Reference operator () error from included file. Thank you. The code I submitted for the bug has worked for years in the world of Borland. Obviously not so good in the world of linux. Again thank you for your help. Brad On 19 Nov 2009 19:12:36 -, pinskia at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 19:12 --- Take a look at The C Programming Language by Kernighan and Ritchie, chapter 5. But this is not a reference operator at this point. It is for a reference type. Reference types are different from the reference operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
[Bug libstdc++/42019] shared_ptr can not be used with -fno-rtti
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 21:23 --- Subject: Bug 42019 Author: redi Date: Fri Nov 20 21:23:02 2009 New Revision: 154377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154377 Log: 2009-11-20 Jonathan Wakely jwakely@gmail.com PR libstdc++/42019 * include/tr1/shared_ptr.h: Only use typeid when RTTI is enabled. * include/bits/shared_ptr_base.h: Likewise. * include/bits/shared_ptr.h: Likewise. * testsuite/tr1/2_general_utilities/shared_ptr/misc/42019.cc: New. * testsuite/20_util/shared_ptr/misc/42019.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/misc/42019.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/misc/42019.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/tr1/shared_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug libgomp/42125] New: check libgomp fails
I downloaded the source code gcc 4.4.2 and compiled at cygwin. I used ../gcc-4.4.2/configure --enable-shared --enable-threads=posix --enable-libssp --enable-libgomp --enable-languages=c,c++ --enable-decimal-float --disable-bootstrap --without-x --enable-version-specific-runtime-libs to do configure, then make. The first errors are xgcc -pthread is not recognized libgomp.lib: File format not recognized so I changed /i686-pc-cygwin/libgomp/libtool file and search for the .lib file extension and change it to .dll.a. and modify file /i686-pc-cygwin/libgomp/Makefile with CFLAGS = -g -O2 -pthread XCFLAGS = -Wall -Werror -Wc,-pthread changed to CFLAGS = -g -O2 XCFLAGS = -Wall -Werror -Wc, added -lpthread at line: libgomp.la: $(libgomp_la_OBJECTS) $(libgomp_la_DEPENDENCIES) $(LINK) -rpath $(toolexeclibdir) $(libgomp_la_LDFLAGS) $(libgomp_la_OBJECTS) $(libgomp_la_LIBADD) $(LIBS) -lpthread Then again to do make. This time it goes thought. But when use make check-target-libgomp to do check, every case fails. It seems that a thread-support library doesn't generated with libgomp. -- Summary: check libgomp fails Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bwcc60 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42125
