Bug#452110: gcc-4.2 generates bad code on alpha
Aurelien Jarno a écrit :
> Aurelien Jarno a écrit :
>> Falk Hueffner a écrit :
>>> Hi,
>> Hi,
>>
>>> I'd be willing to take a look if there is a small testcase (i.e. a
>>> single C file which when compiled and run will either succeed or
>>> fail). Anybody willing to create such a testcase?
>>>
>> I have started to work on that, but unfortunately I haven't found time
>> to get very far, all that I know is that it happens when calling
>> db_open(), but the problem is actually in the glibc code.
>>
>
> I have made some progress, I have reduced the testcase to a simple C
> code, but that still uses glibc functions:
>
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
>
>
> int main() {
> int fd;
> int ret;
>
> fd = open("test.txt", O_CREAT);
> ret = fdatasync(fd);
> printf("ret: %i\n",ret);
> close(fd);
>
> return 0;
> }
>
> fdatasync() behaves differently on a glibc built with gcc 4.2.1-5 and
> with gcc 4.2.2-3.
>
I have finally found the problem. It is actually not a gcc bug. There is
one more difference between the two builds that I haven't seen before,
linux-libc-dev is available in different versions. And the newer version
has in /usr/include/asm/unistd.h:
#define __NR_fdatasync 447
The problem therefore lies in the glibc, we should define a fallback
when the syscall is not available.
I am therefore closing this bug, leaving the one opened on the glibc opened.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: