Menu
▾
▴
linuxsh-dev
|
From: Bao C. H. <ba...@se...> - 2001-08-13 18:33:50
|
I am having problems with the following code. It works fine
in an x86 system. The problem is at the minus sign of the
datum. The scanf is doing something weird. Changing "%f"
to "%lf" in the scanf statement makes it work again.
==== test.c =====
[bao@build bao]$ cat test.c
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
FILE *fptr;
float dum;
int status;
fptr=fopen("./DATA", "r");
while (!feof(fptr)){
status = fscanf(fptr,"%f", &dum);
printf("\n status=%x\n", (int)status);
if (status)
printf("\n dum=%f\n", dum);
}
}
[bao@build bao]$ sh4-linux-gcc test.c -o test
=== Output of test ===
[root@mgatebao /root]# ./test
status=1
dum=0.000000
status=1
dum=0.951057
status=1
dum=0.587785
status=%x
dum=%f
|AGNUÿÿÿÿÿÿÿÿ¨A¼@Ø@ô@@,@H@d@M¬
À@ä@D@ @@
±
ATÔ@þÿÿo´@ÿÿÿoðÿÿo @GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
2000112
0
(experimental).symtab.strtab.shstrtab.interp.hash.dynsym.dynstr.gnu.version.
gn
u.version_r.rela.plt.init.plt.text.fini.rodata.data.note.ABI-tag.ctors.dtors
.got
.dynamic.sbss.bss.commentô<)
D@D 1ä@ä»9ÿÿÿo @ Fþÿÿo´@´ UÔ@ÔT
_@@@V
e@àj@@
@LÀ@À6 v0§ô@D@ä@ @´@Ô@@@xA A@¨A¨®AA¹öF Âð
À@
ø@
PApAxAA¨AAAñÿAñÿñÿñÿñÿñÿñÿÊ°@
Segmentation fault
=== Input: DATA ===
[root@mgatebao /root]# cat DATA
0.0000000e+000
9.5105652e-001
+5.8778525e-001
-9.5105652e-001
==================
Appreciate any suggestions/comments.
Thanks.
Bao
|
|
From: kaz K. <kk...@rr...> - 2001-08-13 23:36:10
|
"Bao C. Ha" <ba...@se...> wrote: > I am having problems with the following code. It works fine > in an x86 system. The problem is at the minus sign of the > datum. The scanf is doing something weird. Changing "%f" > to "%lf" in the scanf statement makes it work again. I can't reproduce your problem on my platforms. It works with gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though my environment will differ from yours in libraries. Which version of glibc are you using? If it was compiled by yourself, which gcc was used for? kaz |
|
From: M. R. B. <mr...@0x...> - 2001-08-13 23:55:47
|
* kaz Kojima <kk...@rr...> on Tue, Aug 14, 2001: > > I can't reproduce your problem on my platforms. It works with > gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though > my environment will differ from yours in libraries. > Which version of glibc are you using? If it was compiled by > yourself, which gcc was used for? > Hmm, you got broken gcc-3.1 to build? How? Mine bricks when building libgcc (internal compiler error in flow.c). M. R. |
|
From: kaz K. <kk...@rr...> - 2001-08-14 02:17:06
|
"M. R. Brown" <mr...@0x...> wrote: >> I can't reproduce your problem on my platforms. It works with >> gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though >> my environment will differ from yours in libraries. >> Which version of glibc are you using? If it was compiled by >> yourself, which gcc was used for? >> > > Hmm, you got broken gcc-3.1 to build? How? Mine bricks when building > libgcc (internal compiler error in flow.c). I'll put the patch for current cvs http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010814.diff http://dodo.nurs.or.jp/~kkojima/gnu-on-sh/gcc-cvs-010515-2add.tar.gz though it's really broken. The regression test by make check for stage1 compiler reports only 3 non essential FAILs, but gcc doesn't bootstrap. The stage2 compiler can't compile any program. It seems that there is a weird bug which happens only for big funtions, at least, in SH. This is too bad. So the patch is only for reference. Never use it for the real work. I'd like to report again about the status of gcc. GCC-3.0 seems to be fairly stable and almost essential compiler patches are sent to the GCC mailing list. Some of them are reviewed already and some patches waiting to review. You can see our 3.0 patch is still big. Almost of them are the configury patches for the non-multilib configurations such sh3-unknown-linux-gnu. Niibe-san sent it to the GCC mailing list already. This part was the target of arguments, repeatedly. We tried first to fix config.sub which is the root of such configury, but many people usually think that four (i.e. sh[34](eb)) is "too many". The change of config.sub is approved and the argument is continued about the configury problem in GCC mailing list. There are some ad hoc ones in our 3.0 patch, which will be never sent main stream. They are not the Right Thing or solved by the complete other way in 3.1. The former cases are wired. For example, some correct SH specific part added in 3.0 are reverted. This is totally wrong, but if not to do so, gcc-3.0 stage 3 compiler will die. Such part is correct itself but reveals the another dark problem. Unfortunately, I couldn't even make an appropriate testcase. Anyways, I don't think gcc-3.0 is more stable than 20001120 version or Abe-san's version. Yes, gcc-3.x has many attractive features, but don't forget it isn't so stable even for x86. kaz |
|
From: M. R. B. <mr...@0x...> - 2001-08-14 03:15:44
|
* kaz Kojima <kk...@rr...> on Tue, Aug 14, 2001: > > I'd like to report again about the status of gcc. > GCC-3.0 seems to be fairly stable and almost essential compiler patches > are sent to the GCC mailing list. Some of them are reviewed already > and some patches waiting to review. You can see our 3.0 patch is still > big. Almost of them are the configury patches for the non-multilib > configurations such sh3-unknown-linux-gnu. Niibe-san sent it to the GCC > mailing list already. This part was the target of arguments, repeatedly. > We tried first to fix config.sub which is the root of such configury, > but many people usually think that four (i.e. sh[34](eb)) is "too many". > The change of config.sub is approved and the argument is continued about > the configury problem in GCC mailing list. > Well, I've been working on my own solution to this problem, but I'm afraid I agree with the others for sh-unknown-linux-gnu, and the removal of multilib for the Linux target. My fix consists of some new config.sub targets, but not of the "eb,el" variety since that wouldn't allow you to do sh3e* as it would conflict with sh3el or sh3eb. Also, I've made some changes to sh.h to try to enable the "sh[1-4][bl]e" to work on all sh targets, not just Linux. I'll try to clean up what I have and send it here for review. Nahh, I don't think that's too many, have you seen the entries for ARM and MIPS (not to mention ix86)? Ugh. > There are some ad hoc ones in our 3.0 patch, which will be never sent > main stream. They are not the Right Thing or solved by the complete > other way in 3.1. The former cases are wired. For example, some correct > SH specific part added in 3.0 are reverted. This is totally wrong, but > if not to do so, gcc-3.0 stage 3 compiler will die. Such part is correct > itself but reveals the another dark problem. Unfortunately, I couldn't > even make an appropriate testcase. > Anyways, I don't think gcc-3.0 is more stable than 20001120 version or > Abe-san's version. > Yes, gcc-3.x has many attractive features, but don't forget it isn't so > stable even for x86. > Wow, thanks for the info, I've been using the patches on your page for awhile, but never really knew the reasons/motivation for them. M. R. |
|
From: Bao C. H. <ba...@se...> - 2001-08-14 01:08:55
|
gcc-2.97 libc-2.2.2.so kernel 2.4.5 Thanks. Bao > -----Original Message----- > From: lin...@li... > [mailto:lin...@li...]On Behalf Of > kaz Kojima > Sent: Monday, August 13, 2001 4:41 PM > To: lin...@li... > Subject: [linuxsh-dev] Re: Floating point problem > > > "Bao C. Ha" <ba...@se...> wrote: > > I am having problems with the following code. It works fine > > in an x86 system. The problem is at the minus sign of the > > datum. The scanf is doing something weird. Changing "%f" > > to "%lf" in the scanf statement makes it work again. > > I can't reproduce your problem on my platforms. It works with > gcc-2.97(20001120), gcc-3.0 and even broken gcc-3.1, though > my environment will differ from yours in libraries. > Which version of glibc are you using? If it was compiled by > yourself, which gcc was used for? > > kaz > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev > |
|
From: kaz K. <kk...@rr...> - 2001-08-14 02:33:09
|
"Bao C. Ha" <ba...@se...> wrote: > gcc-2.97 > libc-2.2.2.so > kernel 2.4.5 Hmm... It looks like the standard set. Does anyone see the same problem? kaz |
|
From: Stuart M. <Stu...@st...> - 2001-08-14 23:05:25
|
Yep, I see the same problem here. This is using the RPMS from SourceForge: gcc 2.97 (20001120 + patches) glibc 2.2.2 kernel 2.4.7-pre6 basically the same set. One other oddity, the garbage which is printed at the end doesn't occur when output is redirected to a file, however the floating point values print as 0.00000 rather than the negative number. Strange Stuart On Aug 14, 11:38am, kk...@rr... wrote: > Subject: [linuxsh-dev] Re: Floating point problem > "Bao C. Ha" <ba...@se...> wrote: > > gcc-2.97 > > libc-2.2.2.so > > kernel 2.4.5 > > Hmm... It looks like the standard set. Does anyone see the same > problem? > > kaz > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev > > >-- End of excerpt from kk...@rr... |
|
From: kaz K. <kk...@rr...> - 2001-08-15 13:12:16
|
Stuart Menefy <Stu...@st...> wrote: > Yep, I see the same problem here. > > This is using the RPMS from SourceForge: > gcc 2.97 (20001120 + patches) > glibc 2.2.2 > kernel 2.4.7-pre6 > basically the same set. > > One other oddity, the garbage which is printed at the end doesn't occur > when output is redirected to a file, however the floating point values > print as 0.00000 rather than the negative number. > > Strange Indeed. One possibility is the problem on changing double/float mode of SH-4 FPU. Is the result same with the option -O2 or -static? I suspect that the wrong FPU mode gives such curious behavior. kaz |
|
From: Bao C. H. <ba...@se...> - 2001-08-16 01:04:28
|
-static works
-O2 does not work (crash!)
Following is a gdb session when it crashes. Note the
"correct" values of dum = -0.95105654 and status = 1!
Breakpoint 1, main () at test.c:13
13 status = fscanf(fptr,"%f", &dum);
(gdb) n
14 printf("\n status=%x\n", (int)status);
(gdb) print dum
$3 = -0.95105654
(gdb) print status
$4 = 1
(gdb) n
status=%x
dum=%f
|AGNUyyyyyyyy?AU@o@@0@L@h@"@U.Y?
A@o@H@ `@
1
?AT@o@
?yyoO@yyyo?yyo?@GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU)
2.97 2
0001120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)?@""-main?@?@test.c/scratch/hotspare/home/baoGNU C 2.97
200011
20 (experimental)?quot?#rem?long long inN__valM?#AAunsigned intint
__sched_paramE__sched_priorityFN# M_pthread_fastlock
I am actually glad that somebody else besides us also sees the
problem.
Thanks.
Bao
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Wednesday, August 15, 2001 6:17 AM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> Stuart Menefy <Stu...@st...> wrote:
> > Yep, I see the same problem here.
> >
> > This is using the RPMS from SourceForge:
> > gcc 2.97 (20001120 + patches)
> > glibc 2.2.2
> > kernel 2.4.7-pre6
> > basically the same set.
> >
> > One other oddity, the garbage which is printed at the end
> doesn't occur
> > when output is redirected to a file, however the floating
> point values
> > print as 0.00000 rather than the negative number.
> >
> > Strange
>
> Indeed.
>
> One possibility is the problem on changing double/float mode of SH-4
> FPU. Is the result same with the option -O2 or -static? I suspect that
> the wrong FPU mode gives such curious behavior.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-08-16 03:04:02
|
"Bao C. Ha" <ba...@se...> wrote:
> -static works
> -O2 does not work (crash!)
>
> Following is a gdb session when it crashes. Note the
> "correct" values of dum = -0.95105654 and status = 1!
>
> Breakpoint 1, main () at test.c:13
> 13 status = fscanf(fptr,"%f", &dum);
> (gdb) n
> 14 printf("\n status=%x\n", (int)status);
> (gdb) print dum
> $3 = -0.95105654
> (gdb) print status
> $4 = 1
Can you please check the result of the following gdb commands at this
point?
(gdb) set archi sh4
(gdb) p/x $fpscr
If you don't get 0x8xxxx as the value of fpscr register, the cause of
the crash will be the wrong mode of FPU.
kaz
|
|
From: Bao C. H. <ba...@se...> - 2001-08-16 16:59:47
|
(gdb) n
14 printf("\n status=%x\n", (int)status);
(gdb) set archi sh4
The target architecture is assumed to be sh4
(gdb) p/x $fpscr
$2 = 0x3f737871
(gdb) n
status=%x
dum=%f
......
CRASHED!!!
So it is the wrong FPU mode. How do we fix it?
Thanks.
Bao
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Wednesday, August 15, 2001 8:04 PM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> "Bao C. Ha" <ba...@se...> wrote:
> > -static works
> > -O2 does not work (crash!)
> >
> > Following is a gdb session when it crashes. Note the
> > "correct" values of dum = -0.95105654 and status = 1!
> >
> > Breakpoint 1, main () at test.c:13
> > 13 status = fscanf(fptr,"%f", &dum);
> > (gdb) n
> > 14 printf("\n status=%x\n", (int)status);
> > (gdb) print dum
> > $3 = -0.95105654
> > (gdb) print status
> > $4 = 1
>
> Can you please check the result of the following gdb commands at this
> point?
>
> (gdb) set archi sh4
> (gdb) p/x $fpscr
>
> If you don't get 0x8xxxx as the value of fpscr register, the cause of
> the crash will be the wrong mode of FPU.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-08-17 00:42:36
|
"Bao C. Ha" <ba...@se...> wrote:
> (gdb) n
> 14 printf("\n status=%x\n", (int)status);
> (gdb) set archi sh4
> The target architecture is assumed to be sh4
> (gdb) p/x $fpscr
> $2 = 0x3f737871
> (gdb) n
>
> status=%x
>
> dum=%f
> ......
> CRASHED!!!
>
> So it is the wrong FPU mode. How do we fix it?
Before going ahead, please try
(gdb) p/x $fpscr=0x80004
(gdb) c
instead of p/x $fpscr to confirm the problem. If it works,
the problem must be caused by $fpscr. If this is the case,
I think that the real problem is the __fpscr_values table
in your shared libraries.
The $fpscr value problem is a long standing problem. As you
know, SH-4 FPU has no individual instructions to handle float
and double, but a mode flags in $fpscr. So the mixture of
the float and double arithmetic needs the wierd switching of
$fpscr value. So, an easiest and only one easy workaround is
to use double only :-)
GCC uses __fpscr_values for this switching. This table is
the array of 32-bit words and __fpscr_values[0] is the value
for float and __fpscr_values[1] is for double. The switchig
is done by the load from these values to $fpscr. There are
versions of compiler have problems in this switching, though
this is not the case in current problem since there is no
problem with static linking.
This __fpscr_values table is in libgcc.a and defined as .comm
symbol originally. But this is not suitable for the shared
library. The __fpscr_values table is writable to set rounding
and floating exception mode, so it must be the unique entity.
The Right Thing is to put it in the shared libgcc like as
we've done it in our gcc-3.0 patch. So the 2nd workaround is
to use gcc-3.0 + our SH patch and rebuild all libraries using
it. But it isn't so easy and will cause another problems.
kaz
|
|
From: Bao C. H. <ba...@se...> - 2001-08-17 02:41:50
|
It still crashed when $fpscr was set to 0x80004
(gdb) p/x $fpscr=0x80004
$2 = 0x80004
(gdb) p/x $fpscr
$3 = 0x80004
(gdb) c
Continuing.
status=%x
dum=%f
|AGNUyyyyyyyy?AU@o@@0@L@h@"@U.Y?
A@o@H@ `@
1
?AT@o@
?yyoO@yyyo?yyo?@GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU)
2.97 2
0001120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
200
01120 (experimental)GCC: (GNU) 2.97 20001120 (experimental)GCC: (GNU) 2.97
20001
120 (experimental)?@""-main?@?@test.c/scratch/hotspare/home/baoGNU C 2.97
200011
20 (experimental)?quot?#rem?long long inN__valM?#AAunsigned intint
__sched_paramE__sched_priorityFN# M_pthread_fastlock
> -----Original Message-----
> From: lin...@li...
> [mailto:lin...@li...]On Behalf Of
> kaz Kojima
> Sent: Thursday, August 16, 2001 5:48 PM
> To: lin...@li...
> Subject: [linuxsh-dev] Re: Floating point problem
>
>
> "Bao C. Ha" <ba...@se...> wrote:
> > (gdb) n
> > 14 printf("\n status=%x\n", (int)status);
> > (gdb) set archi sh4
> > The target architecture is assumed to be sh4
> > (gdb) p/x $fpscr
> > $2 = 0x3f737871
> > (gdb) n
> >
> > status=%x
> >
> > dum=%f
> > ......
> > CRASHED!!!
> >
> > So it is the wrong FPU mode. How do we fix it?
>
> Before going ahead, please try
> (gdb) p/x $fpscr=0x80004
> (gdb) c
> instead of p/x $fpscr to confirm the problem. If it works,
> the problem must be caused by $fpscr. If this is the case,
> I think that the real problem is the __fpscr_values table
> in your shared libraries.
>
> The $fpscr value problem is a long standing problem. As you
> know, SH-4 FPU has no individual instructions to handle float
> and double, but a mode flags in $fpscr. So the mixture of
> the float and double arithmetic needs the wierd switching of
> $fpscr value. So, an easiest and only one easy workaround is
> to use double only :-)
>
> GCC uses __fpscr_values for this switching. This table is
> the array of 32-bit words and __fpscr_values[0] is the value
> for float and __fpscr_values[1] is for double. The switchig
> is done by the load from these values to $fpscr. There are
> versions of compiler have problems in this switching, though
> this is not the case in current problem since there is no
> problem with static linking.
> This __fpscr_values table is in libgcc.a and defined as .comm
> symbol originally. But this is not suitable for the shared
> library. The __fpscr_values table is writable to set rounding
> and floating exception mode, so it must be the unique entity.
> The Right Thing is to put it in the shared libgcc like as
> we've done it in our gcc-3.0 patch. So the 2nd workaround is
> to use gcc-3.0 + our SH patch and rebuild all libraries using
> it. But it isn't so easy and will cause another problems.
>
> kaz
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
|
|
From: kaz K. <kk...@rr...> - 2001-08-17 03:59:26
|
"Bao C. Ha" <ba...@se...> wrote: > It still crashed when $fpscr was set to 0x80004 > > (gdb) p/x $fpscr=0x80004 > $2 = 0x80004 > (gdb) p/x $fpscr > $3 = 0x80004 > (gdb) c > Continuing. > > status=%x [snip] Hmm... I have no idea for the real problem at this point. Anyway, 0x3f737871 is very broken if gdb works correctly and it seems that some bad things occur in shared library. Perhaps, rebuilding libc with gcc -O may be not so bad idea. kaz |
|
From: Jeremy S. <js...@mv...> - 2001-08-17 16:51:05
|
I suspect the odd fpscr displayed is due to a broken GDB, or at least one with register number identifiers that are inconsistent with the kernel/ptrace... mine behaves the same way (at the moment). [BTW, we see the same thing, and we're using glibc 2.2.3.] --Jeremy Siegel kaz Kojima wrote: > "Bao C. Ha" <ba...@se...> wrote: > > It still crashed when $fpscr was set to 0x80004 > > > > (gdb) p/x $fpscr=0x80004 > > $2 = 0x80004 > > (gdb) p/x $fpscr > > $3 = 0x80004 > > (gdb) c > > Continuing. > > > > status=%x > [snip] > > Hmm... I have no idea for the real problem at this point. Anyway, > 0x3f737871 is very broken if gdb works correctly and it seems > that some bad things occur in shared library. Perhaps, rebuilding > libc with gcc -O may be not so bad idea. > > kaz > > _______________________________________________ > linuxsh-dev mailing list > lin...@li... > http://lists.sourceforge.net/lists/listinfo/linuxsh-dev |
|
From: kaz K. <kk...@rr...> - 2001-08-18 02:57:42
|
Jeremy Siegel <js...@mv...> wrote: > I suspect the odd fpscr displayed is due to a broken GDB, > or at least one with register number identifiers that are > inconsistent with the kernel/ptrace... mine behaves the > same way (at the moment). [BTW, we see the same > thing, and we're using glibc 2.2.3.] Agreed. I've found bad fpscr values on the native gdb. BTW, I've just build libc-2.2.3 by gcc-2.97(20001120) again, but I can't reproduce the problem with it. kaz |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X