[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2009-07-11 09:23 ---
Subject: Bug 40668

Author: jakub
Date: Sat Jul 11 09:23:32 2009
New Revision: 149511

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149511
Log:
PR target/40668
* function.c (assign_parm_setup_stack): Adjust
MEM_OFFSET (data->stack_parm) if promoted_mode is different
from nominal_mode on big endian.

* gcc.c-torture/execute/pr40668.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr40668.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668



[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #10 from jakub at gcc dot gnu dot org  2009-07-11 09:26 ---
Subject: Bug 40668

Author: jakub
Date: Sat Jul 11 09:26:23 2009
New Revision: 149512

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149512
Log:
PR target/40668
* function.c (assign_parm_setup_stack): Adjust
MEM_OFFSET (data->stack_parm) if promoted_mode is different
from nominal_mode on big endian.

* gcc.c-torture/execute/pr40668.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40668.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/function.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668



[Bug target/40710] SH: gcc-4.3.4 miscompiles linux kernel for sh4-linux

2009-07-11 Thread kkojima at gcc dot gnu dot org


--- Comment #2 from kkojima at gcc dot gnu dot org  2009-07-11 13:14 ---
I've tried to see what is going on.   fill_slots_from_thread
fills wrongly the delay slot of a conditional jmp insn with
"add #-4,r15" where r15 is the stack pointer register for SH.
fill_slots_from_thread computes the resource set for
the follow-through block with

mark_target_live_regs (get_insns (), opposite_thread, &opposite_needed);

and mark_target_live_regs uses df_get_live_in to get live regs
for the basic block including the opposite_thread insn which is

the first insn of the follow-through block:

(insn 32 46 35 fs/ext3/balloc.c:66 (parallel [
(asm_operands/v ("") ("") 0 []
 [] 2935777)
(clobber (mem:BLK (scratch) [0 A8]))
]) -1 (nil))

The resulting opssite_needed is

$1 = {memory = 0x1, unch_memory = 0x0, volatil = 0x0, cc = 0x0,
  regs = {0xf6,  0x0, 0x0, 0x0, 0x4}}

i.e. it seems that df_get_live_in doesn't count r15 as an live
register and fill_slots_from_thread picks "add #-4,r15" up as
an eligible insn to fill that delayed slot.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P4
   Last reconfirmed|-00-00 00:00:00 |2009-07-11 13:14:17
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40710



[Bug bootstrap/40719] New: [4.4 Regression] Revision 149512 caused botstrap failure on Linux/x86-64

2009-07-11 Thread hjl dot tools at gmail dot com
Revision 149512:

http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00392.html

caused:

/export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include -g -O2 -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I../../../src-4.4/libgcc -I../../../src-4.4/libgcc/.
-I../../../src-4.4/libgcc/../gcc -I../../../src-4.4/libgcc/../include
-I../../../src-4.4/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o _gcov_execvp.o -MT _gcov_execvp.o -MD -MP -MF
_gcov_execvp.dep -DL_gcov_execvp -c ../../../src-4.4/libgcc/../gcc/libgcov.c
../../../../src-4.4/libgcc/../gcc/libgcov.c: In function 'gcov_exit':
../../../../src-4.4/libgcc/../gcc/libgcov.c:210: internal compiler error: tree
check: expected tree_vec, have var_decl in build_int_cst_wide, at tree.c:967
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[8]: *** [_gcov.o] Error 1

on Linux/x86-64 when configured with

--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld


-- 
   Summary: [4.4 Regression] Revision 149512 caused botstrap failure
on Linux/x86-64
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40719



[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument

2009-07-11 Thread jvdelisle at gcc dot gnu dot org


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-07-11 15:15 
---
Marked as regression.  Not platform specific.  I confirmed this on x86-64
Linux.

We have an illegal seek in transfer.c (next_record_w_unf) at line 2824.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.1 4.5.0
  Known to work||4.3.4
Summary|Fortran runtime error:  |[4.4, 4.5 Regression]
   |Invalid argument|Fortran runtime error:
   ||Invalid argument


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714



[Bug target/38642] [4.3/4.4/4.5 Regression] Code with -fPIC results in segfault on ARM (old ABI)

2009-07-11 Thread mikpe at it dot uu dot se


--- Comment #5 from mikpe at it dot uu dot se  2009-07-11 15:23 ---
The bug occurs on OABI with gcc-4.3-20090705 but not with gcc-4.4-20090707.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642



[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code

2009-07-11 Thread mikpe at it dot uu dot se


--- Comment #13 from mikpe at it dot uu dot se  2009-07-11 15:34 ---
(In reply to comment #12)
> would be interesting to know what fixed this on the trunk.

A binary search on trunk identified revision 138207 as the point that fixed
this ICE. That revision is a large merge from gimple-tuples-branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072



[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code

2009-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2009-07-11 15:40 
---
Bah.  So this then becomes "it would be interesting to know what fixed this on
the gimple-tuples-branch" ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072



[Bug fortran/40714] [4.4, 4.5 Regression] Fortran runtime error: Invalid argument

2009-07-11 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-07-11 17:16 
---
Another aspect of this bug.  If we do this:

PROGRAM test
OPEN(UNIT=32,FILE="fort.32",STATUS="NEW",ACCESS="SEQUENTIAL",FORM="UNFORMATTED")
!READ(32,END=100)
100 CONTINUE
WRITE (32)
END PROGRAM test

We get:

$ gfc pr40714.f90
$ ./a.out 
$ xxd fort.32 
000:      

The correct result should be:

$ gfc43 -static pr40714.f90
$ ./a.out 
$ xxd fort.32 
000:      

So we need to correctly handle both error recovery and empty writes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714



[Bug lto/40721] [LTO] complains about two tentative definitions

2009-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-07-11 17:53 ---
Cases like

t1.c
int i = 2;

t2.c
int i = 1;
int main() { return i; }

are diagnosed by the linker - not ideal, but not different from -fno-lto
either.


Index: lto-symtab.c
===
--- lto-symtab.c(revision 149512)
+++ lto-symtab.c(working copy)
@@ -568,15 +568,17 @@ lto_symtab_merge_decl (tree new_decl,
   if (resolution == LDPR_PREVAILING_DEF
   || resolution == LDPR_PREVAILING_DEF_IRONLY)
 {
-  if (old_resolution == LDPR_PREVAILING_DEF
- || old_resolution == LDPR_PREVAILING_DEF_IRONLY)
+  if ((old_resolution == LDPR_PREVAILING_DEF
+  || old_resolution == LDPR_PREVAILING_DEF_IRONLY)
+ && old_resolution != resolution)
{
  error ("%J%qD has already been defined", new_decl, new_decl);
  error ("%Jpreviously defined here", old_decl);
  return;
}
   gcc_assert (old_resolution == LDPR_PREEMPTED_IR
- || old_resolution ==  LDPR_RESOLVED_IR);
+ || old_resolution ==  LDPR_RESOLVED_IR
+ || old_resolution == resolution);
   lto_symtab_set_identifier_decl (name, new_decl);
   return;
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40721



[Bug lto/40721] New: [LTO] complains about two tentative definitions

2009-07-11 Thread rguenth at gcc dot gnu dot org
This breaks a lot of benchmarks in SPEC CPU 2000.

t.c

int i;

t2.c

int i;
int main() { return i; }

$ ./xgcc -B. -o t t1.c t2.c
$ ./xgcc -B. -o t t1.c t2.c -flto
t2.c:1:5: error: 'i' has already been defined
t1.c:1:5: error: previously defined here
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

the LTO behavior is wrong for C.  The testcase would violate the C++ ODR, but
LTO should not reject the valid C program (note ODR violations do not need to
be diagnosed).


-- 
   Summary: [LTO] complains about two tentative definitions
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40721



[Bug c++/40720] New: Optimizer Bug: bad register name

2009-07-11 Thread mckelvey at maskull dot com
Code compiles fine w/o O3. Recent SVN. I'm unsure how to proceed, as temp files
will be very large. I don't know where to begin making a smaller testcase.
Please advise.

uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.7.0(0.210/5/3) 2009-06-18 12:51 i686 Cygwin

g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/e/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --enable-checking=release
--disable-win32-registry --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090705 (experimental) (GCC) 

BUILDING:
alias CONFIGURECVS='/cygdrive/e/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --enable-checking=release
--disable-win32-registry --enable-languages=c,c++ 2>&1 | tee clog'

alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g
-O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap 2>&1 |
tee log'


g++ -c  -O3 -DNDEBUG  -DUSE_MUTEX=1 -findirect-inlining -Winline
-pedantic-errors -Werror -ansi -fno-common -Wall -Wold-style-cast -Wsign-promo
-Wpointer-arith -Wundef -Wwrite-strings -Winvalid-pch -Woverloaded-virtual
-Wcast-qual -Wextra -Wredundant-decls -Wshadow -Wcast-align -Wcomment
-fstrict-aliasing -Winit-self -Wmissing-include-dirs -Wswitch-default
-Wswitch-enum -Wlogical-op -Wconversion -Wsign-conversion
-Wmissing-declarations -Wdeprecated -ftree-switch-conversion -Wuninitialized
-Wparentheses -Wunused -MMD  -fimplicit-templates -I. -I.. -o test054.o
test054.cc
/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp/cchrs5yb.s: Assembler messages:
/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp/cchrs5yb.s:77000: Warning: end of file
not at end of a line; newline inserted
/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp/cchrs5yb.s:77764: Error: bad register
name `%'

File cchrs5yb.s no longer exists.


-- 
   Summary: Optimizer Bug: bad register name
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40720



[Bug debug/40713] Overlapping .debug_ranges (C++)

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2009-07-11 17:42 ---
Subject: Bug 40713

Author: jakub
Date: Sat Jul 11 17:41:59 2009
New Revision: 149514

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149514
Log:
PR debug/40713
* dwarf2out.c (dw_fde_struct): Add in_std_section and
cold_in_std_section bits.
(dwarf2out_begin_prologue): Initialize them.
(dwarf2out_finish): Don't emit FDE range into .debug_ranges
if already covered by text_section or cold_text_section range.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713



[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #12 from jakub at gcc dot gnu dot org  2009-07-11 17:40 ---
Subject: Bug 40667

Author: jakub
Date: Sat Jul 11 17:40:29 2009
New Revision: 149513

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149513
Log:
PR rtl-optimization/40667
* defaults.h (MINIMUM_ALIGNMENT): Define if not defined.
* doc/tm.texi (MINIMUM_ALIGNMENT): Document it.
* config/i386/i386.h (MINIMUM_ALIGNMENT): Define.
* config/i386/i386.c (ix86_minimum_alignment): New function.
* config/i386/i386-protos.h (ix86_minimum_alignment): New prototype.
* cfgexpand.c (expand_one_var): Use MINIMIM_ALIGNMENT.
* emit-rtl.c (gen_reg_rtx): Likewise.
* function.c (assign_parms): Likewise.  If nominal_type needs
bigger alignment than FUNCTION_ARG_BOUNDARY, use its alignment
rather than passed_type's alignment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/defaults.h
trunk/gcc/doc/tm.texi
trunk/gcc/emit-rtl.c
trunk/gcc/function.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667



[Bug lto/40721] [LTO] complains about two tentative definitions

2009-07-11 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-07-11 18:05 ---
Note this is only true for the non -fno-common case.  Really this is an
extension to the standard C language but we should support it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40721



[Bug lto/40721] [LTO] complains about two tentative definitions

2009-07-11 Thread rguenther at suse dot de


--- Comment #3 from rguenther at suse dot de  2009-07-11 18:09 ---
Subject: Re:  [LTO] complains about two tentative
 definitions

On Sat, 11 Jul 2009, pinskia at gcc dot gnu dot org wrote:

> --- Comment #2 from pinskia at gcc dot gnu dot org  2009-07-11 18:05 
> ---
> Note this is only true for the non -fno-common case.  Really this is an
> extension to the standard C language but we should support it.

You mean it is only true for -fcommon (which is the default)?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40721



[Bug lto/40721] [LTO] complains about two tentative definitions

2009-07-11 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-07-11 18:19 ---
(In reply to comment #3)
> Subject: Re:  [LTO] complains about two tentative
>  definitions
> 
> On Sat, 11 Jul 2009, pinskia at gcc dot gnu dot org wrote:
> 
> > --- Comment #2 from pinskia at gcc dot gnu dot org  2009-07-11 18:05 
> > ---
> > Note this is only true for the non -fno-common case.  Really this is an
> > extension to the standard C language but we should support it.
> 
> You mean it is only true for -fcommon (which is the default)?

What I write is the same as what your wrote (I had  two negatives ;) .

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40721



[Bug bootstrap/40719] [4.4 Regression] Revision 149512 caused botstrap failure on Linux/x86-64

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2009-07-11 18:40 ---
4.4 branch configured without --enable-checking=yes shouldn't do any checking.
Anyway, I've bootstrapped 4.4 branch after that checkin on both x86_64-linux
and i686-linux without any problem, both without --enable-checking=yes and with
it.

Are you sure it is reproducible and caused by that checkin?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40719



[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #13 from jakub at gcc dot gnu dot org  2009-07-11 19:06 ---
Subject: Bug 40667

Author: jakub
Date: Sat Jul 11 19:06:26 2009
New Revision: 149517

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149517
Log:
PR rtl-optimization/40667
* defaults.h (MINIMUM_ALIGNMENT): Define if not defined.
* doc/tm.texi (MINIMUM_ALIGNMENT): Document it.
* config/i386/i386.h (MINIMUM_ALIGNMENT): Define.
* config/i386/i386.c (ix86_minimum_alignment): New function.
* config/i386/i386-protos.h (ix86_minimum_alignment): New prototype.
* cfgexpand.c (expand_one_var): Use MINIMIM_ALIGNMENT.
* emit-rtl.c (gen_reg_rtx): Likewise.
* function.c (assign_parms): Likewise.  If nominal_type needs
bigger alignment than FUNCTION_ARG_BOUNDARY, use its alignment
rather than passed_type's alignment.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/cfgexpand.c
branches/gcc-4_4-branch/gcc/config/i386/i386-protos.h
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/config/i386/i386.h
branches/gcc-4_4-branch/gcc/defaults.h
branches/gcc-4_4-branch/gcc/doc/tm.texi
branches/gcc-4_4-branch/gcc/emit-rtl.c
branches/gcc-4_4-branch/gcc/function.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667



[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

2009-07-11 Thread jakub at gcc dot gnu dot org


--- Comment #14 from jakub at gcc dot gnu dot org  2009-07-11 19:07 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667



[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions

2009-07-11 Thread hubicka at gcc dot gnu dot org


--- Comment #8 from hubicka at gcc dot gnu dot org  2009-07-11 19:08 ---
Fixed.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40388



[Bug libstdc++/40712] locale(const locale&, const char*, locale::category) can create broken locale

2009-07-11 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-11 19:43 
---
I think this constructor never ever worked correctly. The only solution I can
see at the moment is consistently dynamically allocating _M_data->_M_grouping,
and copying the characters of __nl_langinfo_l(__MON_GROUPING, __cloc) into it
as part of _M_initialize_moneypunct. The same for the other C strings, for
numpunct too, of course. Isn't such a big issue, after all, but I'm rather
surprised that we didn't notice the issue much earlier: destroying the __cloc
at the end of locale::_Impl::_Impl(const char*, size_t) after having referred
to the various __nl_langinfo_l(..., __cloc) in _M_initialize_moneypunct without
actually copying the data should unavoidably cause problems...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40712



[Bug target/39429] compiler create bad asm codes.

2009-07-11 Thread mikpe at it dot uu dot se


--- Comment #3 from mikpe at it dot uu dot se  2009-07-11 20:20 ---
It seems that cpu type and tuning options make a difference here. If I compile
with -mcpu and -mtune referring to a cpu that does not imply FL_LDSCHED, such
as arm740t, then I get the broken code that clobbers r0 before loading r3.
Changing cpu and tune types to a cpu that does imply FL_LDSCHED, such as arm8
or xscale, then r3 is loaded before r0 is clobbered and the sub becomes an rsb.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429



[Bug bootstrap/18252] if the last fn in lib2funcs is implemented in lib1asmfuncs, configuration can fail

2009-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2009-07-11 21:37 ---
Likely fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18252



[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274

2009-07-11 Thread d dot g dot gorbachev at gmail dot com


--- Comment #5 from d dot g dot gorbachev at gmail dot com  2009-07-11 
21:55 ---
See also bug 40716.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886



[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274

2009-07-11 Thread d dot g dot gorbachev at gmail dot com


--- Comment #6 from d dot g dot gorbachev at gmail dot com  2009-07-11 
21:55 ---
*** Bug 40716 has been marked as a duplicate of this bug. ***


-- 

d dot g dot gorbachev at gmail dot com changed:

   What|Removed |Added

 CC||d dot g dot gorbachev at
   ||gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886



[Bug middle-end/40716] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2323

2009-07-11 Thread d dot g dot gorbachev at gmail dot com


--- Comment #3 from d dot g dot gorbachev at gmail dot com  2009-07-11 
21:55 ---


*** This bug has been marked as a duplicate of 39886 ***


-- 

d dot g dot gorbachev at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40716



[Bug target/40722] New: ia32intrin.h defines of _rotl, _rotr conflict with target stdlib.h decls.h

2009-07-11 Thread dannysmith at users dot sourceforge dot net
These defines in ia32intrin.h 

#define _lrotl(a,b) __rold((a), (b))
#define _lrotr(a,b) __rord((a), (b))
...
#define _rotl(a,b)  __rold((a), (b))
#define _rotr(a,b)  __rord((a), (b))


conflict with mingw32 stdlib.h which
declares those names as functions

_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotl(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned int __cdecl __MINGW_NOTHROW _rotr(unsigned int, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotl(unsigned long, int)
__MINGW_ATTRIB_CONST;
_CRTIMP unsigned long __cdecl __MINGW_NOTHROW _lrotr(unsigned long, int)
__MINGW_ATTRIB_CONST;


This is caught by  g++.dg/other/i386-[23456].C


-- 
   Summary: ia32intrin.h defines of _rotl, _rotr conflict with
target stdlib.h  decls.h
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40722



[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

2009-07-11 Thread hubicka at gcc dot gnu dot org


--- Comment #4 from hubicka at gcc dot gnu dot org  2009-07-11 22:34 ---
OK,
this is interesting case.  We have:

  # BLOCK 6
  # PRED: 2 [61.0%]  (true,exec) 3 [61.0%]  (true,exec) 4 [39.0%]  (true,exec)
5 [100.0%]  (fallthru,exec)
  # D.2735_12 = PHI <0(2), 0(3), 0(4), 1(5)>
  # .MEM_21 = PHI <.MEM_22(2), .MEM_25(3), .MEM_27(4), .MEM_27(5)>
  goto ;
  # SUCC: 8 [100.0%]  (fallthru,exec)

This block exists only because of D.2735_12 def that gets removed.  Now we 
also eliminate conditional of BB 4:

  # BLOCK 4
  # PRED: 3 [39.0%]  (false,exec)
  # .MEM_26 = VDEF <.MEM_25>
  xmsih.2_10 = f1 ();
  # .MEM_27 = VDEF <.MEM_26>
  xmsih = xmsih.2_10;
  # VUSE <.MEM_27>
  xmsih.3_11 = xmsih;
  if (xmsih.3_11 == 0)
goto ;
  else
goto ;
  # SUCC: 6 [39.0%]  (true,exec) 5 [61.0%]  (false,exec)

and redirect it to the first live post dominator, that is BB 8 skipping BB 6
that is on the way but dead since it contains dead PHI and virtual PHI ignored
for liveness.

Now everythign would go well, since BB 6 would get removed and result of its
virtual PHI would be eliminated and symbol sent for renaming by previously
discussed if (cfg_altered) code, if we didn't had the other two live
predecestors BB 2 and 3.  Those don't contain dead control flow statement and
thus does not get updated.

The BB becomes dead later during cleanup_cfg done before update_ssa and
update_ssa fails.

I see two ways to fix this:

1) Make SSA DCE to forward every control flow edge in program to first live
post dominator (this is in original formulation of program) so we can rely on
fact that code removing unreachable BB in tree-ssa-dce will handle the PHIs.
I am bit affraid that it will be difficult to handle well all the corner cases
where edges gets identified and such, but I can give it a try.
2) Move the if (cfg_altered) code into unreachable blocks removal.  Unreachable
blocks removal is run on SSA prepared for updating in other cases too, so it
would make sense.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676



[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

2009-07-11 Thread hubicka at ucw dot cz


--- Comment #5 from hubicka at ucw dot cz  2009-07-11 22:45 ---
Subject: Re:  [4.5 Regression] internal compiler error: verify_ssa error:
definition in block 5 does not dominate use in block 7

Thinking about this more, we change here dominance relation in
not-so-obvious way.  It is not really textbook case with presence of
both abnormal edges that might prevent forwarding consistently
everything across the empty BBs and virtual operands that may remain in
the BBs otherwise empty.

I think we need
1) forward the edges in the tree-ssa-dce itself (i.e. don't do the edge
forwarding only when control flow stmt becomes dead but for every edge
leading to dead BB that is not abnormal)
2) for empty BBs that remains in the program (only reason would be
because they are destination of abnormal edge), send all virtual PHIs
for updating since we can not be sure dominance relations are preserved.

Sounds sane?  If so, I will give it a try tomorrow.

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40676



[Bug c++/40723] New: Optimizer Causes Undefined References

2009-07-11 Thread mckelvey at maskull dot com
Valid code that links fine without optimization gets undefined references at
-O3. The references are to such as vtable, L8185, WinMain, etc.

Full log attached. I await direction as to what to provide to help solve this.
Temps will be fairly large, and I don't know how to approach a smaller test
case.

(Compile error in log has been separately reported.)

Cygwin and svn update are recent.


uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.7.0(0.210/5/3) 2009-06-18 12:51 i686 Cygwin

g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/e/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --enable-checking=release
--disable-win32-registry --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090705 (experimental) (GCC) 

BUILDING:
alias CONFIGURECVS='/cygdrive/e/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --enable-checking=release
--disable-win32-registry --enable-languages=c,c++ 2>&1 | tee clog'

alias BUILD='nice make CFLAGS='\'''\'' BOOT_CFLAGS='\'''\'' LIBCFLAGS='\''-g
-O'\'' CXXFLAGS='\''-O'\'' LIBCXXFLAGS='\''-g -O'\'' bootstrap 2>&1 |
tee log'


-- 
   Summary: Optimizer Causes Undefined References
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40723



[Bug c++/40723] Optimizer Causes Undefined References

2009-07-11 Thread mckelvey at maskull dot com


--- Comment #1 from mckelvey at maskull dot com  2009-07-12 00:13 ---
Created an attachment (id=18178)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18178&action=view)
Build that shows errors


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40723



[Bug c++/40723] Optimizer Causes Undefined References

2009-07-11 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-07-12 00:15 ---
this looks like a different problem, that is an error is causing gcc to leave
behind a .o file which is invalid ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40723



[Bug debug/40599] [4.5 regression] GCC error in pre_and_rev_post_order_compute, at cfganal.c:1045

2009-07-11 Thread oliver dot kellogg at eads dot com


--- Comment #7 from oliver dot kellogg at eads dot com  2009-07-12 04:41 
---
> --- Comment #2 From Oliver Kellogg  2009-06-30 10:49  [reply] ---
> 
> Does not happen with 4.5.0 trunk 20090406 and earlier versions.

Pardon, the version used was 20090314.
Does happen with 20090506 (r147182).
Building 20090406 r145578 now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599



[Bug debug/40599] [4.5 regression] GCC error in pre_and_rev_post_order_compute, at cfganal.c:1045

2009-07-11 Thread oliver dot kellogg at eads dot com


--- Comment #8 from oliver dot kellogg at eads dot com  2009-07-12 05:28 
---
> Building 20090406 r145578 now.

Does not happen there - problem must be between 20090406 and 20090506.
Does further narrowing down make sense?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599