Is it possible to port GCC backend to a architecture with very limited hard registers?
Hi all, Right now I attempts to port the GCC backend to a MCU with very limited hard registers: only one 8 bit ACC reg, one 16 bit base reg for addressing, one stats reg. I searched the GCC backend porting, and seems 68HC1X has the similar scene, but it use many ram simulated register. I wonder that if it is possbile to provided thislimited 3 register to GCC bankend, and let all 16bit(HImode), 32bit(SImode) operands spilled to stack. Thanks! Redriver
Re: Is it possible to port GCC backend to a architecture with very limited hard registers?
Almost certainly you will run into severe problems in the reload phase. You might also profitably study the ip2k port. This is a ALU machine, but it does have multiple address registers. -Original Message- From: redriver jiang jiang.redri...@gmail.com Sent: Mar 17, 2010 8:55 AM To: gcc@gcc.gnu.org Subject: Is it possible to port GCC backend to a architecture with very limited hard registers? Hi all, Right now I attempts to port the GCC backend to a MCU with very limited hard registers: only one 8 bit ACC reg, one 16 bit base reg for addressing, one stats reg. I searched the GCC backend porting, and seems 68HC1X has the similar scene, but it use many ram simulated register. I wonder that if it is possbile to provided thislimited 3 register to GCC bankend, and let all 16bit(HImode), 32bit(SImode) operands spilled to stack. Thanks! Redriver
Re: Is it possible to port GCC backend to a architecture with very limited hard registers?
We only had one real 8-bit accumulator on that port (the W register) which we did not expose the RA, instead exposing 32 virtual 8-bit registers from which we could construct 8, 16, 32 and 64-bit pairs. The key to really good code generation was to aggresively split the larger pseudo-operations after reload and eliminate all possible redundancy. The IP2k did have 2 offsettable address pointers though, one as a stack pointer and one as a data pointer which made the code much easier to manage (there was also one that wasn't offsettable and wasn't anywhere near as useful). I can imagine that any code where there's only one address register is going to be very messy because it will be permenantly swapping things in and out of it as things like register spills happen. Cheers, Dave On 17 Mar 2010, at 14:01, Alan Lehotsky wrote: Almost certainly you will run into severe problems in the reload phase. You might also profitably study the ip2k port. This is a ALU machine, but it does have multiple address registers. -Original Message- From: redriver jiang jiang.redri...@gmail.com Sent: Mar 17, 2010 8:55 AM To: gcc@gcc.gnu.org Subject: Is it possible to port GCC backend to a architecture with very limited hard registers? Hi all, Right now I attempts to port the GCC backend to a MCU with very limited hard registers: only one 8 bit ACC reg, one 16 bit base reg for addressing, one stats reg. I searched the GCC backend porting, and seems 68HC1X has the similar scene, but it use many ram simulated register. I wonder that if it is possbile to provided thislimited 3 register to GCC bankend, and let all 16bit(HImode), 32bit(SImode) operands spilled to stack. Thanks! Redriver
Re: (un)aligned accesses on x86 platform.
On Tue, 16 Mar 2010 06:50:30 -0800, H.J. Lu hjl.to...@gmail.com wrote: 2010/3/8 Pawe=C5=82 Sikora pl...@agmk.net: hi, during development a cross platform appliacation on x86 workstation i've enabled an alignemnt checking [1] to catch possible erroneous code before it appears on client's sparc/arm cpu with sigbus ;) it works pretty fine and catches alignment violations but Jakub Jelinek had told me (on glibc bugzilla) that gcc on x86 can still dereference an unaligned pointer (except for vector insns). i suppose it means that gcc can emit e.g. movl for access a short int (or maybe others scenarios) in some cases and violates cpu alignment rule= s. so, is it possible to instruct gcc-x86 to always use suitable loads/stores like on sparc/arm? [1] AC bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing) I am interested in an -mstrict-alignment option for x86. Me too. One use I have in mind is in emulators for ISAs that require alignment checks. Setting the AC bit would allow the emulator to replace explicit alignment checks with the x86 host's alignment checks, which could speed up emulation and reduce code volume (for JITs). However, this relies on gcc and glibc to not generate too many misaligned accesses. The glibc bit can be worked around (use a replacement libc or offload libc accesses to a sibling thread that runs with AC=0), but gcc does need to be instructed to not generate code with misaligned accesses. Another use is in implementations of dynamically-typed languages like Lisp. You can choose a tagging scheme so that CAR and CDR become simple loads with appropriate offsets. If the tagged pointer happens to not be a CONS, you'll get an alignment exception. /Mikael
libgcc-arch.ver details
Hi, I am quite confused with libgcc-arch.ver details. I can't find any documentation on this file except by looking at the files that already exist. So, let me see if I got this write. The file config/arch/libgcc-arch.ver tells gcc to build libgcc so that it export the symbols listed there (under a specific group which seems to be a gcc version). - Will gcc automatically pick the file when building for a specific arch or do I need to do something else? - For floating point emulation, how does gcc know that the arch needs floating point emulation or not? Does it depend on the insns that are defined in the md file? Cheers, -- PMatos
RFC: VTA alias set discrepancy
Hi folks.
I am debugging a bunch of Fortran -fdebug-compare failures on the
testsuite, all of which stem from symbols ending up on different alias
set slots. Notice the 2 versus 3 discrepancy below:
(insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI (i.0.1535)
[flags 0x2] var_decl # i.0) [2 i.0+0 S4 A32])
---
(insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI (i.0.1535)
[flags 0x2] var_decl # i.0) [3 i.0+0 S4 A32])
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already created a new alias set for first
time callers:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
...
...
{
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
In the non debug path we don't call rtl_for_decl_location(). Instead,
make_decl_rtl gets called through varpool_finalize_decl much later.
However, we end up creating alias sets in a different order, and even if
things end up in their correct alias sets, the numbers may be off from
the debug and non-debug paths.
A simple way to fix this would be to remove alias set numbers from the
RTL dumps when doing -fdebug-compare. I can think of all sorts of other
evil ways of forcing the sets to be created in the right order, but it
seems like bending over backwards for no good reason.
What do y'all suggest?
Aldy
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already created a new alias set for first
time callers:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
...
...
{
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
expand_debug_expr is another such spot.
I guess best would be to make sure no new alias set is created in these
places. Perhaps
int save_strict_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
rtl = DECL_RTL (decl);
flag_strict_aliasing = save_strict_aliasing;
in both places?
The rtls created this way are used only for DEBUG purposes.
I bet C/C++ FEs create the alias set for the decls much earlier...
Jakub
mingw32 gnat build on based on GCC gcc-4.4-20100223
My problems with GCC 4.4- were solved as suggested by adding in more multiply patterns specifically smulsi3_highpart, which enabled reciprocal multiplication to work. GCC 3.4.4 seems to be happy without this, don't know why. I have now built a mingw32 build of my private port, built on x86_64 linux, based on gcc-4.4-20100223 Building gnat for the final cross is the only problematic one There seem to be 3 build problems. 1) The ada bldtools don't build correctly, host versions of xnmake,xtreeprs,xsinfo , xeinfo and xgnatugn are built but the makefile needs ones built for the build system. I put versions built for the build system on my path and re-enter these lines, modified slightly from the originals (e.g. ./ removed from xnmake etc ) : (cd tools/objdir/gcc/ada/bldtools/nmake_b i686-pc-mingw32-gnatmake -q xnmake xnmake -b ../../nmake.adb ) (cd tools/objdir/gcc/ada/bldtools/nmake_s i686-pc-mingw32-gnatmake -q xnmake xnmake -s ../../nmake.ads ) (cd tools/objdir/gcc/ada/bldtools/treeprs i686-pc-mingw32-gnatmake -q xtreeprs xtreeprs ../../treeprs.ads ) (cd tools/objdir/gcc/ada/bldtools/sinfo i686-pc-mingw32-gnatmake -q xsinfo xsinfo ../../sinfo.h ) (cd tools/objdir/gcc/ada/bldtools/einfo i686-pc-mingw32-gnatmake -q xeinfo xeinfo ../../einfo.h ) (cd /home/linux/lmp-elf-gcc-4.4.4-prerelease/tools/objdir/gcc xgnatugn unw ../../gcc-4.4-20100223/gcc/ada/gnat_ugn.texi \ ../../gcc-4.4-20100223/gcc/ada/ug_words doc/gnat_ugn.texi) 2) I had to form an appropriate s-oscons.ads for mingw32 outside the build process 3) The Makefile in gnattools used build system adalib and adainclude files, I had to change it to use the cross libraries, in my case ADA_INCLUDES=-I/i686-pc-mingw32/lib/gcc/i686-pc-mingw32/4.4.4/adalib \ -I/i686-pc-mingw32/lib/gcc/i686-pc-mingw32/4.4.4/adainclude -I. -I/home/linux/lmp-elf-gcc-4.4.4-prerelease/tools/gcc-4.4-20100223/gcc/ada \
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already created a new alias set for first
time callers:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
...
...
{
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
expand_debug_expr is another such spot.
I guess best would be to make sure no new alias set is created in these
places. Perhaps
int save_strict_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
rtl = DECL_RTL (decl);
flag_strict_aliasing = save_strict_aliasing;
in both places?
The rtls created this way are used only for DEBUG purposes.
I bet C/C++ FEs create the alias set for the decls much earlier...
Ugh. I'd rather simply drop alias-sets from compare-debug dumps.
But ..
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
... why do this in the first place? Is this an issue for all decls or just
for DEBUG_DECLs? For DEBUG_DECLs you could refuse to assign
alias-sets in get_alias_set by returning 0 for them.
Richard.
Jakub
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 5:51 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Mar 17, 2010 at 5:32 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Mar 17, 2010 at 12:06:49PM -0400, Aldy Hernandez wrote:
What happens is that rtl_for_decl_location():dwarf2out.c will call
make_decl_rtl() which further down the call chain will call
get_alias_set/new_alias_set. It matters not that we reset DECL_RTL
immediately after, we have already created a new alias set for first
time callers:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
...
...
{
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
expand_debug_expr is another such spot.
I guess best would be to make sure no new alias set is created in these
places. Perhaps
int save_strict_aliasing = flag_strict_aliasing;
flag_strict_aliasing = 0;
rtl = DECL_RTL (decl);
flag_strict_aliasing = save_strict_aliasing;
in both places?
The rtls created this way are used only for DEBUG purposes.
I bet C/C++ FEs create the alias set for the decls much earlier...
Ugh. I'd rather simply drop alias-sets from compare-debug dumps.
But ..
rtl = DECL_RTL (decl);
/* Reset DECL_RTL back, as various parts of the compiler expects
DECL_RTL set meaning it is actually going to be output. */
SET_DECL_RTL (decl, NULL);
... why do this in the first place? Is this an issue for all decls or just
for DEBUG_DECLs? For DEBUG_DECLs you could refuse to assign
alias-sets in get_alias_set by returning 0 for them.
It seems to me that code-path is from before we forced unit-at-a-time
compile and now should only trigger for statics we do not emit
(and debug-decls?). Why not simply remove it alltogether?
Richard.
Richard.
Jakub
Re: RFC: VTA alias set discrepancy
I guess best would be to make sure no new alias set is created in these places. Perhaps int save_strict_aliasing = flag_strict_aliasing; flag_strict_aliasing = 0; rtl = DECL_RTL (decl); flag_strict_aliasing = save_strict_aliasing; in both places? Remember when I said I had come up with all sorts of evil ways of keeping the alias sets the same on both paths? Well, that was one of the patches I toyed around with: works, and is ugly as sin. :) I'm with Richi on this one, remove everything.
Re: RFC: VTA alias set discrepancy
? ? rtl = DECL_RTL (decl); ? ? /* Reset DECL_RTL back, as various parts of the compiler expects ? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/ ? ? SET_DECL_RTL (decl, NULL); ... why do this in the first place? ?Is this an issue for all decls or just for DEBUG_DECLs? ?For DEBUG_DECLs you could refuse to assign alias-sets in get_alias_set by returning 0 for them. It seems to me that code-path is from before we forced unit-at-a-time compile and now should only trigger for statics we do not emit (and debug-decls?). Why not simply remove it alltogether? The testcase I'm looking at is gfortran.dg/assign.f90. No, it's not a DEBUG_DECL, but a VAR_DECL named __BLNK__ which looks like the blank common block in Fortran (and of which I know nothing about). var_decl 0x7794d140 __BLNK__ type record_type 0x779493f0 SI size integer_cst 0x77854988 constant 32 unit size integer_cst 0x77854690 constant 4 align 32 symtab 0 alias set -1 canonical type 0x779493f0 fields field_decl 0x77946d10 i type integer_type 0x77863498 integer(kind=4) decl_2 SI file a.f90 line 4 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 32 offset_align 128 offset integer_cst 0x778546b8 constant 0 bit offset integer_cst 0x77854d98 constant 0 context record_type 0x779493f0 public static ignored common decl_3 SI defer-output file a.f90 line 5 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 128 context function_decl 0x7794b300 test chain var_decl 0x7794d0a0 i.1 Are you suggesting we remove the entire code path here: /* Try harder to get a rtl. If this symbol ends up not being emitted in the current CU, resolve_addr will remove the expression referencing it. */ ?? Aldy
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote: ? ? rtl = DECL_RTL (decl); ? ? /* Reset DECL_RTL back, as various parts of the compiler expects ? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/ ? ? SET_DECL_RTL (decl, NULL); ... why do this in the first place? ?Is this an issue for all decls or just for DEBUG_DECLs? ?For DEBUG_DECLs you could refuse to assign alias-sets in get_alias_set by returning 0 for them. It seems to me that code-path is from before we forced unit-at-a-time compile and now should only trigger for statics we do not emit (and debug-decls?). Why not simply remove it alltogether? The testcase I'm looking at is gfortran.dg/assign.f90. No, it's not a DEBUG_DECL, but a VAR_DECL named __BLNK__ which looks like the blank common block in Fortran (and of which I know nothing about). var_decl 0x7794d140 __BLNK__ type record_type 0x779493f0 SI size integer_cst 0x77854988 constant 32 unit size integer_cst 0x77854690 constant 4 align 32 symtab 0 alias set -1 canonical type 0x779493f0 fields field_decl 0x77946d10 i type integer_type 0x77863498 integer(kind=4) decl_2 SI file a.f90 line 4 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 32 offset_align 128 offset integer_cst 0x778546b8 constant 0 bit offset integer_cst 0x77854d98 constant 0 context record_type 0x779493f0 public static ignored common decl_3 SI defer-output file a.f90 line 5 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 128 context function_decl 0x7794b300 test chain var_decl 0x7794d0a0 i.1 Are you suggesting we remove the entire code path here: /* Try harder to get a rtl. If this symbol ends up not being emitted in the current CU, resolve_addr will remove the expression referencing it. */ ?? Yes. Richard. Aldy
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 6:40 PM, Richard Guenther richard.guent...@gmail.com wrote: On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote: ? ? rtl = DECL_RTL (decl); ? ? /* Reset DECL_RTL back, as various parts of the compiler expects ? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/ ? ? SET_DECL_RTL (decl, NULL); ... why do this in the first place? ?Is this an issue for all decls or just for DEBUG_DECLs? ?For DEBUG_DECLs you could refuse to assign alias-sets in get_alias_set by returning 0 for them. It seems to me that code-path is from before we forced unit-at-a-time compile and now should only trigger for statics we do not emit (and debug-decls?). Why not simply remove it alltogether? The testcase I'm looking at is gfortran.dg/assign.f90. No, it's not a DEBUG_DECL, but a VAR_DECL named __BLNK__ which looks like the blank common block in Fortran (and of which I know nothing about). var_decl 0x7794d140 __BLNK__ type record_type 0x779493f0 SI size integer_cst 0x77854988 constant 32 unit size integer_cst 0x77854690 constant 4 align 32 symtab 0 alias set -1 canonical type 0x779493f0 fields field_decl 0x77946d10 i type integer_type 0x77863498 integer(kind=4) decl_2 SI file a.f90 line 4 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 32 offset_align 128 offset integer_cst 0x778546b8 constant 0 bit offset integer_cst 0x77854d98 constant 0 context record_type 0x779493f0 public static ignored common decl_3 SI defer-output file a.f90 line 5 col 0 size integer_cst 0x77854988 32 unit size integer_cst 0x77854690 4 align 128 context function_decl 0x7794b300 test chain var_decl 0x7794d0a0 i.1 Are you suggesting we remove the entire code path here: /* Try harder to get a rtl. If this symbol ends up not being emitted in the current CU, resolve_addr will remove the expression referencing it. */ ?? Yes. That said - it would be good to have ensurance that debug info for, say, cc1files doesn't change if we remove it. Richard. Richard. Aldy
Re: Is it possible to port GCC backend to a architecture with very limited hard registers?
redriver jiang jiang.redri...@gmail.com writes: Right now I attempts to port the GCC backend to a MCU with very limited hard registers: only one 8 bit ACC reg, one 16 bit base reg for addressing, one stats reg. I searched the GCC backend porting, and seems 68HC1X has the similar scene, but it use many ram simulated register. I wonder that if it is possbile to provided thislimited 3 register to GCC bankend, and let all 16bit(HImode), 32bit(SImode) operands spilled to stack. It should be possible, though it owuld not be easy to resolve all the reload issues. gcc will not generate particularly good code for such a processor; you will see an awful lot of register shuffling. Ian
Re: constant hoisting out of loops
On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote: You are correct. The reload pass emitted the clr.w insn. However, I can see loop opt passes after reload: problem1.c.174r.loop2_invariant1 Not unless you have a modified toolchain. We don't run loop opt after register allocation. See the list of optimization passes in the FSF GCC passes.c file. loop2 occurs before ira/postreload. If you do have a modified toolchain, then I doubt that the current loop passes would work right, since they were designed to handle pseudo-regs not hard-regs. Jim
Re: Question on mips multiply patterns in md file
On Tue, 2010-03-16 at 15:12 +0800, Amker.Cheng wrote: In my understanding, the macro GENERATE_MADD_MSUB is true when the processor has madd insn, rather than madd2. And the macro ISA_HAS_DMUL3 is false if it has no mul insn. for this kind processor, gcc will step 1 : generate insn using gen_mulmode3_internal, according to pattern mulmode3; step 2 : the combiner try to combine by matching against pattern *mul_acc_si; step 3 : it's possible that gcc fail to get LO register allocated for the combined *mul_acc_si insn; step 4 : after reload, the combined insn will be split according to the split pattern listed in previous mail. step 5 : the split insn is actually a mulmode3_internal , but get no LO allocated, which break the constraints in mulmode3_internal pattern; OK. A much more complicated question than I realized. Yes, it does look like the mips port will fail in this case. As a practical matter, both mul and madd are MIPS32R1 and up instructions, so I would be surprised to see a processor that has the second one but not the first one. The new define_split you propose looks like it would work. Another possible solution is to take the mul_acc_si pattern and make two copies of it, one which tests ISA_HAS_MUL3 and one which tests ! ISA_HAS_MUL3. The first one remains the same. The second one drops the second alternative that has the 'd' destination. The reasoning here is that if splitting will result in worse code, then we shouldn't have accepted it in the first place. If dropping this alternative results in register allocator failures for some strange reason, then we accept it and generate the 3 instruction sequence with a new define_split. If dropping this alternative results in the register allocator generating worse code for other surrounding operations, then it is better to accept it and add the new define_split. Some experimentation might be necessary to see which change is the better solution. Jim
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 06:40:30PM +0100, Richard Guenther wrote:
var_decl 0x7794d140 __BLNK__
type record_type 0x779493f0 SI
size integer_cst 0x77854988 constant 32
unit size integer_cst 0x77854690 constant 4
align 32 symtab 0 alias set -1 canonical type 0x779493f0
fields field_decl 0x77946d10 i type integer_type
0x77863498 integer(kind=4)
decl_2 SI file a.f90 line 4 col 0 size integer_cst
0x77854988 32 unit size integer_cst 0x77854690 4
align 32 offset_align 128
offset integer_cst 0x778546b8 constant 0
bit offset integer_cst 0x77854d98 constant 0 context
record_type 0x779493f0
public static ignored common decl_3 SI defer-output file a.f90 line
5 col 0 size integer_cst 0x77854988 32 unit size integer_cst
0x77854690 4
align 128 context function_decl 0x7794b300 test chain
var_decl 0x7794d0a0 i.1
Are you suggesting we remove the entire code path here:
/* Try harder to get a rtl. If this symbol ends up not being emitted
in the current CU, resolve_addr will remove the expression referencing
it. */
??
Yes.
That will very much pessimize debug info. While we are now always in
-funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough.
From the file scope non-static vars, at the point debug info is generated only
the first var usually has DECL_RTL set, all others don't.
For the cfgexpand.c occurence of this idiom, please see e.g. PR41353 -
even simple testcases like:
int i = 1, j, k = 1;
int
foo (void)
{
int i1 = 2 * i;
int i2 = 2 * i;
int k1 = 2 * k;
int k2 = 2 * k;
return j;
}
(and note this is artificial testcase, while obviously if the function does
something real, the same problem will be present often too) will have value
just for i1/i2, but not for k1/k2. i above has DECL_RTL set in
notice_global_symbol, but all other such vars have DECL_RTL set only way
after debuginfo for foo is created (unless the function has non-optimized
out references to the vars). As we can't create DECL_RTL just for -g case
and at different time for -g0, we do the DECL_RTL + SET_DECL_RTL NULL
hack.
Jakub
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 09:26:29PM +0100, Jakub Jelinek wrote: That will very much pessimize debug info. While we are now always in -funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough. From the file scope non-static vars, at the point debug info is generated only the first var usually has DECL_RTL set, all others don't. ... And for the dwarf2out.c hunk please see http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00546.html In both spots this happens only for TREE_STATIC !DECL_EXTERNAL variables, and the debug info really doesn't care if the alias set will be 0 on all of those MEMs. Though of course it could use the decl's alias set if it has been computed already, and 0 otherwise. Jakub
Re: RFC: VTA alias set discrepancy
Are you suggesting we remove the entire code path here: ?/* Try harder to get a rtl. ?If this symbol ends up not being emitted ? ? in the current CU, resolve_addr will remove the expression referencing ? ? it. ?*/ ?? Yes. That will very much pessimize debug info. While we are now always in -funit-at-a-time mode, that doesn't mean DECL_RTL is computed early enough. From the file scope non-static vars, at the point debug info is generated only the first var usually has DECL_RTL set, all others don't. For the cfgexpand.c occurence of this idiom, please see e.g. PR41353 - even simple testcases like: So... Richi, et al. Instead, should I remove alias set numbers on the -fcompare-debug case, or inhibit new alias sets like thus: unsigned int save_aliasing = flag_strict_aliasing; flag_strict_aliasing = 0; do the DECL_RTL thing flag_strict_aliasing = save_aliasing; Well, I'll let you two figure it out... :) Thanks for taking a look at this. Aldy
DWARF Version 4 Released
DWARF Version 4 Released March 17, 2010 The DWARF Debugging Information Format Committee is pleased to announce the availability of the public review draft of Version 4 of the DWARF Debugging Information Format standard. The DWARF debugging format is used to communicate information between a compiler and debugger to make it easier for programmers to develop, test, and debug programs. DWARF is used by commercial and open source compilers and debuggers to support debugging of Ada, C, C++, Cobol, Fortran, Java, and several other programming languages. DWARF is used with many processors: ARM, Intel/AMD x86, MIPS, PowerPC, and many others, from 8-bit to 64-bit. DWARF is the standard debugging format for Linux and is widely used with embedded processors. DWARF is designed to be extended easily to support new languages and new processors. DWARF Version 4 is compatible with Version 3, making it easy for compiler and debugger developers to upgrade their development tools. Most programmers will not notice the differences when using compilers or debuggers that use DWARF Version 4, although they may see improvements in debugging their programs. The DWARF Committee consists of representatives from a broad range of companies, including Apple, ARM, CodeSourcery, Concurrent Computer, Eager Consulting, Google, Hewlett-Packard, IBM, RedHat, SGI, Sun Microsystems, and TotalView, as well as unaffiliated individuals with significant experience in compiler and debugger development. Michael Eager, Chair of the DWARF Committee, said we have made significant improvements in Version 4 since the previous version was released in 2006. These include improved data compression, better description of optimized code, and support for new language features in C++. Debugging programs can be difficult. Providing the best quality information to programmers can make this easier. The DWARF Version 4 standard can be downloaded without charge from the DWARF website (http://dwarfstd.org). The DWARF Committee will accept public comments on DWARF Version 4 until May 31, after which a finalized version will be published. Additional information about DWARF, including how to subscribe to the DWARF mailing list, can also be found on the website. Questions about the DWARF Debugging Information Format or the DWARF Committee can be directed to the DWARF Committee Chair, Michael Eager, at mailto:i...@dwarfstd.org. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: RFC: VTA alias set discrepancy
On Wed, Mar 17, 2010 at 06:08:06PM -0400, Aldy Hernandez wrote: So... Richi, et al. Instead, should I remove alias set numbers on the -fcompare-debug case, or inhibit new alias sets like thus: unsigned int save_aliasing = flag_strict_aliasing; flag_strict_aliasing = 0; do the DECL_RTL thing flag_strict_aliasing = save_aliasing; If this, then I guess this together with the following SET_DECL_RTL NULL should be put into a new make_decl_rtl_for_debug helper (or something similar), with a big comment why it is doing that. Dropping of alias sets from -fdump-final-insns is risky, we'd miss if DEBUG insns/stmts actually cause any real aliasing changes. Jakub
inconsistencies in the documentation regarding side effects with auto inc-dec
Hi Kenneth, The documentation of auto-inc-dec still refers to flow and when I raised this on IRC folks suggested that you might have some documentation fixes if any, in this area. http://gcc.gnu.org/onlinedocs/gccint/Incdec.html#Incdec The lines in the doco are as below : These embedded side effect expressions must be used with care. Instruction patterns may not use them. Until the `flow' pass of the compiler, they may occur only to represent pushes onto the stack. The `flow' pass finds cases where registers are incremented or decremented in one instruction and used as an address shortly before or after; these cases are then transformed to use pre- or post-increment or -decrement. Cheers Ramana
Re: inconsistencies in the documentation regarding side effects with auto inc-dec
i will fix it. kenny On 03/17/2010 07:28 PM, Ramana Radhakrishnan wrote: Hi Kenneth, The documentation of auto-inc-dec still refers to flow and when I raised this on IRC folks suggested that you might have some documentation fixes if any, in this area. http://gcc.gnu.org/onlinedocs/gccint/Incdec.html#Incdec The lines in the doco are as below : These embedded side effect expressions must be used with care. Instruction patterns may not use them. Until the `flow' pass of the compiler, they may occur only to represent pushes onto the stack. The `flow' pass finds cases where registers are incremented or decremented in one instruction and used as an address shortly before or after; these cases are then transformed to use pre- or post-increment or -decrement. Cheers Ramana
Re: libgcc-arch.ver details
Paulo J. Matos pocma...@gmail.com writes: I am quite confused with libgcc-arch.ver details. I can't find any documentation on this file except by looking at the files that already exist. So, let me see if I got this write. The file config/arch/libgcc-arch.ver tells gcc to build libgcc so that it export the symbols listed there (under a specific group which seems to be a gcc version). Basically, yes. The symbol grouping is a version string which the linker will attach to the symbols in that group when creating libgcc.so. When a program is later linked against libgcc.so, the linker will record the versions of the symbols in the resulting executable. The dynamic linker will then verify at runtime that the symbol versions are available. - Will gcc automatically pick the file when building for a specific arch or do I need to do something else? You need to have gcc/config.gcc include t-slibgcc-elf-ver in tmake_file. You also need to set SHLIB_MAPFILES in some config/ARCH/t-XXX file that config.gcc includes in tmake_file. See existing examples. - For floating point emulation, how does gcc know that the arch needs floating point emulation or not? Does it depend on the insns that are defined in the md file? Yes. If insns exist with the right name, they will be used. Otherwise gcc will generate calls to library functions. Ian
Re: Hash Function for switch statement
On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner meiss...@linux.vnet.ibm.com wrote: Note, that many hash tables are computed by the modulus operation, which is often fairly expensive (and on machines without a hardware divide unit, requiring a function call). I would expect many switch statements would slow down if you switch to a hash operation that used modolus. Hi Michael, I agree that the cost of modulation can be high, but it can be even higher if we use a bunch of else if. Consider the situation that a program has about 400 cases on a single switch statement. The cost of modulation will be fixed price so that there should be a certain point that the price bis lower than else if statements. If jump table is possible, it can be a choice, but jump table is not always feasible depending on the values on case. Thank you for the reply. Jay
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #10 from bonzini at gnu dot org 2010-03-17 06:41 --- REG_EQUAL notes are not there to guarantee correctness. Relying on them to avoid misoptimization is always wrong and just hides the bug. It is a regression from 4.2. -- bonzini at gnu dot org changed: What|Removed |Added Known to work||4.2.1 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression] |possible wrong code bug |wrong loop invariant ||hoisting http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug c++/43376] template member function instantiations are not hidden if the class has default visibility and -fvisibility-ms-compat is used
--- Comment #3 from fjoe at samodelkin dot net 2010-03-17 07:09 ---
The source of library bar is:
--- cut here ---
#include foo.h
#ifdef _MSC_VER
#define BAR_API __declspec(dllexport)
#else
#define BAR_API __attribute__((visibility(default)))
#endif
void BAR_API
bar()
{
Foo foo;
foo.foo(5);
}
--- cut here ---
And Foo::foo is visible in bar:
[Wed Mar 17 12:27:12] kenny:~/work/export$g++44 -c -fvisibility-ms-compat
bar.cc
[Wed Mar 17 12:27:20] kenny:~/work/export$readelf -sW bar.o | grep foo
15: 45 FUNCWEAK DEFAULT6 _ZN3Foo3fooIiEEvRKT_
When I compile the same using Visual Studio (.DLL configuration) I get the
following output from objdump (cygwin objdump):
mk...@pond /cygdrive/c/Users/mkhon/export$ objdump -x bar.dll
[...]
The Export Tables (interpreted .rdata section contents)
Export Flags0
Time/Date stamp 4ba07f9e
Major/Minor 0/0
Name000c7302 bar.dll
Ordinal Base1
Number in:
Export Address Table0001
[Name Pointer/Ordinal] Table0001
Table Addresses
Export Address Table000c72f8
Name Pointer Table 000c72fc
Ordinal Table 000c7300
Export Address Table -- Ordinal Base 1
[ 0] +base[ 1] 3ab7c Export RVA
[Ordinal/Name Pointer] Table
[ 0] ?bar@@YAXXZ
[...]
As you can see there are no Foo::foo symbols exported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43376
[Bug c++/43376] template member function instantiations are not hidden if the class has default visibility and -fvisibility-ms-compat is used
--- Comment #4 from pluto at agmk dot net 2010-03-17 07:57 --- this PR sounds like a PR38610. -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43376
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #11 from steven at gcc dot gnu dot org 2010-03-17 08:23 --- So why not just something like the following: Note that uses in REG_EQUAL notes are taken into account in the computation of invariants. Hence it is safe to retain the note even if the note contains register references. */ - if (! inv-always_executed - (note = find_reg_note (inv-insn, REG_EQUAL, NULL_RTX))) + note = find_reg_note (inv-insn, REG_EQUAL, NULL_RTX); + if (note + (! inv-always_executed + || ! check_maybe_invariant (XEXP (note, 0))) remove_note (inv-insn, note); } else In other words, nuke the note if it is not always executed or if the note value is not invariant? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-17 08:30 --- If it is ok to call check_maybe_invariant in this spot, then I think that's the right fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #13 from steven at gcc dot gnu dot org 2010-03-17 08:33 --- Mine. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-14 15:32:49 |2010-03-17 08:33:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug rtl-optimization/43360] [4.3/4.4/4.5 Regression] wrong loop invariant hoisting
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-03-17 08:59 --- I just posted the same fix. :-) Yes, it is OK for all branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
[Bug c/43381] [4.4/4.5 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-17 09:20 --- Actually, this seems to be a C FE bug, corruption of TREE_CHAIN chains. The reason for dwarf2out hanging is that in foo we have a block: BLOCK #0 [written] SUPERCONTEXT: foo VARS: vector_size foo i h Note that the foo in both cases is the same, i.e. in function_decl 0x71d6db00 block 0x71d6db00 is in the BLOCK_VARS chain. First vector_size() is added to foo's parameter scope (depth 2) BLOCK_VARs, then i() is added to h's parameter scope (depth 2) BLOCK_VARs. Then h() is added to external scope (depth 0). Then i() (after duplicate_decls which resulted in the i() that has been already added earlier to h's parameter scope) is added to external scope (depth 0). Then foo() is added to external scope (depth 0). Finally vector_size() is added to external scope. Given that i() and vector_size() are referenced from both the external_scope and function's parameter_scope, in both cases the same tree, and BLOCK_VARs are chained through TREE_CHAIN, this obviously doesn't work very well, so while foo's parameter scope was supposed to contain just vector_size(), it now contains all the FUNCTION_DECLs added to external_scope. And, while h's parameter scope was supposed to contain just i(), it now contains i() and h() too. Joseph, could you please look at this? I'm not sure if the right fix is force these implicit declarations in fn parameters as externs (i.e. BLOCK_VARs contains a copy of the decl rather than the decl itself), or ensure pushdecl/duplicate_decls from other functions doesn't find them. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Component|debug |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug rtl-optimization/42216] [4.5 Regression] changes in scheduling regress 464.h264ref 20%
--- Comment #27 from bernds at gcc dot gnu dot org 2010-03-17 09:25 --- Subject: Bug 42216 Author: bernds Date: Wed Mar 17 09:25:35 2010 New Revision: 157511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157511 Log: PR rtl-optimization/42216 * regrename.c (create_new_chain): New function, broken out from... (scan_rtx_reg): ... here. Call it. Handle the case where we are appending a use to an empty chain. (build_def_use): Remove previous changes that convert OP_INOUT to OP_OUT operands; instead detect the case where an OP_INOUT operand uses a previously untracked register and create an empty chain for it. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
[Bug fortran/42950] gfortran testsuite failures on mingw64
--- Comment #12 from burnus at gcc dot gnu dot org 2010-03-17 09:30 --- Close as fixed as only PR 42954 remains to be done. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42950
[Bug fortran/42954] gfortran with libcpp: TARGET_*_CPP_BUILDINS issues (MinGW, FreeBSD, MIPS, Fry)
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-17 09:31 --- Cross reference: The missing define of _WIN32 causes failures on MinGW/MinGW64 for gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90. (cf. PR 42950 which is otherwise fixed.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
[Bug c/43398] New: ICE with -O -floop-block
I found that when I emerged libcaca 0.99 beta 16, I got 2 ICEs in demo.c
and demo0.c. After some code cutting I got down to [attached demo.i]. Note that
draw_circle isn't defined, it was a real function in libcaca's
demo.c. Also, the there's an -O flag, removing it causes an error on
draw_circle (since it's not defined), adding this to the code below:
void draw_circle(int *a, int b, int c, int d, int e, int f){}
will make the ICE go away (with or without -O). (I'm guessing it's not related
to the ICE, which I believe is caused by -floop-block alone)
I have these versions of the graphite dependencies installed:
dev-libs/ppl-0.10.2-r1 USE=pch -doc -test -watchdog
dev-libs/cloog-ppl-0.15.8
Here's the commandline with it's output:
$ LC_ALL=C gcc -v -save-temps -O -floop-block demo.c
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python
--disable-libgcj --enable-objc-gc --enable-languages=c,c++,objc,obj-c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.4.3 p1.0'
Thread model: posix
gcc version 4.4.3 (Gentoo 4.4.3 p1.0)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-floop-block' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/cc1 -E -quiet -v demo.c
-D_FORTIFY_SOURCE=2 -mtune=generic -floop-block -O -fpch-preprocess -o demo.i
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/../../../../x86_64-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-floop-block' '-mtune=generic'
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/cc1 -fpreprocessed demo.i -quiet
-dumpbase demo.c -mtune=generic -auxbase demo -O -version -floop-block -o
demo.s
GNU C (Gentoo 4.4.3 p1.0) version 4.4.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.4.3, GMP version 4.3.1, MPFR version
2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a82a244c7fb9c82fc087b2597e2d44f9
demo.c: In function 'main':
demo.c:2: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:4295
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/ for instructions.
--
Summary: ICE with -O -floop-block
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scientica at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43398
[Bug c/43398] ICE with -O -floop-block
--- Comment #1 from scientica at gmail dot com 2010-03-17 09:40 --- Created an attachment (id=20122) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20122action=view) the crash case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43398
[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end
--- Comment #5 from burnus at gcc dot gnu dot org 2010-03-17 09:53 --- Subject: Bug 43331 Author: burnus Date: Wed Mar 17 09:53:40 2010 New Revision: 157512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157512 Log: 2010-03-17 Tobias Burnus bur...@net-b.de PR fortran/43331 * trans-array.c (gfc_conv_array_index_offset,gfc_conv_array_ref, gfc_conv_ss_startstride): Remove no-longer-needed cp_was_assumed check. * decl.c (gfc_match_derived_decl): Don't mark assumed-size Cray pointees as having explizit size. * expr.c (gfc_check_assign): Remove now unreachable Cray pointee check. * trans-types.c (gfc_is_nodesc_array): Add cp_was_assumed to * assert. (gfc_sym_type): Don't mark Cray pointees as restricted pointers. * resolve.c (resolve_symbol): Handle cp_was_assumed. * trans-decl.c (gfc_trans_deferred_vars): Ditto. (gfc_finish_var_decl): Don't mark Cray pointees as restricted pointers. 2010-03-17 Tobias Burnus bur...@net-b.de PR fortran/43331 * gfortran.dg/cray_pointers_1.f90: Update dg-error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/cray_pointers_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43331
[Bug tree-optimization/42906] [4.5 Regression] Empty loop not removed
--- Comment #19 from rguenther at suse dot de 2010-03-17 10:01 ---
Subject: Re: [4.5 Regression] Empty loop not
removed
On Wed, 17 Mar 2010, changpeng dot fang at amd dot com wrote:
--- Comment #17 from changpeng dot fang at amd dot com 2010-03-17 00:18
---
(In reply to comment #8)
And
int foo (int b, int j)
{
if (b)
{
int i;
for (i = 0; i1000; ++i)
;
j = b;
}
return j;
}
With j=b, b is not folded as a phi argument:
bb 5:
# i_2 = PHI 0(3), i_6(4)
if (i_2 = 999)
goto bb 4;
else
goto bb 6;
bb 6:
j_7 = b_3(D);
bb 7:
# j_1 = PHI j_4(D)(2), j_7(6)
However, if j=0, it is:
bb 6:
j_7 = 0;
bb 7:
# j_1 = PHI j_4(D)(2), 0(6)
j_8 = j_1;
return j_8;
Then copy propagation will remove j_7 = 0 (and thus bb 6) because it has
no
user.
So, one possible solution is do not remove trival dead code in
copy_propagation pass. Any dce pass will remove such code.
Of course, if we follow Steven's suggestion not use constants as phi
arguments,
j_7=0 will not be removed by constant propagation, and we are all fine.
Splitting critical edges for CDDCE will probably also solve this problem.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42906
[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-17 10:03 --- FIXED on the trunk (4.5). Richard: Thanks for the clear bug report! And for making the middle-end smarter with regards to bonds. Actually, will this middle-end change cause problems for inlining such old-style Fortran code as below? real A(100) call sub(A(1), 100) ! Correct syntax: call sub(A, 100) subroutine sub(x, n) integer n real x(*) ! Or: real x(n) to be slightly more modern x(n) = 5 (I think the code was never valid but one can find it quite often in old code that it passes the first array element to a procedure, which expects an array.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43331
[Bug fortran/43331] Cray pointers generate bogus IL for the middle-end
--- Comment #7 from rguenther at suse dot de 2010-03-17 10:07 --- Subject: Re: Cray pointers generate bogus IL for the middle-end On Wed, 17 Mar 2010, burnus at gcc dot gnu dot org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2010-03-17 10:03 --- FIXED on the trunk (4.5). Richard: Thanks for the clear bug report! And for making the middle-end smarter with regards to bonds. Actually, will this middle-end change cause problems for inlining such old-style Fortran code as below? real A(100) call sub(A(1), 100) ! Correct syntax: call sub(A, 100) subroutine sub(x, n) integer n real x(*) ! Or: real x(n) to be slightly more modern x(n) = 5 (I think the code was never valid but one can find it quite often in old code that it passes the first array element to a procedure, which expects an array.) The middle-end should be able to deal with this (well, worst case by refusing to inline). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43331
[Bug c++/43393] integral promotion of long bit-fields broken in g++ 4.4.0
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 10:47 --- From [3] ISO/IEC 14882-1998 [conv.prom] An rvalue for an integral bit-field can be converted to an rvalue of type int if int can represent all the values of the bit-field; otherwise, it can be converted to unsigned int if unsigned int can represent all the values of the bit-field. If the bit-field is larger yet, no integral promotion applies to it. If the bit-field has an enumerated type, it is treated as any other value of that type for promotion purposes. I read that t.f promotes to int. And that is exactly what the C++ frontend does: (void) printf ((const char *) %lx %lx %lx\n, (long unsigned int) t.f, (long unsigned int) ((int) t.f 17), (long unsigned int) (((int) t.f 17) 17)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43393
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #20 from doko at ubuntu dot com 2010-03-17 10:51 --- no change in the libjava testsuite when built with these binutils -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug c++/43376] template member function instantiations are not hidden if the class has default visibility and -fvisibility-ms-compat is used
--- Comment #5 from redi at gcc dot gnu dot org 2010-03-17 10:54 --- I think the behaviour is intentional, for the same reasons described at http://gcc.gnu.org/wiki/Visibility#Problems_with_C.2B-.2B-_exceptions_.28please_read.21.29 Instantiated templates (such as Foo::fooint) have vague linkage so cannot be hidden. Quoting from the wiki page: Symbol visibility is default by default but if the linker encounters just one definition with it hidden - just one - that [...] symbol becomes permanently hidden (remember the C++ standard's ODR - one definition rule). ... The same issue can arise with other vague linkage entities such as static data members of a class template. If the class has hidden visibility, the data member can be instantiated in multiple DSOs and referenced separately, causing havoc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43376
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #12 from jakub at gcc dot gnu dot org 2010-03-17 10:58 ---
Reduced testcase at -g -O2 on x86_64 grows during var-tracking get_max_uid ()
from ~ 22000 to over a 100. Adding ten X4's instead of 1 of course eats
even more memory.
extern void *f1 (void *, void *, void *);
extern void *f2 (const char *, int, int, int, void *(*) ());
extern void *f3 (const char *);
extern void *f4 (void *s);
extern void *f5 (void *);
void test (void)
{
#define X1 f1 (f2 (a, 1, 0, 0, f5), \
f4 (({ const char *a = b; f3 (a); })), \
({ const char *a = c; f3 (a); }));
#define X2 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1
#define X3 X2 X2 X2 X2 X2 X2 X2 X2 X2 X2
#define X4 X3 X3 X3 X3 X3 X3 X3 X3 X3 X3
X4
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #4 from bernds at codesourcery dot com 2010-03-17 11:05 --- It's not immediately obvious to me why the ARM mulsi3 patterns are written the way they are - what are the earlyclobber tricks supposed to be good for? Richard E., any clues? -- bernds at codesourcery dot com changed: What|Removed |Added CC||rearnsha at arm dot com, ||bernds at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #5 from bernds at codesourcery dot com 2010-03-17 11:44 --- Created an attachment (id=20123) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20123action=view) A patch to fix it. Okay, so the pattern is written strangely because it's a two-operand mul where the input and output may not be the same register. It may be better to write this using an earlyclobbered in-out operand, but you can't show anymore that the operation is commutative. It can be fixed with a simple peephole optimization, at least for this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug rtl-optimization/42258] [4.5 Regression] redundant register move around mul instruction
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-17 11:59 --- Perhaps add a comment why the peephole is needed? That information tend to get lost rather quickly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
[Bug tree-optimization/43347] [4.5 Regression] Warning about symbols generated by SRA being used uninitialized
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-03-17 12:02 --- Subject: Bug 43347 Author: jamborm Date: Wed Mar 17 12:02:35 2010 New Revision: 157515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157515 Log: 2010-03-17 Martin Jambor mjam...@suse.cz PR tree-optimization/43347 * tree-sra.c (create_access_replacement): Set TREE_NO_WARNING when the original base is DECL_ARTIFICIAL or DECL_IGNORED_P. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347
[Bug tree-optimization/43347] [4.5 Regression] Warning about symbols generated by SRA being used uninitialized
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-03-17 12:04 --- Fixed with http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00694.html -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347
[Bug bootstrap/43399] New: [4.5 Regression] bootstrap failure in stage1
current trunk is failing bootstrap in stage 1 on Cortex-A8 (armv7l target) First caught it svn 157489. Started bisection yesterday between 157445 157489. First bad commit is: 157476. System is running Debian Testing(Squeeze) Error: /opt/trunk/objdir/./gcc/xgcc -B/opt/trunk/objdir/./gcc/ -B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/bin/ -B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/lib/ -isystem /opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/include -isystem /opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/opt/trunk/libgcc -I/opt/trunk/libgcc/. -I/opt/trunk/libgcc/../gcc -I/opt/trunk/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /opt/trunk/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /opt/trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3': /opt/trunk/libgcc/../gcc/libgcc2.c:562:1: internal compiler error: in adjust_mems, at var-tracking.c:789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_muldi3.o] Error 1 make[3]: Leaving directory `/var/builds/opt/trunk/objdir/armv7l-unknown-linux-gnueabi/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/var/builds/opt/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/builds/opt/trunk/objdir' make: *** [bootstrap] Error 2 gcc_build: error: Could not bootstrap the compiler Build Logs: http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-ERROR/ I'll need to rebuild that svn id to provide more test info, as i delete the old build when building a new checkout.. Note a similar commit went into gcc-4.4 at : 157487 (var-tracking.c) so gcc-4.4 might be broken too.. -- Summary: [4.5 Regression] bootstrap failure in stage1 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: robertcnelson at gmail dot com GCC target triplet: armv7l-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-17 12:56 --- Please provide preprocessed source. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug tree-optimization/43379] [4.5 Regression] ICE: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set with -O2 -ftracer
--- Comment #7 from ubizjak at gmail dot com 2010-03-17 12:57 --- New test fails with: Executing on host: /space/uros/gcc-build/gcc/xgcc -B/space/uros/gcc-build/gcc/ /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c -O2 -ftracer -S -o pr43379.s(timeout = 300) /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c: In function 'foo':^M /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c:9:3: warning: function returns address of local variable^M output is: /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c: In function 'foo':^M /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c:9:3: warning: function returns address of local variable^M FAIL: gcc.dg/pr43379.c (test for excess errors) Excess errors: /home/uros/gcc-svn/trunk/gcc/testsuite/gcc.dg/pr43379.c:9:3: warning: function returns address of local variable -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43379
[Bug tree-optimization/43379] [4.5 Regression] ICE: error: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set with -O2 -ftracer
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-17 13:44 --- I fixed htat. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43379
[Bug bootstrap/43400] New: [4.5 Regression] internal compiler error: in adjust_mems, at var-tracking.c:789
While crosscompiling gcc 4.5.0 svn rev. 157515, it barfs while compiling itself: /usr/src/CVS/toolchains/gcc-4.5.0/build/./gcc/xgcc -B/usr/src/CVS/toolchains/gcc-4.5.0/build/./gcc/ -B/usr/armv6j-blankpage-linux-gnueabi/bin/ -B/usr/armv6j-blankpage-linux-gnueabi/lib/ -isystem /usr/armv6j-blankpage-linux-gnueabi/include -isystem /usr/armv6j-blankpage-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -o _absvsi2.o -MT _absvsi2.o -MD -MP -MF _absvsi2.dep -DL_absvsi2 -c ../../../libgcc/../gcc/libgcc2.c \ ../../../libgcc/../gcc/libgcc2.c: In function __negdi2: ../../../libgcc/../gcc/libgcc2.c:76:1: internal compiler error: in adjust_mems, at var-tracking.c:789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_negdi2.o] Error 1 make[2]: *** Waiting for unfinished jobs ../../../libgcc/../gcc/libgcc2.c: In function __muldi3: ../../../libgcc/../gcc/libgcc2.c:562:1: internal compiler error: in adjust_mems, at var-tracking.c:789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_muldi3.o] Error 1 ../../../libgcc/../gcc/libgcc2.c: In function __absvsi2: ../../../libgcc/../gcc/libgcc2.c:237:1: internal compiler error: in adjust_mems, at var-tracking.c:789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_absvsi2.o] Error 1 svn rev. 157441 didn't have this problem. -- Summary: [4.5 Regression] internal compiler error: in adjust_mems, at var-tracking.c:789 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: armv6j-blankpage-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43400
[Bug c/43401] New: Register not cleand correctly by acessing thru pointer
On the assigned file you can reproduce the bug. If you compile this file with -O2 the error occures, only way is use -O0 or use volatile statement for the double arrays. I think this should be checkt during optimization. Greets, Matthias -- Summary: Register not cleand correctly by acessing thru pointer Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matthias at goldhoorn dot eu GCC build triplet: amd64 GCC host triplet: amd64 GCC target triplet: amd64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug c/43401] Register not cleand correctly by acessing thru pointer
--- Comment #1 from matthias at goldhoorn dot eu 2010-03-17 13:48 --- Created an attachment (id=20124) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20124action=view) source file where the bugg occures -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug c/43401] Register not cleand correctly by acessing thru pointer
-- matthias at goldhoorn dot eu changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-17 13:51 --- *** Bug 43400 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug bootstrap/43400] [4.5 Regression] internal compiler error: in adjust_mems, at var-tracking.c:789
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-17 13:51 --- *** This bug has been marked as a duplicate of 43399 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43400
[Bug c/43401] Register not cleand correctly by acessing thru pointer
--- Comment #2 from matthias at goldhoorn dot eu 2010-03-17 13:54 --- Created an attachment (id=20125) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20125action=view) Object dump without optization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug c/43401] Register not cleand correctly by acessing thru pointer
--- Comment #3 from matthias at goldhoorn dot eu 2010-03-17 13:55 --- Created an attachment (id=20126) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20126action=view) Object Dumpo with optimization (broken result) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug c/43401] Register not cleand correctly by acessing thru pointer
--- Comment #4 from matthias at goldhoorn dot eu 2010-03-17 13:57 --- Forgotten output with optimization: (10.00,20.00) (0.00,0.00) (0.00,0.00) (0.00,0.00) sould be: (10.00,20.00) (10.00,20.00) (10.00,20.00) (10.00,20.00) without optimization: (10.00,20.00) (10.00,20.00) (10.00,20.00) (10.00,20.00) sould be: (10.00,20.00) (10.00,20.00) (10.00,20.00) (10.00,20.00) (In reply to comment #0) On the assigned file you can reproduce the bug. If you compile this file with -O2 the error occures, only way is use -O0 or use volatile statement for the double arrays. I think this should be checkt during optimization. Greets, Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug tree-optimization/43402] New: dom1 miscompiles binary search
This actually happens in libicu, preventing genbrk (and hence openoffice and texlive) to work. # gcc -O1 icubug.c ./a.out Aborted With -O0 it works. The wrong transformation is done by dom1, it transforms the loop into a linear sequence without backedges. bb 2: goto bb 8; bb 3: # start_16 = PHI mid_25(5), start_21(8) # limit_19 = PHI limit_22(5), mid_25(8) # lastMid_15 = PHI mid_25(5), mid_25(8) bb 4: # start_1 = PHI start_16(3) # limit_2 = PHI limit_19(3) # lastMid_3 = PHI mid_25(3) D.2744_9 = start_1 + limit_2; mid_10 = D.2744_9 / 2; goto bb 7; bb 5: if (result_14 0) goto bb 3; else goto bb 6; bb 6: D.2754_17 = cnvNameType[mid_25].type; D.2753_18 = converterData[D.2754_17]; bb 7: # D.2753_4 = PHI D.2753_18(6), 0B(4) return D.2753_4; bb 8: # start_21 = PHI 0(2) # limit_22 = PHI 3(2) # lastMid_23 = PHI 4294967295(2) D.2744_24 = start_21 + limit_22; mid_25 = D.2744_24 / 2; D.2746_12 = cnvNameType[mid_25].name; result_14 = __builtin_strcmp (realName_13(D), D.2746_12); if (result_14 0) goto bb 3; else goto bb 5; -- Summary: dom1 miscompiles binary search Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] dom1 miscompiles binary search
--- Comment #1 from matz at gcc dot gnu dot org 2010-03-17 14:02 --- Created an attachment (id=20127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127action=view) testcase Testcase reduced from ucnv_bld.c of libicu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #3 from robertcnelson at gmail dot com 2010-03-17 14:04 --- Rebuilding 157476, will take a couple hours to hit that error.. System: gcc -v voo...@beagle-256mb-1:~$ gcc -v Using built-in specs. Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9' --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-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|dom1 miscompiles binary |[4.5 Regression] dom1 |search |miscompiles binary search Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug bootstrap/43403] New: [4.5 Regression] ICE in stage1 compiling __bswapdi2
/home2/dave/gcc-4.5/objdir/./gcc/xgcc -B/home2/dave/gcc-4.5/objdir/./gcc/ -B/hom e2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home2/dave/opt/gnu/gcc/gcc-4.5. 0/hppa-linux/lib/ -isystem /home2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -isystem /home2/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmi ssing-prototypes -Wold-style-definition -isystem ./include -fPIC -DELF=1 -DLIN UX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I.. /.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/.. /gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -o _fixunsxfsi.o -MT _fixun sxfsi.o -MD -MP -MF _fixunsxfsi.dep -DL_fixunsxfsi -c ../../../gcc/libgcc/../gcc /libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__bswapdi2': ../../../gcc/libgcc/../gcc/libgcc2.c:513:1: internal compiler error: Segmentatio n fault Please submit a full bug report, Program received signal SIGSEGV, Segmentation fault. 0x022d7790 in dv_uid (dv=0x3616ec8) at ../../gcc/gcc/var-tracking.c:1043 1043return CSELIB_VAL_PTR (dv_as_value (dv))-uid; (gdb) by Undefined command: by. Try help. (gdb) bt #0 0x022d7790 in dv_uid (dv=0x3616ec8) at ../../gcc/gcc/var-tracking.c:1043 #1 0x022d7868 in dv_htab_hash (dv=0x3616ec8) at ../../gcc/gcc/var-tracking.c:1061 #2 0x022dd060 in add_value_chain (loc=0xfdf01e98, dvp=0x3616ed8) at ../../gcc/gcc/var-tracking.c:2745 ... (gdb) disass 0x022d7780 0x022d77a0 Dump of assembler code from 0x22d7780 to 0x22d77a0: 0x022d7780 dv_uid+36: ldw -24(r3),r26 0x022d7784 dv_uid+40: b,l 0x22d74b4 dv_as_value,rp 0x022d7788 dv_uid+44: nop 0x022d778c dv_uid+48: ldw 4(ret0),ret0 0x022d7790 dv_uid+52: ldw 4(ret0),ret0 0x022d7794 dv_uid+56: stw ret0,c(r3) 0x022d7798 dv_uid+60: b,l,n 0x22d7814 dv_uid+184,r0 0x022d779c dv_uid+64: ldw -24(r3),r26 End of assembler dump. (gdb) p/x $ret0 $1 = 0x0 -- Summary: [4.5 Regression] ICE in stage1 compiling __bswapdi2 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #1 from danglin at gcc dot gnu dot org 2010-03-17 14:30 --- d...@gsyprf11:~/gcc-4.5/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-nls --prefix=/home2/dave/opt/gnu/gcc/gcc-4.5.0 --with-local-prefix=/home2/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada Thread model: posix gcc version 4.5.0 20100317 (experimental) [trunk revision 157506] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 14:41 --- Can you attach preprocessed source? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-03-17 14:42 --- Mine. Looking into it now. We might even want to simply relax the checking if it triggers on lately build stuff like tinfos. Let me see if I can avoid tinfos producing mallformed decls. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-03-16 14:47:37 |2010-03-17 14:42:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug c++/43327] ICE in unifiy.c
--- Comment #3 from dodji at gcc dot gnu dot org 2010-03-17 14:55 --- A patch was proposed at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00662.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
[Bug tree-optimization/43401] Register not cleand correctly by acessing thru pointer
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-17 14:57 --- This is points-to information being computed wrongly. A lot was fixed for GCC 4.4.x in this area. The constraints are already wrong: arr = a arr.32 = b arr.64 = c arr.96 = d D.2332_12 = arr With 4.4 and 4.5 we do not create subvars for array elements and so end up with the valid arr = a arr = b arr = c arr = d D.2407_14 = arr Fixed as part of 2008-05-08 Richard Guenther rguent...@suse.de * tree-flow-inline.h (var_can_have_subvars): Move ... * tree-ssa-structalias.c (var_can_have_subvars): ... here. * tree-flow.h (var_can_have_subvars): Remove. (push_fields_onto_fieldstack): Remove. (sort_fieldstack): Likewise. (struct fieldoff): Move ... * tree-ssa-structalias.c (struct fieldoff): ... here. Remove alias_set and base_for_components fields. (sort_fieldstack): Make static. (push_fields_onto_fieldstack): Likewise. Remove code that handles anything but RECORD_TYPEs. Remove alias_set and base_for_components handling. (create_variable_info_for): Adjust. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Known to work||4.4.0 Last reconfirmed|-00-00 00:00:00 |2010-03-17 14:57:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43401
[Bug c/43404] New: ARM: Internal compiler error when using 'foo' in naked function
Tested with GCC 4.4.1 and 4.4.3 (custom built) on Arch Linux
host arch is x86_64 and target is arm-elf
This is the full source code needed to reproduce the bug:
void __data_abort(void) __attribute__ ((naked));
void __data_abort(void)
{
long foo;
long* bar = foo;
}
test.c: In function __data_abort:
test.c:5: warning: unused variable bar
test.c:5: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6835
---
% arm-elf-gcc -v -save-temps -Wall -c test.c -o test.o
Using built-in specs.
Target: arm-elf
Configured with: ../configure --prefix=/opt/arm-elf-gcc --target=arm-elf
--enable-interwork --enable-multilib --disable-threads --enable-languages=c,c++
--with-newlib
--with-headers=/home/marti/crosschain/gcc-4.4.3/build/../newlib-1.18.0/newlib/libc/include
Thread model: single
gcc version 4.4.3 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-o' 'test.o'
/opt/arm-elf-gcc/libexec/gcc/arm-elf/4.4.3/cc1 -E -quiet -v
-D__USES_INITFINI__ test.c -Wall -fpch-preprocess -o test.i
#include ... search starts here:
#include ... search starts here:
/opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/include
/opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/include-fixed
/opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/../../../../arm-elf/sys-include
/opt/arm-elf-gcc/lib/gcc/arm-elf/4.4.3/../../../../arm-elf/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-c' '-o' 'test.o'
/opt/arm-elf-gcc/libexec/gcc/arm-elf/4.4.3/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -auxbase-strip test.o -Wall -version -o test.s
GNU C (GCC) version 4.4.3 (arm-elf)
compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 913e44b5d872dc5aa4cdba7cf6499b83
test.c: In function __data_abort:
test.c:5: warning: unused variable bar
test.c:5: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6835
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ARM: Internal compiler error when using 'foo' in naked
function
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marti at juffo dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug c/43404] ARM: Internal compiler error when using 'foo' in naked function
--- Comment #1 from marti at juffo dot org 2010-03-17 15:03 --- Created an attachment (id=20128) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20128action=view) test.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43404
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17 15:03 --- Subject: Re: [4.5 Regression] ICE in stage1 compiling __bswapdi2 Can you attach preprocessed source? Attached. Dave --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-17 15:03 --- Created an attachment (id=20129) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20129action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug rtl-optimization/43058] [4.5 Regression] var-tracking uses up all virtual memory
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-17 15:05 --- Created an attachment (id=20130) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20130action=view) gcc45-pr43058.patch So far untested fix. This just optimizes handling of optimized out variables which are known to be constant (in some part of the code or whole function). We don't need to change the location list every time the constant value is assigned to some register or memory. That's unlike vars that actually live in some register or memory at some point, there of course we want to have the location for the register/memory so that the debugger can change it. The testcase keeps pushing .LC0 resp. LC1 into some register (or MEM slot) and then every call actually clobbers that reg resp. MEM slot, so after every set of the reg resp. mem var-tracking was generating up to 1000 var_location notes for every a decl with that value, then in the middle of every call another up to 1000 var_location notes that the var now is constant and doesn't live in the reg or mem. While it is IMHO desirable to do what this patch does in any case, I'll try to come up with another solution which would try to keep the location list less fragmented. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43058
[Bug c/43398] ICE with -O -floop-block
--- Comment #2 from spop at gcc dot gnu dot org 2010-03-17 15:13 --- This looks like a duplicate of PR42860. This works on gcc4.5. *** This bug has been marked as a duplicate of 42860 *** -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.5.0 Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43398
[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite
--- Comment #3 from spop at gcc dot gnu dot org 2010-03-17 15:13 --- *** Bug 43398 has been marked as a duplicate of this bug. *** -- spop at gcc dot gnu dot org changed: What|Removed |Added CC||scientica at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-17 15:14 --- See PR43398 for a nicely reduced testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug c/43381] [4.4/4.5 Regression] infinite loop in gcc.dg/parm-impl-decl-1.c with -g
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43381
[Bug c/43384] [4.3/4.4/4.5 Regression] ICE: Segmentation fault with invalid KR-like code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43384
[Bug c/43385] [4.5 Regression] glibc regex testsuite failures
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-17 15:19 --- Waiting for testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43385
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-17 15:21 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-03-17 15:21:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug middle-end/43365] [4.5 Regression] Destructor not called when returning in exception handler
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-17 15:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43365
[Bug c/43405] New: sinl is not computed correctly
sinl (and probably others) are not computed correctly. At least for large
inputs.
Please consider the following simple testcase:
$ cat sintest.c
#include stdio.h
#include math.h
int
main (void) {
double arg = 1e22;
long double larg = 1e22L;
printf(double precision: sin(1e22) = %.16lf\n, sin(arg));
printf(quad precison: sin(1e22)=%.16Lf\n, sinl(larg));
return 0;
}
$gcc sintest.c
$./a.out
double precision: sin(1e22) = -0.8522008497671888
quad precison: sin(1e22)=0.4626130407646018
This behavior is demonstrated by gcc-4.4.3 and gcc-4.5 (current snapshot)
I am using ubuntu on a 64 bit linux machine (intel).
However, the same results were obtained on different machines.
--
Summary: sinl is not computed correctly
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eli dot osherovich at gmail dot com
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
[Bug c/43405] sinl is not computed correctly
--- Comment #1 from eli dot osherovich at gmail dot com 2010-03-17 15:29 --- Created an attachment (id=20131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20131action=view) testcase as a standalone file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43405
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup. Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:
bb 2:
goto bb 9;
bb 3:
# start_16 = PHI mid_10(6), start_1(10)
# limit_19 = PHI limit_2(6), mid_10(10)
# lastMid_15 = PHI mid_10(6), mid_10(10)
bb 4:
# start_1 = PHI start_16(3)
# limit_2 = PHI limit_19(3)
# lastMid_3 = PHI mid_10(3)
D.2744_9 = start_1 + limit_2;
mid_10 = D.2744_9 / 2;
if (lastMid_3 == mid_10)
goto bb 8;
else
goto bb 5;
bb 6:
if (result_14 0)
goto bb 3;
else
goto bb 7;
bb 7:
D.2754_17 = cnvNameType[mid_10].type;
D.2753_18 = converterData[D.2754_17];
bb 8:
# D.2753_4 = PHI D.2753_18(7), 0B(4)
return D.2753_4;
bb 9:
# start_21 = PHI 0(2)
# limit_22 = PHI 3(2)
# lastMid_23 = PHI 4294967295(2)
D.2744_24 = start_1 + limit_2;
mid_25 = D.2744_9 / 2;
goto bb 10;
bb 5:
bb 10:
D.2746_12 = cnvNameType[mid_10].name;
result_14 = __builtin_strcmp (realName_13(D), D.2746_12);
if (result_14 0)
goto bb 3;
else
goto bb 6;
At that point the PHI nodes for BB 10 are still missing, and we have
registered these ssaname updates:
start_21 - { start_1 }
limit_22 - { limit_2 }
lastMid_23 - { lastMid_3 }
D.2744_24 - { D.2744_9 }
mid_25 - { mid_10 }
With the right PHI nodes at bb 10 the code still looks good. But somehow
cfgcleanup scrambles the whole thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-17 15:36 --- Um, we cleanup the CFG before updating SSA form, hence no wonder that the missing PHI nodes confuse it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1
--- Comment #4 from robertcnelson at gmail dot com 2010-03-17 15:42 --- Here here is the preprocessed source. http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/save-temps.log http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/libgcc2.i Results from running with: /opt/trunk/objdir/./gcc/xgcc -v -save-temps -B/opt/trunk/objdir/./gcc/ -B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/bin/ -B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/lib/ -isystem /opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/include -isystem /opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/opt/trunk/libgcc -I/opt/trunk/libgcc/. -I/opt/trunk/libgcc/../gcc -I/opt/trunk/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /opt/trunk/libgcc/../gcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS^C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43399
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-17 15:49 --- Hmm, create_edge_and_update_destination_phis is supposed to add new PHI arguments for the ultimate threading destination. But it only does so if there are already PHI nodes in that BB. We need to create new ones, which is difficult as we would have to create a new SSA name to hold the result, and rewrite all dominating uses. I wonder how this all is supposed to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #6 from hjl dot tools at gmail dot com 2010-03-17 15:51 --- It is caused by revision 157093: http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00676.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug c/43406] New: __builtin_popcountll fails with -O0 and -mpopcnt
Sample code:
#include stdio.h
int main (void)
{
long long a = 0xLL; // 48 bits set
int popcount;
#if 1
popcount = __builtin_popcountll (a);
#else
popcount = __popcountdi2 (a);
#endif
printf (%llx popcount = %d\n, a, popcount);
return 0;
}
If -mpopcnt is enabled, this code only outputs the correct value (48) when -O3
is on (apparently it's calculating it at compile time). Without optimizations,
it is apparently only counting the bits in the lower dword of the long long
variable.
OTOH, If __popcountdi2 is used, it works correctly (but according to the
assembly code it's not really using the popcnt instruction which means it's
much slower).
Test runs and output follow (note you need a CPU which supports the popcnt
instruction):
= gcc popcnt.c -o popcnt -Wall -O0 -mpopcnt ./popcnt
popcount = 32
= gcc popcnt.c -o popcnt -Wall -O3 -mpopcnt ./popcnt
popcount = 48
= gcc popcnt.c -o popcnt -Wall -O0 ./popcnt
popcount = 48
= gcc popcnt.c -o popcnt -Wall -O3 ./popcnt
popcount = 48
--
Summary: __builtin_popcountll fails with -O0 and -mpopcnt
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbarreira at gmail dot com
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43406
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-17 16:05 --- Hmm, I wonder how that could cause the bug. Probably because we can't rely on SSA form being uptodate during cfgcleanup, and hence looking up PHI arguments is wrong, at least for those SSA names that are registered for updating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug c/43406] __builtin_popcountll fails with -O0 and -mpopcnt
--- Comment #1 from rbarreira at gmail dot com 2010-03-17 16:35 --- Note that if you use scanf (%llx, a) and input instead of having a hardcoded value for a, the bug happens both with -O3 and -O0. To sum up it seems that when the popcnt instruction is actually issued, it's using a 32-bit instruction instead of 64-bit. -- rbarreira at gmail dot com changed: What|Removed |Added Summary|__builtin_popcountll fails |__builtin_popcountll fails |with -O0 and -mpopcnt |with -O0 and -mpopcnt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43406
[Bug bootstrap/43403] [4.5 Regression] ICE in stage1 compiling __bswapdi2
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-17 16:36 ---
var-tracking expects that if frame_pointer_rtx (resp. arg_pointer_rtx,
depending on whether FRAME_POINTER_CFA_OFFSET or ARG_POINTER_CFA_OFFSET is
defined)
is said to be eliminated (to stack_pointer_rtx in case of
!frame_pointer_needed), then it is actually eliminated. Apparently that's not
the case on PA, which happily uses both %r3 and %r30 in the code.
I guess
--- var-tracking.c.jj22010-03-17 15:29:42.0 +0100
+++ var-tracking.c2010-03-17 17:15:09.0 +0100
@@ -7942,6 +7942,11 @@ vt_init_cfa_base (void)
#else
cfa_base_rtx = arg_pointer_rtx;
#endif
+ if (cfa_base_rtx == hard_frame_pointer_rtx)
+{
+ cfa_base_rtx = NULL_RTX;
+ return;
+}
if (!MAY_HAVE_DEBUG_INSNS)
return;
can fix this, that will rule out PA with its arg_pointer_rtx ==
frame_pointer_rtx == hard_frame_pointer_rtx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43403
[Bug tree-optimization/43402] [4.5 Regression] dom1 miscompiles binary search
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-03-17 16:42 ---
(In reply to comment #7)
Hmm, I wonder how that could cause the bug. Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those SSA names that are registered for
updating.
But you can't have SSA names around when you rename its symbol. And only
with SSA names the lookup is performed.
After DOM (but before cfgcleanup completes) we have
bb 4:
# start_1 = PHI start_16(3)
# limit_2 = PHI limit_19(3)
# lastMid_3 = PHI mid_10(3)
D.1978_9 = start_1 + limit_2;
mid_10 = D.1978_9 1;
if (lastMid_3 == mid_10)
goto bb 8;
else
goto bb 5;
which is then simplified.
Hm. It seems we have a SSA name replacement table, thus probably the
cfgcleanup lookup code has to honor this.
The following seems to fix it:
Index: tree-cfgcleanup.c
===
*** tree-cfgcleanup.c (revision 157512)
--- tree-cfgcleanup.c (working copy)
*** cleanup_control_expr_graph (basic_block
*** 100,123
{
tree lhs = gimple_cond_lhs (stmt);
tree rhs = gimple_cond_rhs (stmt);
! /* For conditions try harder and lookup single-argument
! PHI nodes. Only do so from the same basic-block though
! as other basic-blocks may be dead already. */
! if (TREE_CODE (lhs) == SSA_NAME)
{
! gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
! if (gimple_code (def_stmt) == GIMPLE_PHI
!gimple_phi_num_args (def_stmt) == 1
!gimple_bb (def_stmt) == gimple_bb (stmt))
! lhs = PHI_ARG_DEF (def_stmt, 0);
! }
! if (TREE_CODE (rhs) == SSA_NAME)
! {
! gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
! if (gimple_code (def_stmt) == GIMPLE_PHI
!gimple_phi_num_args (def_stmt) == 1
!gimple_bb (def_stmt) == gimple_bb (stmt))
! rhs = PHI_ARG_DEF (def_stmt, 0);
}
val = fold_binary_loc (loc, gimple_cond_code (stmt),
boolean_type_node, lhs, rhs);
--- 100,126
{
tree lhs = gimple_cond_lhs (stmt);
tree rhs = gimple_cond_rhs (stmt);
! if (!name_mappings_registered_p ())
{
! /* For conditions try harder and lookup single-argument
! PHI nodes. Only do so from the same basic-block though
! as other basic-blocks may be dead already. */
! if (TREE_CODE (lhs) == SSA_NAME)
! {
! gimple def_stmt = SSA_NAME_DEF_STMT (lhs);
! if (gimple_code (def_stmt) == GIMPLE_PHI
!gimple_phi_num_args (def_stmt) == 1
!gimple_bb (def_stmt) == gimple_bb (stmt))
! lhs = PHI_ARG_DEF (def_stmt, 0);
! }
! if (TREE_CODE (rhs) == SSA_NAME)
! {
! gimple def_stmt = SSA_NAME_DEF_STMT (rhs);
! if (gimple_code (def_stmt) == GIMPLE_PHI
!gimple_phi_num_args (def_stmt) == 1
!gimple_bb (def_stmt) == gimple_bb (stmt))
! rhs = PHI_ARG_DEF (def_stmt, 0);
! }
}
val = fold_binary_loc (loc, gimple_cond_code (stmt),
boolean_type_node, lhs, rhs);
though the essence of r157093 was to capture single-valued PHI nodes
with constant operands, so we could restrict the lookup to consider
constants only.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-03-17 15:21:02 |2010-03-17 16:42:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
[Bug c++/43407] New: Specifying visibility attribute of C++0x enum class emits warning
If one specifies any visibility attribute on an enum class emits the type
attributes ignored after type is already defined warning.
Easy to reproduce! Just add the following lines anywhere and compile them
(without -Wno-attributes):
enum class __attribute__((visibility(default))) Number
{
Zero, One, Two
};
Obviously this isn't a major concern, since the end result is almost nothing
and
it certainly isn't wrong, since the non-finalized standard will not detail
any
of this behavior, but it kind of annoying in a slight way (barely).
--
Summary: Specifying visibility attribute of C++0x enum class
emits warning
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: travis at gockelhut dot com
GCC build triplet: 3
GCC host triplet: 4
GCC target triplet: 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43407
