[Cygwin] Failure in building current GCC snapshot

[Angelo Graziosi]

At least on Cygwin (1.7), the current GCC snapshot (20090917) fails to 
build:


[...]
/tmp/build/./gcc/xgcc -B/tmp/build/./gcc/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include-g -O2 -O2 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/w32api/include 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/include 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/cygwin/include -g -O2 -DIN_GCC 
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. 
-I../.././gcc -I/tmp/gcc-4.5-20090917/libgcc 
-I/tmp/gcc-4.5-20090917/libgcc/. -I/tmp/gcc-4.5-20090917/libgcc/../gcc 
-I/tmp/gcc-4.5-20090917/libgcc/../include 
-I/tmp/gcc-4.5-20090917/libgcc/../libdecnumber/dpd 
-I/tmp/gcc-4.5-20090917/libgcc/../libdecnumber -DHAVE_CC_TLS -o 
_powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c 
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c \


/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powisf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal compiler 
error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powisf2.o] Error 1
make[3]: *** Waiting for unfinished jobs
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powidf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal compiler 
error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powidf2.o] Error 1
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powixf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal compiler 
error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powixf2.o] Error 1
make[3]: Leaving directory `/tmp/build/i686-pc-cygwin/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/tmp/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/build'
make: *** [all] Error 2
---

I have configured with:

-
${source_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--program-suffix="${suffix}" \
--enable-bootstrap \
--enable-checking=release \
--enable-decimal-float \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-libssp \
--enable-nls \
--enable-threads=posix \
--enable-version-specific-runtime-libs \
--disable-libmudflap \
--disable-shared \
--disable-sjlj-exceptions \
--disable-win32-registry \
--with-arch=i686 \
--with-dwarf2 \
--with-system-zlib \
--with-tune=generic \
--without-included-gettext \
--without-x
-

The previous snapshot (20090910) builds fine, with the same methods.


Cheers,
Angelo.

Re: [Cygwin] Failure in building current GCC snapshot

[Allan McRae]

Angelo Graziosi wrote:
At least on Cygwin (1.7), the current GCC snapshot (20090917) fails to 
build:


[...]
/tmp/build/./gcc/xgcc -B/tmp/build/./gcc/ 
-B/usr/local/gfortran/i686-pc-cygwin/bin/ 
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem 
/usr/local/gfortran/i686-pc-cygwin/include -isystem 
/usr/local/gfortran/i686-pc-cygwin/sys-include-g -O2 -O2 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/w32api/include 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/include 
-I/tmp/gcc-4.5-20090917/gcc/../winsup/cygwin/include -g -O2 -DIN_GCC 
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. 
-I../.././gcc -I/tmp/gcc-4.5-20090917/libgcc 
-I/tmp/gcc-4.5-20090917/libgcc/. -I/tmp/gcc-4.5-20090917/libgcc/../gcc 
-I/tmp/gcc-4.5-20090917/libgcc/../include 
-I/tmp/gcc-4.5-20090917/libgcc/../libdecnumber/dpd 
-I/tmp/gcc-4.5-20090917/libgcc/../libdecnumber -DHAVE_CC_TLS -o 
_powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c 
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c \

/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powisf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal 
compiler error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powisf2.o] Error 1
make[3]: *** Waiting for unfinished jobs
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powidf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal 
compiler error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powidf2.o] Error 1
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c: In function '__powixf2':
/tmp/gcc-4.5-20090917/libgcc/../gcc/libgcc2.c:1739:1: internal 
compiler error: in convert_regs_1, at reg-stack.c:3052

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_powixf2.o] Error 1
make[3]: Leaving directory `/tmp/build/i686-pc-cygwin/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2
make[2]: Leaving directory `/tmp/build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/tmp/build'
make: *** [all] Error 2
---

I have configured with:

-
${source_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--program-suffix="${suffix}" \
--enable-bootstrap \
--enable-checking=release \
--enable-decimal-float \
--enable-languages=c,c++,fortran \
--enable-libgomp \
--enable-libssp \
--enable-nls \
--enable-threads=posix \
--enable-version-specific-runtime-libs \
--disable-libmudflap \
--disable-shared \
--disable-sjlj-exceptions \
--disable-win32-registry \
--with-arch=i686 \
--with-dwarf2 \
--with-system-zlib \
--with-tune=generic \
--without-included-gettext \
--without-x
-

The previous snapshot (20090910) builds fine, with the same methods.


Seems to be the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395

Allan

Re: [Cygwin] Failure in building current GCC snapshot

[Angelo Graziosi]

Allan McRae ha scritto:

Angelo Graziosi wrote:
At least on Cygwin (1.7), the current GCC snapshot (20090917) fails to 


Seems to be the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395

Allan



Indeed!

Thanks,
Angelo.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> > As an alternative to the operand predicate, you might also add
> > an extra check to the insn condition.  For example, something
> > along the following lines should work:
> > 
> > (define_insn ""
> >   [(set (match_operand:SI 0 "register_operand" "=d")
> > (mult:SI (match_operand:SI 1 "register_operand" "0")
> >  (match_operand:SI 2 "const_int_operand" "K")))]
> >   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"
> 
> My eyes lit up when I saw that!  However, it produced a compiler
> error when I tried it.  But undeterred, I tried this:
> 
> (define_insn ""
>   [(set (match_operand:SI 0 "register_operand" "=d")
> (mult:SI (match_operand:SI 1 "register_operand" "0")
>  (match_operand:SI 2 "immediate_operand" "K")))]
>   "(GET_CODE (operands[2]) == CONST_INT
>&& REG_P (operands[0])
>&& CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"

Huh.  Instead of adding an explicit CONST_INT check, my approach
above used a const_int_operand predicate (instead of immediate_operand).
That should have had the exact same effect ...   I'm not sure why the
REG_P check on the other operand would be necessary at this point.

> And it worked (verified by self-compile)!  And I relaxed the 
> constraint on the "M" instruction as well.  Those old warnings 
> are apparently irrelevant now.  Thank you sir.  :-)

OK, that's good to know.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: i370 port

[Paul Edwards]

> As an alternative to the operand predicate, you might also add
> an extra check to the insn condition.  For example, something
> along the following lines should work:
>
> (define_insn ""
>   [(set (match_operand:SI 0 "register_operand" "=d")
> (mult:SI (match_operand:SI 1 "register_operand" "0")
>  (match_operand:SI 2 "const_int_operand" "K")))]
>   "CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K')"

My eyes lit up when I saw that!  However, it produced a compiler
error when I tried it.  But undeterred, I tried this:


Sorry.  I just copied the last line into the existing pattern, didn't
notice that you'd changed the predicate too.


(define_insn ""
  [(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 1 "register_operand" "0")
 (match_operand:SI 2 "immediate_operand" "K")))]
  "(GET_CODE (operands[2]) == CONST_INT
   && REG_P (operands[0])
   && CONST_OK_FOR_LETTER_P (INTVAL (operands[2]), 'K'))"


Huh.  Instead of adding an explicit CONST_INT check, my approach
above used a const_int_operand predicate (instead of immediate_operand).
That should have had the exact same effect ...   I'm not sure why the
REG_P check on the other operand would be necessary at this point.


I just copied that from the existing condition too.  Once I realised
that I could put a check in advance, I just copied the check
across basically.  I'd seen that before, it just hadn't sunk in that
I could use it for this situation.

I will try out your original suggestion again properly.  :-)


And it worked (verified by self-compile)!  And I relaxed the
constraint on the "M" instruction as well.  Those old warnings
are apparently irrelevant now.  Thank you sir.  :-)


OK, that's good to know.


Indeed.

And as I mentioned, there's just one real bug that I know of left.  I can
bypass the bug in the GCC code that I am compiling, by forcing a
function call.

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include

varasm.c
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
at

function.c:3765
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gccmvs.sourceforge.net> for instructions.

This is the code that is triggering off that bug:

force_const_mem (enum machine_mode mode, rtx x)
{
 int hash;
 struct constant_descriptor_rtx *desc;
...
   if (compare_constant_rtx (mode, x, desc))


static int
compare_constant_rtx (enum machine_mode mode, rtx x,
^I^I  struct constant_descriptor_rtx *desc)
{
 struct rtx_const value;

 decode_rtx_const (mode, x, &value);

 /* Compare constant contents.  */
#if defined(XTARGET_MVS) /* +++ seems we have a machine definition problem 
*/

 return (memcmp) (&value, &desc->value, sizeof (struct rtx_const)) == 0;
#else
 return memcmp (&value, &desc->value, sizeof (struct rtx_const)) == 0;
#endif
}


You can see how I normally work around this problem by forcing a
function call.

If I do that force, then I get this code generated:

L445 EQU   *
LTR   3,3
BEL442
MVC   88(4,13),0(11)
MVC   92(4,13),4(11)
LA2,560(,13)
ST2,96(13)
LA1,88(,13)
L 15,=A(@@F17)
BALR  14,15
ST2,88(13)
LR2,3
A 2,=F'8'
ST2,92(13)
MVC   96(4,13),=F'196'
LA1,88(,13)
L 15,=V(MEMCMP)
BALR  14,15
LTR   15,15

which is bizarre.  It seems to be comparing two values that are 8 bytes
apart, for a length of 196.  Can't imagine that doing anything useful.

It's almost certainly an i370 port bug, but I haven't had any bright
ideas on how to fix that yet.  :-)

BFN.  Paul.

Geleceğiniz için aylık 100 TL taksitle arsanzı alın.

[DEY EMLAK]

Merhaba;

Türkiyenin başkenti Ankara ve Ankara'nın gözbebeği Çankaya ilçesinde yada diğer 
ilçelerinde aylık 100 TL taksitla arsa alarak geleceğinize yatırım 
yapabileceğinizi biliyormuydunuz. Ayrıntılar için

www.deyemlak.com

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> And as I mentioned, there's just one real bug that I know of left.  I can
> bypass the bug in the GCC code that I am compiling, by forcing a
> function call.
> 
> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors 
> -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>  varasm.c
> varasm.c: In function `force_const_mem':
> varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
> at
> function.c:3765
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gccmvs.sourceforge.net> for instructions.

