VRPC RISC OS 4.39
gcc (GCC) 4.1.1 (GCCSDK GCC 4.1.1 Prerelease 1)
I've recompiled and tested most of my C and C++ programs with GCC 4.1.1
prerelease 1 and on the whole things have gone fairly smoothly. It's
particularly nice to have some smaller executables. Many thanks to
everyone involved in the development process - your work is much
appreciated.
Here's a miscellaneous list of outstanding issues and comments:
1) I have what I think is an array alignment problem due to a cast from
char* to int*, which I've condensed to the following code (it arose
in one of the standard 'gawk' 3.1.6 test cases):
main.c:
#include <stdio.h>
void zzz(char *ccc) {
int *bbb = (int *) ccc;
bbb[0] = 1;
printf("bbb[0] %i\n",bbb[0]);
printf("bbb[0] %i\n",bbb[0]);
}
void yyy();
int main() {
yyy();
return 0;
}
zzzzz.c:
void mmm() {
static short nnn = 0;
nnn = 1;
}
void zzz (char *ccc);
static char aaa[256];
void yyy() {
zzz(aaa);
}
*gcc -mthrowback -Wall -Wextra main.c zzzzz.c -o ggg
*ggg
bbb[0] 65536
bbb[0] 65536
*gcc -mthrowback -O2 -Wall -Wextra main.c zzzzz.c -o ggg
*ggg
bbb[0] 1
bbb[0] 65536
With the unused mmm() function removed I get what I would expect
with either optimisation level:
bbb[0] 1
bbb[0] 1
Adusting bbb to a multiple of 4 also fixes the problem.
The original 'gawk' test case gave correct results with gcc 3 (i.e.
it agreed with the test output supplied with gawk). I haven't tried
the above condensed version with gcc 3.
I suspect this is a bug - or should I be using some compiler
alignment option?
2) When I compile bzip2 with -D_FILE_OFFSET_BITS=64, for large file
support, I get error messages like this when linking:
bzip2.o: In function `cleanUpAndFail':
bzip2.c:(.text+0x554): undefined reference to `stat64'
(It links OK if I don't use _FILE_OFFSET_BITS.)
This linked OK with gcc 3 and _FILE_OFFSET_BITS=64 (whether it
actually worked with large files, greater than 4 gigabytes, I've no
idea).
Should I expect this to link or not?
3) The '.' character is not handled properly in library names:
*gcc -o test test.o libTEST.a
gcc: libTEST/a: No such file or directory
This didn't work on earlier versions either.
4) I'm not sure how closely the symbolic link system is intended to
reflect that on Unix systems. I note that:
1) Member st_mode of struct stat does not recognise symbolic links.
2) If I execute a symbolic link file from a C program, argv[0],
UnixEnv$$nonametrans etc are set for the target file rather than
the link.
5) 'make' is no longer included with !GCC. For new users, some
indication in the documentation of where to obtain 'make' may be
useful.
6) Could 'd' be added to sfix in !GCC.!Run - its for dependency files.
Merry Christmas
Duncan Moore
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
