configure gcc - target_header_dir
Hello,
I have a problem while cross-compiling a native sh4 compiler. To be
exact, I'm building on x86_64 a linux native sh4 compiler. My
configure is :
configure *--host=sh4-linux* *--build=x86_64-unknown-linux-
gnu* --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/usr/share
--mandir=/usr/share/man --infodir=/usr/share/info *--target=sh4-linux*
--enable-target-optspace --enable-languages=c,c++
--enable-threads=posix --enable-nls --enable-c99 --enable-long-long
--with-system-zlib --enable-shared --disable-libgomp
--disable-sjlj-exceptions --with-pkgversion=GCC
--with-bugurl=https://bugzilla.stlinux.com --disable-libstdcxx-pch
--disable-libitm --enable-multilib --disable-multi-sysroot
--with-multilib-list=m4-nofpu --enable-lto
--with-mpc=/tmp/69328.tmpdir/
stlinux-shared/distro-sh4/STLinux-2.4/devkit/sh4/target
--with-gmp=/tmp/69328.tmpdir/stlinux-shared/distro-sh4/STLinux-2.4/devkit/sh4/target
--with-mpfr=/tmp/69328.tmpdir/stlinux-shared/distro-sh4/STLinux-2.4/devkit/sh4/target
--without-ppl --enable-symvers=gnu --enable-__cxa_atexit
In the configuration phase, I can see :
if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
if test "x$with_headers" != x; then
target_header_dir=$with_headers
elif test "x$with_sysroot" = x; then
target_header_dir="${exec_prefix}/${target_noncanonical}/sys-include"
elif test "x$with_build_sysroot" != "x"; then
target_header_dir="${with_build_sysroot}${native_system_header_dir}"
elif test "x$with_sysroot" = xyes; then
target_header_dir="${exec_prefix}/${target_noncanonical}/sys-root${native_system_header_dir}"
else
target_header_dir="${with_sysroot}${native_system_header_dir}"
fi
else
target_header_dir=${native_system_header_dir}
fi
[...]
if test -f $target_header_dir/sys/sdt.h; then
AC_DEFINE(HAVE_SYS_SDT_H, 1, [Define if your target C library
provides sys/sdt.h])
fi
In my case, the $host and $target are the same (sh4-linux), the
target_header_dir is then assigned to /usr/include, which is not the
$target_header_dir but the "host system header dir").
Later, the configure erroneously checks the existence of a target
header dir. the HAVE_SYS_SDT_H defined is set while it doesn't exist
in the target headers.
I have the feeling that the target_header_dir is not properly set. I
believe the test should be between $build and the $target.
What do you think about :
-if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
+if test x$build != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
Then, beside that change I might also need to add a --with-sysroot to
my configure command, but looking at the gnu install pages, i m not
sure ... Please advice.
Thanks
Laurent
Re: RFC: [ARM] Disable peeling
On Wed, Dec 12, 2012 at 6:50 PM, Andi Kleen wrote:
> "H.J. Lu" writes:
>>
>> i386.c has
>>
>>{
>> /* When not optimize for size, enable vzeroupper optimization for
>> TARGET_AVX with -fexpensive-optimizations and split 32-byte
>> AVX unaligned load/store. */
>
> This is only for the load, not for deciding whether peeling is
> worthwhile or not.
>
> I believe it's unimplemented for x86 at this point. There isn't even a
> hook for it. Any hook that is added should ideally work for both ARM64
> and x86. This would imply it would need to handle different vector
> sizes.
There is
/* Implement targetm.vectorize.builtin_vectorization_cost. */
static int
ix86_builtin_vectorization_cost (enum vect_cost_for_stmt type_of_cost,
tree vectype,
int misalign ATTRIBUTE_UNUSED)
{
...
case unaligned_load:
case unaligned_store:
return ix86_cost->vec_unalign_load_cost;
which indeed doesn't distinguish between unaligned load/store cost. Still
it does distinguish between aligned and unaligned load/store cost.
Now look at the cost tables and see different unaligned vs. aligned costs
dependent on the target CPU.
generic32 and generic64 have:
1,/* vec_align_load_cost. */
2,/* vec_unalign_load_cost. */
1,/* vec_store_cost. */
The missed piece in the vectorizer is that peeling for alignment should have the
option to turn itself off based on that costs (and analysis).
Richard.
Re: Deprecate i386 for GCC 4.8?
On Wed, Dec 12, 2012 at 10:07 PM, David Brown wrote: > On 12/12/12 20:54, Robert Dewar wrote: >> >> On 12/12/2012 2:52 PM, Steven Bosscher wrote: >> >>> And as usual: If you use an almost 30 years old architecture, why >>> would you need the latest-and-greatest compiler technology? >>> Seriously... >> >> >> Well the embedded folk often end up with precisely this dichotomy :-) > > > True enough. > > >> But if no sign of 386 embedded chips, then reasonable to deprecate >> I agree. > > > I believe it has been a very long time since any manufacturers made a pure > 386 chip. While I've never used x86 devices in any of my embedded systems, > I believe there are two main classes of x86 embedded systems - those that > use DOS (these still exist!), and those that aim to be a small PC with more > modern x86 OS's. For the DOS systems, gcc does not matter, because it is > not used - compilers like OpenWatcom are far more common (ref. the FreeDOS > website). And for people looking for "embedded PC's", the processor is > always going to be a lot more modern than the 386 - otherwise they are not > going to be able to run any current OS. > > The only people I can think of that still actively compile for 386 as the > lowest common denominator are the BSD folks. Some of them still like to > compile with compatibility for 386 chips. But I have no idea if they need > 386 support in future gcc versions. They are stuck with pre-GPLv3 GCC compilers anyway. ISTR we changed the default i?86 triple from i386 to i586 for 4.6, so we are already half-way through the deprecation. I'd say simply go ahead. Note that i386-freebsd is still listed as primary architecture though, so something has to be done about that first. Steering Commitee please? (I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers) Richard.
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 11:11, Richard Biener wrote: They are stuck with pre-GPLv3 GCC compilers anyway. ISTR we changed the default i?86 triple from i386 to i586 for 4.6, so we are already half-way through the deprecation. I'd say simply go ahead. Note that i386-freebsd is still listed as primary architecture though, so something has to be done about that first. Steering Commitee please? (I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers) Both NetBSD and DragonFly BSD use GPLv3 compilers in their base systems. FreeBSD ports have every modern version of GCC in them, nothing stops a user from building and using the latest GCC on FreeBSD (Note the ports are well maintained). FreeBSD and DragonFly (at least) have already dropped i386 support, it's an alias for i486. I don't know about NetBSD or OpenBSD. I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. John
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: > On 12/13/2012 11:11, Richard Biener wrote: >> >> >> They are stuck with pre-GPLv3 GCC compilers anyway. >> >> ISTR we changed the default i?86 triple from i386 to i586 for 4.6, so we >> are already half-way through the deprecation. I'd say simply go ahead. >> >> Note that i386-freebsd is still listed as primary architecture though, so >> something has to be done about that first. Steering Commitee please? >> (I'd say drop *-freebsd from the list of primary/secondary archs entirely >> given that they are not at all happy with GPLv3 and not using still >> maintained >> compilers) > > > > Both NetBSD and DragonFly BSD use GPLv3 compilers in their base systems. > FreeBSD ports have every modern version of GCC in them, nothing stops a user > from building and using the latest GCC on FreeBSD (Note the ports are well > maintained). > > FreeBSD and DragonFly (at least) have already dropped i386 support, it's an > alias for i486. I don't know about NetBSD or OpenBSD. > > I don't speak for FreeBSD, but dropping them from Tier 1 support because > they don't use a GPLv3 *BASE* compiler is a bit vindictive. Well, I'm fine with changing it to i486-freebsd - just keeping i386-freebsd listed but deprecating i386 looks odd. Richard. > John
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: > I don't speak for FreeBSD, but dropping them from Tier 1 support because > they don't use a GPLv3 *BASE* compiler is a bit vindictive. FreeBSD has dropped GCC for future releases so there's no reason for it to be a primary platform. Ciao! Steven
Re: Deprecate i386 for GCC 4.8?
On Wed, Dec 12, 2012 at 9:54 PM, Robert Dewar wrote: > On 12/12/2012 2:52 PM, Steven Bosscher wrote: > >> And as usual: If you use an almost 30 years old architecture, why >> would you need the latest-and-greatest compiler technology? >> Seriously... > > > Well the embedded folk often end up with precisely this dichotomy :-) > But if no sign of 386 embedded chips, then reasonable to deprecate > I agree. According to http://web.archive.org/web/20061009060120/http://developer.intel.com/design/pcn/Processors/D0106013.pdf Intel stopped producing embedded 386 chips in 2007. -- Janne Blomqvist
Re: Deprecate i386 for GCC 4.8?
On 13/12/2012 12:24, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. FreeBSD has dropped GCC for future releases so there's no reason for it to be a primary platform. Yes there is good reason for keeping bsd targets. FreeBSD and others may be moving to llvm, or using older gcc's, for their official binary builds - but /users/ are still free to pick whatever tools they want. They are also free to download the source of FreeBSD and compile it themselves with gcc 4.8 fresh from svn. Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8.
Re: Deprecate i386 for GCC 4.8?
On 12/12/2012 08:54 PM, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) But if no sign of 386 embedded chips, then reasonable to deprecate I've never heard about them before, nor do I know how far spread their products are, however these folks seem to be producing i386-SoCs http://www.dmp.com.tw/ esp. this one http://www.dmp.com.tw/tech/vortex86sx/ Ralf
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 12:43 PM, John Marino wrote: > FreeBSD and DragonFly (at least) have already dropped i386 support, it's an > alias for i486. I don't know about NetBSD or OpenBSD. According to http://mail-index.netbsd.org/tech-toolchain/2009/02/24/msg000582.html i386 support has been dropped from the netbsd kernel, although at least back in 2009 when that mail was written they still targeted their toolchain for i386. -- Janne Blomqvist
Re: Deprecate i386 for GCC 4.8?
On 13/12/2012 11:11, Richard Biener wrote: On Wed, Dec 12, 2012 at 10:07 PM, David Brown wrote: On 12/12/12 20:54, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) True enough. But if no sign of 386 embedded chips, then reasonable to deprecate I agree. I believe it has been a very long time since any manufacturers made a pure 386 chip. While I've never used x86 devices in any of my embedded systems, I believe there are two main classes of x86 embedded systems - those that use DOS (these still exist!), and those that aim to be a small PC with more modern x86 OS's. For the DOS systems, gcc does not matter, because it is not used - compilers like OpenWatcom are far more common (ref. the FreeDOS website). And for people looking for "embedded PC's", the processor is always going to be a lot more modern than the 386 - otherwise they are not going to be able to run any current OS. The only people I can think of that still actively compile for 386 as the lowest common denominator are the BSD folks. Some of them still like to compile with compatibility for 386 chips. But I have no idea if they need 386 support in future gcc versions. They are stuck with pre-GPLv3 GCC compilers anyway. ISTR we changed the default i?86 triple from i386 to i586 for 4.6, so we are already half-way through the deprecation. I'd say simply go ahead. Note that i386-freebsd is still listed as primary architecture though, so something has to be done about that first. Steering Commitee please? (I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers) Richard. Is there much to be gained from keeping 486 support - or alternatively, is there much to be gained by dropping it at the same time? If 586 has been the standard configuration for the last two releases of gcc, and 686 has been the standard for most 32-bit x86 Linux distributions for a number of years, perhaps it is worth deprecating 486 (and maybe even 586) at the same time. After all, "deprecating" targets does not mean that they are dead - users can always use older versions of gcc, and can argue against the deprecation if it is affecting them. David
Re: Deprecate i386 for GCC 4.8?
Intel stopped producing embedded 386 chips in 2007. Right, but this architecture is not protected, so the question is whether there are other vendors producing compatible chips. I don't know the answer.
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 12:38, David Brown wrote: On 13/12/2012 12:24, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote: I don't speak for FreeBSD, but dropping them from Tier 1 support because they don't use a GPLv3 *BASE* compiler is a bit vindictive. FreeBSD has dropped GCC for future releases so there's no reason for it to be a primary platform. Yes there is good reason for keeping bsd targets. FreeBSD and others may be moving to llvm, or using older gcc's, for their official binary builds - but /users/ are still free to pick whatever tools they want. They are also free to download the source of FreeBSD and compile it themselves with gcc 4.8 fresh from svn. This is exactly right and what I attempted to say earlier. Also, the FreeBSD ports collection contains entries for gcc 3.4, 4.2, 4.4, 4.6, 4.7, and 4.8 (development) so the users would build from ports since gcc typically needs a few patches on *BSD. Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8. It needs to be pointed out that while the base system can be built without gcc, literally thousands of ports require GCC to build. It's still in widespread use. John
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote: > Dropping bsd as a target architecture just because the BSD distributions > don't use it is a bit like dropping support for targeting windows just > because Microsoft didn't use gcc to compile Windows 8. You're confused. Dropping something as a target is not the same as dropping it from the list of primary platforms. See http://gcc.gnu.org/gcc-4.8/criteria.html Ciao! Steven
Accessing Go type descriptors from the middle end
Hello, I have a GIMPLE pass and would like to make use of the data type information that the Go frontend produces. Is there a way to access this information from the middle end without having to query the frontend? -Matt
Re: Deprecate i386 for GCC 4.8?
On 13/12/2012 13:09, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote: Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8. You're confused. Dropping something as a target is not the same as dropping it from the list of primary platforms. See http://gcc.gnu.org/gcc-4.8/criteria.html Ciao! Steven You are correct - I was confused. Thanks for setting me right. mvh., David
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 13:09, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 12:38 PM, David Brown wrote: Dropping bsd as a target architecture just because the BSD distributions don't use it is a bit like dropping support for targeting windows just because Microsoft didn't use gcc to compile Windows 8. You're confused. Dropping something as a target is not the same as dropping it from the list of primary platforms. See http://gcc.gnu.org/gcc-4.8/criteria.html Which clause are you invoking to remove it from the primary tier list? Richard claimed "they are not at all happy with GPLv3". That's not a reason listed on your reference. He also claimed they "not using still maintained compilers" which is also clearly false. Maybe FreeBSD violates the "Primary platforms are popular systems" clause (of course "popular" is not quantified so no way to defend accusations of being not popular enough). GCC is certainly "frequently used" on FreeBSD so that's not in violation. John
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 12:59 PM, Robert Dewar wrote: > >> Intel stopped producing embedded 386 chips in 2007. > > > Right, but this architecture is not protected, so the > question is whether there are other vendors producing > compatible chips. I don't know the answer. Ralf has found one such a vendor, it seems. But to me, that doesn't automatically imply that GCC must continue to support such a target. Other criteria should also be considered. For instance, quality of implementation and maintenance burden. Just two examples: * It's already happened in the past (at least 10 years ago) that i386 was broken for a while without anyone noticing. (See e.g. http://gcc.gnu.org/onlinedocs/gcc-4.7.2/libstdc++/manual/faq.html#faq.threads_i386) * Supporting the C/C++ memory models on 386 is hard and susceptible to bitrot unless tested on real 386 hardware. (see e.g. http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary -- actually, it looks like libatomic currently doesn't support 386 at all) But we digress... Ciao! Steven
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote: > Which clause are you invoking to remove it from the primary tier list? > Richard claimed "they are not at all happy with GPLv3". That's not a reason > listed on your reference. He also claimed they "not using still maintained > compilers" which is also clearly false. > > Maybe FreeBSD violates the "Primary platforms are popular systems" clause > (of course "popular" is not quantified so no way to defend accusations of > being not popular enough). GCC is certainly "frequently used" on FreeBSD so > that's not in violation. The "it's 386, nobody uses it" clause? I wouldn't mind if some other freebsd tripled would stay on the list, e.g. i686-freebsd. Stop being so emotional and look at the facts. Nobody is taking away your favorite toys. Ciao! Steven
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 2:21 AM, John Marino wrote: > Which clause are you invoking to remove it from the primary tier list? > Richard claimed "they are not at all happy with GPLv3". That's not a reason > listed on your reference. He also claimed they "not using still maintained > compilers" which is also clearly false. > > Maybe FreeBSD violates the "Primary platforms are popular systems" clause > (of course "popular" is not quantified so no way to defend accusations of > being not popular enough). GCC is certainly "frequently used" on FreeBSD so > that's not in violation. Probably the part about running regular testsuites and posting them to the mailing list, tracking the regressions, and fixing them.
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 1:53 PM, NightStrike wrote: > On Thu, Dec 13, 2012 at 2:21 AM, John Marino wrote: >> Which clause are you invoking to remove it from the primary tier list? >> Richard claimed "they are not at all happy with GPLv3". That's not a reason >> listed on your reference. He also claimed they "not using still maintained >> compilers" which is also clearly false. >> >> Maybe FreeBSD violates the "Primary platforms are popular systems" clause >> (of course "popular" is not quantified so no way to defend accusations of >> being not popular enough). GCC is certainly "frequently used" on FreeBSD so >> that's not in violation. > > Probably the part about running regular testsuites and posting them to > the mailing list, tracking the regressions, and fixing them. Gerald runs regression tests on both i386 and x86_64 freebsd (though some old versions of it). We do have a listed maintainer for freebsd. Apart from build issues I am not aware of frequent freebsd specific bugs. If we deprecate i386 it shouldn't stay as i386-freebsd though. There isn't a rule what target can become primary or secondary (but at least it should have a listed active maintainer and regular testresults appearing on gcc-testresults). Recently we dropped ia64-linux for the fact it was actively unmaintained. I'm not arguing in any way against i386-freebsd but if we have to change it I did want to drop the occasional reason against having it on the list (eh, release managers always are happy dropping targets from the list of those they have to block releases for ;)) >From a users view you could argue that singling out freebsd from the other bsds is unfair (freebsd is primary but the others are not even secondary?). There are a total of 6 x86 variant targets on the primary/secondary list (out of a total 13). Maybe we should start to use wildcards there and separate host architectures/OSs we care for from target CPUs and target OSs. And drop the distinction between primary and secondary. (now I'm getting off-topic) Richard.
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 2:19 PM, Richard Biener wrote: > Gerald runs regression tests on both i386 and x86_64 freebsd (though some old > versions of it). We do have a listed maintainer for freebsd. Apart from > build > issues I am not aware of frequent freebsd specific bugs. Gerald's test for i386-freebsd are for 386-unknown-freebsd10.0, so that's not old but bleeding edge. But for the build status lists, freebsd, or for that matter any other BSD variant, is missing from the latest maintained releases. The last confirmed build is for GCC 4.4 on i386-unknown-freebsd7.2. That'd be in 2009... But, again, we digress. I don't think anyone's arguing for dropping BSDs from the primary/secondary targets lists. All I'm arguing for, is to drop a 30 year old architecture that really nobody uses: 80386. Ciao! Steven http://gcc.gnu.org/gcc-4.7/buildstat.html - no bsd variants reported http://gcc.gnu.org/gcc-4.6/buildstat.html - no bsd variants reported http://gcc.gnu.org/gcc-4.5/buildstat.html - no bsd variants reported http://gcc.gnu.org/gcc-4.4/buildstat.html - successful build for i386-unknown-freebsd7.2
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 13:32, Steven Bosscher wrote: On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote: Which clause are you invoking to remove it from the primary tier list? Richard claimed "they are not at all happy with GPLv3". That's not a reason listed on your reference. He also claimed they "not using still maintained compilers" which is also clearly false. Maybe FreeBSD violates the "Primary platforms are popular systems" clause (of course "popular" is not quantified so no way to defend accusations of being not popular enough). GCC is certainly "frequently used" on FreeBSD so that's not in violation. The "it's 386, nobody uses it" clause? I wouldn't mind if some other freebsd tripled would stay on the list, e.g. i686-freebsd. Stop being so emotional and look at the facts. Nobody is taking away your favorite toys. Everything I have said is a fact, please illustrate which statement I made seems emotional. Quote from Richard: "(I'd say drop *-freebsd from the list of primary/secondary archs entirely given that they are not at all happy with GPLv3 and not using still maintained compilers)" As you can see, the "*" means all triplets, not only i386. He has since clarified that another triplet could take its place, but not before you tried to revise what he said. Those are the facts. Some FreeBSD triplet should be on the primary tier as those tiers are defined today. If nobody disagrees with that, that part of the discussion is over.
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 2:40 PM, John Marino wrote: > Everything I have said is a fact, please illustrate which statement I made > seems emotional. Joining in this discussion at all? I wish *bsd people were just as responsive to bug reports... Ciao! Steven
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 7:26 AM, Steven Bosscher wrote: Ralf has found one such a vendor, it seems. But to me, that doesn't automatically imply that GCC must continue to support such a target. Other criteria should also be considered. For instance, quality of implementation and maintenance burden. Yes, of course these are valid concerns. It's just important to have all the facts. In particular, it would be interesting to contact this company and see if they use gcc. Perhaps they would be willing to invest some development effort?
Re: Deprecate i386 for GCC 4.8?
On Thu, Dec 13, 2012 at 1:48 PM, Ralf Corsepius wrote: > On 12/12/2012 08:54 PM, Robert Dewar wrote: >> >> On 12/12/2012 2:52 PM, Steven Bosscher wrote: >> >>> And as usual: If you use an almost 30 years old architecture, why >>> would you need the latest-and-greatest compiler technology? >>> Seriously... >> >> >> Well the embedded folk often end up with precisely this dichotomy :-) >> But if no sign of 386 embedded chips, then reasonable to deprecate > > > I've never heard about them before, nor do I know how far spread their > products are, however these folks seem to be producing i386-SoCs > http://www.dmp.com.tw/ > esp. this one > http://www.dmp.com.tw/tech/vortex86sx/ I've never heard of them either, but according to the manual ftp://ftp.dmp.com.tw/DMP_Vortex86_Series_Software_Programming_Reference_091216.pdf page 5, the Vortex86* products are 486 compatible. That being said, one that same webpage there is http://www.dmp.com.tw/tech/m6117d/ which is mentioned as "386SX" compatible. However, the above PDF, again page 5, says "The Vortex86 System-On-Chip (SoC) family was originally designed to provide product migration path to the existing user of the DMP M6117D SoC, a 40 MHz x86 SoC introduced to the market in the early 1990s that reached end-of-life in 2007." -- Janne Blomqvist
Re: Deprecate i386 for GCC 4.8?
>> Well the embedded folk often end up with precisely this dichotomy :-) >> But if no sign of 386 embedded chips, then reasonable to deprecate > > > I've never heard about them before, nor do I know how far spread their > products are, however these folks seem to be producing i386-SoCs > http://www.dmp.com.tw/ > esp. this one > http://www.dmp.com.tw/tech/vortex86sx/ The Vortex86 line is 486 compatible. DM&P's 386 SoC was end-of-lifed in 2007 according to ftp://downl...@ftp.dmp.com.tw/DMP_Vortex86_Series_Software_Programming_Reference_091216.pdf Regards, David Bremner
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 03:15 PM, Robert Dewar wrote: On 12/13/2012 7:26 AM, Steven Bosscher wrote: Ralf has found one such a vendor, it seems. But to me, that doesn't automatically imply that GCC must continue to support such a target. Other criteria should also be considered. For instance, quality of implementation and maintenance burden. Yes, of course these are valid concerns. It's just important to have all the facts. In particular, it would be interesting to contact this company and see if they use gcc. Perhaps they would be willing to invest some development effort? They at least mention linux and Ubuntu. c.f. http://www.dmp.com.tw/tech Ralf
Re: Deprecate i386 for GCC 4.8?
Quoting Ralf Corsepius : On 12/12/2012 08:54 PM, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) But if no sign of 386 embedded chips, then reasonable to deprecate I've never heard about them before, nor do I know how far spread their products are, however these folks seem to be producing i386-SoCs http://www.dmp.com.tw/ esp. this one http://www.dmp.com.tw/tech/vortex86sx/ I am not 100% sure, but from looking at the documents on that page I think it is based on the i486 rather than on the i386. My impression (although I am not quite up to date with the current situation) is that many (most?) x86 CPUs used in smaller embedded systems are i48&/i586 hybrids, i.e. they are i486-compatible and also supports some (but not all) features of the i586.
Re: Deprecate i386 for GCC 4.8?
On 12/13/2012 04:53 PM, Erik Trulsson wrote: Quoting Ralf Corsepius : On 12/12/2012 08:54 PM, Robert Dewar wrote: On 12/12/2012 2:52 PM, Steven Bosscher wrote: And as usual: If you use an almost 30 years old architecture, why would you need the latest-and-greatest compiler technology? Seriously... Well the embedded folk often end up with precisely this dichotomy :-) But if no sign of 386 embedded chips, then reasonable to deprecate I've never heard about them before, nor do I know how far spread their products are, however these folks seem to be producing i386-SoCs http://www.dmp.com.tw/ esp. this one http://www.dmp.com.tw/tech/vortex86sx/ I am not 100% sure, but from looking at the documents on that page I think it is based on the i486 rather than on the i386. Neither am I ;) My impression (although I am not quite up to date with the current situation) is that many (most?) x86 CPUs used in smaller embedded systems are i48&/i586 hybrids, i.e. they are i486-compatible and also supports some (but not all) features of the i586. No idea, on http://www.dmp.com.tw/tech/vortex86sx/faq.htm#3001 they are telling the Vortex86sx doesn't have an FPU, while the "upcoming Vortex86dx" would have one. Ralf
Re: Accessing Go type descriptors from the middle end
On Thu, Dec 13, 2012 at 4:16 AM, Matt Davis wrote: > > I have a GIMPLE pass and would like to make use of the data type > information that the Go frontend produces. Is there a way to access > this information from the middle end without having to query the > frontend? What kind of data type information are you interested in? In general you can't query the frontend from a GIMPLE pass. And the way the Go frontend is structured, it would be pretty hard to make that work even if it were possible. There is no mapping from GIMPLE types to Go types, because no such mapping is needed. Once the program has been converted to GIMPLE, the Go frontend is out of the picture anyhow. Ian
Forum about Legal Drugs
Legal drugs: smoking blends, powders and tablets. Trip-reports, reviews, contacts of proven sellers. For Russian ONLY. New website: http://www.narkop.net/ You can use your old login and password. This new domain name was registred via bullet-prof chinese registration service and never will be closed. Enjoy.
Re: Accessing Go type descriptors from the middle end
Hi Ian, Thank you for your reply. On Fri, Dec 14, 2012 at 10:00 AM, Ian Lance Taylor wrote: > On Thu, Dec 13, 2012 at 4:16 AM, Matt Davis wrote: >> >> I have a GIMPLE pass and would like to make use of the data type >> information that the Go frontend produces. Is there a way to access >> this information from the middle end without having to query the >> frontend? > > What kind of data type information are you interested in? I am working on an implementation of my alternate memory allocator for Go. This allocator makes use of the layout of data types. I was hoping to use the existing descriptors that are generated by the frontend, so that I would not have to create my own. My runtime will make use of these descriptors. However, it would suit me just as well to create my own type-information. It will just bloat the binary a bit, but, for my purposes, that is no big deal. > In general you can't query the frontend from a GIMPLE pass. And the > way the Go frontend is structured, it would be pretty hard to make > that work even if it were possible. There is no mapping from GIMPLE > types to Go types, because no such mapping is needed. Once the > program has been converted to GIMPLE, the Go frontend is out of the > picture anyhow. Ah, that's cool. Thank you very much for your input. -Matt
Re: Accessing Go type descriptors from the middle end
On Thu, Dec 13, 2012 at 3:52 PM, Matt Davis wrote: > > On Fri, Dec 14, 2012 at 10:00 AM, Ian Lance Taylor wrote: >> On Thu, Dec 13, 2012 at 4:16 AM, Matt Davis wrote: >>> >>> I have a GIMPLE pass and would like to make use of the data type >>> information that the Go frontend produces. Is there a way to access >>> this information from the middle end without having to query the >>> frontend? >> >> What kind of data type information are you interested in? > > I am working on an implementation of my alternate memory allocator for Go. > This allocator makes use of the layout of data types. I was hoping to > use the existing descriptors that are generated by the frontend, so > that I would not have to create my own. My runtime will make use of > these descriptors. However, it would suit me just as well to create my > own type-information. It will just bloat the binary a bit, but, for > my purposes, that is no big deal. The Go frontend allocates memory by calling just a few magic functions, all listed in gcc/go/gofrontend/runtime.def. I would change those functions to take a type descriptor as a parameter where they don't already do so. Then you can reliably find them in your GIMPLE pass and get the Go type descriptor. Ian
Re: New dump infrastructure
On Tue, Dec 11, 2012 at 1:43 AM, Richard Biener wrote: > On Mon, Dec 10, 2012 at 8:55 PM, Sharad Singhai wrote: >> On Mon, Dec 10, 2012 at 11:02 AM, Richard Biener >> wrote: >>> On Mon, Dec 10, 2012 at 7:46 PM, Sharad Singhai wrote: Hi, The new dump infrastructure was committed shortly before the trunk entered stage 3. However, except the vectorization passes, other passes do not dump anything in response to -fopt-info flags despite the documentation. I can prepare patches for a couple more passes so that they output more meaningful information, otherwise, the -fopt-info would remain largely useless in 4.8. Also I suspect some other passes can be converted relatively easily to use the new dump scheme. Would it be acceptable to consider -fopt-info patches in stage 3? If yes, I can send out a more detailed message about the conversion and solicit for help. >>> >>> It should be decided on a case-by-case basis. What passes do you have in >>> mind >>> that people are usually interested in in the context of -fopt-info? >> >> For starters, I was looking at unrolling and inlining decisions >> (loop-unroll.c and tree-inline.c respectively). > > Unrolling is probably easy, I'm not sure how to handle inlining (the info > will be very noisy for C++ for example, so eventually early inlining should > be excempt). Make sure to propose separate patches for different passes > you handle - giving examples of -fopt-info output for them. I do think that > exposing more stuff via it for 4.8 would be nice. Yes, unrolling to use new dump scheme was quite easy. I proposed a patch in http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00953.html. I think I will hold off on inlining as it seems more involved. I looked at if-conversion and that looks like a ripe candidate for next dump conversion. Thanks, Sharad
