regression for ada on mips-sgi-irix6.5

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

for gcc-4.0.2-20050917 all acats tests failed.

for gcc-4.0.1 it was 546 unexpected failures, 1774 expected passes.

for gcc-4.1-20050917 I got a build failure while building gnattools:

../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings
- -Wstrict-prototypes -Wmissing-prototypes -fno-common  -gnatpg -gnata
- -I- -I../rts -I.
- -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada/make.adb
- -o make.o

raised STORAGE_ERROR : SIGSEGV: (stack overflow or erroneous memory access)

for all three I used binutils 2.16.1 and gcc-4.0.1 for building.
Building with gnu as and gnu ld.

Last I tried to build with native ld, which failed in bootstrapping stage 2:

stage1/xgcc -Bstage1/
- -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/
  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
- -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
- -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common
- -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengtype \
 build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \
 build/errors.o ../build-mips-sgi-irix6.5/libiberty/libiberty.a
build/gengtype
gmake[2]: *** [s-gtype] Segmentation fault (core dumped)


Has anybody some suggestions?

Rainer

- --
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOldZ3s6elE6CYeURAiKqAKCmZjdx7EdmKA+IMChvjyIoEpW2fwCgoc1b
n4N1j+tz2I/lQ2rdZynugbk=
=U2ty
-END PGP SIGNATURE-

Re: regression for ada on mips-sgi-irix6.5

[Rainer Orth]

Rainer Emrich <[EMAIL PROTECTED]> writes:

> for gcc-4.0.2-20050917 all acats tests failed.
> 
> for gcc-4.0.1 it was 546 unexpected failures, 1774 expected passes.

for some reason, the acats tests didn't complete for me in gcc 4.0.2
20050817: I haven't yet investigated why, but the 1327 tests that did
complete, all PASSed, so this looks extremely bad.  If you are using GNU ld
here, too, I recall that I had massive problems with acats failures the
last time I tried this combination (GNU as with GNU ld).  I'd recommend
sticking with the native ld on this platform.

> for gcc-4.1-20050917 I got a build failure while building gnattools:
> 
> ../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings
> - -Wstrict-prototypes -Wmissing-prototypes -fno-common  -gnatpg -gnata
> - -I- -I../rts -I.
> - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada
> /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada/make.adb
> - -o make.o
> 
> raised STORAGE_ERROR : SIGSEGV: (stack overflow or erroneous memory access)
> 
> for all three I used binutils 2.16.1 and gcc-4.0.1 for building.
> Building with gnu as and gnu ld.

Same for me as of 20050921, but using the native ld on IRIX 6.5.10m.  The
same error happens on sparc-sun-solaris2.8, while i386-pc-solaris2.10 is ok.

> Last I tried to build with native ld, which failed in bootstrapping stage 2:
> 
> stage1/xgcc -Bstage1/
> - -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/
>   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> - -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
> - -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common
> - -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengtype \
>  build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \
>  build/errors.o ../build-mips-sgi-irix6.5/libiberty/libiberty.a
> build/gengtype
> gmake[2]: *** [s-gtype] Segmentation fault (core dumped)
> 
> 
> Has anybody some suggestions?

Which bootstrap compiler do you use, and which version of ld is this?

Rainer

Re: regression for ada on mips-sgi-irix6.5

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I used gcc-4.0.1 for bootstrapping:

Compiler version: 4.0.1
Platform: mips-sgi-irix6.5
configure flags:
- --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
- --with-gnu-as
- --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
- --with-gnu-ld
- --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld
- --disable-shared --enable-threads=single --enable-haifa --disable-nls
- --disable-libmudflap --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5
- --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5
- --enable-languages=c,ada,c++,objc

binutils:
binutils-2.16.1


Build system:
IRIX64 octane-3 6.5.22m 10070055 IP30 mips unknown Irix

cc for building:
gcc
gcc (GCC) 4.0.1
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

