Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Arnaud Charlet]

> I thought so too, and indeed tried it this way at first, but got:
> "../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
> -I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC
> 
> /bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
> -I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada: No such file or 
> directory
> 
> The quotes around GCC_LINK could be removed here and instead put in the the 
> -GCC=$(GCC_LINK) bits,

Right, that seems easy enough to do, and I do prefer to keep a single
variable, used for all tools.

> but it seemed easier to have a new var.

easier for who ? The person who writes the code or all the people who
have to read, understand and maintain it afterwards ?

Arno

Re: Bootstrap failure on Linux/x86-64

[Andreas Jaeger]

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

> I am not going to see this failure on my machine.  I have a 2gb x86-64
> which will easily handle
> compiling this size file.   I was watching top as it compiled a stage2
> insn-addrtab, which I think is the largest function in the gcc stack
> and the VIRT topped at 501mb, which is no sweat for this machine.  You
> could argue, (and I would not disagree with you) that 501mb is not
> tolerable and is symptomatic of something bad happening.  There are,
> most likely storage leaks in the system.  But I do not think that you
> are going to necessarily find the problem by looking to see which
> version happens to crash on your machine.  The worst case senario is
> that this is just footprint creep and the version that failed was just
> the one the added the straw that broke the camels back with you
> particular config.

Ok, figured it out, it's my ulimit call:

ulimit -m 60 -v 60

So, memory usage has increased during the last days.  Don't we have
some automatic testers that look at memory usage as well?

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpiWfc2Ss96U.pgp
Description: PGP signature

[CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Laurent GUERBY]

Hi,

I've put in place a script that monitor svn log on trunk and launches
a bootstrap + check on each commit (distributed on the 7 CFARM ubuntu
machines). On average since Nov2005 there have been 20 commits per day
on trunk so, a cycle taking about 8 hours I expect to use about 50%
of CFARM ressources for this task. I'm currently limiting to one build
per machine to leave a processor for other users of CFARM.

I still validate manually the output before sending to gcc-testresults
but that will change soon (when I'm confident that it survives a few
problems), see current results with subject "[r1100xx]":
http://gcc.gnu.org/ml/gcc-testresults/2006-01/

I'm currently using the following configure flags:
--disable-nls --disable-multilib --enable-languages=c,ada

So build & check takes between 4h30 and 6h00 depending on the
processor frequency. Adding other languages will push that figure to
6 to 8 hours (last time I checked). CFARM is a bit behind on commits
since I launched my script starting with r110006, it has currently
done up to r110047 and has 25 revisions to go (as of r110115).

Is sending each rev testresults to gcc-testresults ok? 

I have a serie of build which failed (gcov build ICE), r110009 to
r110025, what to do with those, email to testresults with end of build
log?

Next tasks will be:

- Activate more languages. What languages, what configure flags are
useful?

- Activate build & check on branches.

- Filter out rev we known aren't changing anything (eg: gccadmin daily
bump).

- Automating cross build & check: Mike Stein has simulators running on C
for a combined tree, with RTEMS folks we nearly have Ada ACATS running
on a few simulators.

- Priority management for all the above workload.

- Document what I've done so far: 170 lines python + 70 lines bourne
shell, nothing big :)

- What to keep from builds? install direcotry for quick hunting, for all
rev or only some? Right now nothing is deleted (even build dir) but it
won't last more than a few days.

- And of course: offer rev+user patch testing.

Comments, suggestion and help welcomed.

Laurent

PS: http://gcc.gnu.org/wiki/CompileFarm
has instructions if you want an account.

Re: Build on mainline broken

[Paolo Bonzini]

I think this is either PR 25890 or PR 25905.


It's PR25905, an assertion failure caused by invalid RTL produced by 
expand.  (PR25890 instead is where combine produces invalid RTL that 
fails its own assertion).


Paolo

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Richard Guenther]

On 1/23/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've put in place a script that monitor svn log on trunk and launches
> a bootstrap + check on each commit (distributed on the 7 CFARM ubuntu
> machines). On average since Nov2005 there have been 20 commits per day
> on trunk so, a cycle taking about 8 hours I expect to use about 50%
> of CFARM ressources for this task. I'm currently limiting to one build
> per machine to leave a processor for other users of CFARM.
>
> I still validate manually the output before sending to gcc-testresults
> but that will change soon (when I'm confident that it survives a few
> problems), see current results with subject "[r1100xx]":
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/
>
> I'm currently using the following configure flags:
> --disable-nls --disable-multilib --enable-languages=c,ada

What you could try doing is restricting the enabled languages if a patch
touches only frontend parts (i.e. a subdirectory out of cp/, fortran/ ada/, etc.
in gcc).  In this case only enable c and the affected language.  Likewise
if only a toplevel target library like libstdc++ or libjava is affected.

> So build & check takes between 4h30 and 6h00 depending on the
> processor frequency. Adding other languages will push that figure to
> 6 to 8 hours (last time I checked). CFARM is a bit behind on commits
> since I launched my script starting with r110006, it has currently
> done up to r110047 and has 25 revisions to go (as of r110115).
>
> Is sending each rev testresults to gcc-testresults ok?

Yes, I think that is useful.

> I have a serie of build which failed (gcov build ICE), r110009 to
> r110025, what to do with those, email to testresults with end of build
> log?
>
> Next tasks will be:
>
> - Activate more languages. What languages, what configure flags are
> useful?

See above.  In general, enabling all default languages is useful, though
enabling java/libjava will push the requirements way up.

> - Activate build & check on branches.

I think this is less important, as other daily(!) testers build the
branches, too,
and with the commit frequency on the branches this already should capture
nearly every revision.

Richard.

bootstrap failure for ADA gcc4.1 Revision 110108 on hppa2.0w-hp-hpux11.00

[Rainer Emrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

stage1/xgcc -Bstage1/
-
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/hppa2.0w-hp-hpux11.00/bin/
- -c -g -O2 -mdisable-indexing -gnatpg -gnata -I- -I. -Iada
- -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/gcc/ada
/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/gcc/ada/ada.ads -o 
ada/ada.o

gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
gmake[2]: *** [ada/ada.o] Error 1

- --
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 Mozilla - http://enigmail.mozdev.org

iD8DBQFD1N7O3s6elE6CYeURAqLnAKCQOGVFYe2O5F8FFex8GiHQILgzXgCfdy4f
Yki4+zmbY6MJXygtdA07Uco=
=dxJA
-END PGP SIGNATURE-

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Arnaud Charlet wrote:

I thought so too, and indeed tried it this way at first, but got:
"../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC


/bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada: No such file or 
directory


The quotes around GCC_LINK could be removed here and instead put in the the 
-GCC=$(GCC_LINK) bits,



Right, that seems easy enough to do, and I do prefer to keep a single
variable, used for all tools.



but it seemed easier to have a new var.



easier for who ? The person who writes the code or all the people who
have to read, understand and maintain it afterwards ?


Attached is a patch to the 4.1 branch, I think it will apply to mainline 
too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.


Peter
Index: gcc/ada/Makefile.in
===
--- gcc/ada/Makefile.in (revision 110115)
+++ gcc/ada/Makefile.in (working copy)
@@ -1308,7 +1308,7 @@
 
   EH_MECHANISM=-gcc
   GNATLIB_SHARED = gnatlib-shared-darwin
-  SO_OPTS = -Wl,-flat_namespace
+  SO_OPTS = -Wl,-flat_namespace -shared-libgcc
   RANLIB = ranlib -c
   GMEM_LIB = gmemlib
   PREFIX_OBJS=$(PREFIX_REAL_OBJS)
@@ -1364,7 +1364,7 @@
  s-[a-o]*.adb s-[p-z]*.adb s-[a-o]*.ads s-[p-z]*.ads  
 
 LIBGNAT=../rts/libgnat.a 
-GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
+GCC_LINK=$(CC) -static-libgcc $(ADA_INCLUDES)
 
 # when compiling the tools, the runtime has to be first on the path so that
 # it hides the runtime files lying with the rest of the sources
@@ -1388,74 +1388,74 @@
 ../../gnatchop$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatchop --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatchop 
-   $(GNATLINK) -v gnatchop -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatchop -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnat$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatcmd --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatcmd 
-   $(GNATLINK) -v gnatcmd -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatcmd -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatkr$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatkr --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatkr 
-   $(GNATLINK) -v gnatkr -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatkr -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatls$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatls --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatls 
-   $(GNATLINK) -v gnatls -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatls -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatname$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatname --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatname 
-   $(GNATLINK) -v gnatname -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatname -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gprmake$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gprmake --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gprmake
-   $(GNATLINK) -v gprmake -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gprmake -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatprep$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatprep --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatprep 
-   $(GNATLINK) -v gnatprep -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatprep -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatxref$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatxref --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatxref 
-   $(GNATLINK) -v gnatxref -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatxref -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatfind$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatfind --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatfind 
-   $(GNATLINK) -v gnatfind -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatfind -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatclean$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatclean --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatclean
-   $(GNATLINK) -v gnatclean -o $@ --GCC=$(GCC_LINK) $(TOOLS_LIBS)
+   $(GNATLINK) -v gnatclean -o $@ --GCC="$(GCC_LINK)" $(TOOLS_LIBS)
 
 ../../gnatsym$(exeext): 
$(GNATMAKE) -c $(ADA_INCLUDES) gnatsym --GCC="$(CC) $(ALL_ADAFLAGS)"
$(GNATBIND) $(ADA_INCLUDES) $(GNATBIND_FLAGS) gnatsym
-   $(GNATLINK) -v gnatsym 

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Daniel Jacobowitz]