That's a bit hard to diagnose without some further information ...

What insn it is failing on?  (To find out, use a debugger, or maybe
add a "debug_rtx (insn)" statement before the abort in 
instantiate_virtual_regs_lossage)?

> which is bizarre.  It seems to be comparing two values that are 8 bytes
> apart, for a length of 196.  Can't imagine that doing anything useful.

This is conceivably another effect of the same bug, but again it's
hard to say.  You'd have to look at the generated RTX and see how
it changes over the various optimization stages (use -da to generate
RTX dumps after each stage).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

[4.5 bootstrap] i686-apple-darwin9 broken at 151839?

[IainS]

$ uname -v
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;  
root:xnu-1228.15.4~1/RELEASE_I386


$ more stage_current
stage3

superficial error is:
$ make -j8 bootstrap >build-log.txt 2>err-log.txt
$ tail err-log.txt
configure: error: cannot compute sizeof (long long)See `config.log'  
for more details.

make[2]: *** [configure-stage3-gcc] Error 77
make[2]: *** Waiting for unfinished jobs

but it seems that the real problem might be ( a lot of these in the  
config log) :


Assertion failed: (!"Unknown one-operand"), function LinkLocation,  
file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/ 
DWARFdSYM.cpp, line 1457.

xgcc: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.

 here is the specific long long case...

configure:5749: checking size of long long
configure:5754:  /Volumes/ScratchCS/gcc-4-5-reg-build/./prev-gcc/xgcc - 
B/Volumes/ScratchCS/gcc-4-5-reg-build/./prev-gcc/ -B/Volumes/Scrat
chCS/gcc-4-5-install/i686-apple-darwin9/bin/ -B/Volumes/ScratchCS/ 
gcc-4-5-install/i686-apple-darwin9/bin/ -B/Volumes/ScratchCS/gcc-4-5-in
stall/i686-apple-darwin9/lib/ -isystem /Volumes/ScratchCS/gcc-4-5- 
install/i686-apple-darwin9/include -isystem /Volumes/ScratchCS/gcc-4-5-
install/i686-apple-darwin9/sys-include-o conftest -g -O2 -fomit- 
frame-pointerconftest.c  >&5
Assertion failed: (!"Unknown one-operand"), function LinkLocation,  
file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.

cpp, line 1457.
xgcc: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.
See  for instructions.
configure:5754: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define HAVE_GNU_LD 0
| #define HAVE_GNU_AS 0
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define SIZEOF_VOID_P 0
| #define SIZEOF_SHORT 0
| #define SIZEOF_INT 0
| #define SIZEOF_LONG 0
| #define HAVE_LONG_LONG 1
| /* end confdefs.h.  */
| #include 
| #ifdef HAVE_SYS_TYPES_H
| # include 
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include 
| #endif
| #ifdef STDC_HEADERS
| # include 
| # include 
| #else
| # ifdef HAVE_STDLIB_H
| #  include 
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include 
| # endif
| # include 
| #endif
| #ifdef HAVE_STRINGS_H
| # include 
| #endif
| #ifdef HAVE_INTTYPES_H
| # include 
| #endif
| #ifdef HAVE_STDINT_H
| # include 
| #endif
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| static long int longval () { return (long int) (sizeof (long long)); }
| static unsigned long int ulongval () { return (long int) (sizeof  
(long long)); }

| #include 
| #include 
| int
| main ()
| {
|
|   FILE *f = fopen ("conftest.val", "w");
|   if (! f)
| return 1;
|   if (((long int) (sizeof (long long))) < 0)
| {
|   long int i = longval ();
|   if (i != ((long int) (sizeof (long long
|   return 1;
|   fprintf (f, "%ld", i);
| }
|   else
| {
|   unsigned long int i = ulongval ();
|   if (i != ((long int) (sizeof (long long
|   return 1;
|   fprintf (f, "%lu", i);
| }
|   /* Do not output a trailing newline, as this causes \r\n confusion
|  on some platforms.  */
|   return ferror (f) || fclose (f) != 0;
|
|   ;
|   return 0;
| }
configure:5758: error: in `/Volumes/ScratchCS/gcc-4-5-reg-build/gcc':
configure:5762: error: cannot compute sizeof (long long)
See `config.log' for more details.



anyone else seeing this?
Iain

Re: i370 port

[Paul Edwards]

That's a bit hard to diagnose without some further information ...

What insn it is failing on?  (To find out, use a debugger, or maybe
add a "debug_rtx (insn)" statement before the abort in
instantiate_virtual_regs_lossage)?


I did the latter.

C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors -DHAVE_CON
FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
../include

varasm.c
(insn 117 429 118 7 (parallel [
   (set (reg:SI 64)
   (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
virtual-stack-vars)


   (const_int 456 [0x1c8])) [232 value+0 S196 A64])
   (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
   (const_int 8 [0x8])) [0 A8])))
   (use (const_int 196 [0xc4]))
   ]) -1 (nil)
   (nil))
varasm.c: In function `force_const_mem':
varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
at

