Re: GCC 4.5 is uncompilable
Matt wrote: > Hey Dave, > > What OS are you bootstrapping on, and with which compiler/version? > (Cygwin, I assume, but you never know ;>) Yep, Cygwin native using 4.3.4 as bootstrap compiler. > I haven't been able to bootstrap for a few weeks, but no one answered my > email for help (which probably got lost in the kernel-related fighting): rofl Linus is such a git! I didn't notice his apology for having screwed up so badly and flamed everyone over nothing, did you? > http://gcc.gnu.org/ml/gcc/2009-11/msg00476.html > > The code in question definitely looks like the uninitialized warning > (reported as error) is valid. I'm surprised no one else has been seeing > this, unless they aren't bootstrapping using 4.4.1 or above. Like I said, 4.3.4 (and occasionally I bootstrap HEAD with itself), but this is one of those areas where false positives/negatives come and go. > Any help is appreciated -- I really want to get cracking on testing 4.5. I read the code in ira-lives.c; it is very clearly not used uninitialised, so this is undoubtedly a bug in your bootstrap compiler. File a PR, reconfigure your tree using --disable-werror, and off you go. cheers, DaveK
Re: i370 port - constructing compile script
gcov-iov creates a gcov-iov.h which has a version number which changes when I change MVS versions. So I am thinking of updating gcov-iov.c so that when the target is MVS, it generates a more fixed format. I don't see how the generated number depends on the MVS version ... It is supposed to depend solely on the *GCC* version string of the compiler currently being built. Mostly yes. However, it still grabs the full version string, which includes the text "MVS 0.X" (which I added, to identify the sub-version of 3.4.6 on MVS (note that for 3.2.3 I am up to MVS 7.6 there's been so much activity). And basically I don't want that GCOV header file to change between MVS releases. Anyway, in the build scripts (ie outside the normal configure/make process, so no-one needs to see it) I just overwrite the header, and I didn't notice any ill-effect. gengtype-yacc.c & .h gets created with my new version of bison. I just want to use the one that came with 3.4.6 instead of having it regenerated. Do I need to hide my bison to stop that from happening? Well, it's just a make step -- the files will get rebuilt if and only if the gengtype-yacc.y file is more recent than the gengtype-yacc.c and .h files. In the default 3.4.6 tarball this is not the case. Did you somehow modify file timestamps while unpacking / copying the files? Yes, I imported everything into CVS and that presumably changed all the timestamps. I wasn't aware of that. Anyway, I got around that problem by making dummy changes to the .c and .h and then reversing them out. So that is fixed now, thanks. gencheck.h is being generated as an empty file, which doesn't work well on some environments. I want it to at least have a comment saying "/* empty file */". I can put that in as part of the build script too. Well, adding a comment should be trivial at the place in the Makefile.in where gencheck.h is generated (s-gencheck). Ok, I decided it was better to keep it outside the common files. In any case, more recent GCC versions no longer refer to this file at all. And I don't even need to revisit that decision for GCC 4 it seems. :-) So I've basically finished doing what I wanted for 3.4.6 now. I'm not going to spend time doing niceties like putting the generated files generation onto MVS so that mainframe users can upgrade the machine definition without needing a non-MVS machine. I have that nicety already for 3.2.3 and I may look into it again for 4.x. There's still one last thing for 3.4.6, although it's not really 3.4.6, I'm doing it for 3.2.3, but will have to incorporate that change into 3.4.6. And that thing is the MUSIC/SP port. I have managed to get dynamic allocation to work, which changes the whole look of the port, so I'm working through that, which I expect will take a couple of weeks. So that will be 3 nicely-working EBCDIC platforms. 4 if you count USS, but I don't use or test that, so don't know whether it works there currently. I should be starting the GCC 4 port in a matter of days, while using my Unix machine. Thanks everyone for helping get it to this point. BFN. Paul.
Impressively difficult to compile code for GNAT
Hello. I'm working on a small project to create an abstraction over directories and archives. I've managed to write some code that seems simple enough (using tagged limited types) and even though the code appears to be valid, it seems to either trigger bugs in the runtime (causing crashes on execution) or fails to compile: Both Debian GCC 4.3, GNAT GPL 2009 and FreeBSD GCC 4.4 fail with the following: pfseudo-archiver-directory.adb:24:41: wrong type for return_subtype_indication pfseudo-archiver-directory.adb:46:35: wrong type for return_subtype_indication GCC SVN (r154285) fails to build with a strange error: arc_dir_003.adb:25:32: "_master" conflicts with declaration at line 21 The output of -gnatG shows this error to be apparently incorrect: error := false; B_1 : declare _master : constant integer := system__soft_links__current_master.all; A6bM : integer renames _master; type A6b is access all pfseudo__archiver__Tarchive_tC; R7b : A6b := pfseudo__archiver__directory. The code is available here: http://git.coreland.ath.cx/gitweb.cgi?p=pfseudo/.git;a=summary $ git clone http://git.coreland.ath.cx/pfseudo/.git Configure and build with: $ echo 'gcc' > conf-adacomp $ echo 'gnatbind' > conf-adabind $ echo 'gnatlink' > conf-adalink $ make $ make tests Regards, M
Re: Impressively difficult to compile code for GNAT
Here's another case from a prototype that causes a crash on GCC 4.4 but, ironically, gives every impression of compiling and running on earlier versions (4.3, GPL 2009): with Ada.Streams.Stream_IO; with Ada.Finalization; package Archiver is type Archiver_t is tagged limited private; type Archive_t is tagged limited private; function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access; private package Stream_IO renames Ada.Streams.Stream_IO; type Archiver_t is tagged limited null record; type Archive_t is new Ada.Finalization.Limited_Controlled with record Name : access String; File : Stream_IO.File_Type; end record; end Archiver; package body Archiver is function Open_Archive (Archiver : in Archiver_t; Path : in String) return Archive_t'Class is pragma Unreferenced (Archiver); begin -- This line causes a segmentation fault. return A : Archive_t'Class := Archive_t'(Ada.Finalization.Limited_Controlled with others => <>) do A.Name := new String'(Path); Stream_IO.Open (Name => A.Name.all, File => A.File, Mode => Stream_IO.In_File); end return; end Open_Archive; function Stream (Archive : in Archive_t) return Ada.Streams.Stream_IO.Stream_Access is begin return Stream_IO.Stream (Archive.File); end Stream; end Archiver; with Ada.Text_IO; with Ada.Streams.Stream_IO; with Archiver; procedure Main is A : Archiver.Archiver_t; S : constant Ada.Streams.Stream_IO.Stream_Access := Archiver.Stream (Archiver.Open_Archive (A, "file.zip")); X : Integer; begin X := Integer'Input (S); Ada.Text_IO.Put_Line (Integer'Image (X)); end Main;
Re: Impressively difficult to compile code for GNAT
By the way, a general note is that it is usually a good idea to stay away from anonymous access types, since for one thing, there are real issues in freeing them.
How does builtin_sqrt get used - or not
I am tracking test failure with avr target where function sqrtf is undefined reference at link time. Here is command line: /media/verbatim/gcchead/obj-dir/gcc/xgcc -B/media/verbatim/gcchead/obj-dir/gcc/ /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.dg/pr41963.c -O2 -ffast-math -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -DSIGNAL_SUPPRESS -mmcu=atmega128 /home/andy/winavrfiles/avrtest/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o pr41963.exe I am lead to believe that gcc might use builtin_sqrtf rather than sqrtf(). I am successfully using fabsf() - with no link errors. Is their any target configuration needed for builtin_sqrtf that I should know about ? Andy
Re: i370 port - constructing compile script
On 11/13/2009 12:43 PM, Paul Edwards wrote: I normally define PREFIX in a common header file. However, this caused a conflict between prefix.c and regex.c which both try to use this keyword. regex.c is forked from anything else, so I don't think a patch changing PREFIX to FUNC_PREFIX will have any objection. Paolo
Re: i370 port - constructing compile script
On 11/14/2009 12:27 PM, Paul Edwards wrote: So what I have done is get the compiler to fail on any missing prototype. I think perhaps we need to have a generic gcc or autoconfigure option called "config by prototype". MVS is just one instance where you might wish to do it this way. Other ports in their infancy may not have working cross-assemblers and linkers either. It worked out quite well. -Wimplicit -Werror? Paolo
Re: How does builtin_sqrt get used - or not
Andrew Hutchinson writes: > I am tracking test failure with avr target where function sqrtf is > undefined reference at link time. > > Here is command line: > > /media/verbatim/gcchead/obj-dir/gcc/xgcc > -B/media/verbatim/gcchead/obj-dir/gcc/ > /media/verbatim/gcchead/trunk/gcc/testsuite/gcc.dg/pr41963.c -O2 > -ffast-math -DSTACK_SIZE=2048 -DNO_TRAMPOLINES -DSIGNAL_SUPPRESS > -mmcu=atmega128 /home/andy/winavrfiles/avrtest/dejagnuboards/exit.c > -Wl,-u,vfprintf -lprintf_flt > -Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o pr41963.exe > > I am lead to believe that gcc might use builtin_sqrtf rather than > sqrtf(). I am successfully using fabsf() - with no link errors. > > Is their any target configuration needed for builtin_sqrtf that I > should know about ? If your target does not define a sqrtsf2 insn, then using builtin_sqrtf won't make any difference; gcc will still call the libc's sqrtf function. Ian
Re: Impressively difficult to compile code for GNAT
On 2009-11-21 12:09:11, Robert Dewar wrote: > By the way, a general note is that it is usually a good > idea to stay away from anonymous access types, since > for one thing, there are real issues in freeing them. Agreed, yes. In the real project, the String_Access types from the unbounded strings package was used. Regards, Mark
Re: Impressively difficult to compile code for GNAT
Bug filed here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42140
