Re: fatal error: gnu/stubs-32.h: No such file
On 07/30/2013 05:50 AM, David Starner wrote: > Sorry about the blank message; I accidentally hit the wrong button. > > On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: >> It was "This is possible, but it's tricky, and it's really important >> to get it right. We don't want a half-arsed patch." > > We've all seen cases where a quick patch is rejected in favor of a > hypothetical patch, and years down the road, the program still has the > problem. The people who blocked the quick patch, naturally, never > bothered trying to write the patch they wanted. This is true. It is a real problem. However, it's up to the proposer to propose something that works for everyone. No-one would object to a decent diagnostic. >> That's a mistranslation. It means that there are other criteria >> beyond some people having trouble. Such as, we really want multilibs >> to be built. > > Who is we here? And why do you really want multilibs built? "We" is the GCC community. "We" really want multilibs to be built so they get tested as much as possible. It's in the best interest of all GCC users that this happens. >>> I think you should detect the issue as *soon as practical* and then >>> *ALWAYS* emit a message that *TELLS THE USER WHAT TO DO*. >> >> Yes! Yes! Yes! > > Then what are we going to do about it? As per my first comment, nobody > has offered to produce a patch in the form you would be happy with, so > I'm not going to hold my breath that it's going to appear. So don't write one. Then you're likely to be proved right. Andrew.
Re: New file extension
On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. Yeah -- this sort of discrepancy I don't like either. In gcc/, we have 362 .c files and 0 .cc files, so every new .cc file will step out of line... That might be pain for people who are used to do 'grep foo gcc/*.c' and suchlike. Marek
Re: fatal error: gnu/stubs-32.h: No such file
On 07/30/2013 07:50 AM, David Starner wrote: Sorry about the blank message; I accidentally hit the wrong button. On Mon, Jul 29, 2013 at 7:19 AM, Andrew Haley wrote: It was "This is possible, but it's tricky, and it's really important to get it right. We don't want a half-arsed patch." We've all seen cases where a quick patch is rejected in favor of a hypothetical patch, and years down the road, the program still has the problem. The people who blocked the quick patch, naturally, never bothered trying to write the patch they wanted. That's a mistranslation. It means that there are other criteria beyond some people having trouble. Such as, we really want multilibs to be built. This is an interesting conflict of requirements. I see the point of both sides, being a developer on one side and being a user on the other. I really appreciate the fact that I got a clear message telling me to install mpc. I would have hated needing to google for a cryptic error message. How about a middle-ground, not aiming at cross compilation? If --enable-multilib or --disable-multilib are passed then things are performed as today, more or less. If these flags are not explicitly given then gcc has to do something different: If the system compiler is GCC then 'configure' tries if the system GCC can build i686/x86-64/x32/etc. If the system gcc creates workable executables then all is fine and 'configure' proceeds to a multilib build. Otherwise an error will be emitted saying something like: " I can't figure out if your system has [???] development libraries. If you have [???] then rerun configure with --enable-multilib If you don't have [???] then you should rerun configure with --disable-multilib You should note that if you pass --enable-multilib despite having no [???] development libraries, then you would likely get the following error at the last stages of bulid: gnu/stubs-[???].h: No such file " This should be relatively simple to implement, and will catch most cases. I guess that a native English speaker can phrase something more readable and welcoming. Michael
Re: New file extension
On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > have 362 .c files and 0 .cc files, so every new .cc file will step out > of line... That might be pain for people who are used to do > 'grep foo gcc/*.c' and suchlike. Any issues with doing a mass rename then? Diego.
Re: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >> I do not care very much but I disagree. Having some files with .c > >> suffix and some with .cc suffix would imply some sort of difference > >> where there is going to be none. > > > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > > have 362 .c files and 0 .cc files, so every new .cc file will step out > > of line... That might be pain for people who are used to do > > 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? I think it is a good idea now (except perhaps for the very few source files which could still be compiled by a plain C, not C++, compiler; maybe we don't have anymore them...). FWIW, when compiling GCC trunk with Clang3.4 (i.e. on Debian/Sid+Experimental) I am getting warnings about *.c being a C++ file. And I think newbies are distracted also by .c files being in C++ (not to mention emacs or other editors being possibly confused). So I am in favor of a massive renaming. (But please do it in one single huge svn commit). Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
Re: New file extension
On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > I think it is a good idea now (except perhaps for the very few source files > which could still be compiled by a plain C, not C++, compiler; maybe we > don't have anymore them...). gcov-io.c is C code used for both host and target (one of the remaining bits of target library source not moved out of the gcc/ directory because of the complications of the dual way it's used), but it's used for the host (and built as C++ when so used) via #include in other .c files rather than being built directly. Various Ada runtime library files are also .c under gcc/ada - in general, I'm not sure which .c files there are used as C, C++ or both, and which are used for host, target or both; that would require careful investigation for any renaming. -- Joseph S. Myers jos...@codesourcery.com
powf(float,float) function from math.h on ARM32-bit platform
I have written a std code for ARM 32-bit platform using math.h library and float=powf(float,float) function. When I give input to my system as 100 ^ 4.4 it gives me answer as 630957632. (as float) whereas calculator in WindowsXP gives answer as 630957344.48019324943436013662234. I just want to know which one is more accurate why is difference ? on what things accuracy depends Also what do we mean by "arbitrary"-precision??? I have read such word on MSDN help forums. how much accurate is my system how to improve accuracy?? Thanks in advance!!! -- View this message in context: http://gcc.1065356.n5.nabble.com/powf-float-float-function-from-math-h-on-ARM32-bit-platform-tp956727.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: New file extension
On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >> I do not care very much but I disagree. Having some files with .c > >> suffix and some with .cc suffix would imply some sort of difference > >> where there is going to be none. > > > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > > have 362 .c files and 0 .cc files, so every new .cc file will step out > > of line... That might be pain for people who are used to do > > 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? If various svn/git blame/log's would work, then I'm fine with it. It's been discussed on gcc@ at some point; I don't remember any major (dis)advantages. Ok, I'll rename my new .c files to .cc. Marek
Re: New file extension
Hi, On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > >> I do not care very much but I disagree. Having some files with .c > >> suffix and some with .cc suffix would imply some sort of difference > >> where there is going to be none. > > > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > > have 362 .c files and 0 .cc files, so every new .cc file will step out > > of line... That might be pain for people who are used to do > > 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? > Well, IIRC mostly worries about history. SVN claims to be able to track history of renamed files but I use the git mirror now and I wonder what the history would show there. I would consider it very unfortunate if 'git blame' did not show the .c era history of the renamed files. But maybe it would just work. I think that proponents of this idea should make some experiments along these lines to estimate the cost. OTOH, I think the time can be spent better (and that is also the reason why I will not fight about this beyond writing this message). As far as newbies are concerned, I think that grasping that .c files are C++ files is one of the easy things to learn about GCC compared to other necessary knowledge (which is something we should work on). If the problem is that your emacs opens gcc files in C mode instead of C++, add this to your .emacs file: (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode)) Even after a rename you would have to do something like that for the .h files anyway. Thanks, Martin
Re: New file extension
On Tue, Jul 30, 2013 at 11:51:35AM +, Joseph S. Myers wrote: > On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > > > I think it is a good idea now (except perhaps for the very few source files > > which could still be compiled by a plain C, not C++, compiler; maybe we > > don't have anymore them...). > > gcov-io.c is C code used for both host and target (one of the remaining > bits of target library source not moved out of the gcc/ directory because > of the complications of the dual way it's used), but it's used for the > host (and built as C++ when so used) via #include in other .c files rather > than being built directly. > > Various Ada runtime library files are also .c under gcc/ada - in general, > I'm not sure which .c files there are used as C, C++ or both, and which > are used for host, target or both; that would require careful > investigation for any renaming. Ok. Then we could at leat rename to *.cc those files which are obviously directly using C++ features (e.g. the class or virtual C++ keywords). Maybe these files should before renaming have #ifndef __cplusplus #error should be compiled as C++ code #endif ?? Cheers -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basilestarynkevitchnet mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
Re: New file extension
> Various Ada runtime library files are also .c under gcc/ada - in general, > I'm not sure which .c files there are used as C, C++ or both, and which > are used for host, target or both; that would require careful > investigation for any renaming. The C files directly under ada/ cannot be renamed since they are meant to be compiled by the C compiler; only the ones under ada/gcc-interface can. -- Eric Botcazou
Re: New file extension
On 07/30/2013 08:27 AM, Marek Polacek wrote: On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: I do not care very much but I disagree. Having some files with .c suffix and some with .cc suffix would imply some sort of difference where there is going to be none. Yeah -- this sort of discrepancy I don't like either. In gcc/, we have 362 .c files and 0 .cc files, so every new .cc file will step out of line... That might be pain for people who are used to do 'grep foo gcc/*.c' and suchlike. Any issues with doing a mass rename then? I'd suggest waiting for a mass rename until the next stage 1... (or stage 0.9 :-) I will want to mass rename a lot of the files (ie, a lot of tree-* will lose the tree- prefix), and I think we'll be moving directory structures around as well... and some include files will be split up... etc. etc.Seems like a logical time to change extensions too. My point is, why go through the pain of changing a bunch of files now when we are probably going to do it again within a year. Andrew
Re: New file extension
On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: > On 07/30/2013 08:27 AM, Marek Polacek wrote: > >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: > >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: > >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. > >>>Yeah -- this sort of discrepancy I don't like either. In gcc/, we > >>>have 362 .c files and 0 .cc files, so every new .cc file will step out > >>>of line... That might be pain for people who are used to do > >>>'grep foo gcc/*.c' and suchlike. > >>Any issues with doing a mass rename then? > I'd suggest waiting for a mass rename until the next stage 1... (or > stage 0.9 :-) I will want to mass rename a lot of the files (ie, a > lot of tree-* will lose the tree- prefix), and I think we'll be > moving directory structures around as well... and some include files > will be split up... etc. etc.Seems like a logical time to change > extensions too. > > My point is, why go through the pain of changing a bunch of files > now when we are probably going to do it again within a year. On second thought, yes, waiting for mass rename sounds better than to add one .cc file... Marek
Re: fatal error: gnu/stubs-32.h: No such file
On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley wrote: > "We" is the GCC community. "We" really want multilibs to be built so > they get tested as much as possible. It's in the best interest of > all GCC users that this happens. "We" really want Ada to be built so that it gets tested as much as possible. "We" really want ARM to be built so that it gets tested as much as possible. I don't see the distinction. Those who need multilibs support should be responsible for making sure that it works right. Presumably enough people do need it. Those that don't should have to shoulder the burden for those who do. > So don't write one. Then you're likely to be proved right. So what you're saying is that "we" don't care if people can easily build "our" compiler. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
On Mon, Jul 29, 2013 at 9:58 PM, Andrew Pinski wrote: > On Mon, Jul 29, 2013 at 9:50 PM, David Starner wrote: >> We've all seen cases where a quick patch is rejected in favor of a >> hypothetical patch, and years down the road, the program still has the >> problem. The people who blocked the quick patch, naturally, never >> bothered trying to write the patch they wanted. > > The problem here is a quick patch makes the situation worse rather > than better. That is the reason why the quick patch is rejected. If it were replaced with a better one, that wouldn't be a problem. > The defaults are there for the > majority of users That remains to be seen. As I said, a substantial majority of Debian users on AMD64 who can compile C programs can't compile for 32 bits. > and majority of users of compiling a compiler knows > the risks of not having the current libraries installed. The "current" libraries? Currency has nothing to do with it. The libc development files for a 32-bit system, which are normally not needed for compiling on a pure 64-bit system. In any case, a couple normal developers on this list have said that has bit them. > That is because it is a hard to do and will force extra time in > compiling and might cause incorrect handling of cross builds. > Remember the host compiler does not have to compile for the multi-lib; > only the newly compiled compiler will be able to. Which goes straight to my first point. There is a build-time bug in GCC that will bite many Linux AMD64 users who might be interesting in trying to build a new version of GCC. It apparently will be there for many years. Certainly this reduces any inclination I might have had of actually trying to figure out GCC's build system and find a patch, as Andrew Haley suggests. -- Kie ekzistas vivo, ekzistas espero.
Re: fatal error: gnu/stubs-32.h: No such file
> If --enable-multilib or --disable-multilib are passed then things > are performed as today, more or less. If these flags are not > explicitly given then gcc has to do something different This sounds reasonable. We could have a specific check, with the following cumulative conditions (to make it as unobtrusive as possible for current users). If: 1. we build a native compiler 2. on x86_64-linux (and possible other x86_64 targets whose maintainers want to opt in) 3. and neither --enable-multilib nor --disable-multilib were passed then: a. we check that the native compiler can handle 32-bit, by compiling a test executable with the "-m32" option b. if we fail, we error out of the configure process, indicating that this can be overriden with --{enable,disable}-multilib I suspect this might catch (at configure time) the large majority of users who currently get stuck at stage 2 with the "gnu/stubs-32.h" error, while being invisible to a large majority of the power users. Question: what are the pitfalls of the test proposed above? are there typical use cases that I have not thought of, and that would trigger this check? FX PS: I attach a tentative patch implementing such as check in configure.ac. Index: configure.ac === --- configure.ac(revision 201292) +++ configure.ac(working copy) @@ -2861,6 +2861,26 @@ case "${target}" in ;; esac +# Special user-friendly check for native x86_64-linux build, if +# multilib is not explicitly enabled. +case "$target:$have_compiler:$host:$target:$enable_multilib" in + x86_64-*linux*:yes:$build:$build:) +# Make sure we have a developement environment that handles 32-bit +dev64=no +echo "int main () { return 0; }" > conftest.c +${CC} -m32 -o conftest ${CFLAGS} ${CPPFLAGS} ${LDFLAGS} conftest.c +if test $? = 0 ; then + if test -s conftest || test -s conftest.exe ; then + dev64=yes + fi +fi +rm -f conftest* +if test x${dev64} != xyes ; then + AC_MSG_ERROR([I suspect your system does not have 32-bit developement libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.]) +fi +;; +esac + # Default to --enable-multilib. if test x${enable_multilib} = x ; then target_configargs="--enable-multilib ${target_configargs}"
Re: [x86-64 psABI]: Extend x86-64 psABI to support AVX-512
On Wed, Jul 24, 2013 at 08:25:14AM -1000, Richard Henderson wrote: > On 07/24/2013 05:23 AM, Richard Biener wrote: > > "H.J. Lu" wrote: > > > >> Hi, > >> > >> Here is a patch to extend x86-64 psABI to support AVX-512: > > > > Afaik avx 512 doubles the amount of xmm registers. Can we get them callee > > saved please? > > Having them callee saved pre-supposes that one knows the width of the > register. Whole architecture of SSE/AVX is based on the fact of zerroing-upper. For references - take a look at definition of VLMAX in Spec. E.g. for AVX2 we had: vaddps %ymm1, %ymm2, %ymm3 Intuition says (at least to me) that after compilation it shouldn't have an idea of 256-bit `upper' half. But with AVX-512 we have (again, see Spec, operation section of vaddps, VEX.256 encoded): DEST[31:0] = SRC1[31:0] + SRC2[31:0] ... DEST[255:224] = SRC1[255:224] + SRC2[255:224]. DEST[MAX_VL-1:256] = 0 So, legacy code *will* change upper 256-bit of vector register. The roots can be found in GPR 64-bit insns. So, we have different behavior on 64-bit and 32-bit target for following sequence: push %eax ;; play with eax pop %eax on 64-bit machine upper 32-bits of %eax will be zeroed, and if we'll try to use old version of %rax - fail! So, following such philosophy prohibits to make vector registers callee-safe. BUT. What if we make couple of new registers calle-safe in the sense of *scalar* type? So, what we can do: 1. make callee-safe only bits [0..XXX] of vector register. 2. make call-clobbered bits of (XXX..VLMAX] in the same register. XXX is number of bits to be callee-safe: 64, 80, 128 or even 512. Advantage is that when we are doing FP scalar code, we don’t bother about save/restore callee-safe part. vaddss %xmm17, %xmm17, %xmm17 call foo vaddss %xmm17, %xmm17, %xmm17 We don’t care if `foo’: - is legacy in AVX-512 sense – it just see no xmm17 - in future ISA sense. If this code is 1024-bit wide reg and `foo’ is AVX-512. It will save XXX bits, allowing us to continue scalar calculations without saving/restore -- Thanks, K
Re: fatal error: gnu/stubs-32.h: No such file
On 07/30/2013 01:52 PM, David Starner wrote: > On Tue, Jul 30, 2013 at 12:56 AM, Andrew Haley wrote: >> "We" is the GCC community. "We" really want multilibs to be built so >> they get tested as much as possible. It's in the best interest of >> all GCC users that this happens. > > "We" really want Ada to be built so that it gets tested as much as > possible. "We" really want ARM to be built so that it gets tested as > much as possible. I don't see the distinction. Those who need > multilibs support should be responsible for making sure that it works > right. Presumably enough people do need it. Those that don't should > have to shoulder the burden for those who do. The burden of typing "--disable-multilib". >> So don't write one. Then you're likely to be proved right. > > So what you're saying is that "we" don't care if people can easily > build "our" compiler. No. I'm saying that you care enough to argue but not enough to write a patch. If you really wanted to change the status quo that's what you'd have done by now. Andrew.
Improve -ftree-loop-distribution
Hi, I thought about optimizing memcpy and have an idea to transform patterns without having to deal with aliasing. When we are not sure about aliasing we can still replace loop with call of this function (provided that we know that n is large): static int __memcpy_loop(char *to,char *from, size_t n, int diff) { size_t i; if (!overlap) memcpy(to, from, n); else for (i=0; i
Re: New file extension
On Mon, Jul 29, 2013 at 3:08 PM, Martin Jambor wrote: > On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote: >> Hi, >> >> I would like to suggest that new implementation files have >> the '.cc' extension, unless they are meant to be processed >> with a C compiler. (I am not proposing wholesale renaming.) >> > > I do not care very much but I disagree. Having some files with .c > suffix and some with .cc suffix would imply some sort of difference > where there is going to be none. Much more confusing than C++ > compiled .c files, especially to newcomers, I suppose... and I though > we cared about them, that's the reason why I'm writing this email. I > will not be surprised by this myself, so I can live with it. > > Martin We do care about newcomers, but with all these new projects for refactoring, rewrites going on, I think you are worrying about things that may start "big" now but will be vanishing as the GCC project lives on. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 6:13 AM, Diego Novillo wrote: > On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >> On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >>> I do not care very much but I disagree. Having some files with .c >>> suffix and some with .cc suffix would imply some sort of difference >>> where there is going to be none. >> >> Yeah -- this sort of discrepancy I don't like either. In gcc/, we >> have 362 .c files and 0 .cc files, so every new .cc file will step out >> of line... That might be pain for people who are used to do >> 'grep foo gcc/*.c' and suchlike. > > Any issues with doing a mass rename then? I didn't want to open of the can of worm where would find any reason to make this happen. There might be genuine concerns with people doing work on branches. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 4:04 AM, Marek Polacek wrote: > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. > > Yeah -- this sort of discrepancy I don't like either. In gcc/, we > have 362 .c files and 0 .cc files, so every new .cc file will step out > of line... Any thing *new* steps out of line for someone. Putting C++ programs in .c file is out of line for most people, including the newcomers that people worry about. For many tools, including editors, .c is a C file, not a C++ file, so you don't get the benefit of working with a C++ program. > That might be pain for people who are used to do > 'grep foo gcc/*.c' and suchlike. > > Marek
Re: New file extension
On Tue, Jul 30, 2013 at 6:51 AM, Joseph S. Myers wrote: > On Tue, 30 Jul 2013, Basile Starynkevitch wrote: > >> I think it is a good idea now (except perhaps for the very few source files >> which could still be compiled by a plain C, not C++, compiler; maybe we >> don't have anymore them...). > > gcov-io.c is C code used for both host and target (one of the remaining > bits of target library source not moved out of the gcc/ directory because > of the complications of the dual way it's used), but it's used for the > host (and built as C++ when so used) via #include in other .c files rather > than being built directly. This is a good example of what I meant originally by "unless they are meant to be processed by a C compiler." > Various Ada runtime library files are also .c under gcc/ada - in general, > I'm not sure which .c files there are used as C, C++ or both, and which > are used for host, target or both; that would require careful > investigation for any renaming. Indeed. -- Gaby
Re: New file extension
On Tue, Jul 30, 2013 at 7:28 AM, Martin Jambor wrote: > As far as newbies are concerned, I think that grasping that .c files > are C++ files is one of the easy things to learn about GCC compared to > other necessary knowledge (which is something we should work on). One more oddities compared to standard practice. > If the problem is that your emacs opens gcc files in C mode instead of > C++, add this to your .emacs file: > > (add-to-list 'auto-mode-alist '("gcc/.+\\.[ch]\\'" . c++-mode)) More oddities: we assume Emacs, and we want people to add those things. Are we sure we are worrying about newcomers, or just fighting to preserve the way things used to be 20 years?
Re: New file extension
On Tue, Jul 30, 2013 at 7:42 AM, Marek Polacek wrote: > On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote: >> On 07/30/2013 08:27 AM, Marek Polacek wrote: >> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: >> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: >> >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: >> I do not care very much but I disagree. Having some files with .c >> suffix and some with .cc suffix would imply some sort of difference >> where there is going to be none. >> >>>Yeah -- this sort of discrepancy I don't like either. In gcc/, we >> >>>have 362 .c files and 0 .cc files, so every new .cc file will step out >> >>>of line... That might be pain for people who are used to do >> >>>'grep foo gcc/*.c' and suchlike. >> >>Any issues with doing a mass rename then? >> I'd suggest waiting for a mass rename until the next stage 1... (or >> stage 0.9 :-) I will want to mass rename a lot of the files (ie, a >> lot of tree-* will lose the tree- prefix), and I think we'll be >> moving directory structures around as well... and some include files >> will be split up... etc. etc.Seems like a logical time to change >> extensions too. >> >> My point is, why go through the pain of changing a bunch of files >> now when we are probably going to do it again within a year. > > On second thought, yes, waiting for mass rename sounds better than to > add one .cc file... > > Marek I am skeptical we would be able to implement mass renaming. -- Gaby
Re: powf(float,float) function from math.h on ARM32-bit platform
On 30/07/13 12:59, hemant wrote: I have written a std code for ARM 32-bit platform using math.h library and float=powf(float,float) function. When I give input to my system as 100 ^ 4.4 it gives me answer as 630957632. (as float) whereas calculator in WindowsXP gives answer as 630957344.48019324943436013662234. I just want to know which one is more accurate why is difference ? on what things accuracy depends Also what do we mean by "arbitrary"-precision??? I have read such word on MSDN help forums. how much accurate is my system how to improve accuracy?? Congratulations, you've just reached the limit for single-precision accuracy... #include #include int main() { printf ("float %f\ndouble: %f\n", powf(100, 4.4), pow(100, 4.4)); return 0; } $ gcc pow.c -lm $ ./a.out float 630957632.00 double: 630957344.480194 R.
Re: powf(float,float) function from math.h on ARM32-bit platform
On 07/30/2013 02:59 PM, hemant wrote: I have written a std code for ARM 32-bit platform using math.h library and float=powf(float,float) function. When I give input to my system as 100 ^ 4.4 it gives me answer as 630957632. (as float) whereas calculator in WindowsXP gives answer as 630957344.48019324943436013662234. I just want to know which one is more accurate why is difference ? on what things accuracy depends Also what do we mean by "arbitrary"-precision??? I have read such word on MSDN help forums. how much accurate is my system how to improve accuracy?? You should read: http://en.wikipedia.org/wiki/IEEE_754 The reason is that 4.4 is not accurately represented in binary. This is like 1/3 which isn't accurately represented in decimal. To calculate the impact of this inaccuracy, you need to consider the structure of float. Float has 23 bits fraction+one leading '1' bit. This means that you have a 24 bit significand. Assuming 'round to nearest' error= 4.4* 2.0^{-24} And the float value is around 4.4+/- error. I computed this with 'bc' using scale=100 and got 100^(4.4+error)-100^4.4 = 762.0... 100^(4.4-error)-100^4.4 = -762.0... Before even considering the inaccuracy of assigning pow's result to float, you get an answer which can be off by +/- 762. Also, since pow(b,e) is implemented, as far as I know, by exp(log(b)*e) you've got 3 operations and not one, which add up their inaccuracies. So your *theoretical* accuracy is even lower, much lower since most inaccuracies are accumulated to the argument of 'exp'. It's probably around +/-2286. This explains why you've got a result which is off by nearly 300. It could have been much worse. Michael
Mips testcase question
Richard, I have noticed that gcc.target/mips/fpr-moves-7.c and gcc.target/mips/fpr-moves-8.c fail when running the GCC testsuite with -msoft-float. I think it is because of this code in mips.exp: if { [mips_using_mips16_p options] && ![mips_same_option_p $abi "-mabi=32"] && ![mips_same_option_p $abi "-mabi=o64"] && (![mips_have_option_p options "addressing=absolute"] || [mips_have_option_p options "-mhard-float"]) } { if { [mips_test_option_p options mips16] } { mips_make_test_option options "addressing=absolute" mips_make_test_option options "-msoft-float" } else { mips_make_test_option options "-mno-mips16" } } If we are running with -hard-float and the test specifies -mips16 then we set addressing=absolute and -msoft-float. But if we were -msoft-float to begin with then we do not set addressing=absolute. This matters because later, addressing=absolute implies -mplt and -mplt implies -msym32 and it is the -msym32 flag that is allowing these tests to pass with -mhard-float. If I run with -msoft-float then -msym32 never gets set and the test fails. Should addressing=absolute be set here for soft-float in mips.exp or do you think these two tests should just not be run in soft-float mode? Steve Ellcey sell...@mips.com
Mirrors for GCC
Hello, We wish to host new mirror sites for GCC. Here are the mirrors that are set up for GCC: + Mirrors-usa: http://mirrors-usa.go-parts.com/gcc/ ftp://mirrors-usa.go-parts.com/gcc/ rsync://mirrors-usa.go-parts.com/mirrors/gcc/ + Mirrors-ru: http://mirrors-ru.go-parts.com/gcc/ ftp://mirrors-ru.go-parts.com/gcc/ rsync://mirrors-ru.go-parts.com/mirrors/gcc/ + Mirrors-au: http://mirrors-au.go-parts.com/gcc/ ftp://mirrors-au.go-parts.com/gcc/ rsync://mirrors-au.go-parts.com/mirrors/gcc/ contact email: timojacob...@gmail.com contact name: Timo Jacob If you could update the links on your end at your convenience, that would be very helpful, and in the meantime, I can coordinate the latest uploads to the newest mirrors for you. Let me know if you have any questions. Kind Regards, Timo Jacob
Re: Mips testcase question
"Steve Ellcey " writes: > I have noticed that gcc.target/mips/fpr-moves-7.c and > gcc.target/mips/fpr-moves-8.c fail when running the GCC > testsuite with -msoft-float. Which configuration and test options are you using and what failure do you see? It works for me with mipsisa64-elf, so it sounds like it might be configuration-specific. With your comment about -msym32, I'm guessing you're running -mabi=64 non-PIC, but even mips-sim-idt64/-mabi=64/-msoft-float seems to work with mipsisa64-elf. Thanks, Richard
Re: Mips testcase question
On Tue, 2013-07-30 at 20:32 +0100, Richard Sandiford wrote: > "Steve Ellcey " writes: > > I have noticed that gcc.target/mips/fpr-moves-7.c and > > gcc.target/mips/fpr-moves-8.c fail when running the GCC > > testsuite with -msoft-float. > > Which configuration and test options are you using and what failure do > you see? It works for me with mipsisa64-elf, so it sounds like it might > be configuration-specific. > > With your comment about -msym32, I'm guessing you're running -mabi=64 non-PIC, > but even mips-sim-idt64/-mabi=64/-msoft-float seems to work with > mipsisa64-elf. > > Thanks, > Richard It looks like it may be specific to my linux target (mips-mti-linux-gnu). With my elf target (mips-mti-elf), I do not get the error. Here is the error I get when running the testsuite with -msoft-float, adding -msym32 to the option list will make the problem go away. Adding -fno-pic to the options does not fix the problem. Steve Ellcey sell...@mips.com Executing on host: /local/home/sellcey/nightly/obj-mips-mti-linux-gnu/gcc/final/gcc/xgcc -B/local/home/sellcey/nightly/obj-mips-mti-linux-gnu/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c -fno-diagnostics-show-caret -fdiagnostics-color=never --sysroot=/local/home/sellcey/nightly/install-mips-mti-linux-gnu/sysroot-mips-mti-linux-gnu -O0 -DNOMIPS16=__attribute__((nomips16)) -DNOMICROMIPS=__attribute__((nomicromips)) -DNOCOMPRESSION=__attribute__((nocompression)) -mabi=64 -mips64r2 -EL -msoft-float -mgp64 -mlong64 -mno-micromips -DMIPS16=__attribute__((mips16)) -S -o fpr-moves-7.s(timeout = 300) spawn /local/home/sellcey/nightly/obj-mips-mti-linux-gnu/gcc/final/gcc/xgcc -B/local/home/sellcey/nightly/obj-mips-mti-linux-gnu/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c -fno-diagnostics-show-caret -fdiagnostics-color=never --sysroot=/local/home/sellcey/nightly/install-mips-mti-linux-gnu/sysroot-mips-mti-linux-gnu -O0 -DNOMIPS16=__attribute__((nomips16)) -DNOMICROMIPS=__attribute__((nomicromips)) -DNOCOMPRESSION=__attribute__((nocompression)) -mabi=64 -mips64r2 -EL -msoft-float -mgp64 -mlong64 -mno-micromips -DMIPS16=__attribute__((mips16)) -S -o fpr-moves-7.s /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c: In function 'bar': /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:25:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64 /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:23:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64 compiler exited with status 1 output is: /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c: In function 'bar': /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:25:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64 /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:23:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64 FAIL: gcc.target/mips/fpr-moves-7.c -O0 (test for excess errors) Excess errors: /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:25:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64 /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.target/mips/fpr-moves-7.c:23:1: sorry, unimplemented: MIPS16 PIC for ABIs other than o32 and o64