2 bugs in mt_allocator (tested on gcc 4.1.1)

[dk]

Hi!
This example will demonstrate 2 problems in mt_allocator.cc:

typedef __gnu_cxx::__mt_alloc allocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;

allocator_type mt_char;
tune_type t(8, 4, 8, (5 - 4 * sizeof(void*)), 4096, 10,  
false);

mt_char._M_set_options(t);
allocator_type::pointer pc = mt_char.allocate(4);

First bug in __pool<..>::_M_initialize():
Binmap_type __bin_max = _M_options._M_min_bin;  // not correct.
size_t __bin_max = _M_options._M_min_bin; // correct.

Second bug in __pool<..>::_M_reserve_block():

  while (--__block_count > 0) // not correct because __block_count may be  
equal 0(and size_t is unsigned)

  {
__c += __bin_size;
__block->_M_next = reinterpret_cast<_Block_record*>(__c);
__block = __block->_M_next;
  }

  while (__block_count > 0) // correct
  {
__c += __bin_size;
__block->_M_next = reinterpret_cast<_Block_record*>(__c);
__block = __block->_M_next;
   --__block_count;
  }
Best regards, dk.

[Bug c/80419] New: rpmbuild with rpmrc file crashed httpd rebuild

[d.kuc...@dk-software.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80419

Bug ID: 80419
   Summary: rpmbuild with rpmrc file crashed httpd rebuild
   Product: gcc
   Version: unknown
   URL: http://https://bugzilla.redhat.com/show_bug.cgi
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.kuc...@dk-software.org
CC: d.kuc...@dk-software.org
  Target Milestone: ---
  Host: Fedora 25
Target: x86_64
 Build: 6.3.1

Created attachment 41193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41193&action=edit
gcc version

when i rebuild the src.rpm with my .rpmrc file i became the error "illegal
instruction", when i create the rpm without the .rpmrc file it works perfectly!
other builds with the rpmrc file (pure-ftpd, mpd, cantata) works!

i use the httpd-2.4.25-3.fc25.src.rpm file 

This is my .rpmrc file:

[builduser@buildsrv]: cat /home/builduser/.rpmrc 
optflags: x86_64 %{__global_cflags} -m64 -march=core2 -mtune=core2

[Bug c/27266] New: syncronization primitives cause ICE with -march=pentium or better

[rask at sygehus dot dk]

Mainline is ICE'ing on testsuite/gcc.c-torture/compile/sync-1.c for some
arguments to -march. For example:

./xgcc -B. -O2
/mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c -S -o
/tmp/sync-1.s -march=pentium
/mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c: In
function 'test_lock':
/mnt/sysfs/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/sync-1.c:261:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

It works with: i386, i486, winchip-c6, winchip2 and c3.
It fails with: pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4,
nocona, prescott, k6, k6-2, k6-3, k8, athlon, opteron and c3-2.

The gcc-4.1.0-3 compiler shipped by Red Hat fails in the same way for the same
arguments to -march.


-- 
   Summary: syncronization primitives cause ICE with -march=pentium
or better
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/27266] syncronization primitives cause ICE with -march=pentium or better

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2006-04-23 14:46 ---
Created an attachment (id=11317)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11317&action=view)
Preprocessed source code


-- 


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

[Bug libstdc++/27846] New: global namespace is polluted

[mbo at intec dot dk]

Problem:
The following code fails to compile. The problem is that call to max is
ambiguous. It seems as if the compiler can also see std::max eventhough I have
not included the global namespace by using "using namespace std;" or by using
"using std::max;". I find this very odd, since the namespace faciliy should
allow us to define the same names without the risk of a name-clash.

#include 

using std::string;

template
inline T max(const T& a, const T&b)
{ return a < b ? b : a; }

int main()
{
string a("a"), b("b");
max(a, b);
}

Compiler info:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)

System type:
Linux pcbmbo 2.6.16 #1 Thu May 4 11:51:04 CEST 2006 i686 GNU/Linux
(Debian/unstable)

Command line used to invoke the compiler:
g++ -std=c++98 -Wall -Werror -Wextra -pedantic-errors -Wfloat-equal -Wshadow
-Wconversion -Wold-style-cast

Error message:
[EMAIL PROTECTED]:~$ g++ -std=c++98 -Wall -Werror -Wextra -pedantic-errors
-Wfloat-equal -Wshadow -Wconversion -Wold-style-cast mymax.cpp
mymax.cpp: In function 'int main()':
mymax.cpp:12: error: call of overloaded 'max(std::string&, std::string&)' is
ambiguous
mymax.cpp:6: note: candidates are: T max(const T&, const T&) [with T =
std::string]
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/bits/stl_algobase.h:206:
note: const _Tp& std::max(const _Tp&, const _Tp&) [with _Tp =
std::string]


-- 
   Summary: global namespace is polluted
   Product: gcc
   Version: 4.0.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mbo at intec dot dk


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

[Bug libstdc++/27846] global namespace is polluted

[mbo at intec dot dk]

--- Comment #1 from mbo at intec dot dk  2006-05-31 19:24 ---
Created an attachment (id=11556)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11556&action=view)
Preprocessed source


-- 


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

[Bug target/25722] New: Stackpointer is not restored correct at end of function

[bl at rosetechnology dot dk]

In at least one case where a lot of local variables have been used in a
function the stackpointer is restored from a register pair where the it have
never been saved.


-- 
   Summary: Stackpointer is not restored correct at end of function
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bl at rosetechnology dot dk
GCC target triplet: avr


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

[Bug target/25722] Stackpointer is not restored correct at end of function

[bl at rosetechnology dot dk]

--- Comment #1 from bl at rosetechnology dot dk  2006-01-09 12:33 ---
Created an attachment (id=10598)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10598&action=view)
Testcase

Testcase including debug code for avr-studio 4. When the funtion 'Evaluate'
exits the program chrashes


-- 


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

[Bug rtl-optimization/25742] Internal compiler error in gen_rtx_SUBREG

[bl at rosetechnology dot dk]

--- Comment #3 from bl at rosetechnology dot dk  2006-01-19 08:52 ---
Created an attachment (id=10673)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10673&action=view)
Another example, this time on windows-xp

I think this is the same bug.
Compiler version 3.4.3 Windows
Target avr mega64


-- 


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