function.c:3767
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gccmvs.sourceforge.net> for instructions.


Which would seem to correspond to this:

; Compare a block that is less than 256 bytes in length.

(define_insn ""
 [(set (match_operand:SI 0 "register_operand" "=d")
^I(compare:SI (match_operand:BLK 1 "s_operand" "m")
^I^I (match_operand:BLK 2 "s_operand" "m")))
  (use (match_operand:QI 3 "immediate_operand" "I"))]
 "((unsigned) INTVAL (operands[3]) < 256)"
 "*
{
 check_label_emit ();
 mvs_check_page (0, 22, 0);
 return 
\"CLC^I%O1(%c3,%R1),%2\;BH^I*+12\;BL^I*+6\;SLR^I%0,%0\;LNR^I%0,%0\";

}"
  [(set_attr "length" "22")]
)



This is conceivably another effect of the same bug, but again it's
hard to say.  You'd have to look at the generated RTX and see how
it changes over the various optimization stages (use -da to generate
RTX dumps after each stage).


Ok, I'll see if I can see something.  Probably easier for me to play
around with the md though.

BFN.  Paul.

Re: [4.5 bootstrap] i686-apple-darwin9 broken at 151839?

[H.J. Lu]

On Fri, Sep 18, 2009 at 6:40 AM, IainS  wrote:
> $ uname -v
> Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
> root:xnu-1228.15.4~1/RELEASE_I386
>
> $ more stage_current
> stage3
>
> superficial error is:
> $ make -j8 bootstrap >build-log.txt 2>err-log.txt
> $ tail err-log.txt
> configure: error: cannot compute sizeof (long long)See `config.log' for more
> details.
> make[2]: *** [configure-stage3-gcc] Error 77
> make[2]: *** Waiting for unfinished jobs
>

This may be:

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


H.J.

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> C:\devel\gccnew\gcc>gccmvs -DUSE_MEMMGR -Os -S -ansi -pedantic-errors 
> -DHAVE_CON
> FIG_H -DIN_GCC -DPUREISO -I ../../pdos/pdpclib -I . -I config/i370 -I 
> ../include
>  varasm.c
> (insn 117 429 118 7 (parallel [
> (set (reg:SI 64)
> (compare:SI (mem/s:BLK (plus:SI (reg/f:SI 21 
> virtual-stack-vars)
> 
> (const_int 456 [0x1c8])) [232 value+0 S196 A64])
> (mem:BLK (plus:SI (reg/v/f:SI 61 [ desc ])
> (const_int 8 [0x8])) [0 A8])))
> (use (const_int 196 [0xc4]))
> ]) -1 (nil)
> (nil))
> varasm.c: In function `force_const_mem':
> varasm.c:3021: internal compiler error: in instantiate_virtual_regs_lossage, 
> at function.c:3767