as for building:
GNU assembler 2.16.1
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of \`mips-sgi-irix6.5'.

ld for building:
GNU ld version 2.16.1
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.


Native ld is version 7.2.1. If I remember right, I wasn't able to build
any version of the 4.x series. Always the same failure as described
below. Segfault in build/gengtype.

I hope this helps.

Rainer



Rainer Orth schrieb:
> Rainer Emrich <[EMAIL PROTECTED]> writes:
> 
> 
>>for gcc-4.0.2-20050917 all acats tests failed.
>>
>>for gcc-4.0.1 it was 546 unexpected failures, 1774 expected passes.
> 
> 
> for some reason, the acats tests didn't complete for me in gcc 4.0.2
> 20050817: I haven't yet investigated why, but the 1327 tests that did
> complete, all PASSed, so this looks extremely bad.  If you are using GNU ld
> here, too, I recall that I had massive problems with acats failures the
> last time I tried this combination (GNU as with GNU ld).  I'd recommend
> sticking with the native ld on this platform.
> 
> 
>>for gcc-4.1-20050917 I got a build failure while building gnattools:
>>
>>../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings
>>- -Wstrict-prototypes -Wmissing-prototypes -fno-common  -gnatpg -gnata
>>- -I- -I../rts -I.
>>- -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada
>>/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1-20050917/gcc/ada/make.adb
>>- -o make.o
>>
>>raised STORAGE_ERROR : SIGSEGV: (stack overflow or erroneous memory access)
>>
>>for all three I used binutils 2.16.1 and gcc-4.0.1 for building.
>>Building with gnu as and gnu ld.
> 
> 
> Same for me as of 20050921, but using the native ld on IRIX 6.5.10m.  The
> same error happens on sparc-sun-solaris2.8, while i386-pc-solaris2.10 is ok.
> 
> 
>>Last I tried to build with native ld, which failed in bootstrapping stage 2:
>>
>>stage1/xgcc -Bstage1/
>>- -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/
>>  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
>>- -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
>>- -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common
>>- -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengtype \
>> build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \
>> build/errors.o ../build-mips-sgi-irix6.5/libiberty/libiberty.a
>>build/gengtype
>>gmake[2]: *** [s-gtype] Segmentation fault (core dumped)
>>
>>
>>Has anybody some suggestions?
> 
> 
> Which bootstrap compiler do you use, and which version of ld is this?
> 
>   Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDOnsU3s6elE6CYeURAqyQAJ4o8n7OWjkCnKGwGlRcz4DT930RMwCgiSQl
GzZ7a1BrzlwGudXwo4A1V9Q=
=EgIa
-END PGP SIGNATURE-

Re: regression for ada on mips-sgi-irix6.5

[Rainer Orth]

Rainer Emrich writes:

> Native ld is version 7.2.1. If I remember right, I wasn't able to build
> any version of the 4.x series. Always the same failure as described
> below. Segfault in build/gengtype.

I'm using ld 7.3 (or 7.4.3m) without problems.  I suppose you should
upgrade to 7.3 at least and try again.  I vaguely recall that there were
considerable problems (both native as and ld) with 7.2.1 in IRIX 6.2.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Error detected at make.adb:7224:23

[Christian Joensson]

Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:

(auroralinux corona + rathann's and rzm's FC3 updates)

binutils-2.16.91.0.2-4.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.3-22.sparc.sparc
gcc4-4.0.0-0.41.sparc.sparc
glibc-2.3.5-0.fc3.1.sparcv9
glibc-2.3.5-0.fc3.1.sparc64
glibc-devel-2.3.5-0.fc3.1.sparc64
glibc-devel-2.3.5-0.fc3.1.sparc
glibc-headers-2.3.5-0.fc3.1.sparc
glibc-kernheaders-2.6-20sparc.sparc
gmp-4.1.4-3sparc.sparc
gmp-4.1.4-3sparc.sparc64
gmp-devel-4.1.4-3sparc.sparc
gmp-devel-4.1.4-3sparc.sparc64
kernel-2.6.13-1.1552sp1.sparc64
package kernel-devel is not installed
package kernel-smp is not installed
libgcc-3.4.3-22.sparc.sparc
libgcc-3.4.3-22.sparc.sparc64
libstdc++-3.4.3-22.sparc.sparc
libstdc++-3.4.3-22.sparc.sparc64
libstdc++-devel-3.4.3-22.sparc.sparc64
libstdc++-devel-3.4.3-22.sparc.sparc
make-3.80-5.sparc
nptl-devel-2.3.5-0.fc3.1.sparcv9
tcl-8.4.7-2.sparc

LAST_UPDATED: Wed Sep 28 07:54:00 UTC 2005

configure:   --build=sparc64-unknown-linux-gnu
--host=sparc64-unknown-linux-gnu --target=sparc64-unknown-linux-gnu
--enable-__cxa_atexit --enable-shared --with-cpu=v7
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang


../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -fno-common  -gnatpg
-gnata -I- -I../rts -I. -I/usr/local/src/trunk/gcc/gcc/ada
/usr/local/src/trunk/gcc/gcc/ada/make.adb -o make.o
+===GNAT BUG DETECTED==+
| 4.1.0 20050928 (experimental) (sparc64-unknown-linux-gnu) GCC error: |
| in build_int_cst_wide, at tree.c:795 |
| Error detected at make.adb:7224:23   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+


Anyone else see similar?

This might be related to bubblestrap so if I get no comments, I'll
restart with a clean bootstrap...

--
Cheers,

/ChJ

Re: New port contribution - picoChip

[Daniel Towner]

Hi all,

Here are some responses to the particular questions that were raised.

I officially volunteer to maintain the picoChip port.

While the port doesn't currently use DejaGNU, I will fix this. 
Consequently, I will be able to feed the results back to the test 
results mailing list. I've bought a new machine which I will use to run 
the verification on a daily basis.


I will make sure that background documentation (including the ISA spec.) 
is made available on picoChip's website, and referenced in `Readings'.


