Re: Deprecate i386 for GCC 4.8?
Quoting Ralf Corsepius : 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. Well, the Intel 80486sx did not have an FPU either, while the 80486dx did have one. From the Pentium (i586) onwards all Intel x86 CPUs have been equipped with an FPU, so not having an FPU would fit in with being compatible with i486 but not the i586.
How does address sanitizer handle read-modify-write memory access?
Hello!
c-c++-common/asan/null-deref-1.c test can generate read-modify-write
instruction ("incl 40(%eax)") when compiled with -Os. However,
address-sanitizer only calls __asan_report_load4 in this case. With
-O2, load of value, modification and store are different instructions,
and address-sanitizer calls __asan_report_load4 and
__asan_report_store4.
BTW: This testcase currently fails on x32 [1], but I don't have x32
runtime to investigate runtime failure further.
[1] http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01227.html
Uros.
Re: How does address sanitizer handle read-modify-write memory access?
Hi Uros,
When we have a code like X++ (either RMW, or a regular increment) it
is enough for asan to instrument it just once (either as a read or a
write, doesn't matter).
LLVM implementation does this optimization for regular increments,
while GCC does not (yet).
% cat inc.cc
void foo(int *a) {
(*a)++;
}
% clang -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
callq __asan_report_load4
% gcc -O2 -fsanitize=address -S -o - inc.cc | grep __asan_report
call__asan_report_load4
call__asan_report_store4
Doing two __asan_report* calls here is not a correctness bug, but a
performance problem.
I think we saw ~3%-5% performance gain due to this optimization in
LLVM, i.e. this is nice to have, but not critical.
hth,
--kcc
On Fri, Dec 14, 2012 at 1:22 PM, Uros Bizjak wrote:
> Hello!
>
> c-c++-common/asan/null-deref-1.c test can generate read-modify-write
> instruction ("incl 40(%eax)") when compiled with -Os. However,
> address-sanitizer only calls __asan_report_load4 in this case. With
> -O2, load of value, modification and store are different instructions,
> and address-sanitizer calls __asan_report_load4 and
> __asan_report_store4.
>
> BTW: This testcase currently fails on x32 [1], but I don't have x32
> runtime to investigate runtime failure further.
>
> [1] http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01227.html
>
> Uros.
Re: Deprecate i386 for GCC 4.8?
On 12/14/2012 10:03 AM, Erik Trulsson wrote: Well, the Intel 80486sx did not have an FPU either, while the 80486dx did have one. From the Pentium (i586) onwards all Intel x86 CPUs have been equipped with an FPU, so not having an FPU would fit in with being compatible with i486 but not the i586. Thanks, you are right. I am always forget about the SXes ;) Ralf
Re: Deprecate i386 for GCC 4.8?
On 13/12/12 11: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. Sun/Oracle has never, to my knowledge used GCC as it's primary compiler. Yet that's still a primary platform. R.
Re: Adding Rounding Mode to Operations Opcodes in Gimple and RTL
On Fri, Dec 14, 2012 at 12:16 PM, Michael Zolotukhin wrote: > Hi, > I found quite an old bug PR34768 and was thinking of doing what was > suggested there. > Particularly, I was wondering about adding new subcodes to gimple and > rtl for describing operations with rounding. > > Currently, I think the problem could be tackled in the following way: > In gimple we'll need to add a pass that would a) find regions with > constant, compile-time known rounding mode, b) replace operations with > subcodes like plus/minus/div/etc. with the corresponding operations > with rounding (plus_ru, plus_rd etc.), c) remove fesetround calls if > the region doesn't contain instructions that could depend on rounding > mode. > In RTL we'll need to support the instructions with rounding mode, and > also we'll need to be able to somehow emit such instructions. > Probably, we'll need a reverse transformation to insert fesetround > calls around the regions with instructions with rounding - that could > be done by mode_switching pass. > > If this approach looks reasonable to you, then there are more questions: > 1) What is the best way to represent operations with rounding in > Gimple and RTL? Should we add plus_round and add an attribute to > describe rounding mode, or we should add opcodes for different > rounding modes (plus_round_up, plus_round_down, etc.) - of course, > that should be done for all opcodes that are affected by rounding, not > only plus-opcode. > 2) What's the best place to insert the new passes? > > Any other input is more than welcome on this. Exposing known rounding modes as new operation codes may sound like a good idea (well, I went a similar way with trying to make operations with undefined overflow explicit ... but the fallout was quite large even though there is only one kind of undefined overflow and not many operation codes that are affected ... so the work stalled - see no-undefined-overflow branch). But don't under-estimate the fallout - both in wrong-code and missed-optimizations. You'd definitely want to keep 'unknown rounding mode' operation codes (where I'd suggest to make the existing ones match that). Not sure if we want to start allocating sub-spaces of codes to a group to allow flag-like composition (say, PLUS_EXPR gets 0x10 and the lower nibble specifies the rounding mode). It looks more appealing for the rounding mode case (more cases) than for the binary (un-)defined overflow case. You'd want to expose the rounding mode libc functions as builtins to be able to detect them. That's good anyway and can be done independently (they currently act as memory optimization barrier which avoids most of the issues with -frounding-math support). Insertion of rounding mode changes has to be done after 2nd scheduling (and you probably want to have even 1st scheduling optimize the schedule for rounding mode changes ...). Machine-reorg is one natural place to do it (or where we currently insert vzeroupper). Similar to the FP rounding mode mess is handling of undefined overflow, also a similar mess but with a different proposed solution is that of -ftrapv support (and general overflow detection) - there is a bugreport which contains quite detailed analysis and suggestion from Joseph about this. Unless you really need the FP rounding mode problem solved I suggest to look at either "simpler" issues first ;) Thanks, Richard. > -- > --- > Best regards, > Michael V. Zolotukhin, > Software Engineer > Intel Corporation.
Re: Deprecate i386 for GCC 4.8?
On Fri, 14 Dec 2012, Richard Earnshaw wrote: Sun/Oracle has never, to my knowledge used GCC as it's primary compiler. I believe they have (early solaris 10), but that was on x86_64, not sparc (which is the one in the primary platform list). -- Marc Glisse
Please don't deprecate i386 for GCC 4.8
Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. Thanks! Cynthia Rempel From: rtems-devel-boun...@rtems.org [rtems-devel-boun...@rtems.org] on behalf of Ralf Corsepius [ralf.corsep...@rtems.org] Sent: Wednesday, December 12, 2012 8:30 PM To: rtems-de...@rtems.org; RTEMS Users Subject: GCC considers to drop i386 Hi, I'd like to pass on this to the RTEMS community: http://gcc.gnu.org/ml/gcc/2012-12/msg00079.html Executive summary: It has been proposed to GCC to drop the i386 CPU and to switch to i486 as minimal required CPU for the ix86-architecture. As RTEMS seems to be one of the last remaining dinosaurs, who is trying to support the i386, this would significantly impact RTEMS and its toolchains. I'd therefore ask all RTEMS users, who might have something substantial to say or have a strong opinion on this topic (e.g. because their works are really using i386s), to reply to the original thread on the GCC list. Otherwise, the i386 is likely gone very soon - If you are using it speak up *now*. This likely your last chance! Sorry for being a little dramatic, but I feel it's inevitable. Thanks in advance. Ralf ___ rtems-devel mailing list rtems-de...@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Please don't deprecate i386 for GCC 4.8
On 12/14/2012 3:13 PM, Cynthia Rempel wrote: Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. Since there is a significant maintenance burden for such continued support, I guess a question to ask is whether the RTEMS folks or someone using RTEMS are willing to step in and shoulder this burden.
Re: Please don't deprecate i386 for GCC 4.8
Having read this whole thread, Ivote for deprecating the 386. People using this ancient architecture can perfectly well use older versions of gcc that have this support.
Re: Please don't deprecate i386 for GCC 4.8
On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote: > On 12/14/2012 3:13 PM, Cynthia Rempel wrote: >> >> Hi, >> >> RTEMS still supports the i386, and there are many i386 machines still >> in use. Deprecating the i386 will negatively impact RTEMS ability to >> support the i386. As Steven Bosscher said, the "benefits" are small, >> and the impact would be serious for RTEMS i386 users. > > Since there is a significant maintenance burden for such continued > support, I guess a question to ask is whether the RTEMS folks or > someone using RTEMS are willing to step in and shoulder this burden. Btw, while I see very sporadical testresults for arm-rtems and older results for v850 and sparc and powerpc-rtems testresult posting on gcc-testresults no such results exist for i386-rtems in 2012 which means it's current status is in the dark. If you want a port to be live show that it is live by posting regular testresults to gcc-testresults. Thanks, Richard.
Stale C++ ABI link
On http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html we have a stale link to http://www.codesourcery.com/public/cxx-abi/abi.html What's the new canonical location for this document? r~
RE: Stale C++ ABI link
Richard Henderson writes: > On > http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html > we have a stale link to > http://www.codesourcery.com/public/cxx-abi/abi.html >What's the new canonical location for this document? Looks like CodeSourcery is being assimilated into Mentor. The parent directory points to http://mentorembedded.github.com/cxx-abi/abi.html as the new location.
Re: Stale C++ ABI link
On 14 December 2012 21:51, Joe Buck wrote: > Richard Henderson writes: >> On >> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html >> we have a stale link to >> http://www.codesourcery.com/public/cxx-abi/abi.html > >>What's the new canonical location for this document? > > Looks like CodeSourcery is being assimilated into Mentor. The parent > directory points to > > http://mentorembedded.github.com/cxx-abi/abi.html > > as the new location. See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01828.html and the quoted mails below it. Gerald did ask me to update the libstdc++ docs but I didn't (and I'm still not sure what the consensus was regarding which link to use.)
gcc-4.6-20121214 is now available
Snapshot gcc-4.6-20121214 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121214/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 194510 You'll find: gcc-4.6-20121214.tar.bz2 Complete GCC MD5=e14afd1ff076548704222727dfe66fd7 SHA1=5a6e51d3eb008e92da32c21f721415a55ecdbd5e Diffs from 4.6-20121207 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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: Stale C++ ABI link
On 14 December 2012 21:58, Jonathan Wakely wrote: > Gerald did ask me to update the libstdc++ docs but I didn't (and I'm > still not sure what the consensus was regarding which link to use.) Actually the right fix for the libstdc++ docs seems pretty obvious, I'll do it tomorrow.
Keeping gcc ports live
Hi Richard Biener and Robert Dewar, Thanks for the fast response, I really appreciate it! I'll look into gcc-testresults for an i386, now that I know it's a requirement to keep a port live. I compile, and run, RTEMS for the pc386 RTEMS target regularly, so I know the 4.7 cross-compiler does that much, but I'll look into the gcc-testresults suite. Below are some links that would be helpful for anyone is interested in helping out with a different architecture live on gcc as well. gcc-testresults for RTEMS http://www.rtems.org/wiki/index.php/ToolStatus#GCC_Test_Results gcc-testresults for a cross-compiler http://gcc.gnu.org/simtest-howto.html Perhaps gcc-testing could be added to what an intern does to "get started" as part of Google Summer of Code for RTEMS? What else would be required to keep a target gcc port live? Thanks, Cynthia Rempel From: Richard Biener [richard.guent...@gmail.com] Sent: Friday, December 14, 2012 1:09 PM To: Robert Dewar Cc: Cynthia Rempel; gcc@gcc.gnu.org Subject: Re: Please don't deprecate i386 for GCC 4.8 On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote: > On 12/14/2012 3:13 PM, Cynthia Rempel wrote: >> >> Hi, >> >> RTEMS still supports the i386, and there are many i386 machines still >> in use. Deprecating the i386 will negatively impact RTEMS ability to >> support the i386. As Steven Bosscher said, the "benefits" are small, >> and the impact would be serious for RTEMS i386 users. > > Since there is a significant maintenance burden for such continued > support, I guess a question to ask is whether the RTEMS folks or > someone using RTEMS are willing to step in and shoulder this burden. Btw, while I see very sporadical testresults for arm-rtems and older results for v850 and sparc and powerpc-rtems testresult posting on gcc-testresults no such results exist for i386-rtems in 2012 which means it's current status is in the dark. If you want a port to be live show that it is live by posting regular testresults to gcc-testresults. Thanks, Richard.
Re: Please don't deprecate i386 for GCC 4.8
On 12/14/2012 09:16 PM, Robert Dewar wrote: On 12/14/2012 3:13 PM, Cynthia Rempel wrote: Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. > Since there is a significant maintenance burden for such continued support, I guess a question to ask is whether the RTEMS folks or someone using RTEMS are willing to step in and shoulder this burden. My view (with my RTEMS hat on) on this: I don't have a strong opinion on dropping the i386, but it will not be possible for me to "shoulder this burden". The primary reason for RTEMS having kept trying to support the i386 was it being the least troublesome, smallest common denominator being available on simulators for a long time. I doubt, nowadays, anybody is using RTEMS on real i386ers - Several years ago (IIRC, ca. 10), there had been at least one, that I am aware about. Ralf
Re: Please don't deprecate i386 for GCC 4.8
On 12/14/2012 10:09 PM, Richard Biener wrote: On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote: On 12/14/2012 3:13 PM, Cynthia Rempel wrote: Hi, RTEMS still supports the i386, and there are many i386 machines still in use. Deprecating the i386 will negatively impact RTEMS ability to support the i386. As Steven Bosscher said, the "benefits" are small, and the impact would be serious for RTEMS i386 users. Since there is a significant maintenance burden for such continued support, I guess a question to ask is whether the RTEMS folks or someone using RTEMS are willing to step in and shoulder this burden. Btw, while I see very sporadical testresults for arm-rtems and older results for v850 and sparc and powerpc-rtems testresult posting on gcc-testresults Correct. These results are side-effects of works from people who currently are working with these architectures, facing problems or porting RTEMS to these targets. This doesn't mean the other targets aren't used nor non functional, because RTEMS targets usually only are variants from the corresponding newlib-elf targets. no such results exist for i386-rtems in 2012 which means it's current status is in the dark. More or less correct. Older ix86-rtems-gcc's are known to work, newer ix86-rtems-gccs are known to have not yet fully understood problems (Related to soft-float math, i386 and not using a linux-libc). If you want a port to be live show that it is live by posting regular testresults to gcc-testresults. Not all of this world is Linux nor backed by large teams at companies :) We simply do not have the resources do to this. Ralf
Re: Deprecate i386 for GCC 4.8?
On Thu, 13 Dec 2012, John Marino wrote: > 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). Thanks, John. :-) (Note to those not aware I am taking care of those.) On Thu, 13 Dec 2012, Richard Biener wrote: > Well, I'm fine with changing it to i486-freebsd - just keeping > i386-freebsd listed but deprecating i386 looks odd. FreeBSD actually does not support i386 anymore either, this is just a way of referring to 32-bit x86. Cf. gcc/config/i386/freebsd.h /* Support for i386 has been removed from FreeBSD 6.0 onward. */ #if FBSD_MAJOR >= 6 #define SUBTARGET32_DEFAULT_CPU "i486" #endif So, making this change definitely should be fine. :-) On Thu, 13 Dec 2012, Steven Bosscher wrote: > 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. Per the above, i486 would be totally straightforward -- famous last words! -- and Loren reported i686 as working while still more active on the GCC and FreeBSD sides. On Thu, 13 Dec 2012, Richard Biener wrote: > If we deprecate i386 it shouldn't stay as i386-freebsd though. Yes, I can see how this would be confusing, even if (or rather: because?) that i386 actually is not really i386. On Thu, 13 Dec 2012, Steven Bosscher wrote: > 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... For the record, the reason we don't have those is that people on FreeBSD usually use the ports since, unlike most GNU/Linux distributions, those also are easy to build from source and the ports have been moving along GCC release branches, but rarely covering an actual GCC release (rather a few days before or after the release, usually). Looking at this thread overall, it occurs to me that nobody so far has objected to just renaming i386-unknown-freebsd* to i?86-unknown-freebsd* (where ? could be a verbatim ? or a 4 or a 6)? Gerald PS. I'll be offline for three weeks now most likely.
