* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-23 4:37 Jim Wilson
1997-08-23 5:17 ` egcs-ss-970821 and test suite Jeffrey A Law
0 siblings, 1 reply; 6+ messages in thread
From: Jim Wilson @ 1997-08-23 4:37 UTC (permalink / raw)
To: egcs
Results for `make bootstrap CFLAGS="-g -O3 -fno-regmove" LANGUAGES=c'.
...the stage2 cc1 hangs while compiling enquire...
I tracked this down to a bug in the new aliasing code.
I don't have access to any m68k workstation, so I am unable to test this
with a bootstrap. I found this by inspection of the m68k code generated
by the stage1 compiler for the real.c function etoasc. The infinite loop
I found there goes away when this patch is applied.
Fri Aug 22 21:31:54 1997 Jim Wilson <wilson@cygnus.com>
* alias.c (true_dependence): Pass x_addr not x to varies.
Index: alias.c
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/alias.c,v
retrieving revision 1.3
diff -p -r1.3 alias.c
*** alias.c 1997/08/22 06:39:29 1.3
--- alias.c 1997/08/23 04:31:19
*************** true_dependence (mem, mem_mode, x, varie
*** 825,831 ****
If either memory reference is a variable structure the other is a
fixed scalar and there is no aliasing. */
if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
! || (MEM_IN_STRUCT_P (x) && varies (x)))
return 0;
return 1;
--- 825,831 ----
If either memory reference is a variable structure the other is a
fixed scalar and there is no aliasing. */
if ((MEM_IN_STRUCT_P (mem) && varies (mem_addr))
! || (MEM_IN_STRUCT_P (x) && varies (x_addr)))
return 0;
return 1;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs-ss-970821 and test suite.
1997-08-23 4:37 egcs-ss-970814 on m68k-next-nextstep3 Jim Wilson
@ 1997-08-23 5:17 ` Jeffrey A Law
0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1997-08-23 5:17 UTC (permalink / raw)
To: egcs
In message <Pine.PMDF.3.91.970822114219.538968753A-100000@MPS.OHIO-STATE.EDU>
you write:
> Hi,
> Bootstrapping of the latest snapshot works fine on linux-2.0.28,
> gcc-2.7.2, libc-5.4.23. There is an error message during each stage of
> the build that I'm not sure is important or not.
>
> gcc -c -DIN_GCC -DUSE_GNULIBC_1 -g -DHAVE_CONFIG_H -I. -I.
> -I./config expr.c
> expr.c: In function `move_by_pieces':
> expr.c:1451: warning: passing arg 1 of `move_by_pieces_1' from
> incompatible pointer t
> ype
> expr.c: In function `clear_by_pieces':
> expr.c:2007: warning: passing arg 1 of `clear_by_pieces_1' from
> incompatible pointer
> type
>
> So, this appears that an ifdef is not set properly in expr.h (though I
> could be wrong, I have zero compiler writing experience).
Not exactly. Regardless, it's just a warning and can be safely
ignored.
> Ran the testsuite with the following results. If this is not a usable
> format or I'm not posting the salient info, let me know what info I can
> include to help the testing process.
This is _exactly_ why we put the testing framework up! :-)
Thanks!
Jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-23 14:31 Toon Moene
0 siblings, 0 replies; 6+ messages in thread
From: Toon Moene @ 1997-08-23 14:31 UTC (permalink / raw)
To: egcs
[ BTW, I'm using egcs-ss-970821 now, which had the same symptoms ]
> - I had to compile config/nextstep.c by hand.
> - Furthermore, convert.c is compiled twice.
Jim correctly diagnosed this as a problem in one of NEXT's make,
sed or other utilities (I haven't looked at which one, because I
normally use a simple alias to switch from standard utilities to GNU
ones all at once).
After the switch, both problems disappeared (this of course means
that these snapshots do not build "out of the box" without manual
intervention on NEXTSTEP, but oh well ...)
Furthermore:
>> ...the stage2 cc1 hangs while compiling enquire...
> I tracked this down to a bug in the new aliasing code.
>
> I don't have access to any m68k workstation, so I am
> unable to test this with a bootstrap. I found this by
> inspection of the m68k code generated by the stage1
> compiler for the real.c function etoasc. The infinite
> loop I found there goes away when this patch is applied.
[ And have us, mere mortals, watch in awe ... ]
Yes, This Works (the bootstrap is not finished yet - takes another
hour - but it passed compiling enquire using the stage2 compiler).
The really irritating thing here, of course, is that I have looked
at this code and haven't noticed this bug; so much for the Quality
Control Department at "Moene Computational Physics" :-(
Craig, this bug is also present in f/gbe/2.7.2.2.diff of
g77-0.5.21-970811.
Cheers,
Toon.
"A truly outstanding programmer can find bugs buried in a 6
megabyte core dump without using a hex calculator."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-22 19:47 Toon Moene
0 siblings, 0 replies; 6+ messages in thread
From: Toon Moene @ 1997-08-22 19:47 UTC (permalink / raw)
To: egcs
Hi Jeff,
Sent to you in a separate message. Sorry that I wasn't able to
debug this myself, but I am not really that good at debugging
recursive programs like gcc.
Cheers,
Toon.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-22 19:23 Jeffrey A Law
0 siblings, 0 replies; 6+ messages in thread
From: Jeffrey A Law @ 1997-08-22 19:23 UTC (permalink / raw)
To: egcs
> The hang at enquire:
>
> Apparently, it happens in routine F_check, because the last routine
> in enquire.s is:
Can you send me the cpp output for enquire on your box so I can
look at things under the debugger?
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* egcs-ss-970814 on m68k-next-nextstep3
@ 1997-08-17 19:06 Toon Moene
0 siblings, 0 replies; 6+ messages in thread
From: Toon Moene @ 1997-08-17 19:06 UTC (permalink / raw)
To: egcs
Results for `make bootstrap CFLAGS="-g -O3 -fno-regmove" LANGUAGES=c'.
A regression with respect to the not-so-public egcs-ss-970813:
- I had to compile config/nextstep.c by hand.
- Furthermore, convert.c is compiled twice.
Both are shortcomings I noted with a recent gcc snapshot too.
The hang at enquire:
Apparently, it happens in routine F_check, because the last routine
in enquire.s is:
.globl _fSelf
_fSelf:
When stopped with Control-C, I get:
Reading in symbols for real.c...done.
etoasc (x=0x6, string=0x3fff4f6 "", ndigs=20) at real.c:1887
1887 bits <<= 1;
(gdb) bt
Reading in symbols for config/m68k/m68k.c...done.
Reading in symbols for final.c...done.
Reading in symbols for toplev.c...done.
Reading in symbols for c-decl.c...done.
Reading in symbols for c-parse.c...done.
#0 etoasc (x=0x6, string=0x3fff4f6 "", ndigs=20) at real.c:1887
#1 0x74c2a in ereal_to_decimal (x=void, s=0x3fff4f6 "") at real.c:1210
#2 0xec338 in print_operand (file=0x3fff4f6, op=0x443214,
letter=67106038) at config/m68k/m68k.c:2734
#3 0xcee26 in output_operand (x=0x443214, code=102) at final.c:2713
#4 0xceb00 in output_asm_insn (template=0x3fff452 "",
operands=0x1356e0) at final.c:2637
#5 0xce3d4 in final_scan_insn (insn=0x443244, file=0x1,
optimize=0, prescan=110, nopeepholes=0) at final.c:2168
#6 0xcd5d8 in final (first=0x1356e0, file=0x1, optimize=110,
prescan=0) at final.c:1322
#7 0x226cc in rest_of_compilation (decl=void) at toplev.c:3592
#8 0xfc46 in finish_function (nested=0) at c-decl.c:7012
#9 0x2d44 in yyparse () at c-parse.y:352
#10 0x1f2c4 in compile_file (name=0x3fffcde "enquire.i") at toplev.c:2470
#11 0x233c2 in main (argc=12, argv=0x124d2c, envp=0x3fffc88) at
toplev.c:4309
but
(gdb) whatis x
type = unsigned short *
the value 0x6 seems a bit odd for a pointer.
HTH,
Toon.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-08-23 14:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-08-23 4:37 egcs-ss-970814 on m68k-next-nextstep3 Jim Wilson
1997-08-23 5:17 ` egcs-ss-970821 and test suite Jeffrey A Law
-- strict thread matches above, loose matches on Subject: below --
1997-08-23 14:31 egcs-ss-970814 on m68k-next-nextstep3 Toon Moene
1997-08-22 19:47 Toon Moene
1997-08-22 19:23 Jeffrey A Law
1997-08-17 19:06 Toon Moene
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).