300+ picoChip processors are embedded on a single chip. Compilation is 
handled on a per-processor basis, but assembly is handled on a per-chip 
basis (e.g., to enable the communications channels between processors to 
be configured and verified properly). For pragmatic reasons, we decided 
to develop a largely proprietary tool chain to support this rather 
unusual system, but this doesn't rule out FOSS tools in the future. We 
did have a port of GDB at one point, but limitations in GDB at the time 
(e.g., poor support for multi-threaded systems) meant that we had to 
drop it, and develop our own multi-process debugger.


I will submit my port to the patches mailing list shortly.

regards,

dan.


Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
[EMAIL PROTECTED]
+44 (0) 7786 702589

Possible bug in tree-ssa-loop-ivopts.c:prepare_decl_rtl?

[Richard Sandiford]

I notice that the following testcase:

int x[4];
void f1 (long long n) { while (n-- != 0) x[n] = 1; }
void f2 (long long n) { while (n-- != 0) x[n] = 1; }
void f3 (long long n) { while (n-- != 0) x[n] = 1; }

when compiled with optimisation enabled on i386-linux-gnu, causes us to
go through the main make_decl_rtl path 3 times for x.  I.e. we create
three separate (mem (symbol_ref ...))s for it.

This happens because tree-ssa-loop-ivopts.c:prepare_decl_rtl replaces
the original DECL_RTL with one of its own making:

static tree
prepare_decl_rtl (tree *expr_p, int *ws, void *data)
{
  [...]
  switch (TREE_CODE (*expr_p))
{
case ADDR_EXPR:
  for (expr_p = &TREE_OPERAND (*expr_p, 0);
   handled_component_p (*expr_p);
   expr_p = &TREE_OPERAND (*expr_p, 0))
continue;
  obj = *expr_p;
  if (DECL_P (obj))
x = produce_memory_decl_rtl (obj, regno);
  [...]
  if (x)
{
  VEC_safe_push (tree, heap, decl_rtl_to_reset, obj);
  SET_DECL_RTL (obj, x);
}
}

and the DECL_RTL is then nullified after the pass has finished.

There don't seem to be many comments explaining why we're doing
what we're doing here, so I'm not sure whether this was the intended
behaviour or not.  Do we really want to kick out existing DECL_RTLs,
or is there simply a missing !DECL_RTL_SET_P in the DECL_P condition:

  if (DECL_P (obj))
x = produce_memory_decl_rtl (obj, regno);

?

(FWIW, this shows up for "int" ivs on mips64-elf, which is why I noticed.)

Richard

Re: Error detected at make.adb:7224:23

[Christian Joensson]

On 9/28/05, Christian Joensson <[EMAIL PROTECTED]> wrote:

> This might be related to bubblestrap so if I get no comments, I'll
> restart with a clean bootstrap...

This might also be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24053

--
Cheers,

/ChJ

Re: GCC 4.0.2 Status

[Christian Joensson]

On 9/27/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
> (yay!), I know of no reason not to spin a release.  I'm going to take a
> final pass through the open PRs and look for show-stoppers.  Is anyone
> aware of regressions from previous 4.0.x releases that are wrong-code,
> ice-on-valid, or rejects-valid?  That will be the class of bugs that
> would concern me most.
>
> I plan to create the release later today.  I don't plan to do an RC4,
> unless people think that's absolutely necessary.  However, I would
> encourage people to do a quick run-through from CVS to make sure that
> libstdc++, in particular, is working for them.

Well, for sparc/sparc64 running linux, I get ok results. See
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01275.html

Here are the details:

LAST_UPDATED: Tue Sep 27 17:29:41 UTC 2005

=== acats tests ===

gnatmake --GCC="/usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/" -gnatws -O2
-I/usr/local/src/branch/objdir/gcc/testsuite/ada/acats/support
ce3810b.adb -largs --GCC="/usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/"
/usr/local/src/branch/objdir/gcc/xgcc -c
-B/usr/local/src/branch/objdir/gcc/ -gnatws -O2
-I/usr/local/src/branch/objdir/gcc/testsuite/ada/acats/support
ce3810b.adb
gnatbind -aO./ -I/usr/local/src/branch/objdir/gcc/testsuite/ada/acats/support
-I- -x ce3810b.ali
gnatlink ce3810b.ali --GCC=/usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/
RUN ce3810b

,.,. CE3810B ACATS 2.5 05-09-28 04:08:57
 CE3810B CHECK THAT FIXED_IO PUT CAN OPERATE ON STRINGS.  ALSO CHECK
THAT LAYOUT_ERROR IS RAISED WHEN THE STRING IS
INSUFFICIENTLY LONG.
/usr/local/src/branch/gcc/gcc/testsuite/ada/acats/run_all.sh: line 15:
 6467 Segmentation fault  $*
FAIL:   ce3810b

=== gcc tests ===


Running target unix/-m64

Executing on host: /usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/  "-w" -c  -m64 -o linkage-x.o
/usr/local/src/branch/gcc/gcc/testsuite/gcc.misc-tests/linkage-x.c   
(timeout = 1200)
cc -c  /usr/local/src/branch/gcc/gcc/testsuite/gcc.misc-tests/linkage-y.c
>&/dev/null
Executing on host: /usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/ linkage-y.o linkage-x.o   -lm  
-m64 -o linkage.exe(timeout = 1200)
/usr/bin/ld: warning: sparc architecture of input file `linkage-y.o'
is incompatible with sparc:v9 output
output is:
/usr/bin/ld: warning: sparc architecture of input file `linkage-y.o'
is incompatible with sparc:v9 output

FAIL: gcc.misc-tests/linkage.c link

=== treelang tests ===


Running target unix/-m64

a whole bunch of (to be adressed by phython after 4.0.2 is spun)
Executing on host: /usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/
/usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree
   -S  -m64 -o autofunc.s(timeout = 1200)
/usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0:
error: -mlong-double-64 not allowed with -m64
compiler exited with status 1
output is:
/usr/local/src/branch/gcc/gcc/testsuite/treelang/compile/autofunc.tree:0:
error: -mlong-double-64 not allowed with -m64


and then, the testsuite isn't run for target unix...

=== libjava tests ===


Running target unix/-m64

Executing on host: /usr/local/src/branch/objdir/gcc/xgcc
-B/usr/local/src/branch/objdir/gcc/
/usr/local/src/branch/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.c
 -I. -I.. -I/usr/local/src/branch/gcc/libjava/testsuite/../include
-L../.libs -lgcj  -lm   -m64 -o PR16923(timeout = 1200)
/usr/bin/ld: skipping incompatible ../.libs/libgcj.so when searching for -lgcj
/usr/bin/ld: skipping incompatible ../.libs/libgcj.a when searching for -lgcj
/usr/bin/ld: cannot find -lgcj
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
/usr/bin/ld: skipping incompatible ../.libs/libgcj.so when searching for -lgcj
/usr/bin/ld: skipping incompatible ../.libs/libgcj.a when searching for -lgcj
/usr/bin/ld: cannot find -lgcj
collect2: ld returned 1 exit status

FAIL: PR16923.c compilation

set_ld_library_path_env_vars:
ld_library_path=.:/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/64/libjava/.libs:/usr/local/src/branch/objdir/gcc:/usr/local/src/branch/objdir/gcc/64
Executing on host:
/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=link /usr/local/src/branch/objdir/gcc/gcj
-B/usr/local/src/branch/objdir/gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include --encoding=UTF-8
-B/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libjava/testsuite/../
/usr/local/src/branch/gcc/libjava/testsuite/libjava.l

Re: Possible bug in tree-ssa-loop-ivopts.c:prepare_decl_rtl?

[Zdenek Dvorak]

Hello,

> There don't seem to be many comments explaining why we're doing
> what we're doing here, so I'm not sure whether this was the intended
> behaviour or not.  Do we really want to kick out existing DECL_RTLs,
> or is there simply a missing !DECL_RTL_SET_P in the DECL_P condition:

I think that adding the !DECL_RTL_SET_P should work.  Nevertheless,
prepare_decl_rtl and friends should disappear when killloop-branch is merged
(I have a patch for this in testing, not yet commited to the branch).

Zdenek

Query regarding execute test 960521-1. c in gcc.c-torture

[Saurabh Verma]

hi,
i had a query regarding testcase gcc.c-torture/execute/960521-1.c [Link
below]. The testcase does the following:
  i) mallocs two integer arrays a and b of size n each
 ii) *b=0 and increment b 
{lets call the new b as bnew, and the old b as bold, so 
 that bnew = bold+1,and bold[0]=bnew[-1]=0 }