[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-07-15 14:29 ---
I get something similiar with my 16-bit x86 port compiling libgcc:

/home/rask/cvsbuild/gcc/./gcc/xgcc -B/home/rask/cvsbuild/gcc/./gcc/ -nostdinc
-B/home/rask/cvsbuild/gcc/ia16-elf/newlib/ -isystem
/home/rask/cvsbuild/gcc/ia16-elf/newlib/targ-include -isystem
/home/rask/cvssrc/gcc/newlib/libc/include -B/usr/local/gcc/ia16-elf/bin/
-B/usr/local/gcc/ia16-elf/lib/ -isystem /usr/local/gcc/ia16-elf/include
-isystem /usr/local/gcc/ia16-elf/sys-include -O2 -g -O2 -fno-split-wide-types
-O2  -O2 -g -O2  -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
 -isystem ./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc
-I. -I. -I../../.././gcc -I../../../../../cvssrc/gcc/libgcc
-I../../../../../cvssrc/gcc/libgcc/. -I../../../../../cvssrc/gcc/libgcc/../gcc
-I../../../../../cvssrc/gcc/libgcc/../include  -DHAVE_CC_TLS -o _mulvsi3.o -MT
_mulvsi3.o -MD -MP -MF _mulvsi3.dep -DL_mulvsi3 -c
../../../../../cvssrc/gcc/libgcc/../gcc/libgcc2.c \

../../../../../cvssrc/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvsi3':
../../../../../cvssrc/gcc/libgcc/../gcc/libgcc2.c:169: internal compiler error:
RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:972

This patch seems to fix it:

Index: gcc/df-problems.c
===
--- gcc/df-problems.c   (revision 126653)
+++ gcc/df-problems.c   (working copy)
@@ -4023,8 +4023,9 @@ df_note_bb_compute (unsigned int bb_inde
   while (*mws_rec)
{
  struct df_mw_hardreg *mws = *mws_rec; 
+ rtx reg = REG_P (mws->mw_reg) ? mws->mw_reg : SUBREG_REG
(mws->mw_reg);
  if ((mws->type != DF_REF_REG_DEF)  
- && !df_ignore_stack_reg (REGNO (mws->mw_reg)))
+ && !df_ignore_stack_reg (REGNO (reg)))
old_dead_notes
  = df_set_dead_notes_for_mw (insn, old_dead_notes, 
  mws, live, do_not_gen,


-- 


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

[Bug target/32753] [4.2 Regression] building a crosscompiler for arm-elf fails because of an error in cirrus.md

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-07-15 23:39 ---
There are test results for GCC 4.2.1 20070706 on arm-elf here:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00334.html>.


-- 


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

[Bug rtl-optimization/32776] New: ICE RTL check: expected code 'reg', have 'concatn' in rhs_regno, at rtl.h:972

[rask at sygehus dot dk]

The attached (slightly reduced) test case causes an ICE:
$ ./xgcc -B./ -S -o /dev/null -O2 /tmp/delta/dtoa-00-o.c.
[several warnings]
/tmp/delta/dtoa-00-o.c:23: internal compiler error: RTL check: expected code
'reg', have 'concatn' in rhs_regno, at rtl.h:972

I'm using revision 126676. These are my configure flags:
--target m32c-unknown-elf --with-newlib --enable-sim --disable-gdb
--disable-nls --disable-multilib --enable-languages=c,c++
--enable-cxx-flags=-O2 --enable-checking=yes,rtl


-- 
   Summary: ICE RTL check: expected code 'reg', have 'concatn' in
rhs_regno, at rtl.h:972
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: m32c-unknown-elf


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

[Bug rtl-optimization/32776] ICE RTL check: expected code 'reg', have 'concatn' in rhs_regno, at rtl.h:972

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-07-16 11:25 ---
Created an attachment (id=13920)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13920&action=view)
Slightly reduced test case


-- 


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

[Bug rtl-optimization/32776] ICE RTL check: expected code 'reg', have 'concatn' in rhs_regno, at rtl.h:972

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-07-16 11:34 ---
The test case was derived from newlib, btw.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

   Keywords|build   |


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

[Bug bootstrap/32785] (hpux11.11)link test not allowed GCC_NO_EXECUTABLES.

[rask at sygehus dot dk]

--- Comment #13 from rask at sygehus dot dk  2007-07-17 09:53 ---
Read config.log. Look for messages about collect2.


-- 


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

[Bug target/32808] New: cris: ICE: RTL check: expected elt 0 type 'e' or 'u', have 'w' (rtx const_int) in cris_print_index, at config/cris/cris.c:499

[rask at sygehus dot dk]

Trunk revision 126699 fails to build when configured like this:
--target cris-axis-elf --with-newlib --enable-sim --disable-gdb --disable-nls
--enable-checking=yes,rtl

/home/rask/build/gcc-cris-axis-elf/./gcc/xgcc
-B/home/rask/build/gcc-cris-axis-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-cris-axis-elf/cris-axis-elf/newlib/ -isystem
/home/rask/build/gcc-cris-axis-elf/cris-axis-elf/newlib/targ-include -isystem
/n/12/rask/src/all/newlib/libc/include
-B/home/rask/build/gcc-cris-axis-elf/cris-axis-elf/libgloss/cris
-L/home/rask/build/gcc-cris-axis-elf/cris-axis-elf/libgloss/libnosys
-L/n/12/rask/src/all/libgloss/cris -B/usr/local/cris-axis-elf/bin/
-B/usr/local/cris-axis-elf/lib/ -isystem /usr/local/cris-axis-elf/include
-isystem /usr/local/cris-axis-elf/sys-include
-L/home/rask/build/gcc-cris-axis-elf/./ld -O2 -g -O2 -march=v10
-mbest-lib-options -O2  -O2 -g -O2  -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/n/12/rask/src/all/libgcc -I/n/12/rask/src/all/libgcc/.
-I/n/12/rask/src/all/libgcc/../gcc -I/n/12/rask/src/all/libgcc/../include 
-DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/n/12/rask/src/all/libgcc/../gcc/libgcc2.c \

/n/12/rask/src/all/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/n/12/rask/src/all/libgcc/../gcc/libgcc2.c:566: internal compiler error: RTL
check: expected elt 0 type 'e' or 'u', have 'w' (rtx const_int) in
cris_print_index, at config/cris/cris.c:499


-- 
   Summary: cris: ICE: RTL check: expected elt 0 type 'e' or 'u',
have 'w' (rtx const_int) in cris_print_index, at
config/cris/cris.c:499
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: cris-axis-elf


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

[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-07-18 11:27 ---
It happens on sh-unknown-elf too compiling newlib:

make[8]: Entering directory
`/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2a/newlib/libc/stdlib'
Makefile:1333: warning: overriding commands for target `lib_a-mbtowc_r.o'
Makefile:791: warning: ignoring old commands for target `lib_a-mbtowc_r.o'
/home/rask/build/gcc-sh-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-sh-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2a/newlib/ -isystem
/home/rask/build/gcc-sh-unknown-elf/sh-unknown-elf/m2a/newlib/targ-include
-isystem /n/12/rask/src/all/newlib/libc/include
-B/usr/local/sh-unknown-elf/bin/ -B/usr/local/sh-unknown-elf/lib/ -isystem
/usr/local/sh-unknown-elf/include -isystem
/usr/local/sh-unknown-elf/sys-include
-L/home/rask/build/gcc-sh-unknown-elf/./ld  -m2a -DPACKAGE_NAME=\"newlib\"
-DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\"
-DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\"  -I.
-I/n/12/rask/src/all/newlib/libc/stdlib -O2 -fno-builtin  -O2 -g -O2   -m2a
-c -o lib_a-dtoa.o `test -f 'dtoa.c' || echo
'/n/12/rask/src/all/newlib/libc/stdlib/'`dtoa.c
/n/12/rask/src/all/newlib/libc/stdlib/dtoa.c: In function '_dtoa_r':
/n/12/rask/src/all/newlib/libc/stdlib/dtoa.c:862: internal compiler error: RTL
check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:972


-- 


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

[Bug target/32808] cris: ICE: RTL check: expected elt 0 type 'e' or 'u', have 'w' (rtx const_int) in cris_print_index, at config/cris/cris.c:499

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-07-18 13:48 ---
Fixed as of revision 126720.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/32761] [4.3 Regression] build broke: var_tracking loses track of register elimination, crashes in find_src_set_src on parallel set

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-07-19 13:31 ---
Created an attachment (id=13939)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13939&action=view)
Test case for frv-unknown-elf with -O2 -g -mcpu=fr400

It breaks on frv-unknown-elf as well:

Program received signal SIGSEGV, Segmentation fault.
find_src_set_src (set=0xdf05a0, loc=0x2b2c3b921760, insn=)
at /n/12/rask/src/all/gcc/var-tracking.c:1865
1865  if (REG_P (src))
(gdb) call debug_rtx(src)
(nil)


-- 


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

[Bug target/32558] v850: unrecognizable insn compiling libgcc2 on 64-bit CPU

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-07-21 09:07 ---
Fixed as of revision 126318.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/32848] FAIL: g++.dg/opt/pr24665.C

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-07-21 23:03 ---
The testcase also fails on:
i686-pc-linux-gnu
x86_64-unknown-linux-gnu
v850-unknown-elf
sh-unknown-elf
frv-unknown-elf
cris-axis-elf
arm-unknown-elf
m32c-unknown-elf

Looking at gcc-testresults for i686-pc-linux-gnu, revision 126573 works while
126587 fails.


-- 


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

[Bug tree-optimization/32850] [4.3 Regression] g++.dg/opt/pr24665.C

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-07-22 08:25 ---
This bug had already been opened as 32746 and 32848. Please search for existing
bugs before opening new ones.


-- 


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

[Bug regression/32849] Unnecessary %esp inc/decrements in trivial code

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-07-22 16:47 ---
That is a known bug in GCC 3.4.3, causing the SSE code in f() to segfault.


-- 


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

[Bug regression/32849] Unnecessary %esp inc/decrements in trivial code

[rask at sygehus dot dk]

--- Comment #5 from rask at sygehus dot dk  2007-07-22 22:56 ---
The point is exactly to align the stack. The call instruction decrements %esp
by 4 bytes, so GCC has to decrement %esp by another 12 bytes to keep the stack
aligned. See also bug target/13685.


-- 


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

[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0

[rask at sygehus dot dk]

--- Comment #9 from rask at sygehus dot dk  2007-07-24 14:56 ---
This is not fully fixed yet. Compile these two functions with -O2
-fdump-tree-original:

void test5_1(int e)
{
  if ((e >> 31) & 64)
foo();
}

typedef int myint;

void test5_2(myint e)
{
  if ((e >> 31) & 64)
foo();
}

On x86_64-unknown-linux-gnu, I get (4.2.0, 4.2.1 and mainline):

;; Function test5_1 (test5_1)
;; enabled by -tree-original


{
  if (e < 0)
{
  foo ();
}
}



;; Function test5_2 (test5_2)
;; enabled by -tree-original

{
  if (((int) (e >> 31) & 64) != 0)
{
  foo ();
}
}


We should get identical dumps for the two functions. I noticed this problem
while trying to fix the original testcase to work targets where an int is
not exactly 32 bits wide. The attached patch to fix the testcase revealed
the problem.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 CC|    |rask at sygehus dot dk


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

[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0

[rask at sygehus dot dk]

--- Comment #10 from rask at sygehus dot dk  2007-07-24 15:00 ---
Created an attachment (id=13959)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13959&action=view)
Patch to fix testcase when int isn't exactly 32 bits


-- 


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

[Bug target/32886] New: c4x: error: unrecognizable insn configuring libgcc

[rask at sygehus dot dk]

GCC revision 126809 configured with these flags:
--target=c4x --disable-gdb --with-newlib --enable-sim --enable-obsolete

configure:2567: checking for suffix of object files
configure:2588: /home/rask/build/gcc-c4x/./gcc/xgcc
-B/home/rask/build/gcc-c4x/./gcc/ -nostdinc
-B/home/rask/build/gcc-c4x/c4x/newlib/ -isystem
/home/rask/build/gcc-c4x/c4x/newlib/targ-include -isystem
/n/12/rask/src/all/newlib/libc/include -B/usr/local/c4x/bin/
-B/usr/local/c4x/lib/ -isystem /usr/local/c4x/include -isystem
/usr/local/c4x/sys-include -L/home/rask/build/gcc-c4x/./ld -c -O2 -g -O2  
conftest.c >&5
conftest.c: In function 'main':
conftest.c:16: error: unrecognizable insn:
(insn 6 5 9 3 conftest.c:12 (set (reg:QI 37 [  ])
(const_int 0 [0x0])) -1 (nil))
conftest.c:16: internal compiler error: in extract_insn, at recog.c:1991
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
configure:2591: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2605: error: cannot compute suffix of object files: cannot compile


-- 
   Summary: c4x: error: unrecognizable insn configuring libgcc
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: c4x-unknown-coff


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

[Bug testsuite/32471] Testcases which always fail on targets where an int is 16 bits

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-07-27 23:05 ---
Fixed as of revision 127005.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/32923] [4.3.0 Regression] too many memory references for `lea'

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-07-28 09:00 ---
This is not a GCC bug. The part that fails is broken, inline asm:

#APP
# 173 "include/asm/string.h" 1
movb %al,%ah
1:  lodsb
cmpb %ah,%al
jne 2f
leal -1(%esi),20(%esp)
2:  testb %al,%al
jne 1b
# 0 "" 2
#NO_APP

Please take this up with whoever supplied you with include/asm/string.h.


-- 


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

[Bug target/29493] -masm=intel - does not emit right asm code

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-08-02 09:42 ---
It's still broken as of "4.3.0 20070729 (experimental)".


-- 


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

[Bug target/29493] -masm=intel - does not emit right asm code

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-08-04 15:37 ---
This appears to intentional. On systems without a prefix on labels, registers
are always prefixed with %. This is so that you can have global variables named
.e.g. edx.


-- 


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

[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))

[sgh at sgh dot dk]

--- Comment #8 from sgh at sgh dot dk  2007-08-06 09:08 ---
also fails on 4.2.1


-- 

sgh at sgh dot dk changed:

   What|Removed |Added

 CC||sgh at sgh dot dk


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

[Bug inline-asm/20518] New: Clobber registers,in inline asm. Problem when using rcall

[bl at rosetechnology dot dk]

When register are listet as clobbert, they are used anyway for local variables 
if the inline assembly code uses rcall. The r1 (zeroreg) is not restored even 
if it is clobbert.
None of these problems genrates error or warnings.

-- 
   Summary: Clobber registers,in inline asm. Problem when using
rcall
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bl at rosetechnology dot dk
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: 3.4.3
  GCC host triplet: win
GCC target triplet: avr


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

[Bug inline-asm/20518] Clobber registers,in inline asm. Problem when using rcall

[bl at rosetechnology dot dk]

--- Additional Comments From bl at rosetechnology dot dk  2005-03-17 14:41 
---
Created an attachment (id=8410)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8410&action=view)
Testcase with listfile

This show the wrong generated code.

-- 


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

[Bug inline-asm/20518] Clobber registers,in inline asm. Problem when using rcall

[bl at rosetechnology dot dk]

-- 
   What|Removed |Added

   Keywords||wrong-code


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

[Bug c++/20578] New: Problem with templates

[mah at systematic dot dk]

The following C++ code does not compile, which I believe it should (It 
compiles on gcc 1.1.1 and Microsoft's VS.NET):

Code start
template 
class A {
protected:
  int a;
};

template 
class B: public A {
public:
  void f() { a = 5; }
};
Code end
I get the following error:
test.cpp: In member function `void B::f()':
test.cpp:10: error: `a' undeclared (first use this function)
test.cpp:10: error: (Each undeclared identifier is reported only once for each 
function it appears in.)
asterix:components/mde> /pack/gcc/3.4.3/bin/g++ test.cpptest.cpp: In member 
function `void B::f()':
test.cpp:10: error: `a' undeclared (first use this function)
test.cpp:10: error: (Each undeclared identifier is reported only once for each 
function it appears in.)

-- 
   Summary: Problem with templates
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mah at systematic dot dk
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20578] Problem with templates

[mah at systematic dot dk]

--- Additional Comments From mah at systematic dot dk  2005-03-21 15:49 
---
Subject: RE:  Problem with templates

Thank you for an extreemly quick response. My code is now compiling:-)


