Re: [PATCH][RFC] Always require a 64bit HWI
On 04/30/2014 05:00 PM, Jeff Law wrote:
> On 04/30/14 02:16, Richard Biener wrote:
>>
>> Testing coverage for non-64bit hwi configs is really low these
>> days (I know of only 32bit hppa-*-* that is still built and
>> tested semi-regularly - Dave, I suppose the host compiler
>> has a 64bit long long type there, right?).
> My recollection is that HP aCC supports long long, but I don't recall
> when support for that was introduced. I'm really trying hard to forget
> hpux-isms.
GCC (in libdecnumber) has been relying on long long / ll existing, and on
it being 64-bits wide, for more than 7 years now, and nobody seems to have
tripped on any host compiler that doesn't support it.
See libdecnumber/bid/bid-dpd.h / bid/bid2dpd_dpd2bid.h. git blame shows:
10de71e1 (meissner 2007-03-24 17:04:47 + 25) typedef unsigned int UINT32;
^^
10de71e1 (meissner 2007-03-24 17:04:47 + 26) typedef unsigned long long
UINT64;
^
10de71e1 (meissner 2007-03-24 17:04:47 + 27) typedef struct { UINT64 w[2];
} UINT128;
...
10de71e1 (meissner 2007-03-24 17:04:47 +28) { {
0x3b645a1cac083127ull, 0x0083126e978d4fdfull } }, /* 3 extra digits */
10de71e1 (meissner 2007-03-24 17:04:47 +29) { {
0x4af4f0d844d013aaULL, 0x00346dc5d6388659ULL } }, /* 10^(-4) * 2^131 */
^^^
So the issue is moot.
> Plus, they can always start the bootstrapping process with GCC 4.9.
They'd have to go much further back than that.
--
Pedro Alves
Re: Secondary platform change request
On 04/30/14 21:56, Wolf wrote: Since the original MinGW refuses to support 64-bit, I would like to discuss whether we should remove i686-mingw32 from the secondary platforms list and replace it with MinGW-w64. Kai should probably chime in here with his recommendation on the technical side. If/when Kai thinks this is appropriate on the pure technical merits, then I'm more than happy to propose the change to the steering committee for the next major GCC release. jeff
Re: Secondary platform change request
2014-05-01 17:23 GMT+02:00 Jeff Law : > On 04/30/14 21:56, Wolf wrote: >> >> Since the original MinGW refuses to support 64-bit, I would like to >> discuss whether we should remove i686-mingw32 from the secondary >> platforms list and replace it with MinGW-w64. > > Kai should probably chime in here with his recommendation on the technical > side. If/when Kai thinks this is appropriate on the pure technical merits, > then I'm more than happy to propose the change to the steering committee for > the next major GCC release. > > jeff Well, from my POV we should do two things for next major release. First, we should add x86_64 cygwin target to the list of secondary targets. And also i?86/x86_64-*-mingw* targets. It is true that mingw-w64's toolchain supports 32-bit and 64-bit IAs. Additionally it is working right now to add support for ARM architectures (v7 and v8). Patches for this will reach gcc/binutils soon. It is right that we don't have an active contributors/maintainers of side of mingw.org anymore. All active development and contributions in this area are done right now from mingw-w64's communtiy AFAICS. All windows targets (cygwin & mingw) are right now maintained by me as other maintainers for these targets seems to be MIA. So naturally I would vote to add here instead of mingw.org the mingw-w64 toolchain. Kai
Re: SPARC LEON3 and CAS instruction
> I think its more natural to generate user-space code by default. Well, the other architectures I know of think differently so we'll follow them. -- Eric Botcazou
Re: aarch64 ada rpms
> Thanks for the reminder. I've now pushed rpms to > > http://people.redhat.com/~rth/ > > That's a 4.9 backport of the changes now on mainline, on top of the current > fedora rawhide package. The srpm of course contains the backport patch. Thanks for the link. I'll backport the changes to the official 4.9 branch at some point. -- Eric Botcazou
sh-*-* Fails to Compile on FreeBSD
Hi
gcc-4.8.2 targeting sh-*-* fails to compile on
FreeBSD 10 which is using clang. I am hoping someone
has some ideas about these.
In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:131:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:438:
In file included from /usr/include/c++/v1/cwchar:107:
In file included from /usr/include/c++/v1/cwctype:54:
/usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
'do_not_use_isalnum_with_safe_ctype'
inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
isalnum(__c);}
sh.c line 63 is this:
#include
#include
#include
It is the only file in gcc/config/* to include sstream. Has some
update sweep for C++ transition missed this file?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: sh-*-* Fails to Compile on FreeBSD
On 01 May 2014, at 22:08, Joel Sherrill wrote:
> Hi
>
> gcc-4.8.2 targeting sh-*-* fails to compile on
> FreeBSD 10 which is using clang. I am hoping someone
> has some ideas about these.
Yes, I've noticed and mentioned this already a while ago:
http://gcc.gnu.org/ml/gcc/2013-12/msg00036.html
> In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
> In file included from /usr/include/c++/v1/sstream:174:
> In file included from /usr/include/c++/v1/ostream:131:
> In file included from /usr/include/c++/v1/ios:216:
> In file included from /usr/include/c++/v1/__locale:15:
> In file included from /usr/include/c++/v1/string:438:
> In file included from /usr/include/c++/v1/cwchar:107:
> In file included from /usr/include/c++/v1/cwctype:54:
> /usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
> 'do_not_use_isalnum_with_safe_ctype'
> inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
> isalnum(__c);}
>
> sh.c line 63 is this:
>
> #include
> #include
> #include
>
> It is the only file in gcc/config/* to include sstream. Has some
> update sweep for C++ transition missed this file?
Could you please try moving the std includes above any other (gcc) includes and
see if it fixes the issue? AFAIR it did it for me.
Cheers,
Oleg
Re: sh-*-* Fails to Compile on FreeBSD
On 5/1/2014 3:29 PM, Oleg Endo wrote:
> On 01 May 2014, at 22:08, Joel Sherrill wrote:
>
>> Hi
>>
>> gcc-4.8.2 targeting sh-*-* fails to compile on
>> FreeBSD 10 which is using clang. I am hoping someone
>> has some ideas about these.
> Yes, I've noticed and mentioned this already a while ago:
> http://gcc.gnu.org/ml/gcc/2013-12/msg00036.html
>
>
>> In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
>> In file included from /usr/include/c++/v1/sstream:174:
>> In file included from /usr/include/c++/v1/ostream:131:
>> In file included from /usr/include/c++/v1/ios:216:
>> In file included from /usr/include/c++/v1/__locale:15:
>> In file included from /usr/include/c++/v1/string:438:
>> In file included from /usr/include/c++/v1/cwchar:107:
>> In file included from /usr/include/c++/v1/cwctype:54:
>> /usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
>> 'do_not_use_isalnum_with_safe_ctype'
>> inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
>> isalnum(__c);}
>>
>> sh.c line 63 is this:
>>
>> #include
>> #include
>> #include
>>
>> It is the only file in gcc/config/* to include sstream. Has some
>> update sweep for C++ transition missed this file?
> Could you please try moving the std includes above any other (gcc) includes
> and see if it fixes the issue? AFAIR it did it for me.
This seems to fix it. I am not sure why sh.c is the only file in
gcc/config which includes sstream though. Is this a violation
of some new rule?
Is there a PR for this?
If not, I probably should file one and get the patch pushed
into 4.8 as well as 4.9 and the head if they need it.
Thanks.
>
> Cheers,
> Oleg
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: sh-*-* Fails to Compile on FreeBSD
On May 1, 2014, at 11:17 PM, Joel Sherrill wrote:
>
> On 5/1/2014 3:29 PM, Oleg Endo wrote:
>> On 01 May 2014, at 22:08, Joel Sherrill wrote:
>>
>>> Hi
>>>
>>> gcc-4.8.2 targeting sh-*-* fails to compile on
>>> FreeBSD 10 which is using clang. I am hoping someone
>>> has some ideas about these.
>> Yes, I've noticed and mentioned this already a while ago:
>> http://gcc.gnu.org/ml/gcc/2013-12/msg00036.html
>>
>>
>>> In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
>>> In file included from /usr/include/c++/v1/sstream:174:
>>> In file included from /usr/include/c++/v1/ostream:131:
>>> In file included from /usr/include/c++/v1/ios:216:
>>> In file included from /usr/include/c++/v1/__locale:15:
>>> In file included from /usr/include/c++/v1/string:438:
>>> In file included from /usr/include/c++/v1/cwchar:107:
>>> In file included from /usr/include/c++/v1/cwctype:54:
>>> /usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
>>> 'do_not_use_isalnum_with_safe_ctype'
>>> inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
>>> isalnum(__c);}
>>>
>>> sh.c line 63 is this:
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> It is the only file in gcc/config/* to include sstream. Has some
>>> update sweep for C++ transition missed this file?
>> Could you please try moving the std includes above any other (gcc) includes
>> and see if it fixes the issue? AFAIR it did it for me.
> This seems to fix it. I am not sure why sh.c is the only file in
> gcc/config which includes sstream though.
Because I added code to sh.c that uses stuff from sstream after the switch to
C++.
> Is this a violation
> of some new rule?
Not that I'm aware of.
> Is there a PR for this?
>
> If not, I probably should file one and get the patch pushed
> into 4.8 as well as 4.9 and the head if they need it.
>
If you insist on having a PR for it, please feel free. In any case, I'll
commit the 'fix' to trunk and the branches by tomorrow.
Cheers,
Oleg
gcc-4.8-20140501 is now available
Snapshot gcc-4.8-20140501 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140501/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 209991 You'll find: gcc-4.8-20140501.tar.bz2 Complete GCC MD5=3477e54e799bceddf7c4f3ae34af704e SHA1=e64e6e34e7b07f99bbc3deb7351f931f18484f33 Diffs from 4.8-20140424 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: sh-*-* Fails to Compile on FreeBSD
On 1 May 2014 22:17, Joel Sherrill wrote: > This seems to fix it. I am not sure why sh.c is the only file in > gcc/config which includes sstream though. Is this a violation > of some new rule? A rule that a feature can only be used if it's in more than one file? ;-) > Is there a PR for this? http://gcc.gnu.org/PR61026 is related.