On Mon, Jan 23, 2006 at 01:27:50PM +0100, Richard Guenther wrote:
> > Is sending each rev testresults to gcc-testresults ok?
> 
> Yes, I think that is useful.

Well, a nice optimization for people using the list archives would be
to only send test logs that have changed since the last one posted.
Optionally, by some change other than the total number of PASS.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Arnaud Charlet]

> Attached is a patch to the 4.1 branch, I think it will apply to mainline 
> too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.

OK to commit, thanks for taking my comments into account.

Arno

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Eric Botcazou]

> Attached is a patch to the 4.1 branch, I think it will apply to mainline
> too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.

That's not sufficient: the compiler bootstraps fine, but all the ACATS tests 
fail to link:

gnatlink a22006c.ali 
--GCC=/nile.build/botcazou/gnat6/powerpc-apple-darwin8/gcc/
xgcc -B/nile.build/botcazou/gnat6/powerpc-apple-darwin8/gcc/
/usr/bin/ld: warning -L: directory name 
(/nile.build/botcazou/gnat6/install_ppc/
lib/gcc/powerpc-apple-darwin8.0.0/4.1.0/adalib/) does not exist
/usr/bin/ld: Undefined symbols:
__Unwind_Resume
__Unwind_ForcedUnwind
__Unwind_GetDataRelBase
__Unwind_GetIP
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
__Unwind_RaiseException
__Unwind_SetGR
__Unwind_SetIP
collect2: ld returned 1 exit status

So, on Darwin, unlike any other platforms, you need to explicitly pass either 
-static-libgcc or -shared-libgcc to link the EH machinery.  That seems weird.

Geoff, any chance to bring Darwin back on par with the other platforms?

-- 
Eric Botcazou

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eric Botcazou wrote:
|>Attached is a patch to the 4.1 branch, I think it will apply to mainline
|>too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada enabled.
|
|
| That's not sufficient: the compiler bootstraps fine, but all the ACATS tests
| fail to link:
|
| collect2: ld returned 1 exit status
|
| So, on Darwin, unlike any other platforms, you need to explicitly pass either
| -static-libgcc or -shared-libgcc to link the EH machinery.  That seems weird.
|
| Geoff, any chance to bring Darwin back on par with the other platforms?
|

Since Geoff is worried about future binary compatibility apparently, it
would probably be easier to modify gnatlink.adb to emit -static-libgcc or
- -shared-libgcc depending on whether static or shared gnatlib is used.

Sorry, I know nothing about ada or I'd help.

Peter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Darwin)

iQCVAwUBQ9TvHLiDAg3OZTLPAQK3dgP/azit2VsBNmWlufxp4PZpbWtO28uZNO15
Zmp0Vh+/439x7dhx8sF3JpD4ryyKg40LiLHe2Qtdx4NyYYrD5rrjabJZ03TmVOV1
9p27Zo0ze/jcXuQvuvmu9Xcu3YDZ87AS1aPyuhIHRJIy/097yQN6yubd/t9WqZMN
AyCMVCKi6gY=
=Hkol
-END PGP SIGNATURE-

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Eric Botcazou]

> Since Geoff is worried about future binary compatibility apparently, it
> would probably be easier to modify gnatlink.adb to emit -static-libgcc or
> -shared-libgcc depending on whether static or shared gnatlib is used.

The problem is that passing -static-libgcc unconditionally can theoritically 
cause problems on Linux when C code using POSIX threads is linked.  So we 
would need to do that only on Darwin.

-- 
Eric Botcazou

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Eric Botcazou wrote:

Since Geoff is worried about future binary compatibility apparently, it
would probably be easier to modify gnatlink.adb to emit -static-libgcc or
-shared-libgcc depending on whether static or shared gnatlib is used.



The problem is that passing -static-libgcc unconditionally can theoritically 
cause problems on Linux when C code using POSIX threads is linked.  So we 
would need to do that only on Darwin.




Then set a var in link.c for darwin and use that as the conditional?

#elif defined(__APPLE__)
const char *__gnat_run_path_option = "-Wl,-filelist";
const char *__gnat_object_file_option = "";
char __gnat_shared_libgnat_default = STATIC;
int __gnat_link_max = 262144;
unsigned char __gnat_objlist_file_supported = 1;
unsigned char __gnat_using_gnu_linker = 0;
const char *__gnat_object_library_extension = ".a";
unsigned char __gnat_darwin_idiocy = 1;
#else
...

You'd have to add the idiocy flag elsewhere too and default to 0.

Peter

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Arnaud Charlet]

> Then set a var in link.c for darwin and use that as the conditional?
> 
> #elif defined(__APPLE__)
> const char *__gnat_run_path_option = "-Wl,-filelist";
> const char *__gnat_object_file_option = "";
> char __gnat_shared_libgnat_default = STATIC;
> int __gnat_link_max = 262144;
> unsigned char __gnat_objlist_file_supported = 1;
> unsigned char __gnat_using_gnu_linker = 0;
> const char *__gnat_object_library_extension = ".a";
> unsigned char __gnat_darwin_idiocy = 1;
> #else

Well, the name certainly cannot be called __gnat_darwin_idiocy.
Instead, these flags should be tailored by capability, not by platforms.

That would be e.g. "unsigned char __gnat_force_libgcc_option = 1;"

Arno

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Peter O'Gorman]

Arnaud Charlet wrote:

Then set a var in link.c for darwin and use that as the conditional?

#elif defined(__APPLE__)
const char *__gnat_run_path_option = "-Wl,-filelist";
const char *__gnat_object_file_option = "";
char __gnat_shared_libgnat_default = STATIC;
int __gnat_link_max = 262144;
unsigned char __gnat_objlist_file_supported = 1;
unsigned char __gnat_using_gnu_linker = 0;
const char *__gnat_object_library_extension = ".a";
unsigned char __gnat_darwin_idiocy = 1;
#else



Well, the name certainly cannot be called __gnat_darwin_idiocy.
Instead, these flags should be tailored by capability, not by platforms.

That would be e.g. "unsigned char __gnat_force_libgcc_option = 1;"


Aw! :)

Also, I missed a comma after -filelist.

Peter

Re: Request for 48 hours of just regression/bug fixes

[Andrew Pinski]

> 
> Richard Guenther wrote:
> 
> > I would even extend this "slush" to the point where all P1 4.1 regressions 
> > are
> > fixed and a first 4.1.0 RC could be built.
> 
> Shutting down the mainline to get folks to focus on 4.1 is a step I'd
> prefer not to take; I'm hopeful that the 4.1 P1s will get the attention
> they deserve.
> 
> However, I am concerned about instability on mainline.
> 
> If someone will put together the meta-bug, I'll consider the request to
> slush mainline.  In the absence of that, I'd certainly ask that we hold
> off on additional major merges until the consensus is that things have
> been reasonably stabililized.

I filed PR 25925 for this purpose.  There currently 5 bugs linked from it.

Thanks,
Andrew Pinski

Re: RTL alias analysis

[Bernhard R. Link]

