[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[bonzini at gnu dot org]

--- Comment #5 from bonzini at gnu dot org  2009-01-02 08:17 ---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

Kenneth Zadeck wrote:
> 2009-01-01  Kenneth Zadeck 
> 
> PR rtl-optimization/35805
> * df-problems.c (df_lr_finalize): Add recursive call to resolve lr
> problem if fast dce is able to remove any instructions.
> * dce.c (dce_process_block): Fix dump message.
>
> This patch fixes the problem.  The comment in the patch describes the
> issue.Since this was not really a failure, it would be hard to make
> this issue into a testcase.

IIUC the bugzilla comment trail, this caused
gcc.c-torture/compile/930523-1.c to fail with --enable-checking=df;
that's already a testcase.

> Ok to commit?

Hmmm... I am not sure I like this patch, for two reasons.

1) it might incur a compile-time penalty for the sake of verification,
even with df checking disabled.  OTOH having possibly different code for
checking and non-checking compilation is even worse.

2) there are already provisions in dce.c to redo the analysis.  But they
do not get to the least fixed point because they just rebuild the local
bitmaps and iterate from the existing solution.  Instead of iterating
"while (global_changed)", we could try doing only one iteration (it's a
fast DCE after all, and the pessimistic dataflow makes me guess that
subsequent DCE iterations won't find much?) and zap the solution there.
 This has the advantage that we can skip the recomputation if
global_changed is false.

Did I miss anything?

Paolo


-- 


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

[Bug middle-end/38690] [4.4 Regression] Missing parentheses for (a-1)/2 in final_cleanup

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 08:30:44
   date||


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

[Bug tree-optimization/38691] New: missed optimization with const pointers

[tkoenig at gcc dot gnu dot org]

This is one possible C equivalent of PR 23169, a Fortran PR.

$ cat foo.c
void bar(const int *, const int *);

int foo(const int *b, const int *c)
{
int d,e;
d = *b;
e = *c;

bar(b, c);
return (d- *b) + (e - *c);
}
$ gcc -O3 -fdump-tree-optimized -S foo.c
$ cat foo.c.123t.optimized

;; Function foo (foo)

Analyzing Edge Insertions.
foo (const int * b, const int * c)
{
  int e;
  int d;

:
  d = *b;
  e = *c;
  bar (b, c);
  return ((e - *b) + d) - *c;

}

Without the call to bar, the function is optimized
to "return 0".  This should be possible even with the
call to bar, because all pointers in sight are marked const.


-- 
   Summary: missed optimization with const pointers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: alias
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
OtherBugsDependingO 23169
 nThis:


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

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

--- Comment #9 from laurent at guerby dot net  2009-01-02 10:11 ---
Thanks Jakub, I'm testing:

Index: gcc/config.host
===
--- gcc/config.host (revision 142984)
+++ gcc/config.host (working copy)
@@ -125,6 +125,9 @@
 ;;
 esac
 case ${host} in
+  arm*-*-linux-gnueabi )
+host_xmake_file="${host_xmake_file} x-cflags-O1"
+;;
   *-*-linux* )
if test "${GCC}:${ac_cv_sizeof_long}" = yes:4; then


-- 


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

[Bug tree-optimization/38691] missed optimization with const pointers

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-02 10:27 ---
const doesn't have any semantic meaning.  Which means that it is valid for bar
to change the memory pointed to by its arguments - just not through the const
qualified pointers.

There is no way to tell the middle-end about anonymous readonly memory.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-01-02 10:29 ---
There is no way to tell the middle-end about anonymous readonly memory.


-- 


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

[Bug fortran/23169] INTENT information not used in the middle-end for optimizations

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2009-01-02 11:04 ---
(In reply to comment #8)
> There is no way to tell the middle-end about anonymous readonly memory.

So, we could either

- teach that to the middle-end (I couldn't, though :-)

- make a duplicate variable for intent(in) variables, to transfer
  the test case from comment #4 into

integer function foo(b,c) 
  integer, intent(in) :: b, c
  integer :: b_shadow, c_shadow;
  integer :: d, e
  b_shadow = b;
  c_shadow = c;
  d = b_shadow;
  e = c_shadow;
  call bar(b,c)

  foo = d-b_shadow + e-c_shadow;
end function foo


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


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

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-01-02 11:23 ---
That won't work, this is surrounded by:
case ${host} in
  rs6000-*-* \
  | powerpc*-*-* )

You want to do it at the same level, so:
--- config.host2008-12-27 10:12:25.0 +0100
+++ config.host2009-01-02 12:23:10.0 +0100
@@ -146,6 +146,9 @@ case ${host} in
 ;;
 esac
 ;;
+  arm*-*-linux-gnueabi )
+host_xmake_file="${host_xmake_file} x-cflags-O1"
+;;
 esac

 # Machine-specific settings.


-- 


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

[Bug classpath/38190] ConcurrentHashMap.java: 2 * unused local variables

[gnu_andrew at member dot fsf dot org]

--- Comment #1 from gnu_andrew at member dot fsf dot org  2009-01-02 11:30 
---
This is external code maintained here:

http://g.oswego.edu/dl/concurrency-interest/


-- 

gnu_andrew at member dot fsf dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/38593] [4.4 regression] ICE: verify_gimple failed

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2009-01-02 11:34 ---
That's unexpected.  Anyway, if you move away the gch file (or directory), can
you still reproduce it and if yes, attach preprocessed source?

Otherwise it would be extremely hard to reproduce for anyone...


-- 


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

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-01-02 11:50 ---
Confirmed with gcc-4.3.2-1 Debian gnueabi:
$ gcc -c -O1 pr36466.c
pr36466.c: In function ‘ReadCfgFile’:
pr36466.c:19: internal compiler error: in choose_reload_regs, at reload1.c:6190

And on trunk rev 142984:
pr36466.c: In function 'ReadCfgFile':
pr36466.c:19: internal compiler error: in choose_reload_regs, at reload1.c:6470


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 11:50:37
   date||


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

[Bug target/36466] internal compiler error: in choose_reload_regs, at reload1.c:6190

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2009-01-02 11:53 ---
backtrace on trunk:

(gdb) bt
#0  fancy_abort (file=0x786084 "../../trunk/gcc/reload1.c", line=6470,
function=0x785f8c "choose_reload_regs") at ../../trunk/gcc/diagnostic.c:712
#1  0x002ba378 in choose_reload_regs (chain=) at
../../trunk/gcc/reload1.c:6470
#2  0x002baf08 in reload_as_needed (live_known=) at
../../trunk/gcc/reload1.c:4240
#3  0x002bf868 in reload (first=, global=) at ../../trunk/gcc/reload1.c:1169
#4  0x0068815c in rest_of_handle_ira () at ../../trunk/gcc/ira.c:2018
#5  0x0026ebc8 in execute_one_pass (pass=0x91fa54) at
../../trunk/gcc/passes.c:1279
#6  0x0026ee34 in execute_pass_list (pass=0x91fa54) at
../../trunk/gcc/passes.c:1328
#7  0x0026ee4c in execute_pass_list (pass=0x91a390) at
../../trunk/gcc/passes.c:1329
#8  0x003726f4 in tree_rest_of_compilation (fndecl=0x40232780) at
../../trunk/gcc/tree-optimize.c:419
#9  0x004e92d4 in cgraph_expand_function (node=0x401b0900) at
../../trunk/gcc/cgraphunit.c:1047
#10 0x004eb35c in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1106
#11 0x0001cabc in c_write_global_declarations () at
../../trunk/gcc/c-decl.c:8074
#12 0x0031e58c in toplev_main (argc=, argv=) at ../../trunk/gcc/toplev.c:981
#13 0x40095dfc in __libc_start_main () from /lib/libc.so.6
#14 0xaa7c in _start ()


-- 


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

[Bug bootstrap/38523] [4.4 regression] arm build fails to link cc1-dummy

[laurent at guerby dot net]

--- Comment #11 from laurent at guerby dot net  2009-01-02 11:56 ---
Yep I spotted my obvious mistake :), the patch I'm testing:

Index: gcc/config.host
===
--- gcc/config.host (revision 143006)
+++ gcc/config.host (working copy)
@@ -148,6 +148,13 @@
 ;;
 esac

+case ${host} in
+  arm*-*-linux-gnueabi )
+# To avoid stage1 link failure due to linker limitations.
+host_xmake_file="${host_xmake_file} x-cflags-O1"
+;;
+esac
+
 # Machine-specific settings.
 case ${host} in
   alpha*-dec-*vms*)


-- 


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

[Bug target/36415] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-01-02 12:02 ---
Confirmed on 4.3.2-1 Debian gnueabi