Med venlig hilsen / kind regards

Martin Hansen 
Lead Architect, Products

Systematic Software Engineering A/S
Søren Frichs Vej 39, DK-8000  Aarhus C
Tel.: +45 8943 2123
Fax: +45 8943 2020
Web: www.systematic.dk  


-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: 21. marts 2005 16:33
To: Martin Hansen
Subject: [Bug c++/20578] Problem with templates


--- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-21 
15:32 --- No this should not compile.  a is not dependent so it needs to be 
looked up at the point of the definition and not instaination.

Read the 3.4.x release notes to figure out how to fix your code.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

--- You are receiving this mail because: --- You reported the bug, or 
are watching the reporter.




-- 


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

[Bug preprocessor/20989] New: The -M option gives object file names without directory

[bje at safepro dot dk]

The -M preprocessor option (and -MM and similar options) strips the directory
part from the listed object file names. The documentaion for -M says:

 "Unless specified explicitly (with `-MT' or `-MQ'), the object file
  name consists of the basename of the source file with any suffix
  replaced with object file suffix."

I interpret the word "basename" in the manual text to include directories as the
basename function in GNU make does, however the actual output is without
directories:

=== Content of test/test.c ===
#include "test.h"
#include 
int main ()
{
puts (GREETING);
}
=== Content of test/test.h ===
#ifndef TEST_H
#define TEST_H
#define GREETING "Hello world"
#endif
===
$ gcc -MM test/test.c
test.o: test/test.c test/test.h
$

I had expected the output to be: "test/test.o: test/test.c test/test.h".

-- 
   Summary: The -M option gives object file names without directory
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at safepro dot dk
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug preprocessor/20989] The -M option gives object file names without directory

[bje at safepro dot dk]

--- Additional Comments From bje at safepro dot dk  2005-04-13 13:43 ---
Then I suggest that the manual is clarified to make it clear what is meant.
The word "basename" is easy to misunderstand, especially because
the "basename" function in GNU make do keep the directory part
of its arguments.

I reopen the bug - as I think it is at least a bug in the documentation.


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug preprocessor/20989] The -M option gives object file names without directory

[bje at safepro dot dk]

--- Additional Comments From bje at safepro dot dk  2005-04-13 14:38 ---
Actually the manual explicit says that any path in the input file name is kept
by default in the description of the "-MT TARGET" option. So either the
preprocessor or the manual does have a bug when the preprocessor discards the 
path:

`-MT TARGET'
 Change the target of the rule emitted by dependency generation.  By
 default CPP takes the name of the main input file, including any
 path, deletes any file suffix such as `.c', and appends the
 platform's usual object suffix.  The result is the target.


-- 


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

[Bug fortran/18752] ICE from index triplet arithmetic for character variables

[theine at nordita dot dk]

--- Additional Comments From theine at nordita dot dk  2005-04-17 15:22 
---
Compilation of the following piece of code gives the same error message:


program test
  character, dimension(2) :: a
  integer :: i=1,j=2
  a(i:j) = a(i:j)   ! gives internal error
! a(1:2) = a(1:2)   ! works fine
end program test


Tested with:

[EMAIL PROTECTED]:~/f90/bugs $ gfc -v
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20050404/irun
--enable-languages=c,f95 --host=i386-linux
Thread model: posix
gcc version 4.1.0 20050404 (experimental)

[EMAIL PROTECTED]:~/f90/bugs $ gfortran-4.0 -v
Using built-in specs.
Target: i486-linux
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada
--prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib
--enable-nls --enable-threads=posix --without-included-gettext
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-gtk-cairo --enable-mpfr --enable-checking=release
i486-linux
Thread model: posix
gcc version 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7)

-- 


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

[Bug c/37448] New: gcc 4.3.1 cannot compile big function

[grue at diku dot dk]

After upgrading to gcc 4.3.1, I can no longer compile a function whose
source code is 0.7 Megabyte before preprocessing and 3.5 Megabyte after
preprocessing.

The function (named "testsuite") is just a long list of statements
essentially of form if(!condition){complain();exit();}

The behaviour is: CPU time goes to 100%, then RAM size grows to
1 Gigabyte, then swap space starts growing and CPU time goes to 10%.

On my previous gcc (4.2.something, I think), compilation went fine.

The problematic source can be found at http://logiweb.eu/grue/lgwam.c

The source only #includes standard headers.

The source is compiled thus:

gcc -ldl -o lgwam lgwam.c

To double check that optimization is off, I tried with -O0
which gave the same result as not using -O0.

I failed to find out how to fill in Host, Target, and Build
triplet. Sorry. Here comes the output from gcc -v:

---

[EMAIL PROTECTED]:~> gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]
(SUSE Linux)

---

Bradley Lucier (lucier aat math doot purdue doot edu) suggested
that this could resemble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854

He wrote thus at the gcc mailing list:

---

I compiled your file with a recent version of the current development
compiler

euler-27% /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../mainline/configure --enable-checking=release --
with-gmp=/pkgs/gmp-4.2.2/ --with-mpfr=/pkgs/gmp-4.2.2/ --prefix=/pkgs/
gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 4.4.0 20080827 (experimental) [trunk revision 139624] (GCC)

with

 /pkgs/gcc-mainline/bin/gcc -c lgwam.c -fmem-report -ftime-report