* Richard Guenther <[EMAIL PROTECTED]> [060122 14:23]:
> [...] The correct solution for converting
> a float to an integer (bit-representation) as in the expample is to use
> two different memory locations and memcpy (which avoids aliasing
> issues by means of using the special rules for access through 'char').

But only in that example. In general memcpy might be optimized to some
assignment causing a SIGBUS if gcc thinks it is save but it is not.
(like a misaligned pointer to a struct where some member is accessed).

Hochachtungsvoll,
Bernhard R. Link

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Joe Buck]

On Mon, Jan 23, 2006 at 09:10:57AM -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 23, 2006 at 01:27:50PM +0100, Richard Guenther wrote:
> > > Is sending each rev testresults to gcc-testresults ok?
> > 
> > Yes, I think that is useful.
> 
> Well, a nice optimization for people using the list archives would be
> to only send test logs that have changed since the last one posted.
> Optionally, by some change other than the total number of PASS.

Agreed; if there is no change there is no information content, and
the list could be overwhelmed with messages that are near-duplicates.
I suppose you could do comparisons of the .sum files to determine if
there has been a change.

[RFC/RFT] PR/25890 and PR/25905

[Paolo Bonzini]

It turns out that the assertion checks I added in my last combine patch 
trigger on about every target but the ones I tested.  ;-)  These 
assertions tested for invalid zero_extract and sign_extract expressions, 
where the initial and/or final positions are out of the first operand's 
bounds.


Some of these failures (PR25890) are caused by combine trying to 
synthesize invalid shifts.  These could be easily fixed in combine itself.


Some other failures however are caused by bitfield operations.  Expand 
is more than happy to create QImode memory accesses independent of the 
width of the bitfield.  Fixing this is a mess because some machine 
descriptions, in turn, *expect* this to be true and use a 
(match_operand:QI 0 "memory_operand") in their extv/extzv patterns.  In 
other word, this would require the rework of the insv/extv/extzv 
patterns that was mentioned a while ago.  This is not appropriate for a 
build-breaking bug, during the slush, and while I have little time to 
devote to FSF GCC development.


For this reason I'm inclined to disable combine's transformations, and 
return a (clobber (const_int 0)), in presence of "invalid" extractions. 
The attached patch does exactly this.  I'm bootstrapping it overnight, 
but I'll post it right now so that people affected by the bug can also 
test it.


Ok for mainline if it passes?

Paolo
2006-01-23  Paolo Bonzini  <[EMAIL PROTECTED]>

PR rtl-optimization/25890
PR rtl-optimization/25905
* combine.c (expand_compound_operation, expand_field_assignment):
Fail if the bitfield's final position is out of bounds.

Index: combine.c
===
--- combine.c   (revision 109978)
+++ combine.c   (working copy)
@@ -5640,8 +5642,9 @@ expand_compound_operation (rtx x)
   len = INTVAL (XEXP (x, 1));
   pos = INTVAL (XEXP (x, 2));
 
-  /* This should stay within the object being extracted, fail.  */
-  gcc_assert (len + pos <= GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0;
+  /* This should stay within the object being extracted, fail otherwise.  
*/
+  if (len + pos > GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0
+   return x;
 
   if (BITS_BIG_ENDIAN)
pos = GET_MODE_BITSIZE (GET_MODE (XEXP (x, 0))) - len - pos;
@@ -5800,9 +5803,9 @@ expand_field_assignment (rtx x)
  pos = XEXP (SET_DEST (x), 2);
 
  /* A constant position should stay within the width of INNER.  */
- if (GET_CODE (pos) == CONST_INT)
-   gcc_assert (INTVAL (pos) + len
-   <= GET_MODE_BITSIZE (GET_MODE (inner)));
+ if (GET_CODE (pos) == CONST_INT
+ && INTVAL (pos) + len > GET_MODE_BITSIZE (GET_MODE (inner)))
+   break;
 
  if (BITS_BIG_ENDIAN)
{

bootstrap broken on ppc-linux

[Richard Henderson]

This is reproducible with an i686 cross.

build/genextract ../../src-head/gcc/config/rs6000/rs6000.md \
  insn-conditions.md > tmp-extract.c
*** glibc detected *** build/genextract: double free or corruption (fasttop): 
0x081cc980 ***
=== Backtrace: =
/lib/libc.so.6[0x9da124]
/lib/libc.so.6(__libc_free+0x77)[0x9da65f]
build/genextract[0x80499af]
/lib/libc.so.6(__libc_start_main+0xdf)[0x98bd5f]
build/genextract(free+0x91)[0x8048c39]
=== Memory map: 
00959000-00973000 r-xp  fd:00 1081346/lib/ld-2.3.5.so
00973000-00974000 r-xp 00019000 fd:00 1081346/lib/ld-2.3.5.so
00974000-00975000 rwxp 0001a000 fd:00 1081346/lib/ld-2.3.5.so
00977000-00a9a000 r-xp  fd:00 1081362/lib/libc-2.3.5.so
00a9a000-00a9c000 r-xp 00123000 fd:00 1081362/lib/libc-2.3.5.so
00a9c000-00a9e000 rwxp 00125000 fd:00 1081362/lib/libc-2.3.5.so
00a9e000-00aa rwxp 00a9e000 00:00 0
00c86000-00c87000 r-xp 00c86000 00:00 0  [vdso]
00df3000-00dfc000 r-xp  fd:00 1081381
/lib/libgcc_s-4.0.2-20051126.so.1
00dfc000-00dfd000 rwxp 9000 fd:00 1081381
/lib/libgcc_s-4.0.2-20051126.so.1
08048000-08057000 r-xp  fd:01 10552009   
/local/rth/gcc/bld-ppc/gcc/build/genextract
08057000-08058000 rw-p e000 fd:01 10552009   
/local/rth/gcc/bld-ppc/gcc/build/genextract
08058000-081da000 rw-p 08058000 00:00 0  [heap]
b7e0-b7e21000 rw-p b7e0 00:00 0
b7e21000-b7f0 ---p b7e21000 00:00 0
b7ff1000-b7ff2000 rw-p b7ff1000 00:00 0
b7fff000-b800 rw-p b7fff000 00:00 0
bffea000-c000 rw-p bffea000 00:00 0  [stack]
/bin/sh: line 1: 26254 Aborted build/genextract 
../../src-head/gcc/config/rs6000/rs6000.md insn-conditions.md >tmp-extract.c


#0  0x0fee6548 in free () from /lib/libc.so.6
#1  0x10001414 in VEC_locstr_heap_free (vec_=0xffe2d5d8)
at ../../src-head/gcc/genextract.c:77
#2  0x100012dc in gen_insn (insn=0x100f3ff0, insn_code_number=339)
at ../../src-head/gcc/genextract.c:179
#3  0x10002e60 in main (argc=3, argv=0xffe2d8e4)
at ../../src-head/gcc/genextract.c:418




r~

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Laurent GUERBY]

On Mon, 2006-01-23 at 09:09 -0800, Joe Buck wrote:
> Agreed; if there is no change there is no information content, and
> the list could be overwhelmed with messages that are near-duplicates.
> I suppose you could do comparisons of the .sum files to determine if
> there has been a change.

There's the information that the CFARM build succeeded and that there is
no regression on the new revision. Not sending an email would mean
you cannot distinguish between a failed build, a not working CFARM and
everything is fine (by looking only at gcc-testresults).

Assuming we send an email, it could be of course much shorter if
it's "unchanged".

For technical reasons (non uniform processor speed, load), rev N+1
can be available before rev N, but we can do with latest available
when build finishes.

I wrote:
> I have a serie of build which failed (gcov build ICE), r110009 to
> r110025, what to do with those, email to testresults with end of build
> log?

I assume no one object to those "FAILED" messages?

Laurent

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Laurent GUERBY]

On Mon, 2006-01-23 at 09:10 -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 23, 2006 at 01:27:50PM +0100, Richard Guenther wrote:
> > > Is sending each rev testresults to gcc-testresults ok?
> > 
> > Yes, I think that is useful.
> 
> Well, a nice optimization for people using the list archives would be
> to only send test logs that have changed since the last one posted.
> Optionally, by some change other than the total number of PASS.

Is there an existing script that does such a diff? (In SVN or on
someone favourite test machine :).

Laurent

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> This is reproducible with an i686 cross.

Urgh.  And I've got Geert reporting a crash (in a different place)
on ppc-darwin.

I won't be able to do anything until I get home, at 4 or 5 Pacific.
If you/anyone feels like fixing it sooner than that, please do
(and I'll buy you a beer sometime).

zw

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Mike Stump]

On Jan 23, 2006, at 11:15 AM, Laurent GUERBY wrote:

Is there an existing script that does such a diff? (In SVN or on
someone favourite test machine :).


Gotta love previously solved problems...

contrib/compare_tests

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Joe Buck]

