https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #26 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Jan 24 10:54:56 2017
New Revision: 244862
URL: https://gcc.gnu.org/viewcvs?rev=244862&root=gcc&view=rev
Log:
PR target/78478
* config/ax_check_define.m4: New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #25 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #24)
> Would you mind applying this to the 6.x branch? That was where the issue was
> initially spotted.
Sure, but let's wait for a week if everything works OK in the m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #24 from Joel Sherrill ---
Would you mind applying this to the 6.x branch? That was where the issue was
initially spotted.
I don't know what to do about this extra line in rtemself.h though. It was not
present in the master
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #23 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:38:44 2017
New Revision: 244653
URL: https://gcc.gnu.org/viewcvs?rev=244653&root=gcc&view=rev
Log:
PR target/78478
Revert:
2013-11-05 Uros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #22 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jan 19 21:00:53 2017
New Revision: 244651
URL: https://gcc.gnu.org/viewcvs?rev=244651&root=gcc&view=rev
Log:
PR target/78478
* config/ax_check_define.m4: New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #21 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #20)
> Looks like it works, Thanks.
>
> Based on my testing, these need to be applied to both the gcc 6 branch and
> master. Should I just commit them with the PR not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #20 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #19)
> (In reply to Joel Sherrill from comment #18)
> > I changed that line to
> >
> > #ifdef _SOFT_FLOAT
> > #include "config/fpu-generic.h"
> >
> > and it built. Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #19 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #18)
> I changed that line to
>
> #ifdef _SOFT_FLOAT
> #include "config/fpu-generic.h"
>
> and it built. Is that OK?
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #18 from Joel Sherrill ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Joel Sherrill from comment #16)
> > Thanks for all the feedback. With this patch, it now builds. Is the style of
> > change to configure.host OK?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #16 from Joel Sherrill ---
Thanks for all the feedback. With this patch, it now builds. Is the style of
change to configure.host OK?
I need to check how far back this impacts. A user reported it with a released
gcc. Since we don't bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #15 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #14)
> (In reply to H.J. Lu from comment #13)
> > The problem is config/i386/rtemself.h has
> >
> > #define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
> >
> > XFmo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #14 from Joel Sherrill ---
(In reply to H.J. Lu from comment #13)
> The problem is config/i386/rtemself.h has
>
> #define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
>
> XFmode isn't available with -msoft-float even when -mlong-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #13 from H.J. Lu ---
The problem is config/i386/rtemself.h has
#define LONG_DOUBLE_TYPE_SIZE (TARGET_80387 ? 80 : 64)
XFmode isn't available with -msoft-float even when -mlong-double-80 is used.
IA MCU defaults long double to double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #12 from H.J. Lu ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Joel Sherrill from comment #9)
>
> > I could pursue this but is soft-float on the x86 target really worth the
> > investment of any effort? AFAIK we would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #10 from Uroš Bizjak ---
(In reply to Joel Sherrill from comment #9)
> > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same
> > time as enabling usage of TFmode. The TFmode functions should be kept in
> > li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #9 from Joel Sherrill ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> >
> > --- Comment #2 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #8 from Uroš Bizjak ---
(In reply to jos...@codesourcery.com from comment #7)
> On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
>
> > > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same
> > > time as enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #7 from joseph at codesourcery dot com ---
On Tue, 17 Jan 2017, joel at gcc dot gnu.org wrote:
> > I.e., the bug was enabling unintended soft-fp usage of XFmode at the same
> > time as enabling usage of TFmode. The TFmode functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #6 from Joel Sherrill ---
(In reply to jos...@codesourcery.com from comment #5)
> On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
> >
> > --- Comment #2 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #5 from joseph at codesourcery dot com ---
On Tue, 22 Nov 2016, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
>
> --- Comment #2 from Uroš Bizjak ---
> For 7.0, somebody changed i[34567]86-*-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #4 from Joel Sherrill ---
FWIW I haven't been able to build this far using i386-elf. It fails in
libbacktrace doing a configure probe because there isn't a crt0.o. I can't
figure out why it isn't building libgloss. I have it and newli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #3 from Joel Sherrill ---
That patch gets the build further but there is more wrong. __float128 isn't
defined.
/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/xgcc
-B/home/joel/test-gcc/b-i386-rtems4.12-gcc/./gcc/ -nostdinc
-B/home/jo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
--- Comment #2 from Uroš Bizjak ---
For 7.0, somebody changed i[34567]86-*-rtems* entry in libgcc/config.host to
use t-softfp-sfdftf. Please test the following patch:
Index: libgcc/config.host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78478
Joel Sherrill changed:
What|Removed |Added
Target||i386-rtems4.12
Known to work|
27 matches
Mail list logo