and got the following statistics.  If you file a bug report, then they may
prove helpful.

---

I have placed the mentioned statistics at
http://logiweb.eu/grue/lgwam.c.stats-O0


-- 
   Summary: gcc 4.3.1 cannot compile big function
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grue at diku dot dk
 GCC build triplet: See section on gcc -v in Description
  GCC host triplet: See section on gcc -v in Description
GCC target triplet: See section on gcc -v in Description


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

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[grue at diku dot dk]

--- Comment #1 from grue at diku dot dk  2008-09-10 08:01 ---
Created an attachment (id=16281)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16281&action=view)
The source mentioned in the bug description


-- 


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

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[grue at diku dot dk]

--- Comment #2 from grue at diku dot dk  2008-09-10 08:01 ---
Created an attachment (id=16282)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16282&action=view)
The statistics mentioned in the bug description


-- 


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

[Bug target/16634] arm-elf-gcc problems when generating code for __attribute__ ((interrupt ("IRQ")))

[sgh at sgh dot dk]

--- Comment #11 from sgh at sgh dot dk  2009-02-12 21:58 ---
Since this is not marked to be fixes I assume is hasn't been fixed in 4.3.3.
Wat is wrong with Pauls patch since it hasn't been included ?


-- 


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

[Bug target/54049] cr16: ICE: in gen_rtx_SUBREG with -O1

[stefan at astylos dot dk]

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

Stefan Sørensen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Stefan Sørensen  2012-08-13 
10:51:19 UTC ---
Works in 4.8-20120812 snapshot, closing.

[Bug target/57636] New: cr16: ICE while building libgcc

[stefan at astylos dot dk]

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

Bug ID: 57636
   Summary: cr16: ICE while building libgcc
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan at astylos dot dk
Target: cr16-none-elf

# ./configure --target cr16-none-elf
# make all-gcc all-target-libgcc'
...
make[4]: Entering directory
`/home/ssorensen/sources/gcc-build/cr16-none-elf/far-pic/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/home/ssorensen/sources/gcc-build/./gcc/xgcc
-B/home/ssorensen/sources/gcc-build/./gcc/ -B/usr/local/cr16-none-elf/bin/
-B/usr/local/cr16-none-elf/lib/ -isystem /usr/local/cr16-none-elf/include
-isystem /usr/local/cr16-none-elf/sys-include-g -O2 -fPIC -mcr16cplus
-mdata-model=far -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I.
-I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _udivmoddi4.o -MT _udivmoddi4.o -MD -MP -MF
_udivmoddi4.dep -DL_udivmoddi4 -c ../../../../gcc/libgcc/libgcc2.c \
  -fexceptions -fnon-call-exceptions -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc/libgcc/libgcc2.c: In function ‘__udivmoddi4’:
../../../../gcc/libgcc/libgcc2.c:1112:1: internal compiler error: in
variable_post_merge_new_vals, at var-tracking.c:4430
 }
 ^
0x8d514b variable_post_merge_new_vals
../../gcc/gcc/var-tracking.c:4428
0x9e5cf7 htab_traverse_noresize
../../gcc/libiberty/hashtab.c:784
0x8d8511 dataflow_post_merge_adjust
../../gcc/gcc/var-tracking.c:4540
0x8d8511 vt_find_locations
../../gcc/gcc/var-tracking.c:6965
0x8de854 variable_tracking_main_1
../../gcc/gcc/var-tracking.c:10166
0x8de854 variable_tracking_main()
../../gcc/gcc/var-tracking.c:10212

Removing either the -g or the -O2 from the compile command avoids the ICE.

It was introduced in trunk@188870:
2012-06-21  Alexandre Oliva  

PR debug/53671
PR debug/49888
* var-tracking.c (vt_initialize): Record initial offset between
arg pointer and stack pointer.

[Bug target/57636] cr16: ICE while building libgcc

[stefan at astylos dot dk]

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

--- Comment #1 from Stefan Sørensen  ---
Created attachment 30318
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30318&action=edit
Simple testcase that triggers the ICE when built with -Os -g

[Bug c/35649] Incorrect printf warning: expect double has float

[sgh at sgh dot dk]

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

Søren Holm  changed:

   What|Removed |Added

 CC||sgh at sgh dot dk

--- Comment #11 from Søren Holm  2011-10-15 21:48:25 UTC ---
Iøm having the same isssue whne compiling with -fshort-double

[Bug target/54049] New: cr16: ICE: in gen_rtx_SUBREG with -O1

[stefan at astylos dot dk]

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

 Bug #: 54049
   Summary: cr16: ICE: in gen_rtx_SUBREG with -O1
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@astylos.dk
Target: cr16-none-elf


Created attachment 27845
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27845
Minimized testcase

# cr16-none-elf-gcc -v -O1 -c cr16-o1-ice.c
Using built-in specs.
COLLECT_GCC=cr16-none-elf-gcc
Target: cr16-none-elf
Configured with: ../gcc-4.7.1/configure --disable-dependency-tracking
--disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
--target=cr16-none-elf --enable-targets=all --program-prefix=cr16-none-elf-
--enable-languages=c --without-headers --enable-sjlj-exceptions
--with-system-libunwind --disable-nls --disable-threads --disable-shared
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath
--disable-gold --disable-decimal-float --enable-checking=
--enable-gnu-unique-object --enable-linker-build-id --disable-plugin
--enable-nls --with-system-zlib
Thread model: single
gcc version 4.7.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O1' '-c'
 /usr/libexec/gcc/cr16-none-elf/4.7.1/cc1 -quiet -v cr16-o1-ice.c -quiet
-dumpbase cr16-o1-ice.c -auxbase cr16-o1-ice -O1 -version -o /tmp/cckoKsDA.s
GNU C (GCC) version 4.7.1 (cr16-none-elf)
compiled by GNU C version 4.7.0 20120507 (Red Hat 4.7.0-5), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/cr16-none-elf/4.7.1/../../../../cr16-none-elf/sys-include"
ignoring nonexistent directory
"/usr/lib/gcc/cr16-none-elf/4.7.1/../../../../cr16-none-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/cr16-none-elf/4.7.1/include
 /usr/lib/gcc/cr16-none-elf/4.7.1/include-fixed
End of search list.
GNU C (GCC) version 4.7.1 (cr16-none-elf)
compiled by GNU C version 4.7.0 20120507 (Red Hat 4.7.0-5), GMP version
5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4e373966a7f913a5f46786a9aa6c7050
cr16-o1-ice.c: In function ‘f’:
cr16-o1-ice.c:14:1: internal compiler error: in gen_rtx_SUBREG, at
emit-rtl.c:769
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

# cat cr16-o1-ice.c
void f (void)
{
char buf[18];
unsigned i;
unsigned *r = 0;

for (i = 0; i < sizeof (buf); i++)
buf[i] = i;

while (1) {
for (i = 0; i < sizeof (buf); i++)
*r = buf[i];
}
}

Compiling without -O1 succeeds

[Bug target/31938] New: Wrong code on int to short cast on armeb

[bigfoot at private dot dk]

Casting a 32 bit integer to a 16 bit integer on armeb with -Os causes the
compiler to generate wrong code.

Short sample:
int foo = 4;

int blah()
{
int bar;

bar = (unsigned short)foo;

return bar;
}

This function returns 0 when compiled with -Os on GCC 4.2.0, -Os on 4.1.2 and
with -O2 or -Os on 3.4.6. Correct code is generated on 4.2.0 and 4.1.2 with -O2

Compiled like this:
$ armeb-elf-gcc -v -Os -c gcctest.c -save-temps
Using built-in specs.
Target: armeb-elf
Configured with: ../gcc-4.2.0/configure --target=armeb-elf
--enable-languages=c,c++
Thread model: single
gcc version 4.2.0
 /usr/local/libexec/gcc/armeb-elf/4.2.0/cc1 -E -quiet -v -D__USES_INITFINI__
gcctest.c -Os -fpch-preprocess -o gcctest.i
ignoring nonexistent directory
"/usr/local/lib/gcc/armeb-elf/4.2.0/../../../../armeb-elf/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/armeb-elf/4.2.0/include
 /usr/local/lib/gcc/armeb-elf/4.2.0/../../../../armeb-elf/include
End of search list.
 /usr/local/libexec/gcc/armeb-elf/4.2.0/cc1 -fpreprocessed gcctest.i -quiet
-dumpbase gcctest.c -auxbase gcctest -Os -version -o gcctest.s
GNU C version 4.2.0 (armeb-elf)
compiled by GNU C version 4.1.3 20070429 (prerelease) (Debian 4.1.2-6).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8a7e5f1c6981e39f06bc8d2ace868d72
 /usr/local/lib/gcc/armeb-elf/4.2.0/../../../../armeb-elf/bin/as -o gcctest.o
gcctest.s

Generates the following code:

.file   "gcctest.c"
.text
.align  2
.global blah
.type   blah, %function
blah:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldrhr0, [r3, #0]
@ lr needed for prologue
bx  lr
.L4:
.align  2
.L3:
.word   foo
.size   blah, .-blah
.global foo
.data
.align  2
.type   foo, %object
.size   foo, 4
foo:
.word   4
.ident  "GCC: (GNU) 4.2.0"

Which tries to load a 16 bit value from the address of foo, which will always
be 0.


-- 
   Summary: Wrong code on int to short cast on armeb
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bigfoot at private dot dk
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: armeb-unknown-elf


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

[Bug target/32055] New: reload failure building libgfortran

[rask at sygehus dot dk]

I have configured gcc (revision 124905) like this:
/n/08/rask/src/gcc/configure --target=m32c-unknown-elf --with-gmp=${HOME}/opt
--with-mpfr=${HOME}/opt --disable-nls --with-newlib --enable-sim
--disable-multilib

Building libgfortran fails with this ICE:

/home/rask/build/gcc-m32c-unknown-elf/./gcc/gfortran
-B/home/rask/build/gcc-m32c-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/usr/local/m32c-unknown-elf/bin/ -B/usr/local/m32c-unknown-elf/lib/ -isystem
/usr/local/m32c-unknown-elf/include -isystem
/usr/local/m32c-unknown-elf/sys-include
-L/home/rask/build/gcc-m32c-unknown-elf/./ld
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/libnosys -I .
-Wall -fno-repack-arrays -fno-underscoring -fallow-leading-underscore -g -O2 -c
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90 -o
selected_int_kind.o
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90: In function
'_gfortran_selected_int_kind':
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: error:
unable to find a register to spill in class 'A_REGS'
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: error: this
is the insn:
(jump_insn 81 79 117 3
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:36 (set (pc)
(if_then_else (lt (mem/s/u:HI (plus:HI (reg:SI 0 r0 [100])
(const:HI (plus:HI (symbol_ref:HI ("int_infos.867")
[flags 0x2] )
(const_int 6 [0x6] [2 .range+2 S2
A8])
(reg:HI 3 r3 [orig:108 pretmp.24+2 ] [108]))
(label_ref 96)
(pc))) 48 {cbranchhi4} (insn_list:REG_DEP_TRUE 79 (nil))
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:42: internal
compiler error: in spill_failure, at reload1.c:2002

The (plus:HI (reg:SI ...)) bit looks suspicious.


-- 
   Summary: reload failure building libgfortran
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i386-unknown-netbsdelf2.0.2
  GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target triplet: m32c-unknown-elf


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

[Bug rtl-optimization/32069] New: segfault in regclass() with -O0 -fsplit-wide-types

[rask at sygehus dot dk]

-bash-3.2$ /usr/local/gcc/bin/gcc -O0 -fsplit-wide-types /tmp/segfault.c -S -o
/dev/null
/tmp/segfault.c: In function 'segfault':
/tmp/segfault.c:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

The lower subreg pass sets regno_reg_rtx[i] to NULL_RTX when splitting register
i. regclass() uses PSEUDO_REGNO_MODE(i) which expands to GET_MODE
(regno_reg_rtx[i)) and gives the segfault.


-- 
   Summary: segfault in regclass() with -O0 -fsplit-wide-types
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/32069] segfault in regclass() with -O0 -fsplit-wide-types

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-05-24 13:28 ---
Created an attachment (id=13608)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13608&action=view)
testcase


-- 


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

[Bug target/32097] New: ICE in expand_builtin_apply, at builtins.c:1525 building libobjc

[rask at sygehus dot dk]

I configured GCC like this:

/n/08/rask/src/gcc/configure --target=m32c-unknown-elf --with-gmp=${HOME}/opt
--with-mpfr=${HOME}/opt --disable-nls --with-newlib --enable-sim
--disable-multilib --enable-languages=c,c++,objc,java

I get an ICE building libobjc:

/home/rask/build/gcc-m32c-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-m32c-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/usr/local/m32c-unknown-elf/bin/ -B/usr/local/m32c-unknown-elf/lib/ -isystem
/usr/local/m32c-unknown-elf/include -isystem
/usr/local/m32c-unknown-elf/sys-include
-L/home/rask/build/gcc-m32c-unknown-elf/./ld
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/libnosys -c
-I. -I/n/08/rask/src/gcc/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions
-I/n/08/rask/src/gcc/libobjc/objc -I/n/08/rask/src/gcc/libobjc/../gcc
-I/n/08/rask/src/gcc/libobjc/../gcc/config -I../.././gcc
-I/n/08/rask/src/gcc/libobjc/../include /n/08/rask/src/gcc/libobjc/sendmsg.c -o
sendmsg.o
/n/08/rask/src/gcc/libobjc/sendmsg.c:44:1: warning: "rtx" redefined
In file included from /n/08/rask/src/gcc/libobjc/sendmsg.c:33:
/n/08/rask/src/gcc/libobjc/../gcc/coretypes.h:80:1: warning: this is the
location of the previous definition
/n/08/rask/src/gcc/libobjc/sendmsg.c: In function 'objc_msg_sendv':
/n/08/rask/src/gcc/libobjc/sendmsg.c:279: internal compiler error: in
expand_builtin_apply, at builtins.c:1525


-- 
   Summary: ICE in expand_builtin_apply, at builtins.c:1525 building
libobjc
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i386-unknown-netbsdelf2.0.2
  GCC host triplet: i386-unknown-netbsdelf2.0.2
GCC target triplet: m32c-unknown-elf


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

[Bug target/32097] ICE in expand_builtin_apply, at builtins.c:1525 building libobjc

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-05-26 15:50 ---
Created an attachment (id=13615)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13615&action=view)
sendmsg.c preprocessed

I have attached the preprocessed sendmsg.c in case you need it.


-- 


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

[Bug target/32130] New: linking problems: multiple definition of `__DTOR_END__'