On Mon, Jan 23, 2006 at 08:13:38PM +0100, Laurent GUERBY wrote:
> On Mon, 2006-01-23 at 09:09 -0800, Joe Buck wrote:
> > Agreed; if there is no change there is no information content, and
> > the list could be overwhelmed with messages that are near-duplicates.
> > I suppose you could do comparisons of the .sum files to determine if
> > there has been a change.
> 
> There's the information that the CFARM build succeeded and that there is
> no regression on the new revision. Not sending an email would mean
> you cannot distinguish between a failed build, a not working CFARM and
> everything is fine (by looking only at gcc-testresults).

Right, but gcc-testresults is not cfarm-status, it's gcc-testresults.

That information could be presented somewhere else, like with Mozilla's
Tinderbox system.  A web page could be kept updated with the latest
revision number that built successfully, together with a summary of the
latest tests.

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Laurent GUERBY]

On Mon, 2006-01-23 at 11:40 -0800, Joe Buck wrote:
> On Mon, Jan 23, 2006 at 08:13:38PM +0100, Laurent GUERBY wrote:
> > On Mon, 2006-01-23 at 09:09 -0800, Joe Buck wrote:
> > > Agreed; if there is no change there is no information content, and
> > > the list could be overwhelmed with messages that are near-duplicates.
> > > I suppose you could do comparisons of the .sum files to determine if
> > > there has been a change.
> > 
> > There's the information that the CFARM build succeeded and that there is
> > no regression on the new revision. Not sending an email would mean
> > you cannot distinguish between a failed build, a not working CFARM and
> > everything is fine (by looking only at gcc-testresults).
> 
> Right, but gcc-testresults is not cfarm-status, it's gcc-testresults.
> 
> That information could be presented somewhere else, like with Mozilla's
> Tinderbox system.  A web page could be kept updated with the latest
> revision number that built successfully, together with a summary of the
> latest tests.

I'm perfectly okay with not sending any email to gcc-testresults from
CFARM and put that information somewhere else.

Is that the consensus?

Laurent

Re: [CFARM] Automatic bootstrap & check of each svn commit on the GCC Compile Farm

[Laurent GUERBY]

On Mon, 2006-01-23 at 11:25 -0800, Mike Stump wrote:
> On Jan 23, 2006, at 11:15 AM, Laurent GUERBY wrote:
> > Is there an existing script that does such a diff? (In SVN or on
> > someone favourite test machine :).
> 
> Gotta love previously solved problems...
> 
> contrib/compare_tests

Thanks, I would have been surprised if it did not exist :).

Right now I'm archiving output from configure, make bootstrap, make -k
check. I'll add find build -name '*.sum' to that for this script.

Any other file I should be keeping around after the build is completed?

Laurent

Re: bootstrap broken on ppc-linux

[Andrew Pinski]

> 
> On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> > This is reproducible with an i686 cross.
> 
> Urgh.  And I've got Geert reporting a crash (in a different place)
> on ppc-darwin.

I was able to reproduce the ppc-darwin failure with a cross compiler from
x86_64-linux-gnu.  See PR 25931.

-- Pinski

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 03:04:25PM -0500, Andrew Pinski wrote:
> > 
> > On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> > > This is reproducible with an i686 cross.
> > 
> > Urgh.  And I've got Geert reporting a crash (in a different place)
> > on ppc-darwin.
> 
> I was able to reproduce the ppc-darwin failure with a cross compiler from
> x86_64-linux-gnu.  See PR 25931.

That's the genextract crash that rth is seeing on ppc-linux.  Can you also
reproduce the ppc-darwin genautomata crash?

zw

Re: bootstrap broken on ppc-linux

[Andrew Pinski]

> 
> On Mon, Jan 23, 2006 at 03:04:25PM -0500, Andrew Pinski wrote:
> > > 
> > > On Mon, Jan 23, 2006 at 11:13:26AM -0800, Richard Henderson wrote:
> > > > This is reproducible with an i686 cross.
> > > 
> > > Urgh.  And I've got Geert reporting a crash (in a different place)
> > > on ppc-darwin.
> > 
> > I was able to reproduce the ppc-darwin failure with a cross compiler from
> > x86_64-linux-gnu.  See PR 25931.
> 
> That's the genextract crash that rth is seeing on ppc-linux.  Can you also
> reproduce the ppc-darwin genautomata crash?

Nope. genautomata just works.

Thanks,
Andrew Pinski

Questions about --enable-__cxa_atexit

[Laurent GUERBY]

Hi,

http://gcc.gnu.org/install/configure.html mentions:
--enable-__cxa_atexit
Define if you want to use __cxa_atexit, rather than atexit, to
register C++ destructors for local statics and global objects.
This is essential for fully standards-compliant handling of
destructors, but requires __cxa_atexit in libc. This option is
currently only available on systems with GNU libc. When enabled,
this will cause -fuse-cxa-exit to be passed by default. 


Is there any reason why this is not detected automatically by configure?
If I build C++ on x86-linux should I add this option?

Thanks in advance,

Laurent

sh-rtems (elf) does not build on head

[Joel Sherrill]

Hi,

I updated this morning and sh-rtems does not
build.  It fails building libgcc2.c as follows:

home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/xgcc 
-B/home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/ -nostdinc 
-B/home/joel/gcc-work/head/b-sh-rtems4.7/sh-rtems4.7/newlib/ -isystem 
/home/joel/gcc-work/head/b-sh-rtems4.7/sh-rtems4.7/newlib/targ-include 
-isystem /home/joel/gcc-work/head/gcc/newlib/libc/include 
-B/home/joel/gcc-head-test//sh-rtems4.7/bin/ 
-B/home/joel/gcc-head-test//sh-rtems4.7/lib/ -isystem 
/home/joel/gcc-head-test//sh-rtems4.7/include -isystem 
/home/joel/gcc-head-test//sh-rtems4.7/sys-include -O2 -O2 -g -O2  
-DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -I. 
-Im4-single-only -I../../gcc/gcc -I../../gcc/gcc/m4-single-only 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include  
-I../../gcc/gcc/../libdecnumber -I../libdecnumber -m4-single-only -g0 
-finhibit-size-directive -fno-inline-functions -fno-exceptions 
-fno-zero-initialized-in-bss -fno-toplevel-reorder -Dinhibit_libc -fPIC \

 -c ../../gcc/gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O \
 -o m4-single-only/crtendS.o
../../gcc/gcc/libgcc2.c: In function '__negvdi2':
../../gcc/gcc/libgcc2.c:199: internal compiler error: in 
expand_compound_operation, at combine.c:5644

Please submit a full bug report,

Any ideas?

--joel

m68k-rtems (elf) does not build on head

[Joel Sherrill]

Hi,

I updated this morning and the head does not
build m68k-rtems which most likely means that
m68k-elf does not build as well. My last
build of this was Jan 17.

gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute 
-fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/tree.c 
-o tree.o

In file included from ../../gcc/gcc/targhooks.c:67:
../../gcc/gcc/optabs.h:25:24: error: insn-codes.h: No such file or directory
In file included from ../../gcc/gcc/targhooks.c:67:
../../gcc/gcc/optabs.h:44: warning: ISO C forbids forward references to 
‘enum’ types


--joel

Re: sh-rtems (elf) does not build on head

[Joel Sherrill]

Sorry to follow up so quick but I last built this on Jan 17 so this
is also a recent breakage.
Joel Sherrill wrote:


Hi,

I updated this morning and sh-rtems does not
build.  It fails building libgcc2.c as follows:

home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/xgcc 
-B/home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/ -nostdinc 
-B/home/joel/gcc-work/head/b-sh-rtems4.7/sh-rtems4.7/newlib/ -isystem 
/home/joel/gcc-work/head/b-sh-rtems4.7/sh-rtems4.7/newlib/targ-include 
-isystem /home/joel/gcc-work/head/gcc/newlib/libc/include 
-B/home/joel/gcc-head-test//sh-rtems4.7/bin/ 
-B/home/joel/gcc-head-test//sh-rtems4.7/lib/ -isystem 
/home/joel/gcc-head-test//sh-rtems4.7/include -isystem 
/home/joel/gcc-head-test//sh-rtems4.7/sys-include -O2 -O2 -g -O2  
-DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include  -I. -Im4-single-only -I../../gcc/gcc 
-I../../gcc/gcc/m4-single-only -I../../gcc/gcc/../include 
-I../../gcc/gcc/../libcpp/include  -I../../gcc/gcc/../libdecnumber 
-I../libdecnumber -m4-single-only -g0 -finhibit-size-directive 
-fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss 
-fno-toplevel-reorder -Dinhibit_libc -fPIC \

 -c ../../gcc/gcc/crtstuff.c -DCRT_END -DCRTSTUFFS_O \
 -o m4-single-only/crtendS.o
../../gcc/gcc/libgcc2.c: In function '__negvdi2':
../../gcc/gcc/libgcc2.c:199: internal compiler error: in 
expand_compound_operation, at combine.c:5644

Please submit a full bug report,

Any ideas?

--joel

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > 
> > That's the genextract crash that rth is seeing on ppc-linux.  Can you also
> > reproduce the ppc-darwin genautomata crash?
> 
> Nope. genautomata just works.

Clarification please.  In a cross configuration targeting ppc-darwin, genextract
crashes and genautomata just works?  Or, in a cross configuration targeting
ppc-linux, genextract crashes and genautomata just works?  Or what?

zw

Re: bootstrap broken on ppc-linux

[Andrew Pinski]

> 
> On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > > 
> > > That's the genextract crash that rth is seeing on ppc-linux.  Can you also
> > > reproduce the ppc-darwin genautomata crash?
> > 
> > Nope. genautomata just works.
> 
> Clarification please.  In a cross configuration targeting ppc-darwin, 
> genextract
> crashes and genautomata just works?  Or, in a cross configuration targeting
> ppc-linux, genextract crashes and genautomata just works?  Or what?

in a cross to targetting powerpc-darwin, genextract crashes and genautomata 
works.

Should I also see what happens for powerpc-linux?

-- Pinski

Re: sh-rtems (elf) does not build on head

[Andrew Pinski]

> 
> 
> Sorry to follow up so quick but I last built this on Jan 17 so this
> is also a recent breakage.

This is related to PR 25890 and PR 25905.

Thanks,
Andrew Pinski

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 03:28:59PM -0500, Andrew Pinski wrote:
> > 
> > On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > > > 
> > > > That's the genextract crash that rth is seeing on ppc-linux.  Can you 
> > > > also
> > > > reproduce the ppc-darwin genautomata crash?
> > > 
> > > Nope. genautomata just works.
> > 
> > Clarification please.  In a cross configuration targeting ppc-darwin, 
> > genextract
> > crashes and genautomata just works?  Or, in a cross configuration targeting
> > ppc-linux, genextract crashes and genautomata just works?  Or what?
> 
> in a cross to targetting powerpc-darwin, genextract crashes and genautomata 
> works.
> 
> Should I also see what happens for powerpc-linux?

If you can, that would be helpful.

Also, if you have access to valgrind (I can't remember if it works on x86-64 
yet?)
you could run both programs under it and report what it says, since this seems
to be a bad-memory-access issue.  The output might be huge - maybe best to take
that to private mail.

zw

Re: [RFC/RFT] PR/25890 and PR/25905

[Jan-Benedict Glaw]

On Mon, 2006-01-23 19:19:23 +0100, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> For this reason I'm inclined to disable combine's transformations, and 
> return a (clobber (const_int 0)), in presence of "invalid" extractions. 
> The attached patch does exactly this.  I'm bootstrapping it overnight, 
> but I'll post it right now so that people affected by the bug can also 
> test it.

Works for me (vax-linux-uclibc).

MfG, JBG

-- 
Jan-Benedict Glaw   [EMAIL PROTECTED]. +49-172-7608481 _ O _
"Eine Freie Meinung in  einem Freien Kopf| Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));


signature.asc
Description: Digital signature

mudflap extention request

[Herman ten Brugge]

Hello,

I recently debugged a program that had an array indexing problem. The
simplified program is:

typedef struct tst_struct
{
 unsigned n;
 unsigned arr[3];
 struct tst_struct *next;
} tst;

tst t = { 3, {0, 1, 2}, 0 };

int
main (void)
{
 t.arr[t.n++] = 3;
}

The 't.arr[t.n++]' overwrites the 'next' field in the structure.

The bounds-checking code in the past could not find this problem
because the structure was seen as one big object. I modified the
bounds-checking code a long time ago to handle arrays special.
Arrays are now checked against the maximum array size. I had
to make one exception because of code like:

typedef struct tst_struct
{
 unsigned n;
 unsigned arr[1];
} tst;

This structure is normally extended using malloc. So I do not
check arrays when the array size is <= array element size.

This code also finds problems like:
int a[10][10];
printf("%d", a[0][11]);

Finally the question. Is it possible to add this extension
to mudflap so the above problem is found here as well.

I did find a lot of array indexing problems like the above
one in the past 10 years since I implemented it.

   Herman.

Re: bootstrap broken on ppc-linux

[Andrew Pinski]

> 
> On Mon, Jan 23, 2006 at 03:28:59PM -0500, Andrew Pinski wrote:
> > > 
> > > On Mon, Jan 23, 2006 at 03:16:56PM -0500, Andrew Pinski wrote:
> > > > > 
> > > > > That's the genextract crash that rth is seeing on ppc-linux.  Can you 
> > > > > also
> > > > > reproduce the ppc-darwin genautomata crash?
> > > > 
> > > > Nope. genautomata just works.
> > > 
> > > Clarification please.  In a cross configuration targeting ppc-darwin, 
> > > genextract
> > > crashes and genautomata just works?  Or, in a cross configuration 
> > > targeting
> > > ppc-linux, genextract crashes and genautomata just works?  Or what?
> > 
> > in a cross to targetting powerpc-darwin, genextract crashes and genautomata 
> > works.
> > 
> > Should I also see what happens for powerpc-linux?
> 
> If you can, that would be helpful.


The same thing happens targetting powerpc-linux in that genextract crashes and
genautomata works.

> 
> Also, if you have access to valgrind (I can't remember if it works on x86-64 
> yet?)
> you could run both programs under it and report what it says, since this seems
> to be a bad-memory-access issue.  The output might be huge - maybe best to 
> take
> that to private mail.

Yes valgrind works on x86_64.
The output is not that huge, it is only 17k.

Attached is the output.

Thanks,
Andrew Pinski

==21865== Memcheck, a memory error detector.
==21865== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==21865== Using LibVEX rev 1367, a library for dynamic binary translation.
==21865== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==21865== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==21865== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==21865== For more details, rerun with: -v
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x119106B1: (within /lib/ld-2.3.5.so)
==21865==by 0x11904454: (within /lib/ld-2.3.5.so)
==21865==by 0x11904A9C: (within /lib/ld-2.3.5.so)
==21865==by 0x11902360: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21865==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21865==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x119104C0: (within /lib/ld-2.3.5.so)
==21865==by 0x11904034: (within /lib/ld-2.3.5.so)
==21865==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21865==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21865==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21865==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21865==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21865==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x119104CF: (within /lib/ld-2.3.5.so)
==21865==by 0x11904034: (within /lib/ld-2.3.5.so)
==21865==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21865==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21865==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21865==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21865==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21865==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x119104DE: (within /lib/ld-2.3.5.so)
==21865==by 0x11904034: (within /lib/ld-2.3.5.so)
==21865==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21865==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21865==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21865==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21865==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21865==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x1191067D: (within /lib/ld-2.3.5.so)
==21865==by 0x11904041: (within /lib/ld-2.3.5.so)
==21865==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21865==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21865==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21865==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21865==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21865==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21865== 
==21865== Conditional jump or move depends on uninitialised value(s)
==21865==at 0x1191067D: (within /lib/ld-2.3.5.so)
==21865==by 0x1190887C: (within /lib/ld-2.3.5.so)
==21865==by 0x11904DF3: (within /lib/ld-2.3.5.so)
==21865==by 0x11906612: (within /lib/ld-2.3.5.so)
==21865==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21865==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21865==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21865==by 0x1190EB6F: (within /lib/ld-2

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Geoffrey Keating]