iii) sets a[0] to a[n-1] to -1
 iv) sets bnew[0] to bnew[BLOCK_SIZE-2] to -1
 => bold [1] to bold [BLOCK_SIZE-1] to -1
  v) results in PASS if bnew [-1] {i.e. bold[0]} is still zero
 FAILs otherwise

Now this test fails for a particular architecture, because on of the
mallocs returned zero (the amount of stack and heap available being 65K
and 20K respectively). This is because the testcase decides the size to
be malloc'ed based on the stack available. Since the heap space
available to me is much smaller than the stack, this calculation ( size
of each array = (STACK_SIZE / (sizeof (*a) + sizeof (*b results in
an impossibly large malloc request, and the array value setting
overwrites the text. 

Before making any changes to the testcase to adapt it to our
requirements, i wanted to be sure about the reason for the test, i.e.
what exactly is the testcase supposed to check for? This is a very old
testcase and a look at viewcvs shows it as an initial import from egcs
testsuite base. 

thanks in advance for any help 

regards
saurabh

Link:
 
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/960521-1.c?rev=1.2&content-type=text/plain

RFC: Adding test cases from the OpenMP standard spec

[Diego Novillo]

Appendix A of the OpenMP standard includes quite a few number of example 
OpenMP programs.  They are small and execute fast enough to be a good 
addition to GCC's testsuite, but I don't know whether it would be 
kosher for us to add them to GCC.

Any opinions?  Should I ask the FSF directly?  I guess I should start 
with the OpenMP folks.


Thanks.

Re: GCC 4.0.2 Status

[Christian Joensson]

On 9/28/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 9/27/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> > Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
> > (yay!), I know of no reason not to spin a release.  I'm going to take a
> > final pass through the open PRs and look for show-stoppers.  Is anyone
> > aware of regressions from previous 4.0.x releases that are wrong-code,
> > ice-on-valid, or rejects-valid?  That will be the class of bugs that
> > would concern me most.
> >
> > I plan to create the release later today.  I don't plan to do an RC4,
> > unless people think that's absolutely necessary.  However, I would
> > encourage people to do a quick run-through from CVS to make sure that
> > libstdc++, in particular, is working for them.
>
> Well, for sparc/sparc64 running linux, I get ok results. See
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01275.html
>
> Here are the details:
>
> LAST_UPDATED: Tue Sep 27 17:29:41 UTC 2005
>


> === libjava tests ===
>
>
> Running target unix/-m64
>
> Executing on host: /usr/local/src/branch/objdir/gcc/xgcc
> -B/usr/local/src/branch/objdir/gcc/
> /usr/local/src/branch/gcc/libjava/testsuite/libjava.jni/invocation/PR16923.c
>  -I. -I.. -I/usr/local/src/branch/gcc/libjava/testsuite/../include
> -L../.libs -lgcj  -lm   -m64 -o PR16923(timeout = 1200)
> /usr/bin/ld: skipping incompatible ../.libs/libgcj.so when searching for -lgcj
> /usr/bin/ld: skipping incompatible ../.libs/libgcj.a when searching for -lgcj
> /usr/bin/ld: cannot find -lgcj
> collect2: ld returned 1 exit status
> compiler exited with status 1
> output is:
> /usr/bin/ld: skipping incompatible ../.libs/libgcj.so when searching for -lgcj
> /usr/bin/ld: skipping incompatible ../.libs/libgcj.a when searching for -lgcj
> /usr/bin/ld: cannot find -lgcj
> collect2: ld returned 1 exit status
>
> FAIL: PR16923.c compilation

This one is addressed here:

http://gcc.gnu.org/ml/java-patches/2005-q3/msg00351.html


--
Cheers,

/ChJ

Re: Query regarding execute test 960521-1. c in gcc.c-torture

[Ian Lance Taylor]

Saurabh Verma <[EMAIL PROTECTED]> writes:

>   i had a query regarding testcase gcc.c-torture/execute/960521-1.c [Link
> below]. The testcase does the following:
> i) mallocs two integer arrays a and b of size n each
>ii) *b=0 and increment b 
>   {lets call the new b as bnew, and the old b as bold, so 
>that bnew = bold+1,and bold[0]=bnew[-1]=0 }
>   iii) sets a[0] to a[n-1] to -1
>iv) sets bnew[0] to bnew[BLOCK_SIZE-2] to -1
>=> bold [1] to bold [BLOCK_SIZE-1] to -1
> v) results in PASS if bnew [-1] {i.e. bold[0]} is still zero
>FAILs otherwise
> 
>   Now this test fails for a particular architecture, because on of the
> mallocs returned zero (the amount of stack and heap available being 65K
> and 20K respectively). This is because the testcase decides the size to
> be malloc'ed based on the stack available. Since the heap space
> available to me is much smaller than the stack, this calculation ( size
> of each array = (STACK_SIZE / (sizeof (*a) + sizeof (*b results in
> an impossibly large malloc request, and the array value setting
> overwrites the text. 
> 
>   Before making any changes to the testcase to adapt it to our
> requirements, i wanted to be sure about the reason for the test, i.e.
> what exactly is the testcase supposed to check for? This is a very old
> testcase and a look at viewcvs shows it as an initial import from egcs
> testsuite base. 

I would assume that the test is for some sort of loop optimization.
But the case of heapsize << stacksize is rather unusual, so I think
the simplest thing would be for you to just xfail the test on your
target by creating a 960521-1.x file.

I wouldn't worry about whether your target has some bug that will fail
the test--the test was almost certainly designed to test target
independent code.

Ian

[gnu.org #252800]

[Tony Wieczorek via RT]

I'm sorry, but as this is only a general contact address, I cannot
properly answer technical questions such as yours.  The best I can do is
refer you to the GCC Manual (http://gcc.gnu.org/onlinedocs/) and
Frequently Asked Questions (http://gcc.gnu.org/faq.html).  If neither of
those provide an answer to your question, please contact the GCC users'
help list; you can learn more about it at .

I am sorry that I couldn't be of more help.
-- 
Tony Wieczorek
Program Assistant
(617) 542-5942

Free Software Foundation
51 Franklin St. Fifth Floor
Boston, MA 02110 USA

Re: GCC 4.0.2 Status (Ada)

[Laurent GUERBY]

Zero ACATS fail on three platforms:

x86-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01292.html
x86_64-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01293.html
s390-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01257.html

Other platforms with one or few ACATS failures:

ia64-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01266.html
x390x-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01254.html
sparc-solaris2.8
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01077.html
sparc64-linux
 http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html

I haven't seen powerpc-darwin or powerpc-linux Ada results yet.

Many thanks to people enabling Ada in their builds!

Laurent

Re: Running ranlib after installation - okay or not?

[Peter O'Gorman]

Gerald Pfeifer wrote:

On Sun, 4 Sep 2005, Peter O'Gorman wrote:


| We currently perform the following sequence of commands as part of the
| installation (-m 444 being the default on current FreeBSD systems).
I can not see where freebsd could be getting a -m 444 from. The libraries
are always installed with INSTALL_DATA and gcc's aclocal.m4 always sets that
to INSTALL_DATA='${INSTALL} -m 644' if it is otherwise unset.

Do have an INSTALL_DATA var set in your environment?



The FreeBSD ports system (/usr/share/mk/bsd.port.mk) indeed sets

  INSTALL_DATA= \
${INSTALL} ${COPY} ${_SHROWNGRP} -m ${SHAREMODE}

and SHAREMODE is set to 444 (in /usr/share/mk/bsd.own.mk).

Which does make sense, in general, but breaks ranlib without your fix.


I posted a patch that nobody has had time to look at for this, even if it is 
not acceptable (it would probably be better if it reset the permissions 
after calling ranlib) I'd appreciate some feedback :)




Peter

GCC 4.0 branch open

[Mark Mitchell]

GCC 4.0.2 has been released; the GCC 4.0 branch is open under the normal
branch rules: fixes for regressions only.

Here are the wwwdocs patches I checked in when creating the new release.

Although I still consider the 4.0 branch open, I am not going to focus
on creating a 4.0.3 release until the 4.1 branch has been created.  I
think the 4.0 branch is relatively stable at this point; our challenge
is to get the bugs out -- and the performance into -- 4.1 so that we can
start making 4.1.x releases.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Index: bugzilla/contrib/bug_email.pl
===
RCS file: /cvs/gcc/wwwdocs/bugzilla/contrib/bug_email.pl,v
retrieving revision 1.28
diff -c -5 -p -r1.28 bug_email.pl
*** bugzilla/contrib/bug_email.pl   12 Aug 2005 14:25:16 -  1.28
--- bugzilla/contrib/bug_email.pl   29 Sep 2005 01:43:38 -
*** sub writeBugIntoDB
*** 306,315 
--- 306,318 
$version = "unknown";
  }
  elsif ($release =~ /.*4\.1\.0.*/o) {
$version = "4.1.0";
  }
+ elsif ($release =~ /.*4\.0\.3.*/o) {
+   $version = "4.0.3";
+ }
  elsif ($release =~ /.*4\.0\.2.*/o) {
$version = "4.0.2";
  }
  elsif ($release =~ /.*4\.0\.1.*/o) {
$version = "4.0.1";
Index: htdocs/develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.62
diff -c -5 -p -r1.62 develop.html
*** htdocs/develop.html 7 Jul 2005 18:21:26 -   1.62
--- htdocs/develop.html 29 Sep 2005 01:43:38 -
*** stages of development, branch points, an
*** 344,354 
 |\
 | v
GCC 4.1 Stage 2 (ends July 8 2005)   GCC 4.0.1 release (July 7 2005) 
 |  \
 v   v
!   GCC 4.1 Stage 3  GCC 4.0.2 release 
 |
 :
 v
  
  
--- 344,354 
 |\
 | v
GCC 4.1 Stage 2 (ends July 8 2005)   GCC 4.0.1 release (July 7 2005) 
 |  \
 v   v
!   GCC 4.1 Stage 3  GCC 4.0.2 release (September 28 
2005)
 |
 :
 v
  
  
Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.518
diff -c -5 -p -r1.518 index.html
*** htdocs/index.html   27 Sep 2005 19:01:43 -  1.518
--- htdocs/index.html   29 Sep 2005 01:43:38 -
*** steering committee, guided by the .
  
  
  
  Current release series:
!   GCC 4.0.1 (released 2005-07-07)
  
!   Branch status http://gcc.gnu.org/ml/gcc/2005-09/msg00835.html";>2005-09-17
!   (frozen for 4.0.2 release).
  
  
  Previous release series:
GCC 3.4.4 (released 2005-05-18)
  
--- 29,41 
  mission statement.
  
  
  
  Current release series:
!   GCC 4.0.2 (released 2005-09-28)
  
!   Branch status: open for regression and documentation fixes only.
  
  
  Previous release series:
GCC 3.4.4 (released 2005-05-18)
  
*** mission statement.
*** 84,93 
--- 82,96 
  
  News/Announcements
  
  
  
+ September 28, 2005
+ 
+ GCC 4.0.2 has been released.
+ 
+ 
  August 22, 2005
  
  Red Hat Inc has contributed a port for the MorphoSys family.
  
  
Index: htdocs/gcc-4.0/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v
retrieving revision 1.48
diff -c -5 -p -r1.48 changes.html
*** htdocs/gcc-4.0/changes.html 7 Jul 2005 17:31:15 -   1.48
--- htdocs/gcc-4.0/changes.html 29 Sep 2005 01:43:38 -
***
*** 10,20 
  
  
  GCC 4.0 Release SeriesChanges, New Features, and Fixes
  
  The latest release in the 4.0 release series is
! GCC 4.0.1.
  
  Caveats
  

  GCC now generates location lists by default when compiling with debug
--- 10,20 
  
  
  GCC 4.0 Release SeriesChanges, New Features, and Fixes
  
  The latest release in the 4.0 release series is
! GCC 4.0.2.
  
  Caveats
  

  GCC now generates location lists by default when compiling with debug
*** href="http://gcc.gnu.org/bugzilla/buglis
*** 599,605 
--- 599,614 
  of problem reports (PRs) from GCC's bug tracking system that are
  known to be fixed in the 4.0.1 release. This list might not be
  complete (that is, it is possible that some PRs that have been fixed
  are not listed here).
  
+ GCC 4.0.2
+ 
+ This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.0.2";>list
+ of problem rep

GCC 4.0.2 Released

[Mark Mitchell]

GCC 4.0.2 has been released.

This release is a minor release, containing primarily fixes for
regressions in GCC 4.0.1 releative to previous releases.

http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2

This release is available from the FTP servers listed here:

http://www.gnu.org/order/ftp.html

The release is in the gcc/gcc-4.0.2 subdirectory.

As usual, a vast number of people contributed to this release -- far too
many to thank by name!

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304