[rask at sygehus dot dk]

Starting with the patch
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html>, committed as
revision 12, linking fails. From libffi/configure.log:

configure:2261: checking for C compiler default output file name
configure:2264: /home/rask/build/gcc-ppc/./gcc/xgcc
-B/home/rask/build/gcc-ppc/./gcc/ -nostdinc
-B/home/rask/build/gcc-ppc/powerpc-eabisim/newlib/ -isystem
/home/rask/build/gcc-ppc/powerpc-eabisim/newlib/targ-include -isystem
/n/08/rask/src/gcc/newlib/libc/include -B/usr/local/powerpc-eabisim/bin/
-B/usr/local/powerpc-eabisim/lib/ -isystem /usr/local/powerpc-eabisim/include
-isystem /usr/local/powerpc-eabisim/sys-include -L/home/rask/build/gcc-ppc/./ld
-O2 -g -O2conftest.c  >&5
/home/rask/build/gcc-ppc/./gcc/ecrtn.o:(.dtors+0x0): multiple definition of
`__DTOR_END__'
/home/rask/build/gcc-ppc/./gcc/crtend.o:(.dtors+0x0): first defined here
collect2: ld returned 1 exit status


-- 
   Summary: linking problems: multiple definition of `__DTOR_END__'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-eabisim


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

[Bug other/32154] New: sim-crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

I configured GCC like this:

/n/08/rask/src/gcc/configure --target=powerpc-unknown-eabisim --disable-nls
--with-newlib --enable-sim --disable-shared --enable-languages=c,c++,objc

When make runs configure in the target subdirectories, sim-crt0.o from libgloss
isn't found:

configure:2362: checking for C compiler version
[...]
configure:2397: /home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/xgcc
-B/home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/ -nostdinc
-B/home/rask/build/gcc-powerpc-unknown-eabisim/powerpc-unknown-eabisim/newlib/
-isystem
/home/rask/build/gcc-powerpc-unknown-eabisim/powerpc-unknown-eabisim/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/usr/local/powerpc-unknown-eabisim/bin/
-B/usr/local/powerpc-unknown-eabisim/lib/ -isystem
/usr/local/powerpc-unknown-eabisim/include -isystem
/usr/local/powerpc-unknown-eabisim/sys-include
-L/home/rask/build/gcc-powerpc-unknown-eabisim/./ld -o conftest -O2 -g -O2   
conftest.c  >&5
/home/rask/build/gcc-powerpc-unknown-eabisim/gcc/../ld/ld-new: sim-crt0.o: No
such file: No such file or directory
collect2: ld returned 1 exit status
configure:2400: $? = 1

I see this in several target subdirs' config.log:
boehm-gc/config.log
libgcc/config.log
libiberty/config.log
libssp/config.log
libstdc++-v3/config.log

The cause of the problem is that the necessary -L or -B option pointing to the
libgloss/rs6000 directory is missing. The result is that link tests fail.


-- 
   Summary: sim-crt0.o isn't found during configure due to missing -
L or -B
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-eabisim


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

[Bug target/27386] AVR: wrong code generated when passing three uint64_t arguments to function

[rask at sygehus dot dk]

--- Comment #12 from rask at sygehus dot dk  2007-05-30 21:29 ---
The AVR is unusual in having

#define STACK_PUSH_CODE POST_DEC
#define STACK_GROWS_DOWNWARD

where most targets would have PRE_DEC when the stack grows downward. The
middle-end tries to synthesize the missing pushdi pattern, but while the
offsets seem to be wrong in any case, the instruction order would be correct
for PRE_DEC. In expr.c/emit_single_push_insn(), there is this comment:

#ifdef STACK_GROWS_DOWNWARD
  /* ??? This seems wrong if STACK_PUSH_CODE == POST_DEC.  */
  dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
GEN_INT (-(HOST_WIDE_INT) rounded_size));
#else

Someone needs to set a breakpoint on emit_push_insn() and friends to find out
exactly where the problem is.


