headers
Geoff Keating | 1 Jun 2002 01:02

Re: Merge from pch branch; call for testers

> From: Andreas Jaeger <aj <at> suse.de>
> Date: Fri, 31 May 2002 21:49:06 +0200

> Geoff Keating <geoffk <at> geoffk.org> writes:
> 
> > Hi Andreas,
> >
> > I'm pretty sure I've now fixed all the problems you reported, but I
> > couldn't check the combination of ia64 and Ada---I did check ia64
> > without Ada and i386 with Ada.  Could you try the branch again on
> > ia64+Ada?
> 
> I still have problems on i686 with ada:
> 
> ../../xgcc -B../../ -c -g -O2   -g -O2   -W -Wall -gnatpg -I. -I/cvs/gcc-pch-branch/gcc/ada a-nscoty.ads
> a-ngcoty.adb: In function `ada.numerics.short_complex_types."abs"':
> a-ngcoty.adb:395: unrecognizable insn:
> (insn 21 17 24 (set (reg/i:SF 8 st(0))
>         (abs:SF (reg/v/u:SF 59))) -1 (insn_list 4 (nil))
>     (expr_list:REG_UNUSED (reg:CC 17 flags)
>         (expr_list:REG_DEAD (reg/v/u:SF 59)
>             (nil))))
> +===========================GNAT BUG DETECTED==============================+
> | 3.1 (20020212) (i686-pc-linux-gnu) GCC error:                            |
> | Internal compiler error in extract_insn, at recog.c:2133                 |
> | Error detected at a-ngcoty.adb:395:21 [a-nscoty.ads:19:1]                |
> | Please submit bug report by email to gcc-bugs <at> gcc.gnu.org.               |
> | 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.              |
(Continue reading)

Permalink | Reply | 3 comments |
headers
CM | 1 Jun 2002 01:06

RE: What to include in a bugreport related to boostrapping?

Upgrade your binutils

-----Original Message-----
From: gcc-owner <at> gcc.gnu.org [mailto:gcc-owner <at> gcc.gnu.org] On Behalf Of
Alexander Klein
Sent: 31 May 2002 23:33
To: gcc <at> gcc.gnu.org
Subject: What to include in a bugreport related to boostrapping?

Hi,

When trying to build GCC with versions >=3, they will always explode
sooner
or later, depending on the exact version. 3.1, for example, goes through
the boostrapping process, but then dies generating illegal Assembler
instructions while compiling the libraries. Unfortunately, I'm a bit
unsure
what I should include to make a useful bugreport.

Should I just report it in the usual way with the .i-file included?

Best regards,

	Alex
Permalink | Reply | 0 comments |
headers
DJ Delorie | 1 Jun 2002 01:07
Picon
Favicon

output_func_start_profiler vs __bb_init_func


It looks like there is an inconsistency in how the call to
__bb_init_func is created in profile.c.  Note the return mode as if
the function returned a GCOV_TYPE_SIZE int:

output_func_start_profiler ()
{
  enum machine_mode mode = mode_for_size (GCOV_TYPE_SIZE, MODE_INT, 0);
  ...
  emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__bb_init_func"), LCT_NORMAL,
		     mode, 1, table_address, Pmode);
}

But in libgcc2.c:

void
__bb_init_func (struct bb *blocks)

On targets where 64-bit ints are returned by reference (like big
structs), the call to __bb_init_func will be corrupted by the
unexpected extra (zeroth) parameter.

A simple replacement of mode -> VOIDmode seems to work.  Does this
sound right?
Permalink | Reply | 0 comments |
headers
Joe Buck | 1 Jun 2002 01:25

Re: What to include in a bugreport related to boostrapping?


> When trying to build GCC with versions >=3, they will always explode sooner
> or later, depending on the exact version. 3.1, for example, goes through
> the boostrapping process, but then dies generating illegal Assembler
> instructions while compiling the libraries. Unfortunately, I'm a bit unsure
> what I should include to make a useful bugreport.

Before filing a bug report, tell us what platform you are using (OS and
version), any special configure options you're using, and what error
messages you're seeing.
Permalink | Reply | 0 comments |
headers
Zack Weinberg | 1 Jun 2002 02:19

Re: QMTest and the G++ testsuite

On Wed, May 22, 2002 at 11:41:52PM -0700, mike stump wrote:
> > The example that comes to mind is the "nasty file names" test, which
> > generates a series of input files whose names (collectively) cover
> > all the characters that the operating system allows in file names,
> > and makes sure that the compiler can handle them.  You can't check
> > all those files into CVS, the set of acceptable names varies with
> > the operating system.  I tried and failed to do this in DejaGNU.
> > Granted, this test requires writing custom Tcl, and would require
> > writing custom Python in QMTest.
> 
> dejagnu runs tcl to do a test.  tcl is Turing complete.  tcl can
> easily do Turing complete things (not as hard as vi say).  It is
> trivial to do this sort of test in the exiting framework for either
> the C or C++ testsuite, one merely needs to `code' it.