OK, so what goes on here is that GCC attempts to replace the "virtual"
register 21 (virtual-stack-vars) with some real register, that is
frame pointer + STARTING_FRAME_OFFSET.  It seems for the i370 port,
this should resolve to
  register 13 + STACK_POINTER_OFFSET + current_function_outgoing_args_size

Overall, the middle-end would therefore replace "reg 21 + 456" with 
"reg 13 + X", where X is constant computed from 456 + STACK_POINTER_OFFSET
+ current_function_outgoing_args_size.

It will then re-process the insn pattern constraints to verify that the
resulting insn is still valid.  At this stage, it appears we're running
into the above error.  I'm not quite sure why this would be case, this
will require some further debugging why the insn was not recognized ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Is Non-Blocking cache supported in GCC?

[Janis Johnson]

On Thu, 2009-09-17 at 21:48 -0700, Ian Lance Taylor wrote:
> "Amker.Cheng"  writes:
> 
> > Recently I found two relative old papers about non-blocking cache,
> > etc. which are :
> >
> > 1) Reducing memory latency via non-blocking and prefetching
> > caches.  BY Tien-Fu Chen and Jean-Loup Baer.
> > 2) Data Prefetching:A Cost/Performance Analysis   BY Chris Metcalf
> >
> > It seems the hardware facility does have the potential to improve the
> > performance with
> > compiler's assistance(especially instruction scheduling). while on the
> > other hand, lifting ahead
> > load instructions may resulting in increasing register pressure.
> >
> > So I'm thinking :
> > 1, Has anyone from gcc folks done any investigation on this topic yet,
> > or any statistic data based on gcc available?
> > 2, Does GCC(in any release version) supports it in any targets(such as
> > mips 24ke) with this hardware feature?
> > If not currently, does it possible to support it by using target
> > definition macros and functions?
> 
> gcc is able to generate prefetches in loops, via the
> -fprefetch-loop-arrays option.  There are various related parameters,
> prefetch-latency, l1-cache-line-size, etc.  I don't know how well this
> works.  To the extent that it does work, it is supported in the MIPS
> backend, and should work on the MIPS 24ke.