-- 


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-05-31 10:02 ---
The same thing happens when configuring with --target==mcore-unknown-elf, only
the startup file is crt0.c instead of sim-crt0.o.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 GCC target triplet|powerpc-unknown-eabisim |powerpc-eabisim mcore-elf
Summary|sim-crt0.o isn't found  |sim-crt0.o/crt0.o isn't
   |during configure due to |found during configure due
   |missing -L or -B|to missing -L or -B


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-05-31 21:01 ---
Created an attachment (id=13641)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13641&action=view)
Patch to add -L and -B as necessary

This happens on all targets except m32c-*-*. I'm testing the attached patch.


-- 


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

[Bug target/31938] Wrong code on int to short cast on armeb

[bigfoot at private dot dk]

--- Comment #2 from bigfoot at private dot dk  2007-05-31 21:22 ---
(In reply to comment #1)
> However, I suspect your test case is wrong. Unpatched versions of gcc default
> to little-endian mode on arm, even if you configure with
> --target=arm${foo}b-${bar}.
> Since you didn't pass -mbig-endian when compiling the test case, gcc will
> generate code assuming little-endian data representation. The assembly code 
> you
> listed is actually correct for little-endian.

Yes, indeed it is correct for little endian, so I assumed it was some
optimisation wrongly applied to big endian. However, you're entirely right.
Using -mbig-endian makes it produce code that looks more correct.

What I'm asking myself now is what sense there is to this default. Shouldn't it
default to big endian?


-- 


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-05-31 22:37 ---
Created an attachment (id=13642)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13642&action=view)
Patch v2 to add -L and -B as necessary

I believe I have covered boths cases of linker script placement.
The comments ended up a lot farther away from the lines they were supposed to
comment than intended.
The attached patch fixes a few things that I didn't get right in my first
attempt.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

  Attachment #13641|0   |1
is obsolete||


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #6 from rask at sygehus dot dk  2007-06-01 19:56 ---
According to the documentation, -B passes -L to the linker, so there is no need
to pass both. It seems to work as documented.


-- 


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

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[rask at sygehus dot dk]

--- Comment #4 from rask at sygehus dot dk  2007-06-06 10:33 ---
   I see no reason to mark this enhancement request as invalid.

   As to generating reasonable x86 code for overflow checks written in C, it
isn't completely hopeless. I did an experiment with my 16-bit x86 port. First,
I wrote the overflow check differently (and of course changed the data size to
16-bits):

#include 

void abort (void);

unsigned short int foo (unsigned short int a, unsigned short int b)
{
  unsigned short int sum;

  sum = a + b;
  if ((unsigned long int) a + (unsigned long int) b > USHRT_MAX)
abort ();
  return sum;
}

   Second, I added new instructions, of which combine was asking for the first
one:

(define_insn_and_split "*addsi3_cconly_highpart_ccz_nc"
  [(set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (match_operand:SI 1 "general_operand" "0")
(match_operand:SI 2 "general_operand" "g")) 2)
(const_int 0)))
   (clobber (match_scratch:HI 0 "=r"))]
  "ia16_arith_operands_p (PLUS, operands)"
  "#"
  ""
  [(parallel
  [(set (match_dup 0) (plus:HI (match_dup 3) (match_dup 4)))
   (set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC (subreg:HI (plus:SI (zero_extend:SI (match_dup 3))
(zero_extend:SI (match_dup 4))) 2)
(const_int 0)))]
  )]
{
  operands[3] = simplify_gen_subreg (HImode, operands[1], SImode, 0);
  operands[4] = simplify_gen_subreg (HImode, operands[2], SImode, 0);
})

(define_insn "*addhi3_cc_carry_ccz_nc"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=qm,r,m")
(plus:HI (match_operand:HI 1 "nonimmediate_operand" "%0,0,0")
 (match_operand:HI 2 "general_operand" "Uo,g,ri")))
   (set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (zero_extend:SI (match_dup 1))
(zero_extend:SI (match_dup 2))) 2)
(const_int 0)))]
  "ia16_arith_operands_p (PLUS, operands)"
  "@
   addb\t%H2,\t%H0
   addw\t%2,\t%0
   addw\t%2,\t%0"
)

(define_insn "*addhi3_cconly_carry_ccz_nc"
  [(set (match_scratch:HI 0 "=qm,r,m")
(plus:HI (match_operand:HI 1 "nonimmediate_operand" "%0,0,0")
 (match_operand:HI 2 "general_operand" "Uo,g,ri")))
   (set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (zero_extend:SI (match_dup 1))
(zero_extend:SI (match_dup 2))) 2)
(const_int 0)))]
  "ia16_arith_operands_p (PLUS, operands)"
  "@
   addb\t%H2,\t%H0
   addw\t%2,\t%0
   addw\t%2,\t%0"
)

(define_insn "*beq_ccz_nc"
[(set (pc)
  (if_then_else (eq (reg:CCZ_NC CC_REG)
(const_int 0))
(label_ref (match_operand 0))
(pc)))]
""
"jnc\t%l0"
)

   Third, I created CCZ_NCmode and modified my SELECT_CC_MODE callback to use
it for the comparison in "*addsi3_cconly_highpart_ccz_nc". Result:

foo:
pushw   %cx ;# 69   *pushhi1_nonimm
pushw   %si ;# 70   *pushhi1_nonimm
pushw   %di ;# 71   *pushhi1_nonimm
pushw   %bp ;# 72   *pushhi1_nonimm
movw%sp,%bp ;# 67   *movhi/1
movw10(%bp),%di ;# 2*movhi/1
movw%sp,%si ;# 68   *movhi/1
movw12(%si),%bp ;# 3*movhi/1
movw%bp,%ax ;# 7*movhi/1
addw%di,%ax ;# 63   *addhi3_cc_carry_ccz_nc/2
jnc .L7 ;# 15   *beq_ccz_nc
callabort   ;# 25   *call
.L7:
popw%bp ;# 75   *pophi1
popw%di ;# 76   *pophi1
popw%si ;# 77   *pophi1
popw%cx ;# 78   *pophi1
ret     ;# 79   *return

   I see no reason the i386 back end can't be improved in a similiar fashion.

   The original example is a lot more difficult because it uses two
comparisons. The middle end would have to recognize that the two comparisons
test the same thing.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 CC||rask at sygehus dot dk


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #7 from rask at sygehus dot dk  2007-06-08 17:35 ---
Created an attachment (id=13669)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669&action=view)
Patch v3 to add -L and -B as necessary

This patch should fix the mep* case that I accidentally deleted.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

  Attachment #13642|0   |1
is obsolete||


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

[Bug target/32262] New: ICE in convert_memory_address, at explow.c:326 compiling libgfortran

[rask at sygehus dot dk]

I have configure gcc like this:

/n/08/rask/src/gcc/configure --target=m68hc11-none --disable-multilib
--disable-nls --with-newlib --enable-sim

Building libgfortran fails with this message:

libtool: compile:  /home/rask/build/gcc-m68hc11-none/./gcc/gfortran
-B/home/rask/build/gcc-m68hc11-none/./gcc/ -nostdinc
-B/home/rask/build/gcc-m68hc11-none/m68hc11-none/newlib/ -isystem
/home/rask/build/gcc-m68hc11-none/m68hc11-none/newlib/targ-include -isystem
/n/08/rask/src/gcc/newlib/libc/include
-B/home/rask/build/gcc-m68hc11-none/m68hc11-none/libgloss/m68hc11
-L/home/rask/build/gcc-m68hc11-none/m68hc11-none/libgloss/libnosys
-L/n/08/rask/src/gcc/libgloss/m68hc11 -B/usr/local/m68hc11-none/bin/
-B/usr/local/m68hc11-none/lib/ -isystem /usr/local/m68hc11-none/include
-isystem /usr/local/m68hc11-none/sys-include
-L/home/rask/build/gcc-m68hc11-none/./ld -I . -Wall -fno-repack-arrays
-fno-underscoring -fallow-leading-underscore -g -O2 -c
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90 -o
selected_int_kind.o
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90: In function
'_gfortran_selected_int_kind':
/n/08/rask/src/gcc/libgfortran/intrinsics/selected_int_kind.f90:22: internal
compiler error: in convert_memory_address, at explow.c:326
Please submit a full bug report,
[...]


-- 
   Summary: ICE in convert_memory_address, at explow.c:326 compiling
libgfortran
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-unknown-none


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

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-06-09 11:02 ---
It is still broken as of revision 125570.


-- 


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #8 from rask at sygehus dot dk  2007-06-11 22:05 ---
Bug bootstrap/12019 looks similiar to this one.


-- 


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