On 23/01/2006, at 6:23 AM, Eric Botcazou wrote:

Attached is a patch to the 4.1 branch, I think it will apply to  
mainline
too. Branch built fine on powerpc-apple-darwin8.4.0 with c,ada  
enabled.




That's not sufficient: the compiler bootstraps fine, but all the  
ACATS tests

fail to link:

gnatlink a22006c.ali
--GCC=/nile.build/botcazou/gnat6/powerpc-apple-darwin8/gcc/
xgcc -B/nile.build/botcazou/gnat6/powerpc-apple-darwin8/gcc/
/usr/bin/ld: warning -L: directory name
(/nile.build/botcazou/gnat6/install_ppc/
lib/gcc/powerpc-apple-darwin8.0.0/4.1.0/adalib/) does not exist
/usr/bin/ld: Undefined symbols:
__Unwind_Resume
__Unwind_ForcedUnwind
__Unwind_GetDataRelBase
__Unwind_GetIP
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
__Unwind_RaiseException
__Unwind_SetGR
__Unwind_SetIP
collect2: ld returned 1 exit status

So, on Darwin, unlike any other platforms, you need to explicitly  
pass either
-static-libgcc or -shared-libgcc to link the EH machinery.  That  
seems weird.


Geoff, any chance to bring Darwin back on par with the other  
platforms?


As I said before in this thread, the Ada driver should do what the C+ 
+ driver does, which is to pass -shared-libgcc if it's going to need  
EH support.  Or, you could pass -fexceptions to the link, which has  
the same effect.


No, it's not possible to let people safely 'just use EH' with no  
extra work.  The issue is compatibility with the various Mac OS X  
versions, including future versions.  Passing -static-libgcc creates  
an executable for which future binary compatibility is not  
guaranteed.  Passing -shared-libgcc creates an executable which will  
not work before 10.3.9 because the library is not there.

smime.p7s
Description: S/MIME cryptographic signature

Re: bootstrap broken on ppc-linux

[Andrew Pinski]

> Yes valgrind works on x86_64.
> The output is not that huge, it is only 17k.
> 
> Attached is the output.
> 
> Thanks,
> Andrew Pinski

Here is the valgrind output for running genautomata, there was two failures.

Thanks,
Andrew Pinski
==21439== Memcheck, a memory error detector.
==21439== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==21439== Using LibVEX rev 1367, a library for dynamic binary translation.
==21439== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==21439== Using valgrind-3.0.1, a dynamic binary instrumentation framework.
==21439== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==21439== For more details, rerun with: -v
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x119106B1: (within /lib/ld-2.3.5.so)
==21439==by 0x11904454: (within /lib/ld-2.3.5.so)
==21439==by 0x11904A9C: (within /lib/ld-2.3.5.so)
==21439==by 0x11902360: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x119104C0: (within /lib/ld-2.3.5.so)
==21439==by 0x11904034: (within /lib/ld-2.3.5.so)
==21439==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21439==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21439==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21439==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x119104CF: (within /lib/ld-2.3.5.so)
==21439==by 0x11904034: (within /lib/ld-2.3.5.so)
==21439==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21439==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21439==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21439==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x119104DE: (within /lib/ld-2.3.5.so)
==21439==by 0x11904034: (within /lib/ld-2.3.5.so)
==21439==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21439==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21439==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21439==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x1191067D: (within /lib/ld-2.3.5.so)
==21439==by 0x11904041: (within /lib/ld-2.3.5.so)
==21439==by 0x1190659E: (within /lib/ld-2.3.5.so)
==21439==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21439==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21439==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x1191067D: (within /lib/ld-2.3.5.so)
==21439==by 0x1190887C: (within /lib/ld-2.3.5.so)
==21439==by 0x11904DF3: (within /lib/ld-2.3.5.so)
==21439==by 0x11906612: (within /lib/ld-2.3.5.so)
==21439==by 0x11900ACA: (within /lib/ld-2.3.5.so)
==21439==by 0x1190B13F: (within /lib/ld-2.3.5.so)
==21439==by 0x11902F06: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x11908F11: (within /lib/ld-2.3.5.so)
==21439==by 0x1190264D: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x11908F51: (within /lib/ld-2.3.5.so)
==21439==by 0x1190264D: (within /lib/ld-2.3.5.so)
==21439==by 0x1190EB6F: (within /lib/ld-2.3.5.so)
==21439==by 0x119014ED: (within /lib/ld-2.3.5.so)
==21439==by 0x11900A37: (within /lib/ld-2.3.5.so)
==21439== 
==21439== Conditional jump or move depends on uninitialised value(s)
==21439==at 0x413CD2: process_insn_equiv_class (genautomata.c:6147)
==21439==by 0x413DB5: process_state_for_insn_equiv_partition 
(genautomata.c:6171)
==21439==by 0x412A29:

Re: bootstrap broken on ppc-linux

[Marcin Dalecki]

On 2006-01-23, at 21:36, Zack Weinberg wrote:


Also, if you have access to valgrind (I can't remember if it works  
on x86-64 yet?)
you could run both programs under it and report what it says, since  
this seems

to be a bad-memory-access issue.


Inside genautomata.c there is a function gen_regexp_el(). It's  
allocating

a regexp_t by calling create_node(). However the code looks like:

  else if (strcmp (str, NOTHING_NAME) == 0)
{
  regexp = create_node (sizeof (struct decl));
  regexp->mode = rm_nothing;
}
  else
{
  regexp = create_node (sizeof (struct decl));
  regexp->mode = rm_unit;
  REGEXP_UNIT (regexp)->name = str;
}

This looks at last dubious.

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Eric Botcazou]

> As I said before in this thread, the Ada driver should do what the C++
> driver does, which is to pass -shared-libgcc if it's going to need
> EH support.  Or, you could pass -fexceptions to the link, which has
> the same effect.

That's not really an option, as Ada links its static runtime by default and 
tries to avoid external dependencies by default.

> No, it's not possible to let people safely 'just use EH' with no
> extra work.  The issue is compatibility with the various Mac OS X
> versions, including future versions.  Passing -static-libgcc creates
> an executable for which future binary compatibility is not
> guaranteed.  Passing -shared-libgcc creates an executable which will
> not work before 10.3.9 because the library is not there.

IIUC, that passing nothing is neither equivalent to -static-libgcc nor to 
-shared-libgcc is a feature, right?  I know Darwin didn't invent it (IIRC 
Linux did) but that's not a valid excuse. :-)  And the "neither -static-libgcc 
not -shared-libgcc" on Darwin is not compatible with the "neither 
-static-libgcc not -shared-libgcc" on Linux.

OK, I guess we have no other solution than defaulting to -static-libgcc for 
Ada on Darwin.

Thanks for your feedback.

-- 
Eric Botcazou

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Geoffrey Keating]

On 23/01/2006, at 1:51 PM, Eric Botcazou wrote:

As I said before in this thread, the Ada driver should do what the  
C++

driver does, which is to pass -shared-libgcc if it's going to need
EH support.  Or, you could pass -fexceptions to the link, which has
the same effect.



That's not really an option, as Ada links its static runtime by  
default and

tries to avoid external dependencies by default.


On systems where it is present, using libgcc is no worse than using  
libSystem.



No, it's not possible to let people safely 'just use EH' with no
extra work.  The issue is compatibility with the various Mac OS X
versions, including future versions.  Passing -static-libgcc creates
an executable for which future binary compatibility is not
guaranteed.  Passing -shared-libgcc creates an executable which will
not work before 10.3.9 because the library is not there.



IIUC, that passing nothing is neither equivalent to -static-libgcc  
nor to
-shared-libgcc is a feature, right?  I know Darwin didn't invent it  
(IIRC
Linux did) but that's not a valid excuse. :-)  And the "neither - 
static-libgcc

not -shared-libgcc" on Darwin is not compatible with the "neither
-static-libgcc not -shared-libgcc" on Linux.


Passing nothing is equivalent to telling the compiler "I want my  
program to run on all versions since 10.1", which means you can't use  
EH at all.


OK, I guess we have no other solution than defaulting to -static- 
libgcc for

Ada on Darwin.


I would rather you defaulted to -shared-libgcc, to avoid creating  
programs that don't run on future versions of Mac OS.  Do you really  
care about being able to create programs that run on 10.2?