gue...@gcc50:~$ g++ -c -O1 pr36415.c 
pr36415.c:29: warning: inline function ‘const UChar*
icu_3_4::UnicodeString::getBuffer() const’ used but never defined
pr36415.c: In member function ‘virtual UBool icu_3_4::RegexMatcher::find()’:
pr36415.c:128: error: unrecognizable insn:
(insn 70 41 42 3 pr36415.c:122 (set (reg:SI 0 r0)
(plus:SI (reg:SI 3 r3 [156])
(mult:SI (reg/v:SI 1 r1 [orig:138 opValue ] [138])
(const_int 32 [0x20] -1 (nil))
pr36415.c:128: internal compiler error: in extract_insn, at recog.c:1990

But this compiles fine at -O0/1/2/3 on trunk rev 142808


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
   Keywords||ice-on-valid-code
  Known to fail||4.3.2
  Known to work||4.4.0
Summary|internal compiler error: in |[4.3 regression] internal
   |extract_insn, at|compiler error: in
   |recog.c:1990|extract_insn, at
   ||recog.c:1990


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

[Bug target/36415] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2009-01-02 12:02 ---
confirmed


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 12:02:52
   date||


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

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-01-02 12:06 ---
Fixed on 4.3.2-1 Debian gnueabi and on trunk at rev 142808 (tested native)


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/33147] ICE: SEGV compiling for -mcpu=ep9312 -mfpu-maverick -mhard-float -O

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-01-02 12:08 ---
Works on gcc 4.3.2-1 Debian gnueabi and trunk at rev 142984.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/38643] Doesn't hide (visibility-wise) vtables and VTTs on ARM EABI

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-01-02 12:13 ---
Confirmed on 4.3.2-1 Debian gnueabi

But it looks like it's fixed on trunk rev 142808
 g O .rodata000c .hidden _ZTV1A
  wO .rodata._ZTV1B 000c .hidden _ZTV1B


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.3.2
  Known to work||4.4.0
 Resolution||FIXED


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

[Bug java/33218] Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT

[laurent at guerby dot net]

--- Comment #14 from laurent at guerby dot net  2009-01-02 12:17 ---
Removing host


-- 

laurent at guerby dot net changed:

   What|Removed |Added

   GCC host triplet|arm_le, x86 - native|
   |compilation |


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

[Bug debug/16442] Crossbuilding the Ada RTS fails

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-01-02 12:20 ---
As of 4.4 cross compiling Ada to ARM works (but for exceptions but that's
another issue).


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe

[laurent at guerby dot net]

--- Comment #8 from laurent at guerby dot net  2009-01-02 12:25 ---
Seems to work on 4.3.2-1 Debian gnueabi

gue...@gcc50:~$ g++ pr14202.c 
gue...@gcc50:~$ ./a.out
gue...@gcc50:~$ echo $?
0

Do you confirm?

Ada exceptions are not working on this target (neither sjlj nor unwind) but
this is for another report.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
 Status|NEW |WAITING


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

[Bug target/32838] gcc generates incorrect trampoline code in thumb mode

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2009-01-02 12:29 ---
This needs a testcase


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/38692] New: ep9312/maverick code generation is broken

[martinwguy at yahoo dot it]

The Cirrus MaverickCrunch code generator has never worked. For example:

#include 
main()
{
int i; double d;
for (i=3, d=3; i<=5; i++, d++) {
printf("%g", d);
if (d < 4.0) printf(" lt";
if (d > 4.0) printf(" gt");
if (d <= 4.0) printf(" le");
if (d >= 4.0) printf(" ge");
putchar('\n');
}
}

should output

3 lt le
4 le ge
5 gt ge

but outputs

3 lt le
4 le ge
5 lt gt le ge

There is a set of patches to cleanly fix code generation in EABI environment
under http://martinwguy.co.uk/martin/crunch as weel as description of the
Maverick's other problems and how they are addressed.


-- 
   Summary: ep9312/maverick code generation is broken
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martinwguy at yahoo dot it
GCC target triplet: arm-linux-gnueabi


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

[Bug target/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1

[laurent at guerby dot net]

--- Comment #6 from laurent at guerby dot net  2009-01-02 12:38 ---
gcc-4.3.2-1 debian gnueabi
pr29693.c: In function ‘init_dwarf_reg_size_table’:
pr29693.c:4: internal compiler error: in arm_dbx_register_number, at
config/arm/arm.c:18276


On trunk 142984
pr29693.c: In function 'init_dwarf_reg_size_table':
pr29693.c:4: internal compiler error: in arm_dbx_register_number, at
config/arm/arm.c:18631


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
   Keywords||ice-on-valid-code


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

[Bug c++/31092] variable-size array confused by exceptions

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-01-02 12:48 ---
Works fine in 4.3.2-1 debian gnueabi and trunk rev 142808


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/38693] New: gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses "USE_GAS" which is undefined

[rob1weld at aol dot com]

# uname -a
SunOS opensolaris 5.11 snv_101b i86pc i386 i86pc Solaris

# /usr/share/src/gcc_build/gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-multilib
--enable-shared --disable-static --enable-decimal-float -enable-nls
Thread model: posix
gcc version 4.4.0 20090101 (experimental) (GCC) 

I installed http://ftp.gnu.org/gnu/binutils/binutils-2.19.tar.bz2 and
I am aware of the ./configure arguments usually used on OpenSolaris.


The "Bug":

The file gcc/config/i386/sol2-10.h uses "USE_GAS" in an "#ifdef" (on
line 27) but since "USE_GAS" does not get defined the "#else" is taken.

That results in "-xarch=" being used in an argument for "as".

The file gcc/config/i386/sol2-10.h says:
/* binutils' GNU as understands --32 and --64, but the native Solaris
   assembler requires -xarch=generic or -xarch=generic64 instead.  */


The OpenSolaris (2008.11) man page for "as" (dated 2004-10-28) says:

 Target SPARC options:
[-Av6|-Av7|-Av8|-Asparclet|-Asparclite
 -Av8plus|-Av8plusa|-Av9|-Av9a]
[-xarch=v8plus|-xarch=v8plusa] [-bump]
[-32|-64]

 Target i386 options:
[--32|--64] [-n]



There seem to be a few incorrect assumptions that have come together
to cause us to make assumptions about what was originally intended and
how best to fix it.

The file "gcc/config/i386/sol2-10.h" uses the term "native Solaris 
assembler" but it is very unlikely that someone would use Sun Studio's 
assembler with "xgcc", they might use "Sun's supplied GNU as" (if that 
is what is meant by the term "native Solaris assembler") with xgcc
(but not if they just finished installing binutils 2.19) but "as"
does not accept "-xarch" (for the x86 platform).

The term "native Solaris assembler" is confusing since it is common
to use "GNU as" for GNU programs (especially xgcc), perhaps it is a
mis-thought confusion of the so-called "native Solaris linker" which
is Sun's modified version of GNU's "ld". Sun has a recommended linker
to use for linking but the assembler (or compiler) is not so restricted.

The "#ifdef" seems only helpful for the "sparc" platform and not
useful for the "x86" the author seems willing to set "-xarch=generic"
and "-xarch=generic64" but ought to use "--32" or "--64" instead.


If we leave things as they currently are the build breaks here:
--
Running configure in multilib subdir amd64
pwd: /usr/share/src/gcc_build/i386-pc-solaris2.11
mkdir amd64
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking for gawk... gawk
checking build system type... i386-pc-solaris2.11
checking host system type... i386-pc-solaris2.11
checking for i386-pc-solaris2.11-ar... /usr/local/i386-pc-solaris2.11/bin/ar
checking for i386-pc-solaris2.11-lipo... lipo
checking for i386-pc-solaris2.11-nm... /usr/share/src/gcc_build/./gcc/nm
checking for i386-pc-solaris2.11-ranlib...
/usr/local/i386-pc-solaris2.11/bin/ranlib
checking for i386-pc-solaris2.11-strip...
/usr/local/i386-pc-solaris2.11/bin/strip
checking whether ln -s works... yes
checking for i386-pc-solaris2.11-gcc... /usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include  -m64
checking for suffix of object files... configure: error: in
`/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgcc] Error 1
gmake[2]: Leaving directory `/usr/share/src/gcc_build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2
u...@opensolaris:/usr/share/src/gcc_build#
--

If I change "#ifndef USE_GAS" to "#ifndef USE_GAS" then I can compile 
past that point -- investigating the correct fix, back soon ...

Rob


-- 
   Summary: gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses
"USE_GAS" which is undefined
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug middle-end/26906] internal compiler error: in do_SUBST, at combine.c:447

[laurent at guerby dot net]

--- Comment #5 from laurent at guerby dot net  2009-01-02 12:51 ---
4.3.2-1 debian gnueabi and trunk rev 142984 do not ICE, waiting for
confirmation.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/38660] Pointer value changed to NULL

[q at ping dot be]

--- Comment #7 from q at ping dot be  2009-01-02 13:00 ---
Created an attachment (id=17021)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17021&action=view)
Reduced test case part 1


-- 


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

[Bug middle-end/38660] Pointer value changed to NULL

[q at ping dot be]

--- Comment #8 from q at ping dot be  2009-01-02 13:01 ---
Created an attachment (id=17022)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17022&action=view)
Reduced test case part 2


-- 

q at ping dot be changed:

   What|Removed |Added

  Attachment #17001|0   |1