[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl

[rask at sygehus dot dk]

--- Comment #7 from rask at sygehus dot dk  2007-06-13 13:36 ---
Looking at this again, I don't think the transformation I'm making with the
splitter is valid, because I'm making up a zero extension which wasn't there to
begin with. The upper part could have been non-zero before the instruction.
As to the original example, it should be possible to optimize

 addl%eax, %edx
 cmpl%edx, %eax
 ja  .L7
into
 addl%eax, %edx
 jc  .L7

with a CCmode expressing that the carry flag is set if %edx is smaller than
%eax.


-- 


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

[Bug target/32332] New: libobjc build failure on arm-unknown-eabi (__gnu_objc_personality_v0)

[rask at sygehus dot dk]

fies array type
make[2]: *** [exception.lo] Error 1
make[2]: Leaving directory
`/home/rask/build/gcc-arm-unknown-eabi/arm-unknown-eabi/libobjc'
make[1]: *** [all-target-libobjc] Error 2
make[1]: Leaving directory `/home/rask/build/gcc-arm-unknown-eabi'
make: *** [all] Error 2


-- 
   Summary: libobjc build failure on arm-unknown-eabi
(__gnu_objc_personality_v0)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-eabi


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

[Bug target/32335] New: libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

[rask at sygehus dot dk]

Here's how I configure gcc:

/n/08/rask/src/gcc/configure --target=m32c-unknown-elf --disable-libgfortran
--disable-multilib --disable-nls --with-newlib --enable-sim --disable-gdb

The error message:

/home/rask/build/gcc-m32c-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-m32c-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c
-L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/libnosys
-L/n/08/rask/src/gcc/libgloss/m32c -B/usr/local/m32c-unknown-elf/bin/
-B/usr/local/m32c-unknown-elf/lib/ -isystem /usr/local/m32c-unknown-elf/include
-isystem /usr/local/m32c-unknown-elf/sys-include
-L/home/rask/build/gcc-m32c-unknown-elf/./ld -O2 -g -O2 -O2  -O2 -g -O2 
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I.
-I../.././gcc -I/n/08/rask/src/gcc/libgcc -I/n/08/rask/src/gcc/libgcc/.
-I/n/08/rask/src/gcc/libgcc/../gcc -I/n/08/rask/src/gcc/libgcc/../include  -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c \

/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error: in
cselib_record_set, at cselib.c:1508
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [_muldi3.o] Error 1
make[2]: Leaving directory
`/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/rask/build/gcc-m32c-unknown-elf'
make: *** [all] Error 2


-- 
   Summary: libgcc build failure, ICE in cselib_record_set, at
cselib.c:1508
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf


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

[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets

[rask at sygehus dot dk]

--- Comment #7 from rask at sygehus dot dk  2007-06-14 10:36 ---
I've thought about adding ENOSYS stubs for the missing functions to libgloss.


-- 


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

[Bug target/32340] New: libjava build failure due to missing thread synchronization primitives

[rask at sygehus dot dk]

I have configured gcc like this:

/n/08/rask/src/gcc/configure --target=arm-unknown-elf --disable-multilib
--disable-nls --disable-gdb --with-newlib --enable-sim

Building libjava fails with this message:
libtool: compile:  /home/rask/build/gcc-arm-unknown-elf/./gcc/xgcc
-shared-libgcc -B/home/rask/build/gcc-arm-unknown-elf/./gcc -nostdinc++
-L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libstdc++-v3/src
-L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libstdc++-v3/src/.libs
-nostdinc -B/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/newlib/
-isystem
/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/newlib/targ-include
-isystem /n/08/rask/src/gcc/newlib/libc/include
-B/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libgloss/arm
-L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libgloss/libnosys
-L/n/08/rask/src/gcc/libgloss/arm -B/usr/local/arm-unknown-elf/bin/
-B/usr/local/arm-unknown-elf/lib/ -isystem /usr/local/arm-unknown-elf/include
-isystem /usr/local/arm-unknown-elf/sys-include
-L/home/rask/build/gcc-arm-unknown-elf/./ld -DHAVE_CONFIG_H -I.
-I/n/08/rask/src/gcc/libjava -I./include -I./gcj -I/n/08/rask/src/gcc/libjava
-Iinclude -I/n/08/rask/src/gcc/libjava/include
-I/n/08/rask/src/gcc/libjava/classpath/include -Iclasspath/include
-I/n/08/rask/src/gcc/libjava/classpath/native/fdlibm
-I/n/08/rask/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include
-I/n/08/rask/src/gcc/libjava/.././libjava/../gcc
-I/n/08/rask/src/gcc/libjava/../zlib -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall
-D_GNU_SOURCE -DPREFIX=\"/usr/local\"
-DTOOLEXECLIBDIR=\"/usr/local/arm-unknown-elf/lib\" -DJAVA_HOME=\"/usr/local\"
-DBOOT_CLASS_PATH=\"/usr/local/share/java/libgcj-4.3.0.jar\"
-DJAVA_EXT_DIRS=\"/usr/local/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/usr/local/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/usr/local/lib/gcj-4.3.0\" -DPATH_SEPARATOR=\":\"
-DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/usr/local/lib/gcj-4.3.0/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.0/classmap.db\" -MT jni-libjvm.lo
-MD -MP -MF .deps/jni-libjvm.Tpo -c /n/08/rask/src/gcc/libjava/jni-libjvm.cc -o
jni-libjvm.o
In file included from /n/08/rask/src/gcc/libjava/include/jvm.h:35,
 from /n/08/rask/src/gcc/libjava/jni-libjvm.cc:14:
./sysdep/locks.h:11:2: error: #error Thread synchronization primitives not
implemented for this platform.
In file included from /n/08/rask/src/gcc/libjava/jni-libjvm.cc:14:
/n/08/rask/src/gcc/libjava/include/jvm.h:754: error: 'obj_addr_t' does not name
a type
/n/08/rask/src/gcc/libjava/include/jvm.h:763: error: 'ParkHelper' does not name
a type
make[3]: *** [jni-libjvm.lo] Error 1
make[3]: Leaving directory
`/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/rask/build/gcc-arm-unknown-elf'
make: *** [all] Error 2


-- 
   Summary: libjava build failure due to missing thread
synchronization primitives
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf


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

[Bug target/32341] New: undefined reference to `df_set_regs_ever_live_p'

[rask at sygehus dot dk]

Here's how I configured gcc:

/n/08/rask/src/gcc/configure --target=v850-unknown-elf --disable-multilib
--disable-nls --disable-gdb --with-newlib --enable-sim

GCC fails to build with this:

gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o
c-dump.o c-pch.o c-parser.o v850-c.o c-gimplify.o tree-mudflap.o
c-pretty-print.o c-omp.o dummy-checksum.o \
  main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -lmpfr -lgmp
libbackend.a(v850.o): In function `substitute_ep_register':
/n/08/rask/src/gcc/gcc/config/v850/v850.c:1137: undefined reference to
`df_set_regs_ever_live_p'
collect2: ld returned 1 exit status
make[2]: *** [cc1-dummy] Error 1
make[2]: Leaving directory `/home/rask/build/gcc-v850-unknown-elf/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/rask/build/gcc-v850-unknown-elf'
make: *** [all] Error 2


-- 
   Summary: undefined reference to `df_set_regs_ever_live_p'
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: v850-unknown-elf


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

[Bug target/32341] undefined reference to `df_set_regs_ever_live_p'

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-06-14 15:43 ---
Finally, I can close a bug as fixed. :-)


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug other/32154] sim-crt0.o/crt0.o isn't found during configure due to missing -L or -B

[rask at sygehus dot dk]

--- Comment #9 from rask at sygehus dot dk  2007-06-15 14:24 ---
Bug bootstrap/28949 is also similiar to this one.
Btw, this bug is the root cause of the error message 'Link tests are not
allowed after GCC_NO_EXECUTABLES' for newlib targets, so it should show up in
searches for that message, which it will now.


-- 


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

[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

[rask at sygehus dot dk]

--- Comment #5 from rask at sygehus dot dk  2007-06-17 08:43 ---
I agree that the insn is invalid. It probably should be something like this:

 (parallel [
 (set (reg:PSI 7 fb)
 (mem:PSI (reg:PSI 7 fb) [0 S4 A8]))
 (set (reg:PSI 8 sp)
 (plus:PSI (reg:PSI 7 fb)
 (const_int 2 [0x2])))
 (return)
 ])

I.e. one set of sp and fb each. The faulty pattern is named "epilogue_exitd".
The two patterns "prologue_enter_16" and "prologue_enter_24" are also broken in
that they use 
(parallel [
... (pre_dec (SP_REGNO))
(set (SP_REGNO) ...)
])
which is just another invalid use of PARALLEL. DJ?

On the AVR, my bets are on the define_insn "call_prologue_saves" with two sets
of (reg:HI SP_REG) inside the implicit parallel.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 GCC target triplet|m32c-unknown-elf|m32c-unknown-elf avr-
   ||unknown-elf


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

[Bug c/32397] wrong instruction order generated

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-06-19 11:27 ---
You can use memcpy (&int, &float, min (sizeof (int), sizeof (float))) and vice
versa. I suppose you can also memcpy() into or out of a char array of the right
size.
If you were to use the GCC extension of using a union, it would look something
like this:

double x;
cyg_uint32 hx, lx;
Cyg_libm_ieee_double_shape_type tmp;

tmp.value = x;
hx = tmp.parts.msw
lx = tmp.parts.lsw


-- 


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

[Bug bootstrap/12019] check for working C compiler on newlib targets fails due to missing crt0.o

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-06-20 11:00 ---
Does it work for you if you apply patch 3 from bug other/32154?


-- 


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

[Bug target/32418] New: ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

Configure gcc like this:

$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java

The attached file fails to compile:

$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume':
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in
global_alloc, at global.c:514


-- 
   Summary: ICE in global_alloc, at global.c:514
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf


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

[Bug target/32419] New: ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

Configure gcc like this:

$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java

The attached file fails to compile:

$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume':
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in
global_alloc, at global.c:514


-- 
   Summary: ICE in global_alloc, at global.c:514
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-06-20 13:21 ---
Created an attachment (id=13742)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13742&action=view)
Preprocessed testcase