There's also a prefetch built-in function; see 

http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins

It's been in GCC since 3.1.

Janis

Re: multilib and Makefile regeneration

[Ralf Wildenhues]

* Paolo Bonzini wrote on Mon, Aug 31, 2009 at 11:53:17PM CEST:
> On 08/31/2009 11:11 PM, Ralf Wildenhues wrote:
> >The easiest for now would be (3), the coolest, most difficult and
> >probably most dangerous one would be (2).  Something like
> >   AC_CONFIG_FILES_COMMANDS(some/Makefile, more-user-commands,
> >[more-init-cmds])
> >
> >but then the order of issuing this and the respective
> >   AC_CONFIG_FILES(some/Makefile)
> >
> >would be significant.  I don't see any way to avoid this.
> 
> You could specify that AC_CONFIG_FILES comes first, and *_COMMANDS
> occurrences come later in the order that appears in the source (and
> do nothing unless the corresponding AC_CONFIG_FILES exists).

Yes; but this would not solve the issue that, when interrupted, we could
end up with the wrong, intermediate Makefile.  I don't want to add a new
API that has known deficiencies.

Maybe going via an explicit intermediate file is better, a la
  AC_CONFIG_FILES([some/Makefile.ml:some/Makefile.in])
  AM_MULTILIB_FILES([some/Makefile:some/Makefile.ml])

but that requires that config.status is passed files in the right order
and rebuild dependencies in the Makefile are right.  Currently, however,
automake doesn't cope with something like the above at all ...

Cheers,
Ralf