is obsolete||


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

[Bug middle-end/38660] Pointer value changed to NULL

[q at ping dot be]

--- Comment #9 from q at ping dot be  2009-01-02 13:04 ---
I've reduced the test case.  The call to siglongjmp() needs to be in a separate
file.

When the problem occurs the test program returns exit code 1.


-- 


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

[Bug c/38694] New: gcc.c-torture/compile/pr11832.c ICE on arm-linux-gnueabi on 4.3.2 and trunk

[laurent at guerby dot net]

On 4.3.2-1 debian gnueabi:

gue...@gcc50:~$ gcc
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c   -O0 
-frtl-abstract-sequences
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
‘foo’:
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c:35: error:
unrecognizable insn:
(jump_insn 222 0 0 (jump_insn 221 0 0 (set (pc)
(reg:SI 0 r0)) -1 (nil)) -1 (nil))


With trunk rev 142984

/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c: In function
'foo':
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c:35: error:
unrecognizable insn:
(jump_insn
217/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c:35:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


(gdb) bt
#0  _fatal_insn_not_found (insn=0x40245960, file=0x7ba0b0
"../../trunk/gcc/config/arm/arm.md", line=158, function=0x7b9ff4
"insn_default_length") at ../../trunk/gcc/rtl-error.c:118
#1  0x005262bc in insn_default_length (insn=0x40245960) at
../../trunk/gcc/config/arm/arm.md:158
#2  0x00182f4c in get_attr_length (insn=0x40245960) at
../../trunk/gcc/final.c:415
#3  0x002bfd78 in compute_rtx_cost (insn=0x40245960) at
../../trunk/gcc/rtl-factoring.c:343
#4  0x002c05d8 in rest_of_rtl_seqabstr () at
../../trunk/gcc/rtl-factoring.c:1382
#5  0x0026ebc8 in execute_one_pass (pass=0x91ac54) at
../../trunk/gcc/passes.c:1279
#6  0x0026ee34 in execute_pass_list (pass=0x91ac54) at
../../trunk/gcc/passes.c:1328
#7  0x0026ee4c in execute_pass_list (pass=0x91a3c4) at
../../trunk/gcc/passes.c:1329
#8  0x0026ee4c in execute_pass_list (pass=0x91a390) at
../../trunk/gcc/passes.c:1329
#9  0x003726f4 in tree_rest_of_compilation (fndecl=0x40232700) at
../../trunk/gcc/tree-optimize.c:419
#10 0x004e92d4 in cgraph_expand_function (node=0x401b0900) at
../../trunk/gcc/cgraphunit.c:1047
#11 0x004e9550 in cgraph_output_in_order () at
../../trunk/gcc/cgraphunit.c:1195
#12 0x004eb3a4 in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1306
#13 0x0001cabc in c_write_global_declarations () at
../../trunk/gcc/c-decl.c:8074
#14 0x0031e58c in toplev_main (argc=, argv=) at ../../trunk/gcc/toplev.c:981
#15 0x40095dfc in __libc_start_main () from /lib/libc.so.6
#16 0xaa7c in _start ()
(gdb)


-- 
   Summary: gcc.c-torture/compile/pr11832.c ICE on arm-linux-gnueabi
on 4.3.2 and trunk
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug c/38694] gcc.c-torture/compile/pr11832.c ICE on arm-linux-gnueabi on 4.3.2 and trunk

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-01-02 13:17 ---
Similar failure for another test: 

Executing on host: /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c   -Os 
-frtl-abstract-sequences -S  -o pr33009.s(t\
imeout = 300)
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c: In function
'foo':^M
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c:41: error:
unrecognizable insn:^M
(jump_insn 132 0 0 (jump_insn 131 0 0 (set (pc)^M
(reg:SI 0 r0)) -1 (nil)) -1 (nil))^M
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c:41: internal
compiler error: in insn_default_length, at config/arm/arm.md:158^M


-- 


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

[Bug c/38695] New: [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on trunk arm_function_in_section_p

[laurent at guerby dot net]

4.3.2 works at -O0/1/2/3 but trunk at rev 142984 works at -O0 and fail at
-O1/2/3

gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/   -O1  -w -c  -o pr37433.o
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c: In function
'regex_subst':
/home/guerby/trunk/gcc/testsuite/gcc.c-torture/compile/pr37433.c:4: internal
compiler error: tree check: expected tree that contains 'decl with visibility'
structure, have 'string_cst' in arm_function_in_section_p, at
config/arm/arm.c:3324
Please submit a full bug report,
with preprocessed source if appropriate.

(gdb) bt
#0  tree_contains_struct_check_failed (node=, en=, file=0x7b1004 "../../trunk/gcc/config/arm/arm.c", line=3324,
function=0x7b0a60 "arm_function_in_section_p")
at ../../trunk/gcc/tree.c:7228
#1  0x004d82d0 in arm_is_long_call_p (decl=0x4023ed80) at
../../trunk/gcc/config/arm/arm.c:3324
#2  0x00586e94 in gen_call_value (operand0=0x4023ee40, operand1=0x402386e0,
operand2=0x401b4450, operand3=) at
../../trunk/gcc/config/arm/arm.md:8431
#3  0x000cbe28 in emit_call_1 (funexp=0x4023edc0, fntree=0x40020780,
fndecl=, funtype=, stack_size=0,
rounded_stack_size=0, struct_value_size=0, 
next_arg_reg=0x401b4450, valreg=0x4023ee40, old_inhibit_defer_pop=0,
call_fusage=0x402386d0, ecf_flags=0, args_so_far=0xbefff0b4) at
../../trunk/gcc/calls.c:348
#4  0x000d11d0 in expand_call (exp=, target=, ignore=) at ../../trunk/gcc/calls.c:2812
#5  0x00168708 in expand_expr_real_1 (exp=0x40020780, target=0x4023eba0,
tmode=, modifier=,
alt_rtl=0xbefff274) at ../../trunk/gcc/expr.c:8078
#6  0x00172864 in expand_expr_real (exp=0x40020780, target=, tmode=, modifier=,
alt_rtl=0xbefff274) at ../../trunk/gcc/expr.c:7125
#7  0x0017931c in store_expr (exp=0x40020780, target=0x4023eba0,
call_param_p=0, nontemporal=0 '\0') at ../../trunk/gcc/expr.c:4611
#8  0x0017be20 in expand_assignment (to=0x401bc160, from=0x40020780,
nontemporal=0 '\0') at ../../trunk/gcc/expr.c:4395
#9  0x001659c8 in expand_expr_real_1 (exp=0x402296b8, target=0x0, tmode=, modifier=, alt_rtl=0x0) at
../../trunk/gcc/expr.c:9232
#10 0x00172864 in expand_expr_real (exp=0x402296b8, target=, tmode=, modifier=, alt_rtl=0x0)
at ../../trunk/gcc/expr.c:7125
#11 0x0030d444 in expand_expr_stmt (exp=0x7aa65c) at ../../trunk/gcc/expr.h:539
#12 0x0063bcc8 in expand_gimple_basic_block (bb=0x401a8ac0) at
../../trunk/gcc/cfgexpand.c:1980
#13 0x0063cc58 in gimple_expand_cfg () at ../../trunk/gcc/cfgexpand.c:2377
#14 0x0026ebc8 in execute_one_pass (pass=0x91f6cc) at
../../trunk/gcc/passes.c:1279
#15 0x0026ee34 in execute_pass_list (pass=0x91f6cc) at
../../trunk/gcc/passes.c:1328
#16 0x003726f4 in tree_rest_of_compilation (fndecl=0x40232700) at
../../trunk/gcc/tree-optimize.c:419
#17 0x004e92d4 in cgraph_expand_function (node=0x401b0900) at
../../trunk/gcc/cgraphunit.c:1047
#18 0x004eb35c in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1106
#19 0x0001cabc in c_write_global_declarations () at
../../trunk/gcc/c-decl.c:8074
#20 0x0031e58c in toplev_main (argc=, argv=) at ../../trunk/gcc/toplev.c:981
#21 0x40095dfc in __libc_start_main () from /lib/libc.so.6
#22 0xaa7c in _start ()


-- 
   Summary: [4.4 regression] gcc.c-torture/compile/pr37433.c ICE on
trunk arm_function_in_section_p
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug c/38696] New: gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing

[laurent at guerby dot net]

GCC 4.3.2-1 debian gnueabi and trunk at rev 142984 generate wrong code at -O2
and above for pr37868.c

gue...@gcc50:~$ /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.dg/torture/pr37868.c   -O2 -lm   -o
./pr37868.exegue...@gcc50:~$ ./pr37868.exe 
Aborted

gue...@gcc50:~$ cat /home/guerby/trunk/gcc/testsuite/gcc.dg/torture/pr37868.c 
/* { dg-do run } */
/* { dg-options "-fno-strict-aliasing" } */
/* { dg-skip-if "unaligned access" { sparc*-*-* } "*" "" } */

extern void abort (void);