-- 


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

[Bug target/32420] New: ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

Configure gcc like this:

$ [...]/configure --target m32c-unknown-elf --with-newlib--enable-sim
--disable-gdb --disable-nls --enable-languages=c,c++,java

The attached file fails to compile:

$ ./xgcc -B./ ~/unwind-dw2.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc: In function '_Unwind_Resume':
/n/08/rask/src/gcc/libgcc/../gcc/unwind.inc:241: internal compiler error: in
global_alloc, at global.c:514


-- 
   Summary: ICE in global_alloc, at global.c:514
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #2 from rask at sygehus dot dk  2007-06-20 13:24 ---
*** Bug 32420 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/32420] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-06-20 13:24 ---


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


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/32419] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-06-20 13:25 ---


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


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #3 from rask at sygehus dot dk  2007-06-20 13:25 ---
*** Bug 32419 has been marked as a duplicate of this bug. ***


-- 


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

[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

[rask at sygehus dot dk]

--- Comment #10 from rask at sygehus dot dk  2007-06-20 13:41 ---
I'm adding the m32c back because the testcase for bug 32069 fails with
optimization turned on:

$ ./xgcc -B./ /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c -S -dp -o
/dev/null -O1
/n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c: In function 'segfault':
/n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:7: internal compiler error:
in cselib_record_set, at cselib.c:1508

(gdb) call debug_rtx(insn)
(jump_insn 62 61 63 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:7
(parallel [
(set (reg:PSI 8 sp)
(plus:PSI (reg:PSI 7 fb)
(const_int 2 [0x2])))
(set (reg:PSI 7 fb)
(mem:PSI (reg:PSI 7 fb) [0 S4 A8]))
(return)
]) -1 (nil))


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 GCC target triplet|avr-unknown-elf |avr-unknown-elf m32c-
   ||unknown-elf


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

[Bug target/32335] libgcc build failure, ICE in cselib_record_set, at cselib.c:1508

[rask at sygehus dot dk]

--- Comment #11 from rask at sygehus dot dk  2007-06-20 13:52 ---
Ah, notice the mismatch in register sizes between prologue and epilogue:
(insn/f 59 5 60 2 /n/08/rask/src/gcc/gcc/testsuite/gcc.dg/pr32069.c:5 (parallel
[
(set/f (mem:HI (plus:HI (reg/f:HI 8 sp)
(const_int -2 [0xfffe])) [0 S2 A8])
(reg/f:HI 7 fb))
(set/f (reg/f:HI 7 fb)
(reg/f:HI 8 sp))
(set/f (reg/f:HI 8 sp)
(minus:HI (reg/f:HI 8 sp)
(const_int 2 [0x2])))
]) -1 (nil))


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 GCC target triplet|avr-unknown-elf m32c-   |avr-unknown-elf
   |unknown-elf |


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

[Bug target/32431] New: ICE in df_refs_verify, at df-scan.c:4066

[rask at sygehus dot dk]

I have configured GCC this way:
$ /n/08/rask/src/gcc/configure --target m68hc11-unknown-none --disable-gdb
--disable-nls --with-newlib

The attached testcase causes an ICE:
$ ./xgcc -B./ ~/muldi3.c -S -dp -o /dev/null -O2
/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error: in
df_refs_verify, at df-scan.c:4066


-- 
   Summary: ICE in df_refs_verify, at df-scan.c:4066
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68hc11-unknown-none


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

[Bug target/32431] ICE in df_refs_verify, at df-scan.c:4066

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-06-20 16:58 ---
Created an attachment (id=13747)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13747&action=view)
Preprocessed testcase


-- 


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #5 from rask at sygehus dot dk  2007-06-20 17:24 ---
I'll CC DJ Delorie since he'll know why EH_RETURN_STACKADJ_RTX has been defined
that way.


-- 

rask at sygehus dot dk changed:

   What|Removed |Added

 CC||dj at redhat dot com


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #7 from rask at sygehus dot dk  2007-06-20 20:08 ---
This is something I have no clue about.


-- 


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

[Bug target/32441] New: ICE in expand_expr_real_1, at expr.c:7109

[rask at sygehus dot dk]

Here's how I configure GCC:
$ /n/08/rask/src/gcc/configure --target m32c-unknown-elf
--with-newlib--enable-sim --disable-gdb --disable-nls
--enable-languages=c,c++,java

This is how to reproduce the failure:

$ ./xgcc -B./ ~/__dprintf.c -S -dp -o /dev/null -mcpu=m32cm
/n/08/rask/src/gcc/newlib/libc/misc/__dprintf.c: In function '__dprintf':
/n/08/rask/src/gcc/newlib/libc/misc/__dprintf.c:73: internal compiler error: in
expand_expr_real_1, at expr.c:7109


-- 
   Summary: ICE in expand_expr_real_1, at expr.c:7109
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m32c-unknown-elf


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

[Bug target/32441] ICE in expand_expr_real_1, at expr.c:7109

[rask at sygehus dot dk]

--- Comment #1 from rask at sygehus dot dk  2007-06-20 21:36 ---
Created an attachment (id=13750)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13750&action=view)
Preprocessed testcase


-- 


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #9 from rask at sygehus dot dk  2007-06-21 15:59 ---
I tried this on top of the patch in comment 3 of bug 32441:

Index: gcc/config/m32c/m32c.c
===
--- gcc/config/m32c/m32c.c  (revision 125892)
+++ gcc/config/m32c/m32c.c  (working copy)
@@ -1143,7 +1143,7 @@ m32c_eh_return_stackadj_rtx (void)
 {
   rtx sa;

-  sa = gen_reg_rtx (Pmode);
+  sa = gen_rtx_REG (Pmode, R0_REGNO);
   cfun->machine->eh_stack_adjust = sa;
 }
   return cfun->machine->eh_stack_adjust;

The build then ends with a reload failure in libstdc++.

Spilling for insn 228.
reload failure for reload 0

Reloads for insn # 228
Reload 0: reload_in (HI) = (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))
A_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (plus:HI (reg/f:HI 7 fb)
(const_int 0 [0x0]))

The lreg dump shows some insn sequences which use up both registers in
A_REGS:

(jump_insn 237 235 238 5 (set (pc)
(label_ref 236)) 163 {jump} (nil))

(barrier 238 237 227)

(code_label/s 227 238 230 6 56 "" [1 uses])

(note 230 227 228 6 [bb 6])

(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))

(insn 229 228 102 6 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))

...
(jump_insn 243 241 244 13 (set (pc)
(label_ref 242)) 163 {jump} (nil))

(barrier 244 243 223)

(code_label/s 223 244 226 14 55 "" [1 uses])

(note 226 223 224 14 [bb 14])

(insn 224 226 225 14 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))

(insn 225 224 166 14 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))

(note/s 166 225 168 14 "" 52)
...
(insn 203 197 231 15
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527
(use (reg/i:HI 0 r0)) -1 (nil))

(code_label/s 231 203 234 16 57 "" [1 uses])

(note 234 231 232 16 [bb 16])

(insn 232 234 233 16 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))

(insn 233 232 185 16 (set (reg:HI 83)
(reg:HI 5 a1)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 5 a1)
(nil)))

(code_label/s 185 233 186 17 53 "" [3 uses])

(note 186 185 187 17 [bb 17])

The usage count is one too high for all the code labels shown above. In
other words, the code that is causing reload problems is dead code. The code
first appears in the "eh" pass and refers to a0 and a1 from the beginning.

int
m32c_eh_return_data_regno (int n)
{
  switch (n)
{
case 0:
  return A0_REGNO;
case 1:
  return A1_REGNO;
default:
  return INVALID_REGNUM;
}
}


-- 


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #10 from rask at sygehus dot dk  2007-06-21 16:15 ---
Created an attachment (id=13758)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13758&action=view)
Preprocessed source code for the problem in comment 9.

$ ./xgcc -B./ -S -dp -o /dev/null ~/complex_io.cc
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:
In function 'std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)
[with _Tp = long double, _CharT = char, _Traits = std::char_traits]':
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: unable to find a register to spill in class 'A_REGS'
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
error: this is the insn:
(insn 228 230 229 6 (set (reg:HI 84)
(reg:HI 4 a0)) 171 {movhi_op} (expr_list:REG_DEAD (reg:HI 4 a0)
(nil)))
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libstdc++-v3/include/complex:527:
internal compiler error: in spill_failure, at reload1.c:2002


-- 


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

[Bug target/32418] ICE in global_alloc, at global.c:514

[rask at sygehus dot dk]

--- Comment #11 from rask at sygehus dot dk  2007-06-21 18:19 ---
Disregard the comment about the code label use count. They have
LABEL_PRESERVE_P (/s) set.


-- 


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

[Bug testsuite/32471] New: Testcases which always fail on targets where an int is 16 bits

[rask at sygehus dot dk]

Starting with revision 122414, we have three testcases which will always fail
on targets where an int is 16 bits wide:

gcc.dg/torture/pr30364-1.c
gcc.dg/torture/pr30364-2.c
gcc.dg/torture/pr30364-3.c

Additionally, they will test nothing on a target where an int is 64 bits wide.


-- 
   Summary: Testcases which always fail on targets where an int is
16 bits
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at sygehus dot dk
GCC target triplet: m32c-unknown-elf avr-unknown-none h8300-unknown-elf


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