smime.p7s
Description: S/MIME cryptographic signature

Re: mudflap extention request

[Frank Ch. Eigler]

Herman ten Brugge <[EMAIL PROTECTED]> writes:

> [...]  Finally the question. Is it possible to add this extension to
> mudflap so the above problem is found here as well.

It is likely possible.

The first one (array embedded in struct, indexed by run-time
expression) is tricky.  There is IIRC no code that specially handles
comparing run-time array indexes with statically-declared bounds.
This would require emitting a new comparison block, likely in addition
to the current pointer-bounds based one.  It may be straightforward,
but it would be new code.

With many tree-ssa optimizations and some subtle tree flag changes
since the original work, some tree-mudflap.c checks have to be
re-tuned to avoid eliding checks (and object registrations) where
still actually necessary.  The second of your two cases you point out
sounds like one that could be detected by just such a tweak.

Similarly, mudflap could exploit some of the clever ssa analysis such
as VRP or alias stuff, which should allow us to elide some checks that
the compiler can prove as unnecessary.

All these just require an interested programmer with some spare time.
(I wish I had enough of the latter.)

- FChE

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

[Eric Botcazou]

> Passing nothing is equivalent to telling the compiler "I want my
> program to run on all versions since 10.1", which means you can't use
> EH at all.

OK, but passing nothing used to just work until 4.0 and works on any other 
platform.  That's what I personally find the most disturbing.

> I would rather you defaulted to -shared-libgcc, to avoid creating
> programs that don't run on future versions of Mac OS.  Do you really
> care about being able to create programs that run on 10.2?

I'm not sure we'd be willing to trade minimal dependencies for "future binary 
compatibility", but I see your point.  I'll let Arnaud decide.

Thanks again.

-- 
Eric Botcazou

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on hppa2.0w-hp-hpux11.00

[Laurent GUERBY]

According to http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01207.html
4.1 was building on hppa2.0w-hp-hpux11.11 as of rev 110094, not very
far from your 110108.

What is your last successful 4.1 build revision on
hppa2.0w-hp-hpux11.00?

Laurent

On Mon, 2006-01-23 at 14:49 +0100, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> stage1/xgcc -Bstage1/
> -
> -B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install/hppa2.0w-hp-hpux11.00/bin/
> - -c -g -O2 -mdisable-indexing -gnatpg -gnata -I- -I. -Iada
> - -I/raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/gcc/ada
> /raid/tecosim/it/devel/projects/develtools/src/gcc-4.1/gcc/ada/ada.ads -o 
> ada/ada.o
> 
> gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
> gmake[2]: *** [ada/ada.o] Error 1
> 
> - --
> 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 Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFD1N7O3s6elE6CYeURAqLnAKCQOGVFYe2O5F8FFex8GiHQILgzXgCfdy4f
> Yki4+zmbY6MJXygtdA07Uco=
> =dxJA
> -END PGP SIGNATURE-
> 

Re: bootstrap failure for Ada gcc 4.1 Revision 110108 on

[John David Anglin]

> > gnat1: out of memory allocating 19028192 bytes after a total of 92324 bytes
> > gmake[2]: *** [ada/ada.o] Error 1

My guess is that this is a problem with the bootstrap compiler.  There
is a known issue with all 3.3 releases that require compiling stage 1
with -O1.  I think there's also a problem with the 4.0 releases.  See
for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24822.  3.4.4
and 3.4.5 seem to be ok based on my testing.   The above error is likely
a garbage collection problem.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: bootstrap broken on ppc-linux

[Richard Henderson]

Got it.


r~



* genextract.c (VEC_safe_set_locstr): Take VEC by reference;
update all callers.

