Re: fatal error: gnu/stubs-32.h: No such file

2013-07-30 Thread Andrew Haley
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

2013-07-30 Thread Marek Polacek
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

2013-07-30 Thread Michael Veksler

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

2013-07-30 Thread Diego Novillo
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

2013-07-30 Thread Basile Starynkevitch
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

2013-07-30 Thread Joseph S. Myers
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

2013-07-30 Thread hemant


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

2013-07-30 Thread Marek Polacek
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

2013-07-30 Thread Martin Jambor
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

2013-07-30 Thread Basile Starynkevitch
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

2013-07-30 Thread Eric Botcazou
> 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

2013-07-30 Thread Andrew MacLeod

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

2013-07-30 Thread Marek Polacek
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

2013-07-30 Thread David Starner
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

2013-07-30 Thread David Starner
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

2013-07-30 Thread FX
> 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

2013-07-30 Thread Kirill Yukhin
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

2013-07-30 Thread Andrew Haley
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

2013-07-30 Thread Ondřej Bílka
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Gabriel Dos Reis
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

2013-07-30 Thread Richard Earnshaw

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

2013-07-30 Thread Michael Veksler

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

2013-07-30 Thread Steve Ellcey
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

2013-07-30 Thread Timo Jacob

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

2013-07-30 Thread Richard Sandiford
"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

2013-07-30 Thread Steve Ellcey
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