Anyone who can bootstrap on x86_64-linux-gnu these days ?

[Toon Moene]

I get:

../../../gcc/libgcc/../gcc/libgcc2.c: In function '__powixf2':
../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in 
convert_regs_1, at reg-stack.c:3052


That's going back to revision 151853.

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: Anyone who can bootstrap on x86_64-linux-gnu these days ?

[H.J. Lu]

On Fri, Sep 18, 2009 at 12:44 PM, Toon Moene  wrote:
> I get:
>
> ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__powixf2':
> ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in
> convert_regs_1, at reg-stack.c:3052
>
> That's going back to revision 151853.
>

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

-- 
H.J.

Re: Anyone who can bootstrap on x86_64-linux-gnu these days ?

[Toon Moene]

H.J. Lu wrote:


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


Indeed, bootstrapping after:

$ svn up -r 151799

worked.

Thanks !

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html

Re: MPC 0.7 officially released, please test and report your results!

[Loren James Rittle]

Kaveh R. GHAZI wrote:

> Please download, compile and run "make check" for this release and post
> your results as well your target triplet and the versions of your
> compiler, gmp and mpfr. All platform results are welcome, but I am
> especially interested in GCC's primary and secondary platform list.

Using the default system compiler [4.2.1] on i386-unknown-freebsd7.2
with /usr/ports/math/libgmp4 [4.3.1] and /usr/ports/math/mpfr [2.4.1]:

All 45 tests passed

gcc mainline -r151819 results without any version of MPC installed:

http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01577.html

gcc mainline -r151819 results with MPC 0.7 installed will be
auto-posted as soon as available (and will be marked with mpc-0.7_1)
but I have already studied the gcc.log portion and seen 24 new PASSes.

Regards,
Loren

the cause of PR41260 is new additional epilog unwind information

[Jack Howarth]

Richard,
   We have an analysis on the cause of the breakage of
exception handling at r147995 on x86_64-apple-darwin10 (PR41260)...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025908.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025909.html

The additional epilog unwind information is breaking the
'running' of the dwarf unwind info. The options to fix it are either
to 1) not add epilog unwind information for Darwin or 2) have the
gcc driver implicitly add -no_compact_unwind to the link line for
Darwin.
   Can you propose a patch to achieve the first solution of not
adding the additional epilog unwind information on darwin so I
can test that solution? Thanks in advance.
   Jack

RE: the cause of PR41260 is new additional epilog unwind information

[Jack Howarth]

   FYI, to clarify for others who haven't been following
PR41260, the messages...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

explain the changes in libgcc handling as of darwin10. If I
understand those correctly, the symbols exported through any
libgcc_s.10.5 are now provided from libSystem. This means
that we aren't really using the FSF libgcc unwinder code but
that from unwinder in libSystem. In Darwin10, this behavior
occurs no matter the order -lSystem and -lgcc on the link
line. Only additional symbols not contained in libgcc_s.10.5
will be used from libgcc_s.
   Jack

RE: the cause of PR41260 is new additional epilog unwind information

[Jack Howarth]

   I can confirm that the second proposed solution of passing 
-Wl,-no_compact_unwind
to the linkage of the g++.dg/torture/stackalign/eh-vararg-2.C test cases 
eliminates
the execution error on x86_64-apple-darwin10 so that option works. This leads 
to a
dejagnu question. I want to do a quick and dirty test to see that 
-Wl,-no_compact_unwind
suppresses all of the regressions that appeared at r147995, however I can't 
puzzle out
how to formulate...

make -k check RUNTESTFLAGS="--target_board=unix'{-Wl,-no_compact_unwind}'"

such that -Wl,-no_compact_unwind is interpreted as a single run with
one flag being passed (ie not one run with -Wl and one run with
-no_compact_unwind). Any ideas?
  Jack

Re: Is Non-Blocking cache supported in GCC?

[Amker.Cheng]

On Sat, Sep 19, 2009 at 1:17 AM, Janis Johnson  wrote:
> On Thu, 2009-09-17 at 21:48 -0700, Ian Lance Taylor wrote:
>
> There's also a prefetch built-in function; see
>
> http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
>
> It's been in GCC since 3.1.
>
> Janis
>
>
Thank you all, It seems prefetch is more useful than non-blocking, no wonder gcc
takes advantage of prefetch, rather than non-blocking.

-- 
Best Regards.