Index: genextract.c
===
--- genextract.c(revision 110129)
+++ genextract.c(working copy)
@@ -187,18 +187,18 @@ gen_insn (rtx insn, int insn_code_number
exist and be NULL, or not yet exist within the vector.  In the latter
case the vector is enlarged as appropriate.  */
 static void
-VEC_safe_set_locstr (VEC(locstr,heap) *v, unsigned int ix, char *str)
+VEC_safe_set_locstr (VEC(locstr,heap) **vp, unsigned int ix, char *str)
 {
-  if (ix < VEC_length (locstr, v))
+  if (ix < VEC_length (locstr, *vp))
 {
-  gcc_assert (VEC_index (locstr, v, ix) == 0);
-  VEC_replace (locstr, v, ix, str);
+  gcc_assert (VEC_index (locstr, *vp, ix) == 0);
+  VEC_replace (locstr, *vp, ix, str);
 }
   else
 {
-  while (ix > VEC_length (locstr, v))
-   VEC_safe_push (locstr,heap, v, 0);
-  VEC_safe_push (locstr,heap, v, str);
+  while (ix > VEC_length (locstr, *vp))
+   VEC_safe_push (locstr, heap, *vp, 0);
+  VEC_safe_push (locstr, heap, *vp, str);
 }
 }
 
@@ -235,13 +235,13 @@ walk_rtx (rtx x, struct accum_extract *a
 
 case MATCH_OPERAND:
 case MATCH_SCRATCH:
-  VEC_safe_set_locstr (acc->oplocs, XINT (x, 0),
+  VEC_safe_set_locstr (&acc->oplocs, XINT (x, 0),
   VEC_char_to_string (acc->pathstr));
   break;
 
 case MATCH_OPERATOR:
 case MATCH_PARALLEL:
-  VEC_safe_set_locstr (acc->oplocs, XINT (x, 0),
+  VEC_safe_set_locstr (&acc->oplocs, XINT (x, 0),
   VEC_char_to_string (acc->pathstr));
 
   base = (code == MATCH_OPERATOR ? '0' : 'a');

cannot find -lm

[Eric Fisher]

Hi,
When I run the test suite on my port, there are many many failures
with the error like this,

ld: cannot find -lm
collect2: ld returned 1 exit status

I'm not sure whether it is the libm(math library), or it is of glibc.
But I guess it is a builtin library of gcc and has nothing to do with
math. Is it right? How can I get it?

Thanks.
Eric.

Re: cannot find -lm

[Eric Christopher]

On Jan 23, 2006, at 5:26 PM, Eric Fisher wrote:


Hi,
When I run the test suite on my port, there are many many failures
with the error like this,

ld: cannot find -lm
collect2: ld returned 1 exit status

I'm not sure whether it is the libm(math library), or it is of glibc.
But I guess it is a builtin library of gcc and has nothing to do with
math. Is it right? How can I get it?


Nope. It means libm.

-eric

Re: cannot find -lm

[Hans-Peter Nilsson]

On Tue, 24 Jan 2006, Eric Fisher wrote:
> ld: cannot find -lm
> collect2: ld returned 1 exit status

> How can I get it?

Port newlib.  It's simple enough.

brgds, H-P

Re: insv vs one-bit fields

[DJ Delorie]

> Write a small test that is supposed to use one of the set-bit insns.
> Verify that it does before and after the patch.

The m68k indeed starts using BFINS with constants in one-bit
bitfields, where it didn't before.  It still uses BFINS for larger
bitfields, as before.  So, it will still function correctly (I checked
the 68020 manual) although it might be less optimal (it's a byte
longer than ORI, not counting the load/stores needed for volatiles)
for non-volatile bitfields.

The ia64 build is still running, but I expect it would do something
similar if it doesn't already have an explicit check for that.

cannot find -lm

[Eric Fisher]

Why so many tests need libm? I don't think the tests really used the
functions of libm. Can I port glibc to get it?

Eirc

Re: cannot find -lm

[Andrew Pinski]

> 
> Why so many tests need libm? I don't think the tests really used the
> functions of libm. Can I port glibc to get it?

Because the tests assume a libc which means a working libm also.

-- Pinski

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

[Shantonu Sen]

I've posted a new version of odcctools (based on Apple's cctools and  
ld64 source) which should fix a few thousand of the failures.  
Instructions are at:




This is based on cctools-590.18 and ld64-26.0.81, which should be  
substantially similar to what you have, and since you can use -- 
prefix, you don't need to overwrite the Apple-provided tools.


Can you report how this changes things?

Shantonu

On Jan 18, 2006, at 9:21 AM, Bradley Lucier wrote:


http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-2006-01-17.gz

(Too large to be accepted here.)

So I have a question.  I've installed the latest Xcode release, or,  
at least I think I did:


[lindv2:gcc/4.1/objdir64] lucier% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure  
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man  
--enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^ 
[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- 
build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- 
target=powerpc-apple-darwin8

Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)
[lindv2:gcc/4.1/objdir64] lucier% ld -v
Apple Computer, Inc. version cctools-590.23.2.obj~17

and I was hoping that this might clear up a significant fraction of  
the 7,000+ 64-bit testsuite failures for 4.1 on powerpc-apple- 
darwin8.4.0.  But it appears this hasn't happened yet.


Does anyone wish to try yet again to drive it into my thick skull  
what goals gcc 4.1 has on powerpc-apple-darwin8.4.0?


(And I still can't seem to use the Apple tools to build 64-bit  
shared libraries that work; but that isn't a problem for this  
list ...)


Brad

Re: insv vs one-bit fields

[DJ Delorie]

> The ia64 build is still running, but I expect it would do something
> similar if it doesn't already have an explicit check for that.

Ok, I can't really read ia64 assembler.  Before:

.global f01#
.proc f01#
f01:
.prologue
.body
.mmi
addl r15 = @ltoffx(a#), r1
;;
ld8.mov r15 = [r15], a#
nop 0
;;
.mmi
ld1.acq r14 = [r15]
;;
or r14 = 1, r14
nop 0
;;
.mib
st1.rel [r15] = r14
nop 0
br.ret.sptk.many b0
.endp f01#


after:
.global f01#
.proc f01#
f01:
.prologue
.body
.mmi
addl r14 = @ltoffx(a#), r1
nop 0
addl r16 = 1, r0
;;
.mmi
ld8.mov r14 = [r14], a#
;;
ld1.acq r15 = [r14]
nop 0
;;
.mii
nop 0
dep r15 = r16, r15, 0, 1
;;
nop 0
.mmb
st1.rel [r14] = r15
nop 0
br.ret.sptk.many b0
.endp f01#

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 03:46:10PM -0800, Richard Henderson wrote:
> Got it.

Looks good to me.  (Argh, I thought I had caught all of the places where
I made that mistake.)  Are you going to check it in?

And here's the fix for genautomata, which had two bugs.  One was a
simple case of assuming that an array got entirely initialized when
it didn't.  The other is actually a latent vec.h bug.  DEF_VEC_ALLOC_I
reused the _p out-of-line allocation functions, which assume the element
size == sizeof(void *).  For smaller integral types, that just wastes
memory; but if HOST_WIDE_INT is 64 bits, pointers are 32, and you ask
for a VEC of HOST_WIDE_INT, you get half as much memory as you need.
genautomata, of course, is very fond of its VECs of HOST_WIDE_INT
(aka vect_el_t).

Thanks to Andrew Pinski for helping me debug.

This is close to obvious and should fix bootstrap, but I am hesitant
to call anything about vec.h obvious.  Nathan cc:ed.

zw

* genautomata.c (process_state_for_insn_equiv_partition):
Use xcalloc for insn_arcs_array.
* vec.h (DEF_VEC_ALLOC_FUNC_I): New set of templates.
(DEF_VEC_ALLOC_I): Use it, not DEF_VEC_ALLOC_FUNC_P.

==
--- genautomata.c   (revision 110196)
+++ genautomata.c   (local)
@@ -6162,7 +6162,7 @@ static void
 process_state_for_insn_equiv_partition (state_t state)
 {
   arc_t arc;
-  arc_t *insn_arcs_array = xmalloc (description->insns_num * sizeof(arc_t));
+  arc_t *insn_arcs_array = xcalloc (description->insns_num, sizeof(arc_t));
 
   /* Process insns of the arcs.  */
   for (arc = first_out_arc (state); arc != NULL; arc = next_out_arc (arc))
==
--- vec.h   (revision 110196)
+++ vec.h   (local)
@@ -479,7 +479,7 @@ DEF_VEC_FUNC_P(T)   
  \
 struct vec_swallow_trailing_semi
 #define DEF_VEC_ALLOC_I(T,A) \
 VEC_TA_GTY(T,base,A,);   \
-DEF_VEC_ALLOC_FUNC_P(T,A)\
+DEF_VEC_ALLOC_FUNC_I(T,A)\
 struct vec_swallow_trailing_semi
 #endif
 
@@ -1032,4 +1032,89 @@ static inline T *VEC_OP (T,A,safe_insert
   return VEC_OP (T,base,quick_insert) (VEC_BASE(*vec_), ix_, obj_\
   VEC_CHECK_PASS);   \
 }
+
+#define DEF_VEC_ALLOC_FUNC_I(T,A)\
+static inline VEC(T,A) *VEC_OP (T,A,alloc)   \
+ (int alloc_ MEM_STAT_DECL)
  \
+{\
+  /* We must request exact size allocation, hence the negation.  */  \
+  return (VEC(T,A) *) vec_##A##_o_reserve (NULL, -alloc_,\
+   offsetof (VEC(T,A),base.vec),  \
+  sizeof (T) \
+   PASS_MEM_STAT);   \
+}\
+ \
+static inline VEC(T,A) *VEC_OP (T,A,copy) (VEC(T,base) *vec_ MEM_STAT_DECL) \
+{\
+  size_t len_ = vec_ ? vec_->num : 0;\
+  VEC (T,A) *new_vec_ = NULL;\
+ \
+  if (len_)  \
+{\
+  /* We must request exact size allocation, hence the negation. */   \
+  new_vec_ = (VEC (T,A) *)(vec_##A##_o_reserve   \
+  (NULL, -len_,  \
+   offsetof (VEC(T,A),base.vec), sizeof (T)  \
+   PASS_MEM_STAT));  \
+ \
+  new_vec_->base.num = len_; \
+  memcpy (new_vec_->base.vec, vec_->vec, sizeof (T) * len_); \
+}\
+  return new_vec_;   \
+}\
+ \
+static inline void VEC_OP (T,A,free) \
+ (VEC(T,A) **vec_)   \
+{   

Re: bootstrap broken on ppc-linux

[Zack Weinberg]

On Mon, Jan 23, 2006 at 10:39:19PM +0100, Marcin Dalecki wrote:
> 
> Inside genautomata.c there is a function gen_regexp_el(). It's  
> allocating
> a regexp_t by calling create_node(). However the code looks like:
> 
>   else if (strcmp (str, NOTHING_NAME) == 0)
> {
>   regexp = create_node (sizeof (struct decl));
>   regexp->mode = rm_nothing;
> }
>   else
> {
>   regexp = create_node (sizeof (struct decl));
>   regexp->mode = rm_unit;
>   REGEXP_UNIT (regexp)->name = str;
> }
> 
> This looks at last dubious.

I'm not seeing the problem.  Could you explain a bit more? (The
instant problem is something else, but I could easily believe
there's a bug here too.)

Next Level Optimization.

[Peter Dolding]

Code of Gcc is getting cleaner.

Gcc is used with avr chips and more systems are going embeded.

I have code for basic to c that does Optimization in a different way.  
It calls the function replaced the call with the resualts.


Ok it can only do this if the function returns predictable out comes.  
Ie the same return from the same args in.


All Optimization up to this point don't to anything to optimize the 
calls to dlls and static libs.


Ok one stupid example
In the lib

int sqr(int x) {
return x*x;
}

In application
int main() {
int x =5
printf("The square %i is %i\n",x,sqr(x));
}

Note nothing will optimize down.

And  with once off function calling with permitted functions in theory.  
Printf would be replace with sprintf to get its new output and require 
minor filtering.


int main() {
printf("The square 5 is 25\n");
}

Their is another to somewhere near this end is to add a optimizer to the 
linker something the binutils linker has never had  ssa has been added 
to gcc but nothing like this is in the ld of binutils.  The SSA 
optimizations on the machine code I don't think it can be done maybe on 
the objs with attachment infomation to C files? Can it be done I guess 
that would be harder than dynamic linking to constant functions.


There would have to be opt files or something equal to tell gcc what to 
do and a new flag to say that the function can be optimized out.  
__optimizeout(theopt.opt)__ int sqr( int x);  This is different to 
Inline.  Number one if it cannot optimize out it calls the dll/so.  
Keeping code size to a min and speed high.  Maybe a different form of 
Inline could be used.  Yes I know this would be a slower build but 
faster and smaller code can be worth it.


Peter Dolding