John David Anglin <[EMAIL PROTECTED]> wrote:
> I find the documentation on checking out branches, particularly
> for branch releases, confusing. It doesn't say you need to use "tags"
> instead of "branches" for releases.
Which documentation, exactly?
Giovanni Bajo
Jan Beulich wrote:
I don't think this is the case. The questionable code (from the test
case) really is
struct Unpacked { int i; };
struct __attribute__ ((packed)) Packed
{
char c;
int i;
Unpacked u;
};
and the test expects that you cannot bind Packed::u to Unpacked& (error
expected), b
Can someone of the Ada folks provide some info how I can get a debugging
session with a failing acats test? Looking at the testsuite log file
I f.i. see c32001e failing and an (appearant) build line(s)
BUILD c32001e.adb
gnatmake --GCC="/space/rguenther/obj/obj3/gcc/xgcc
-B/space/rguenther/obj/o
> I see there's magic going on in the testsuite/ada/acats/run_acats and
> run_all.sh scripts, but they cannot be invoked directly to set up the
> environment.
The magic is only there to support testing in the build tree,
with the compiler not installed.
Assuming you've done a make install, then c
On Tue, 13 Dec 2005, Arnaud Charlet wrote:
> > I see there's magic going on in the testsuite/ada/acats/run_acats and
> > run_all.sh scripts, but they cannot be invoked directly to set up the
> > environment.
>
> The magic is only there to support testing in the build tree,
> with the compiler not
Hi,
current mainline configured with the following command
$SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/afs/mpa/data/martin/mygmp
aborts during bootstrap at this place:
/scratch/ogcc/./gcc/xgcc -B/scratch/ogcc/./gcc/
-B/afs/mpa/data/martin/ugcc/i686-p
> This is exactly what I'm trying to do, as I'm testing with the
> stage1 compiler that happens to miscompile the stage2 compiler,
> so I guessed it might be easier to debug the testsuite fallout
> of the stage1 compiler.
>
> I'm used to do ./xgcc -B/whatever in the gcc/ directory, maybe
> gnatmak
On Tue, 13 Dec 2005, Arnaud Charlet wrote:
> > This is exactly what I'm trying to do, as I'm testing with the
> > stage1 compiler that happens to miscompile the stage2 compiler,
> > so I guessed it might be easier to debug the testsuite fallout
> > of the stage1 compiler.
> >
> > I'm used to do .
> /space/rguenther/obj/obj3/gcc/xgcc -c -B/space/rguenther/obj/obj3/gcc/
> -gnatws -O2 -I/space/rguenther/obj/obj3/gcc/testsuite/ada/acats/support
> /space/rguenther/obj/obj3/gcc/testsuite/ada/acats/tests/c3/c32001e/c32001e.adb
>
> -I/space/rguenther/obj/obj3/gcc/ada/rts
>
> ? This way it wou
Can someone of the Ada folks provide some info how I can get a debugging
session with a failing acats test? Looking at the testsuite log file
I f.i. see c32001e failing and an (appearant) build line(s)
BUILD c32001e.adb
but neither of them is invokable from no existing direct
The magic is only there to support testing in the build tree,
with the compiler not installed.
Assuming you've done a make install, then compiling an ACATS
test is as simple as:
Yeah, but the problem is that most of us don't want to do a "make install"
of a compiler that we know d
Richard Guenther wrote:
> On Tue, 13 Dec 2005, Arnaud Charlet wrote:
> > Except that unlike C, Ada needs a run-time, even for simple things,
> > so you need in addition to point (using e.g. -I) to the runtime,
> > which is built under obj/gcc/ada/rts,
> >
> > so from obj/gcc directory, you can do
> John David Anglin <[EMAIL PROTECTED]> wrote:
>
> > I find the documentation on checking out branches, particularly
> > for branch releases, confusing. It doesn't say you need to use "tags"
> > instead of "branches" for releases.
>
> Which documentation, exactly?
http://gcc.gnu.org/svn.html
I
Ada seems to set TYPE_SIZE of an ARRAY_TYPE to integer_zero_node,
which does not follow (tree.def):
/* Each node that represents a data type has a component TYPE_SIZE
containing a tree that is an expression for the size in bits.
also it makes querying the element size difficult if you have an
Hi,
I was thinking about collecting the patches to be tested dirrectly in
the gcc-patches mailing list, like the patch queue tracks new patches.
This could also be convenient for having some control by peer review
on the patches proposed for testing.
If the machines that run the bootstrap and tes
Note that 4157 is out of order. I *think* what's happening is that
the MERGE_TO_OTHER macro isn't taking into account that if you merge
RELOAD_OTHER and RELOAD_FOR_OTHER_ADDRESS, you can't end up with a
RELOAD_OTHER.
No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER.
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> Is anyone seeing this? With current 4.1 sources, on a machine
Gerald> with "only" 1GB of main memory + 1GB swap, the following part
Gerald> of `make install`
[...]
Gerald> spawns a recursive make (GNU make 3.80) that consumes so
On Tue, 2005-12-13 at 11:41 -0700, Tom Tromey wrote:
> First, yeah, this is known. And, kudos to HJ for trying to fix this
> in 'make'.
If nothing else, HJ's hack is keeping things from being too insane
while y'all sort out the best fix.
> I've been considering working around this problem by ju
> No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER.
Why?
Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
merged with RELOAD_OTHER reloads?
Tom Tromey wrote:
"Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> Is anyone seeing this? With current 4.1 sources, on a machine
Gerald> with "only" 1GB of main memory + 1GB swap, the following part
Gerald> of `make install`
[...]
Gerald> spawns a recursive make (GNU make 3.80)
DJ Delorie wrote:
No, anything merged with RELOAD_OTHER has to be RELOAD_OTHER.
Why?
RELOAD_FOR_OTHER_ADDRESS only lives till the RELOAD_OTHER input reloads.
Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
merged with RELOAD_OTHER reloads?
Yes. But if they load
I see this here too. Apparently this was caused by the i386.h PUSH_ROUNDING
change of this patch:
2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]>
PR debug/25023
PR target/25293
* expr.c (emit_move_resolve_push): Handle PRE_MODIFY
and POST_MODIFY with CONST_INT adjustm
I see the same failure on x86-linux both 4.1 and trunk as of revision
108478 (was working on trunk as of 108381). x86_64-linux is fine on both
branches at the same revision.
Probably:
2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]>
PR debug/25023
PR target/25293
* expr.c (
On Tue, Dec 13, 2005 at 07:44:39PM +0100, Laurent GUERBY wrote:
> 2005-12-13 Jakub Jelinek <[EMAIL PROTECTED]>
>
> PR debug/25023
> PR target/25293
> * expr.c (emit_move_resolve_push): Handle PRE_MODIFY
> and POST_MODIFY with CONST_INT adjustment equal to PUSH_ROU
I'll leaving home for the datacenter, the machines will reboot within
the next two hours.
I'll setup the account for people who requested them by email tonight.
Laurent
Tom Tromey writes:
> > "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
>
> Gerald> Is anyone seeing this? With current 4.1 sources, on a machine
> Gerald> with "only" 1GB of main memory + 1GB swap, the following part
> Gerald> of `make install`
> [...]
> Gerald> spawns a recursi
I can't reproduce it (otherwise I wouldn't have committed it), it
bootstrapped/regtested just fine for me.
Can one of those who can reproduce it give me preprocessed mf-runtime.i
and exact gcc options that triggered it?
I have attached the stripped down testcase.
The bug is triggered with:
> >Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
> >merged with RELOAD_OTHER reloads?
> >
> Yes. But if they load the same value as a RELOAD_OTHER input, they can
> share the same reload register.
So why does reload specifically check for RELOAD_FOR_OTHER_ADDRESS
when deci
DJ Delorie wrote:
Does this mean that RELOAD_FOR_OTHER_ADDRESS reloads can never be
merged with RELOAD_OTHER reloads?
Yes. But if they load the same value as a RELOAD_OTHER input, they can
share the same reload register.
So why does reload specifically check for RELOAD_FOR_OTHER
On Tue, Dec 13, 2005 at 08:49:56PM +, Joern RENNECKE wrote:
> >I can't reproduce it (otherwise I wouldn't have committed it), it
> >bootstrapped/regtested just fine for me.
>
> >Can one of those who can reproduce it give me preprocessed mf-runtime.i
> >and exact gcc options that triggered it?
Jakub Jelinek wrote:
While we could use pushhi2 insn
(would need to use pre_modify rather than pre_dec etc.), it wouldn't
buy us anything.
Presumably, it would prevent a partial register stall.
> That test checks that the value can actually live in the reload
> register not only during, but also in-between (if there is such a
> time) the two reloads. If there is a reload type available that is
> suitable for the merged reload is another matter. I see now that
> this code is in merge_as
On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote:
> >While we could use pushhi2 insn
> >(would need to use pre_modify rather than pre_dec etc.), it wouldn't
> >buy us anything.
> >
> Presumably, it would prevent a partial register stall.
Only if we use the real pushw instruction. Bu
On Tue, Dec 13, 2005 at 09:25:45PM +, Joern RENNECKE wrote:
> >While we could use pushhi2 insn
> >(would need to use pre_modify rather than pre_dec etc.), it wouldn't
> >buy us anything.
> >
> Presumably, it would prevent a partial register stall.
Alternatively we could
subl $4, %esp
movw %ax,
Snapshot gcc-3.4-20051213 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051213/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Ada seems to set TYPE_SIZE of an ARRAY_TYPE to integer_zero_node,
Not integer_zero_node, but to bitsize_zero_node, for any type that has
a size of zero, which is the case here
domain
min
max
since the size in elements of the ARRAY_TYPE is zero.
Not
I don't think the mailing list archive search functionality is
working. It's not showing any results after May 2005. Go to:
http://gcc.gnu.org/ml/gcc/
Type the name of any frequent contributor, oh say "rth" and sort by
"newest". I don't get anything after May 2005.
I tried several other lists
On 2005-12-14, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> I don't think the mailing list archive search functionality is
> working. It's not showing any results after May 2005. Go to:
>
> http://gcc.gnu.org/ml/gcc/
It was noted about a week ago (but ironically you couldn't search
for this threa
> Summary of the thread: it's known about and may never be fixed, but
> alternative searchable archives exist (gmane, nabble, probably
> others like marc and mail-archive too).
Could we put in a google search box on the archive pages at least, to
stop confusing people?
http://www.google.com/sear
> "Sebastian" == Sebastian Pop <[EMAIL PROTECTED]> writes:
Sebastian> I was thinking about collecting the patches to be tested
Sebastian> dirrectly in the gcc-patches mailing list, like the patch
Sebastian> queue tracks new patches.
This is a nice idea. I wonder, though, whether most of the
On Tue, 13 Dec 2005, DJ Delorie wrote:
> > Summary of the thread: it's known about and may never be fixed, but
> > alternative searchable archives exist (gmane, nabble, probably
> > others like marc and mail-archive too).
>
> Could we put in a google search box on the archive pages at least, to
> s
I've been considering working around this problem by just redoing the
whole .java->.class step whenever any .java file changes. That would
probably be slower for libgcj developers but at least wouldn't hugely
hurt folks working elsewhere. Also, most class library development
happens in Classpath
42 matches
Mail list logo