struct X {
  unsigned char pad : 4;
  unsigned int a : 32;
  unsigned int b : 24;
  unsigned int c : 6;
} __attribute__((packed));

int main (void)
{
  struct X x;
  unsigned int bad_bits;

  x.pad = -1;
  x.a = -1;
  x.b = -1;
  x.c = -1;

  bad_bits = ((unsigned int)-1) ^ *(1+(unsigned int *) &x);
  if (bad_bits != 0)
abort ();
  return 0;
}


-- 
   Summary: gcc.dg/torture/pr37868.c wrong code at -O2 and above for
4.3 and trunk / bit packing
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug target/38697] New: gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[laurent at guerby dot net]

As shown on http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00092.html
neon tests scanning for vmov are failing on trunk:

FAIL: gcc.target/arm/neon/polytypes.c (test for excess errors)
FAIL: gcc.target/arm/neon/vget_lowf32.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowp16.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowp8.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lows16.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lows32.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lows64.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lows8.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowu16.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowu32.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowu64.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n
FAIL: gcc.target/arm/neon/vget_lowu8.c scan-assembler vmov[ \\t]+[dD][0-9]+,
[dD][0-9]+!?([ \\...@[a-za-z0-9 ]+)?\\n

Looking at one of the assembly generated vmov is indeed not there:

gue...@gcc50:~$ cat  vget_lowf32.s
.cpu arm10tdmi
.eabi_attribute 27, 3
.fpu neon
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 6
.eabi_attribute 18, 4
.file   "vget_lowf32.c"
.text
.align  2
.global test_vget_lowf32
.type   test_vget_lowf32, %function
test_vget_lowf32:
@ args = 0, pretend = 0, frame = 24
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
str fp, [sp, #-4]!
add fp, sp, #0
sub sp, sp, #28
vldrd16, [fp, #-20]
vldrd17, [fp, #-12]
fstdd16, [fp, #-28]
add sp, fp, #0
ldmfd   sp!, {fp}
bx  lr
.size   test_vget_lowf32, .-test_vget_lowf32
.ident  "GCC: (GNU) 4.4.0 20081231 (experimental) [trunk revision
142984]"
.section.note.GNU-stack,"",%progbits

My configure:

../trunk/configure --prefix=/n/50/guerby/install-trunk-142984
--enable-languages=c --enable-__cxa_atexit --disable-nls --enable-threads=posix
--with-mpfr=/opt/cfarm/mpfr-2.3.2 --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
--enable-stage1-checking=release

My host/build/target:

gue...@gcc50:~$ cat /proc/cpuinfo 
Processor   : XScale-80219 rev 0 (v5l)
BogoMIPS: 593.10
Features: swp half thumb fastmult edsp 
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part: 0x2e3
CPU revision: 0
Cache type  : undefined 5
Cache clean : undefined 5
Cache lockdown  : undefined 5
Cache format: Harvard
I size  : 32768
I assoc : 32
I line length   : 32
I sets  : 32
D size  : 32768
D assoc : 32
D line length   : 32
D sets  : 32

Hardware: Thecus N2100
Revision: 
Serial  : 


-- 
   Summary: gcc.target/arm/neon/neon.exp tests for vmov fail on arm-
linux-eabi
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-01-02 13:43 ---
Forgot the compile line used:

/home/guerby/build-142984/gcc/xgcc -B/home/guerby/build-142984/gcc/  
-save-temps -O0 -mfpu=neon -mfloat-abi=softfp -c  -o vget_lowf32.o
/home/guerby/trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowf32.c


-- 


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

[Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses "USE_GAS" which is undefined

[rob1weld at aol dot com]

--- Comment #1 from rob1weld at aol dot com  2009-01-02 13:46 ---
Prior to changing "gcc/config/i386/sol2-10.h":

u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v
-B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include  -m64 -c -g -O2 test_gcc_1.c
...
GNU C (GCC) version 4.4.0 20090101 (experimental) (i386-pc-solaris2.11)
compiled by GNU C version 4.2.2, GMP version 4.2.1, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0e3e878a55369e9ed157733a6752ae45
COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/'
'-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/'
'-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem'
'/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2'
'-mtune=generic'
 /usr/share/src/gcc_build/gcc/as -V -Qy -xarch=generic64 -s -o test_gcc_1.o
/var/tmp//cc2mayli.s
GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU
Binutils) 2.19
/usr/local/i386-pc-solaris2.11/bin/as: unrecognized option `-xarch=generic64'
u...@opensolaris:/usr/share/src/gcc_build# 


After changing "gcc/config/i386/sol2-10.h":

u...@opensolaris:/usr/share/src/gcc_build# /usr/share/src/gcc_build/gcc/xgcc -v
-B/usr/share/src/gcc_build/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/
-B/usr/local/i386-pc-solaris2.11/lib/ -isystem
/usr/local/i386-pc-solaris2.11/include -isystem
/usr/local/i386-pc-solaris2.11/sys-include  -m64 -c -g -O2 test_gcc_1.c
...
GNU C (GCC) version 4.4.0 20090101 (experimental) (i386-pc-solaris2.11)
compiled by GNU C version 4.2.2, GMP version 4.2.1, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 0e3e878a55369e9ed157733a6752ae45
COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/'
'-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/'
'-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem'
'/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2'
'-mtune=generic'
 /usr/share/src/gcc_build/gcc/as -V -Qy --64 -s -o test_gcc_1.o
/var/tmp//ccU3aynm.s
GNU assembler version 2.19 (i386-pc-solaris2.11) using BFD version (GNU
Binutils) 2.19
COMPILER_PATH=/usr/share/src/gcc_build/gcc/:/usr/local/i386-pc-solaris2.11/bin/:/usr/local/i386-pc-solaris2.11/lib/:/usr/ccs/bin/
LIBRARY_PATH=/lib/amd64/:/usr/lib/amd64/:/usr/share/src/gcc_build/gcc/:/usr/local/i386-pc-solaris2.11/bin/:/usr/local/i386-pc-solaris2.11/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-B/usr/share/src/gcc_build/gcc/'
'-B/usr/local/i386-pc-solaris2.11/bin/' '-B/usr/local/i386-pc-solaris2.11/lib/'
'-isystem' '/usr/local/i386-pc-solaris2.11/include' '-isystem'
'/usr/local/i386-pc-solaris2.11/sys-include' '-m64' '-c' '-g' '-O2'
'-mtune=generic'
u...@opensolaris:/usr/share/src/gcc_build#


If "USE_GAS" in "gcc/config/i386/sol2-10.h" was set in the root ./configure
on the basis of "--with-as=/usr/gnu/bin/as" and "--with-gnu-as" in a
combination of whether the platform was "sparc" or "i386" then we could
get past this block in the build. 


It is unclear (to me) if the original author intended that Sun's assembler
could be used instead of binutils' "as" (unlikely?) or if they were uncertain
of which commands are used by each version (unlikely?).

OpenSolaris' "as" (one of them) is called "fbe" (sunas) and accepts "-m32"
and "-m64". The man page (2008/04/23) also says that this "as" only will
accept "-xarch=" arguments for the Sparc Platform.

If I knew what the original author intended I could suggest a proper fix.
It would seem that either the root configure.ac needs to be modified to
set "USE_GAS" correctly _or_ line 27 (the "#ifndef USE_GAS") in the file 
"gcc/config/i386/sol2-10.h" could check if we are x86 or sparc .

Rob


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[zadeck at naturalbridge dot com]

--- Comment #6 from zadeck at naturalbridge dot com  2009-01-02 14:09 
---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

Paolo Bonzini wrote:
> Kenneth Zadeck wrote:
>   
>> 2009-01-01  Kenneth Zadeck 
>>
>> PR rtl-optimization/35805
>> * df-problems.c (df_lr_finalize): Add recursive call to resolve lr
>> problem if fast dce is able to remove any instructions.
>> * dce.c (dce_process_block): Fix dump message.
>>
>> This patch fixes the problem.  The comment in the patch describes the
>> issue.Since this was not really a failure, it would be hard to make
>> this issue into a testcase.
>> 
>
> IIUC the bugzilla comment trail, this caused
> gcc.c-torture/compile/930523-1.c to fail with --enable-checking=df;
> that's already a testcase.
>
>   
>> Ok to commit?
>> 
>
> Hmmm... I am not sure I like this patch, for two reasons.
>
> 1) it might incur a compile-time penalty for the sake of verification,
> even with df checking disabled.  OTOH having possibly different code for
> checking and non-checking compilation is even worse.
>
>   
There is a compile time penalty here but it is not for the sake of
verification.   It is for the sake of getting the best answer going
forward, into the computation of live.

There was a deeper bug here.   The code that was removed which cleared
the solutions_dirty flag is really wrong, because it lets the
conservative solution go forward and the next call to df_analyze will
not even try to redo anything and thus improve the solution. That was
how vlad saw the extra bits even though he was calling df_analyze before
using the bits.

 On the other hand, if you do not clear that flag in the old way, the
verifier will fail.
> 2) there are already provisions in dce.c to redo the analysis.  But they
> do not get to the least fixed point because they just rebuild the local
> bitmaps and iterate from the existing solution.  Instead of iterating
> "while (global_changed)", we could try doing only one iteration (it's a
> fast DCE after all, and the pessimistic dataflow makes me guess that
> subsequent DCE iterations won't find much?) and zap the solution there.
>  This has the advantage that we can skip the recomputation if
> global_changed is false.
>
> Did I miss anything?
>
>   
I think so.   The global changed flag allows it to delete the case:

loop:
  ... <- x  // This is dead.
 x- <- ...
go to loop

it just is not going to get rid of it if there is is no kill of x inside
the loop.

Anyway. the loop inside the fast dce code will only cause one extra
iteration of the blocks, and because of that it is still pessimistic.
>   


> Paolo
>   


-- 


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

[Bug target/38692] ep9312/maverick code generation is broken

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-01-02 14:17 ---
gcc 4.3.2-1 on debian gnueabi and current trunk do not seem to generate wrong
code but may be I'm wrong in my setup to reproduce this problem?

gue...@gcc50:~$ cat pr38692.c 
#include 
int main(void)
{
int i; double d;
for (i=3, d=3; i<=5; i++, d++) {
printf("%g", d);
if (d < 4.0) printf(" lt");
if (d > 4.0) printf(" gt");
if (d <= 4.0) printf(" le");
if (d >= 4.0) printf(" ge");
putchar('\n');
}
return 0;
}
gue...@gcc50:~$ ./install-trunk-142808/bin/gcc -mfpu=maverick -mcpu=ep9312
pr38692.c 
gue...@gcc50:~$ ./a.out
3 lt le
4 le ge
5 gt ge
gue...@gcc50:~$ gcc -mfpu=maverick -mcpu=ep9312 pr38692.c 
gue...@gcc50:~$ ./a.out 
3 lt le
4 le ge
5 gt ge
gue...@gcc50:~$ cat /proc/cpuinfo 
Processor   : XScale-80219 rev 0 (v5l)
BogoMIPS: 593.10
Features: swp half thumb fastmult edsp 
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant : 0x0
CPU part: 0x2e3
CPU revision: 0
Cache type  : undefined 5
Cache clean : undefined 5
Cache lockdown  : undefined 5
Cache format: Harvard
I size  : 32768
I assoc : 32
I line length   : 32
I sets  : 32
D size  : 32768
D assoc : 32
D line length   : 32
D sets  : 32

Hardware: Thecus N2100
Revision: 
Serial  : 


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
 Status|UNCONFIRMED |WAITING


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

[Bug c++/36654] [4.2/4.3 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes

[tdragon at tdragon dot net]

--- Comment #9 from tdragon at tdragon dot net  2009-01-02 14:23 ---
That patch seems to work fine, and I haven't seen any unwarranted errors
relating to static data members so far. Thank you very much for tracking this
down!


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2009-01-02 14:26 ---
Subject: Re:  [ira] error in start_allocno_priorities, at ira-color.c:1806

> I think so.   The global changed flag allows it to delete the case:
>
> loop:
>  ... <- x  // This is dead.
>  x- <- ...
> go to loop
>
> it just is not going to get rid of it if there is is no kill of x inside
> the loop.

I just don't think it's acceptable to load each and every "fast DCE"
with the burden of a full df solution.  We need to find a way to limit
this to the cases when it is needed, or at least not to be too
conservative in ascertaining *when* it is needed.

Hence my first and foremost question is: does it happen that the
solution is wrong and global_changed never became true?

If the answer is "definitely no", then an alternative preferrable
patch would be to move the code you added to df-problems.c into dce.c,
so that the full analysis (including rebuilding the bitmaps and
iterating possibly many times) is not run if it was to yield the same
answer that was before in the bitmaps.

Paolo


-- 


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

[Bug c++/38698] New: [4.4 regression] ICE initializing union with initializer list

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on the trunk:

=
union U
{
  int i, j;
};

U u({1,2});
=

bug.cc:6: internal compiler error: in process_init_constructor_union, at
cp/typeck2.c:1101
Please submit a full bug report, [etc.]


-- 
   Summary: [4.4 regression] ICE initializing union with initializer
list
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/38698] [4.4 regression] ICE initializing union with initializer list

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/38690] [4.4 Regression] Missing parentheses for (a-1)/2 in final_cleanup

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-01-02 14:39 ---
Subject: Bug 38690

Author: jakub
Date: Fri Jan  2 14:38:05 2009
New Revision: 143012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143012
Log:
PR middle-end/38690
* tree-flow.h (op_code_prio, op_prio): New prototypes.
* tree-pretty-print.c (op_code_prio): New function.
(op_prio): No longer static.  Use op_code_prio.
* gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs):
Use op_prio and op_code_prio to determine if () should be
printed around operand(s) or not.

* gimple-pretty-print.c (dump_unary_rhs, dump_binary_rhs,
dump_gimple_call, dump_gimple_switch, dump_gimple_cond,
dump_gimple_label, dump_gimple_try, dump_symbols, dump_gimple_phi,
dump_gimple_mem_ops, dump_bb_header, dump_bb_end, pp_cfg_jump): Use
pp_character instead of pp_string for single letter printing.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-pretty-print.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-pretty-print.c


-- 


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

[Bug c++/38699] New: [4.2/4.3/4.4 regression] ICE using offsetof with array

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.2.0:

==
struct A
{
  const char* p;
};

void foo()
{
  __builtin_offsetof(struct A, p[0]);
}
==

bug.cc: In function 'void foo()':
bug.cc:8: internal compiler error: in fold_offsetof_1, at c-common.c:7647
Please submit a full bug report, [etc.]

The code is accepted by the C frontend.


-- 
   Summary: [4.2/4.3/4.4 regression] ICE using offsetof with array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/38699] [4.2/4.3/4.4 regression] ICE using offsetof with array

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.5


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

[Bug c/38700] New: [4.2/4.3/4.4 regression] ICE with __builtin_expect and label

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE since GCC 4.1.0:

==
int foo()
{
  L: return __builtin_expect ((__SIZE_TYPE__)&&L, 0);
}
==

bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected tree that contains 'decl
with visibility' structure, have 'label_decl' in fold_builtin_expect, at
builtins.c:7327
Please submit a full bug report, [etc.]


-- 
   Summary: [4.2/4.3/4.4 regression] ICE with __builtin_expect and
label
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c/38700] [4.2/4.3/4.4 regression] ICE with __builtin_expect and label

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.2.5


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

[Bug middle-end/38690] [4.4 Regression] Missing parentheses for (a-1)/2 in final_cleanup

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-01-02 14:44 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33677] Member with same name as class is not rejected

[s__nakayama at infoseek dot jp]

--- Comment #6 from s__nakayama at infoseek dot jp  2009-01-02 14:52 ---
> If T is the name of a class, then each of the following shall have a name 
> different from T:
> - every data member of class T;

This description is the one in "ISO/IEC 14882:1998". 
It was changed in "ISO/IEC 14882:2003" as follows.

> If T is the name of a class, then each of the following shall have a name 
> different from T:
> - every static data member of class T;

http://www.open-std.org/jtc1/sc22/wg21/docs/core5.htm#80


-- 


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

[Bug c++/38701] New: [4.4 regression] ICE with defaulted function

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on the trunk:

==
void foo() = default;
==

bug.cc:1: error: 'void foo()' cannot be defaulted
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

A similar code snippet triggers an ICE in a different place:

==
namespace
{
  void foo() = default;
}
==

bug.cc:3: error: 'void::foo()' cannot be defaulted
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'declaration' (namespace_decl) in synthesize_method, at cp/method.c:758
Please submit a full bug report, [etc.]

This is a recent regression on the trunk, introduced between 2008-11-20
and 2008-12-06.


-- 
   Summary: [4.4 regression] ICE with defaulted function
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/38701] [4.4 regression] ICE with defaulted function

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug c++/38702] New: [4.4 regression] ICE with defaulted operator

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE on the trunk:

=
enum E { e }; 

E& operator |= (E&, const E&) = default;
=

bug5.cc:3: internal compiler error: in copy_fn_p, at cp/decl.c:9717
Please submit a full bug report, [etc.]

This is related to PR38701. It's not a duplicate though, because the ICE
appeared already in July and it's not an error-recovery problem.


-- 
   Summary: [4.4 regression] ICE with defaulted operator
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/38702] [4.4 regression] ICE with defaulted operator

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug c/38700] [4.2/4.3/4.4 regression] ICE with __builtin_expect and label

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 15:02:36
   date||


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

[Bug target/38703] New: testsuite __gnu_mcount_nc link error when profiling on arm

[laurent at guerby dot net]

Current debian lenny comes with glibc-2.7 and does not provide __gnu_mcount_nc
which will come with 2.8 as discussed on gcc-patches here:

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00319.html

But this means that all the tests from gcc testsuite using -p fail to link, eg:

Executing on host: /home/guerby/build-142984/gcc/xgcc
-B/home/guerby/build-142984/gcc/
/home/guerby/trunk/gcc/testsuite/gcc.dg/20021014-1.c   -O2 -p  -lm   -o
./20021014-1.exe(timeout = 300)
/tmp/cc1YND67.o: In function `foo':^M
20021014-1.c:(.text+0x4): undefined reference to `__gnu_mcount_nc'^M
/tmp/cc1YND67.o: In function `main':^M
20021014-1.c:(.text+0x18): undefined reference to `__gnu_mcount_nc'^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
/tmp/cc1YND67.o: In function `foo':^M
20021014-1.c:(.text+0x4): undefined reference to `__gnu_mcount_nc'^M
/tmp/cc1YND67.o: In function `main':^M
20021014-1.c:(.text+0x18): undefined reference to `__gnu_mcount_nc'^M
collect2: ld returned 1 exit status^M

FAIL: gcc.dg/20021014-1.c (test for excess errors)

May be there's a way to tell configure and/or dejagnu about missing profiling
support and be a bit more graceful than a link error?


-- 
   Summary: testsuite __gnu_mcount_nc link error when profiling on
arm
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: link-failure
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: arm-linux-gnueabi
  GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi


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

[Bug ada/24167] Visibility of private component of parent in child generic, generic compiles but instantiation doesn't

[laurent at guerby dot net]

--- Comment #3 from laurent at guerby dot net  2009-01-02 15:17 ---
Still there with 4.3.2 and
gcc version 4.4.0 20081228 (experimental) [trunk revision 142939] (GCC) 

Arnaud, do you have a generic expert handy to check wether this code is legal
or not? generic compiling but not an instance is quite rare in the language.
Thanks!


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||charlet at adacore dot com


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

[Bug c++/38699] [4.2/4.3/4.4 regression] ICE using offsetof with array

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-01-02 15:20 ---
That seems invalid, not valid.
E.g. C says that for offsetof (type, member) for
static type t;
&(t.member) evaluates to an address constant, which is not the case for
const char *p; field and p[0].


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[zadeck at naturalbridge dot com]

--- Comment #8 from zadeck at naturalbridge dot com  2009-01-02 15:20 
---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

Paolo Bonzini wrote:
>> I think so.   The global changed flag allows it to delete the case:
>>
>> loop:
>>  ... <- x  // This is dead.
>>  x- <- ...
>> go to loop
>>
>> it just is not going to get rid of it if there is is no kill of x inside
>> the loop.
>> 
>
> I just don't think it's acceptable to load each and every "fast DCE"
> with the burden of a full df solution.  We need to find a way to limit
> this to the cases when it is needed, or at least not to be too
> conservative in ascertaining *when* it is needed.
>   
i am not, i am only doing it for each and every dce, only if the dce
actually deletes code. 

If there was a faster way to determine if the solution was too
conservative than redoing it, you would have an effective incremental
dataflow analysis algorithm.   I strongly believe that such a technique
does not exist.
> Hence my first and foremost question is: does it happen that the
> solution is wrong and global_changed never became true?
>
>   
The example in the pr exhibits this property.  the problem is that
deleting the use of pseudo 69 does not cause bit 69 to ever get turned
off because it was live at the bottom of the loop (since it had been
propagated around the loop to start with.)  Hence, when you get to the
top of the loop, there are no changes at all with respect to pseudo 69
and local_changed would not have been set.  (I do not know if it is
really true for the example that local_changes is not set, because the
deletion of the kill on the set side of the insn could have caused that
to happen.  But the point is that with respect to position 69, the use
in the deleted insn would not have caused local_changed to be set.)

> If the answer is "definitely no", then an alternative preferrable
> patch would be to move the code you added to df-problems.c into dce.c,
> so that the full analysis (including rebuilding the bitmaps and
> iterating possibly many times) is not run if it was to yield the same
> answer that was before in the bitmaps.
>
> Paolo
>   


-- 


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

[Bug target/38692] ep9312/maverick code generation is broken

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-02 15:19 ---
This is a bug specific to the maverick set of chips. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 15:19:42
   date||


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

[Bug middle-end/38696] gcc.dg/torture/pr37868.c wrong code at -O2 and above for 4.3 and trunk / bit packing

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-02 15:20 ---
Most likely needs to be skipped just like sparc as this is an unaligned access.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug c++/38701] [4.4 regression] ICE with defaulted function

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-01-02 15:29 
---
CC-ing Jason...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[zadeck at naturalbridge dot com]

--- Comment #9 from zadeck at naturalbridge dot com  2009-01-02 15:34 
---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

On looking at the code, there is an issue with the first patch.   I
should have been clearing solutions_dirty flag at the start of the
function.   However, I do not think that this is the issue that you are
complaining about.  

What this corrects is the case where the solution was dirty before the
first call to df_analyze and dce finds nothing to delete.   In that
case, the code would have redone the lr solution for no reason. 

I will test this patch, but we still need to resolve your issues with my
approach.

Kenny


zadeck at naturalbridge dot com wrote:
> --- Comment #8 from zadeck at naturalbridge dot com  2009-01-02 15:20 
> ---
> Subject: Re:  [ira] error in start_allocno_priorities,
>  at ira-color.c:1806
>
> Paolo Bonzini wrote:
>   
>>> I think so.   The global changed flag allows it to delete the case:
>>>
>>> loop:
>>>  ... <- x  // This is dead.
>>>  x- <- ...
>>> go to loop
>>>
>>> it just is not going to get rid of it if there is is no kill of x inside
>>> the loop.
>>> 
>>>   
>> I just don't think it's acceptable to load each and every "fast DCE"
>> with the burden of a full df solution.  We need to find a way to limit
>> this to the cases when it is needed, or at least not to be too
>> conservative in ascertaining *when* it is needed.
>>   
>> 
> i am not, i am only doing it for each and every dce, only if the dce
> actually deletes code. 
>
> If there was a faster way to determine if the solution was too
> conservative than redoing it, you would have an effective incremental
> dataflow analysis algorithm.   I strongly believe that such a technique
> does not exist.
>   
>> Hence my first and foremost question is: does it happen that the
>> solution is wrong and global_changed never became true?
>>
>>   
>> 
> The example in the pr exhibits this property.  the problem is that
> deleting the use of pseudo 69 does not cause bit 69 to ever get turned
> off because it was live at the bottom of the loop (since it had been
> propagated around the loop to start with.)  Hence, when you get to the
> top of the loop, there are no changes at all with respect to pseudo 69
> and local_changed would not have been set.  (I do not know if it is
> really true for the example that local_changes is not set, because the
> deletion of the kill on the set side of the insn could have caused that
> to happen.  But the point is that with respect to position 69, the use
> in the deleted insn would not have caused local_changed to be set.)
>
>   
>> If the answer is "definitely no", then an alternative preferrable
>> patch would be to move the code you added to df-problems.c into dce.c,
>> so that the full analysis (including rebuilding the bitmaps and
>> iterating possibly many times) is not run if it was to yield the same
>> answer that was before in the bitmaps.
>>
>> Paolo
>>   
>> 
>
>
>   

Index: ChangeLog
===
--- ChangeLog   (revision 142954)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2009-01-01  Kenneth Zadeck 
+
+   PR rtl-optimization/35805
+   * df-problems.c (df_lr_finalize): Add recursive call to resolve lr
+   problem if fast dce is able to remove any instructions.
+   * dce.c (dce_process_block): Fix dump message.
+   
 2008-12-29  Seongbae Park  

* tree-profile.c (tree_init_ic_make_global_vars): Make static
Index: df-problems.c
===
--- df-problems.c   (revision 142954)
+++ df-problems.c   (working copy)
@@ -1001,25 +1001,34 @@ df_lr_transfer_function (int bb_index)
 /* Run the fast dce as a side effect of building LR.  */

 static void
-df_lr_finalize (bitmap all_blocks ATTRIBUTE_UNUSED)
+df_lr_finalize (bitmap all_blocks)
 {
+  df_lr->solutions_dirty = false;
   if (df->changeable_flags & DF_LR_RUN_DCE)
 {
   run_fast_df_dce ();
-  if (df_lr->problem_data && df_lr->solutions_dirty)
+
+  /* If dce deletes some instructions, we need to recompute the lr
+solution before proceeding further.  The problem is that fast
+dce is a pessimestic dataflow algorithm.  In the case where
+it deletes a statement S inside of a loop, the uses inside of
+S may not be deleted from the dataflow solution because they
+were carried around the loop.  While it is conservatively
+correct to leave these extra bits, the standards of df
+require that we maintain the best possible (least fixed
+point) solution.  The only way to do that is to redo the
+iteration from the beginning.  See PR35805 for an
+example.  */
+  if (df_lr->solutions_dirty)
{
- /* If we are here, then it is because we are both verifying
- the solution and the dce changed the funct

[Bug c++/38702] [4.4 regression] ICE with defaulted operator

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-01-02 15:30 
---
Likewise...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug bootstrap/38686] Bootstrap fails on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2009-01-02 15:36 ---
>--with-cpu=pentium-m 

Hmm, that might be the cause Testing with that option.


-- 


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

[Bug c++/38698] [4.4 regression] ICE initializing union with initializer list

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-01-02 15:31 
---
And again...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug c/38704] New: Very bad quality of compilation of a floating point numbers.

[lisp2d at lisp2d dot net]

#include
int main(int,char**){
const   longdouble  PiLD=3.1415926535897932384626433832795029L;
std::cout<<"   3.1415926535897932384626433832795029"

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[bonzini at gnu dot org]

--- Comment #10 from bonzini at gnu dot org  2009-01-02 16:33 ---
Subject: Re:  [ira] error in start_allocno_priorities,
  at ira-color.c:1806

> I will test this patch, but we still need to resolve your issues with my
> approach.

The problem is that you're really doubling the cost of computing the
live registers.  I know that previously it was wrong, but at this point
there's no difference with the full-blown pass...  Despite the idea of
DF_LR_RUN_DCE being that it was "free", now it would do the same work as
a pass_fast_rtl_dce modulo some O(#bbs) work.

At this point, if your patch costs say 0.3%, and removing all traces of
DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in
passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to
look for opportunities to remove some useless DCE.

If it wasn't for verification, we could just decide that DF_LR_RUN_DCE
is only for passes that can tolerate a little inaccurate info...

Paolo


-- 


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

[Bug pch/38013] Option to turn off usage of any precompiled header

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2009-01-02 16:33 ---
Changing component to pch.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|preprocessor|pch


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

[Bug c++/38698] [4.4 regression] ICE initializing union with initializer list

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 16:33:30
   date||


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

[Bug preprocessor/38105] -Wundef -Werror -Wno-error=undef result in error, not warning

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2009-01-02 16:39 ---
Please report the bug in comment #2 separately.
Otherwise it is unlikely to be seen by the appropriate person.

Andrew is correct; this would probably be fixed if we had gcc
tell libcpp to use its diagnostic code.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 16:39:43
   date||


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

[Bug preprocessor/38322] ICE in gcc.dg/cpp/trad/include.c -fno-show-column at -m32 and -m64

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2009-01-02 16:44 ---
You can try -C to keep the comments.

In the original report you said you can't get a backtrace.
That makes it a lot harder :(

Could you try shrinking the test case somehow?
Or perhaps you could change the abort() calls in libcpp to something
that would print __FILE__ and __LINE__.  That might help a little.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug c++/38705] New: ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t

[sdirkse at gams dot com]

I turfed up an ICE with optimization, but the thing compiled fine without.  To
reproduce, use the soon-to-be attached source and do:
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -c AlpsTreeNode.ii 
madison.gams.com:/home/steve/lang/cpp/alpsBug$g++ -O3 -c AlpsTreeNode.ii 
AlpsTreeNode.cpp: In member function 'AlpsReturnStatus
AlpsTreeNode::encodeAlps(AlpsEncoded*) const':
AlpsTreeNode.cpp:144: internal compiler error: canonical types differ for
identical types const int and const AlpsNodeIndex_t
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I was using the trunk src at rev 142984:
$gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local2
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.4.0 20081231 (experimental) (GCC)


-- 
   Summary: ICE: canonical types differ for identical types const
int and const AlpsNodeIndex_t
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sdirkse at gams dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/38705] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t

[sdirkse at gams dot com]

--- Comment #1 from sdirkse at gams dot com  2009-01-02 16:49 ---
Created an attachment (id=17023)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17023&action=view)
test case


-- 


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

[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm

[pbrook at gcc dot gnu dot org]

--- Comment #1 from pbrook at gcc dot gnu dot org  2009-01-02 17:01 ---
That's what dg-require-profiling does.

IMHO this is a deficiency in your glibc. It's very hard to distinguish between
"something is subtly busted" and "my glibc sucks", so I'm not sure fixing this
is appropriate for fsf gcc.


-- 


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

[Bug c/38704] Very bad quality of compilation of a floating point numbers.

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2009-01-02 17:02 ---
Depending on the actual value of DECIMAL_DIG this does not really look bad.


-- 


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

[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - < /dev/null'

[tromey at gcc dot gnu dot org]

--- Comment #6 from tromey at gcc dot gnu dot org  2009-01-02 17:04 ---
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.

This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug target/38686] Bootstrap fails on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-02 17:07 ---
Ok, I can reproduce the failure.  The work around is removing
-with-arch=pentium-m.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
  Component|bootstrap   |target
 Ever Confirmed|0   |1
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet||i686-pc-linux-gnu
   Keywords||build, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 17:07:05
   date||


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

[Bug target/37633] [4.4 Regression] wrong register use on sh64

[andreasmeier80 at gmx dot de]

--- Comment #8 from andreasmeier80 at gmx dot de  2009-01-02 17:08 ---
What is the status of this bug?


-- 

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||andreasmeier80 at gmx dot de


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[andreasmeier80 at gmx dot de]

--- Comment #8 from andreasmeier80 at gmx dot de  2009-01-02 17:08 ---
What is the status of this bug?


-- 

andreasmeier80 at gmx dot de changed:

   What|Removed |Added

 CC||andreasmeier80 at gmx dot de


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

[Bug target/38686] Bootstrap fails on i686-pc-linux-gnu with --with-arch=pentium-m

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-01-02 17:17 ---
Seeing what tests gcc fail with stage1's gcc.


-- 


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

[Bug preprocessor/38322] ICE in gcc.dg/cpp/trad/include.c -fno-show-column at -m32 and -m64

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-02 17:09 ---
Here is a reduced testcase:
t.c:

#include 


--- CUT ---
t.h:

#ifdef __PME__

#define _TLS_QUAL /*0123456790*/

#endif // __PME__

Compile with "gcc t.c -isystem . -traditional-cpp".


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 17:09:50
   date||


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

[Bug preprocessor/38322] ICE in gcc.dg/cpp/trad/include.c -fno-show-column at -m32 and -m64

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-02 17:11 ---
I can reproduce the abort on both i686-linux-gnu and i386-darwin8.11 with my
reduced testcase.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|x86_64-apple-darwin10   |
   GCC host triplet|x86_64-apple-darwin10   |
 GCC target triplet|x86_64-apple-darwin10   |
   Keywords||ice-on-valid-code


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

[Bug c++/38705] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-02 17:29 ---
Reducing ...


-- 


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

[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-01-02 17:30 ---
The test already has:

/home/guerby/trunk/gcc/testsuite/gcc.dg/20021014-1.c
/* { dg-require-profiling "-p" } */

If configure tests the system compiler for profiling "support" it will of
course be fooled by a GCC changing the symbol/ABI needed for profiling during
bootstrap :).

I could not find a GLIBC 2.8 release in http://ftp.gnu.org/gnu/glibc/
nor in ftp://sources.redhat.com/pub/glibc/releases/
do you know if it has been formally released? 


-- 


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

[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm

[joseph at codesourcery dot com]

--- Comment #3 from joseph at codesourcery dot com  2009-01-02 17:35 ---
Subject: Re:  testsuite __gnu_mcount_nc link error when
 profiling on arm

On Fri, 2 Jan 2009, laurent at guerby dot net wrote:

> I could not find a GLIBC 2.8 release in http://ftp.gnu.org/gnu/glibc/
> nor in ftp://sources.redhat.com/pub/glibc/releases/
> do you know if it has been formally released? 

glibc no longer releases tarballs, only CVS tags.  The current release is 
2.9.


-- 


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

[Bug target/38706] New: [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault

[arthur dot loiret at gmail dot com]

Hi!

configured with: --host=alpha-linux-gnu --build=alpha-linux-gnu
--target=alpha-linux-gnu --enable-languages=c,c++ --with-system-zlib

Build fails with this error:

/bin/sh ../libtool --tag CXX --mode=compile /home/arthur/build/./gcc/xgcc
-shared-libgcc -B/home/arthur/build/./gcc -nostdinc++
-L/home/arthur/build/alpha-linux-gnu/libstdc++-v3/src
-L/home/arthur/build/alpha-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/alpha-linux-gnu/bin/ -B/usr/local/alpha-linux-gnu/lib/ -isystem
/usr/local/alpha-linux-gnu/include -isystem
/usr/local/alpha-linux-gnu/sys-include 
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include/alpha-linux-gnu
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include
-I/home/arthur/src/libstdc++-v3/libsupc++  -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once 
-ffunction-sections -fdata-sections  -g -O2   -D_GNU_SOURCE -mieee   
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../src/libstdc++-v3/src/strstream.cc
libtool: compile:  /home/arthur/build/./gcc/xgcc -shared-libgcc
-B/home/arthur/build/./gcc -nostdinc++
-L/home/arthur/build/alpha-linux-gnu/libstdc++-v3/src
-L/home/arthur/build/alpha-linux-gnu/libstdc++-v3/src/.libs
-B/usr/local/alpha-linux-gnu/bin/ -B/usr/local/alpha-linux-gnu/lib/ -isystem
/usr/local/alpha-linux-gnu/include -isystem
/usr/local/alpha-linux-gnu/sys-include
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include/alpha-linux-gnu
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include
-I/home/arthur/src/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -mieee
-I/home/arthur/build/alpha-linux-gnu/libstdc++-v3/include/backward
-Wno-deprecated -c ../../../../src/libstdc++-v3/src/strstream.cc  -fPIC -DPIC
-o .libs/strstream.o
../../../../src/libstdc++-v3/src/strstream.cc: In member function 'void
std::ostrstream::_ZTv0_n24_NSt10ostrstreamD0Ev()':
../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [strstream.lo] Error 1

Thanks.


-- 
   Summary: [4.4 regression] ../../../../src/libstdc++-
v3/src/strstream.cc:419: internal compiler error:
Segmentation fault
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arthur dot loiret at gmail dot com
 GCC build triplet: alpha-linux-gnu
  GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu


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

[Bug tree-optimization/33649] cc1 segfaults when multiple tree opts disabled

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2009-01-02 18:05 
---
Subject: Bug 33649

Author: mmitchel
Date: Fri Jan  2 18:04:28 2009
New Revision: 143014

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143014
Log:
PR 33649
* tree-ssa-pre.c (compute_antic): Correct loop bounds.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c


-- 


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

[Bug tree-optimization/33649] cc1 segfaults when multiple tree opts disabled

[mmitchel at gcc dot gnu dot org]

--- Comment #6 from mmitchel at gcc dot gnu dot org  2009-01-02 18:08 
---
Fixed.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug target/38707] New: gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m

[pinskia at gcc dot gnu dot org]

While trying to figure out what is causing bootstrap to fail with
--with-arch=pentium-m, I decided to test the testsuite with stage1's gcc and
found that gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m, this
happens even with a normal compiled compiler.


-- 
   Summary: gcc.c-torture/execute/20050121-1.c ICEs with -
march=pentium-m
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/38707] gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-02 18:19 ---
Forgot to add the ICE:
/home/pinskia/src/local/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c:33:
internal compiler error: in immed_double_const, at emit-rtl.c:548^M


-- 


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

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-01-02 18:21 ---
Confirmed at r134530 with the following reduced test case:

typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef USItype halffractype;
typedef UDItype fractype;

typedef struct
{
  unsigned int sign;
  int normal_exp;

  union
  {
fractype ll;
halffractype l[2];
  } fraction;
} fp_number_type;

extern void bar ();

extern fp_number_type * _fpmul_parts (fractype, fractype, fp_number_type *);
fp_number_type *
_fpmul_parts (fractype low, fractype high, fp_number_type *tmp)
{
  while (high >= ((fractype) 1 << (52 + 1 + 8L)))
{
  tmp->normal_exp++;
  if (high & 1)
bar ();
  high >>= 1;
}
  while (high < ((fractype) 1 << (52 + 8L)))
{
  tmp->normal_exp--;
  high <<= 1;
}

  tmp->fraction.ll = high;
  return tmp;
}

Unfortunately I can't reproduce it with the top-of-trunk of today.


-- 


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[zadeck at naturalbridge dot com]

--- Comment #11 from zadeck at naturalbridge dot com  2009-01-02 18:21 
---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806

Paolo Bonzini wrote:
>> I will test this patch, but we still need to resolve your issues with my
>> approach.
>> 
>
> The problem is that you're really doubling the cost of computing the
> live registers.  I know that previously it was wrong, but at this point
> there's no difference with the full-blown pass...  Despite the idea of
> DF_LR_RUN_DCE being that it was "free", now it would do the same work as
> a pass_fast_rtl_dce modulo some O(#bbs) work.
>   
you are being too pessimistic.  most of the time, dce finds nothing.  
If DCE finds nothing, then the second pass does not run.

I considered just fixing the verification part (not clearing the
solutions_dirty flag) and letting the next call to df_analyze clean
things up.  In this way it would be like every other pass and leave
things dirty until the next pass that needed the info. 

StevenB talked me out of this because he considered it wrong to have the
client pass get conservative info.  I agreed with him but I am willing
to change my mind if you really want to push your case.  

> At this point, if your patch costs say 0.3%, and removing all traces of
> DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in
> passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to
> look for opportunities to remove some useless DCE.
>
> If it wasn't for verification, we could just decide that DF_LR_RUN_DCE
> is only for passes that can tolerate a little inaccurate info...
>
>   
This was in fact my argument to stevenb.  The point is that the live
info which is run after it will generally hide this conservativeness. 
On the other hand we do have standards that we always use the best info
 As i pointed out on irc, the only reason that vlad noticed this at
all was that he uses the wrong sets in his code (and he was running at
O1 in this case.)  At O2 and above he should be using the DF_LIVE sets.

Kenny

> Paolo
>   


-- 


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

[Bug middle-end/36003] pass_fast_rtl_byte_dce is disabled currently because of breakage in CC0 targets

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2009-01-02 18:25 ---
The zero_extract:DI appears for the first time in the .163r.combine dump.


-- 


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

[Bug target/38686] Bootstrap fails on i686-pc-linux-gnu with --with-arch=pentium-m

[aanisimov at inbox dot ru]

--- Comment #9 from aanisimov at inbox dot ru  2009-01-02 18:30 ---
(In reply to comment #7)
> Ok, I can reproduce the failure.  The work around is removing
> -with-arch=pentium-m.
> 

Not a good idea ;-). I found that reverting diff r137645:r137646 makes the
compilation finish and the resulting GCC seems to compile the programs
correctly (i compiled a medium-sized app and ran it under valgrind to see if
the program messes with memory accesses, though I did not run the whole GCC
testsuite).


-- 


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

[Bug c++/38705] [4.4 Regression] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-01-02 18:38 ---
Reduced testcase:
typedef int AlpsNodeIndex_t;
  void writeRep(char* representation_, const int len)   {
__builtin_memcpy(representation_ , &len, sizeof(int));
  }
struct AlpsTreeNode
{
  AlpsNodeIndex_t index_;
  int explicit_;
  int encodeAlps() const;
  template  void writeRep(const T& value) const {  }
};
int AlpsTreeNode:: encodeAlps() const
{
  writeRep(explicit_);
  writeRep(index_);
}

--- CUT ---
I think this might have something to do with the __builtin_memcpy optimization.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||ice-checking, ice-on-valid-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 18:38:20
   date||
Summary|ICE: canonical types differ |[4.4 Regression] ICE:
   |for identical types const   |canonical types differ for
   |int and const   |identical types const int
   |AlpsNodeIndex_t |and const AlpsNodeIndex_t
   Target Milestone|--- |4.4.0


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

[Bug tree-optimization/35805] [ira] error in start_allocno_priorities, at ira-color.c:1806

[bonzini at gnu dot org]

--- Comment #12 from bonzini at gnu dot org  2009-01-02 18:38 ---
Subject: Re:  [ira] error in start_allocno_priorities,
 at ira-color.c:1806


> StevenB talked me out of this because he considered it wrong to have
> the client pass get conservative info.  I agreed with him but I am
> willing to change my mind if you really want to push your case.

If there was preexisting discussion outside bugzilla, it's of course
okay for me, and I'll not push my opinion beyond, but I'd still like to
see some numbers.  You can commit the second patch either before or
after, I don't care.

>> At this point, if your patch costs say 0.3%, and removing all traces 
>> DF_LR_RUN_DCE (instead scheduling a dozen more pass_fast_rtl_dce in
>> passes.c) costs 0.5%, I'd rather see the latter, at least it's easier to
>> look for opportunities to remove some useless DCE.

I'll try to do this for 4.5.

Paolo


-- 


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

[Bug target/38686] Bootstrap fails on i686-pc-linux-gnu with --with-arch=pentium-m

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-01-02 18:39 
---
I think:
FAIL: gcc.c-torture/execute/memset-2.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/memset-2.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/memset-2.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/memset-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O1 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O2 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/memset-3.c execution,  -O3 -g 

Might the issue.

Looking more into it.


-- 


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

[Bug target/38708] New: [4.4 Regression] gcc.c-torture/execute/memset-3.c Fails with -march=pentium-m -O1

[pinskia at gcc dot gnu dot org]

I think this is the cause of PR 38686 but I could be wrong.
Anyways gcc.c-torture/execute/memset-3.c   fails with -march=pentium-m -O1


-- 
   Summary: [4.4 Regression] gcc.c-torture/execute/memset-3.c  Fails
with -march=pentium-m -O1
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
OtherBugsDependingO 38686
 nThis:


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

[Bug middle-end/37813] assert with IRA_COVER_CLASSES with singleton

[hp at gcc dot gnu dot org]

--- Comment #9 from hp at gcc dot gnu dot org  2009-01-02 18:44 ---
See comment #5.  The subsequent commits were AFAIK not addressing it.  I don't
have time to experiment right now, and as the bug only appeared (at the time)
with separate patches, I'm making it SUSPENDED.  CC:ers, feel free to upgrade.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-01-02 18:44:36
   date||


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