Turing-completeness doesn't mean a hell of a lot.  Yes, tcl is easier
to work with than vi, or INTERCAL.  It is still a language that a lot
of people (including myself) find nearly impossible to write anything
substantial in.

Also, the language isn't what's at stake here.  A test harness is,
fundamentally, a set of library modules for whatever language.  A
discussion of the merits of QMTest vs DejaGNU should be a discussion
of those library modules, how easily they allow people to express
common test cases and common testing scenarios, how comprehensive
their built-in features are, and how easy it is to extend them if the
built-in features don't cover the territory.

You claim that this test is expressible in DejaGNU as it stands.  I
can only say that I tried and failed.  I would be delighted to get a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Dewar | 1 Jun 2002 02:37

Re: QMTest and the G++ testsuite

<<Turing-completeness doesn't mean a hell of a lot.  Yes, tcl is easier
to work with than vi, or INTERCAL.  It is still a language that a lot
of people (including myself) find nearly impossible to write anything
substantial in.
>>

Of course the other thing is to worry about whether the people who
do NOT find it imsposible to write substantial code in tcl produce
results that other people can read :-)
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Jun 2002 03:18
Picon
Favicon

Re: C99 conformance bug in gcc-3.1

On Fri, May 31, 2002 at 09:06:13PM +1000, Fergus Henderson wrote:
> Well, those are differences in legality (and diagnostics),
> not differences in behaviour.  Each different syntax
> may give you a different subset of the available features,
> but in cases where both are legal, the result is the same.

Yes and no.  The two cases are definitely distinguished within
the compiler all the way though.  For instance, sizeof applies
to a zero-length-array, but not to a flexible array member.

r~
Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Jun 2002 03:20
Picon
Favicon

Re: Merge from pch branch; call for testers

On Fri, May 31, 2002 at 04:02:31PM -0700, Geoff Keating wrote:
> This is not a regression, since it happens on the mainline at
> pch-merge-20020517 too.

The offending patch has been reverted on mainline.

r~
Permalink | Reply | 1 comment |
headers
Richard Henderson | 1 Jun 2002 03:26
Picon
Favicon

Re: TARGET_* target hook inconsistency

On Fri, May 31, 2002 at 06:50:08PM -0400, DJ Delorie wrote:
> However, some of the target hooks are protected with #ifndefs, and are
> used in #ifs.  Obviously, those must be defined *before* target-def.h
> is included.

Yep.  In general, the hooks that are cpu related can be properly
redefined in the .c file.  However, the hooks that are OS related
are problematic -- the only way to avoid an unholy ifdef mess in
the .c files is to define the hook in the OS-specific target header.

r~
Permalink | Reply | 0 comments |
headers
Jeff Sturm | 1 Jun 2002 06:20

Re: 3.2 bootstrap failure in libjava on sparcv9-sun-solaris2.8

On Fri, 31 May 2002, David S. Miller wrote:
> Yep, Sparc64 GDB is in a sorry state these days.

Hmm... I get reasonably good results with mine.  But I always configure
--with-dwarf2.  Gave up on stabs long ago...

Jeff
Permalink | Reply | 6 comments |

Gmane