Are Decimal operations are fully implemented/tested ?

[Hesham Moustafa]

Hey,

I want to inquire about the state of decimal floating point operations
at gcc low-level library.
Does gcc fully implement IEEE 754-2008 standard ?
I know that gcc support _Decimal64 / _Decimal128
as a decimal types and i did some simple operations on it. Also i want
to be sure if the current implementation
of decimal operations is fully tested and known to work well without
any bugs or not.

regards,
Hesham

Re: GCC's Decimal Floating Point extension problem

[Vincent Lefevre]

On 2012-09-11 11:34:58 -0700, H.J. Lu wrote:
> On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra
>  wrote:
> >  Hi All,
> >
> > I'm trying to write a small program to check the decimal floating
> > point gcc extension but I encountered some problems
> >
> > The program just converts a _Decimal64 number to double to print
> > it and I used the function (double __bid_truncdddf (_Decimal64 a)
> > as the gnu online docs show)

If you cast the decimal64 value to double (whatever the method),
the printed value may be incorrect (see below).

> > #include 
> >
> > int main ()
> > {
> >_Decimal64 d = 12.5DD;
> > printf ("%lf\n",__bid_truncdddf(d) );
> >
> > return 0;
> > }
> >
> > $ gcc test.c -Wall -g
> > test.c: In function ‘main’:
> > test.c:23: warning: implicit declaration of function ‘__bid_truncdddf’
> > test.c:23: warning: format ‘%lf’ expects type ‘double’, but argument 2 has 
> > type ‘int’
> >
> > $ ./a.out
> > 0.00
> >
> > I don't know why the result is zero and why the second warning
> > appears although I wrote the function properly!
> 
> ,__bid_truncdddf is a libgcc internal function.  Don't ever use it
> in user programs.  Just cast DFP to double.

A double has 53 bits in general (always with GCC, AFAIK), so that
it doesn't have enough precision to guarantee that the output in
decimal (with the exact precision of _Decimal64) will be correct.
There has recently been a related discussion in the MPFR list.
See:

  https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00027.html
  https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00028.html
  https://sympa.inria.fr/sympa/arc/mpfr/2012-09/msg00011.html

So, if long double has at least 55 bits, a solution would be to
cast the _Decimal64 to long double.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-12 11:29:41 +0300, Hesham Moustafa wrote:
> I want to inquire about the state of decimal floating point operations
> at gcc low-level library.
> Does gcc fully implement IEEE 754-2008 standard ?

No. Even for binary-only it doesn't (though it almost does). Also
note that some parts of IEEE 754-2008 are (should be) implemented
on the C library side (e.g. glibc).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Cgraph Modification Plan

[Diego Novillo]

On 2012-09-11 16:22 , Lawrence Crowl wrote:

We do not yet seem to have consensus on a long term plan.
Would it be reasonable to start on short term prepatory work?

In particular, I was think we could do

Add converters and testers.
Change callers to use those.

and maybe

Change callers to use type-safe parameters.

Where those mean what I earlier stated.

Comments?


Seems straightforward enough.  And it doesn't seem like it will affect 
the longer term conversion.



Diego.

Re: Are Decimal operations are fully implemented/tested ?

[Hesham Moustafa]

On Wed, Sep 12, 2012 at 1:29 PM, Vincent Lefevre  wrote:
> On 2012-09-12 11:29:41 +0300, Hesham Moustafa wrote:
>> I want to inquire about the state of decimal floating point operations
>> at gcc low-level library.
>> Does gcc fully implement IEEE 754-2008 standard ?
>
> No. Even for binary-only it doesn't (though it almost does). Also
> note that some parts of IEEE 754-2008 are (should be) implemented
> on the C library side (e.g. glibc).
>
If exist, what are the known bugs in the current implementation of
Decimal / IEEE 754-2008 standard ?
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Cgraph Modification Plan

[Jan Hubicka]

> We do not yet seem to have consensus on a long term plan.
> Would it be reasonable to start on short term prepatory work?
> 
> In particular, I was think we could do
> 
>Add converters and testers.
>Change callers to use those.
> 
> and maybe
> 
>Change callers to use type-safe parameters.
> 
> Where those mean what I earlier stated.
> 
> Comments?

Yes, it seems sane.
> 
> CONVERTERS AND TESTERS ###
> 
> add
> symtab_node_base &symtab_node_def::ref_symbol()
>   { return symbol; }
> symtab_node_base &cgraph_node::ref_symbol()
>   { return symbol; }
> symtab_node_base &varpool_node::ref_symbol()
>   { return symbol; }
> 
> change
> node->symbol.whatever
> to
> node->ref_symbol().whatever

I still do not gather why simple inheritance can't let me to write
node->whatever again...

If that is GTY limitation, I have no problem having this in short term and
update it later.  symbol_node is really base of functions/variables and new
beasts we are going to get soon.
I implemented it as union only to make GTY happy.
> 
> 
> 
> should not need to add these
> 
> cgraph_node &symtab_node_def::ref_cgraph()
>   { gcc_assert (symbol.type == SYMTAB_FUNCTION);

I think checking_assert is enough in these cases. We are getting more
conversions back and forth and we don't really want to have asserts all around
code.

> return x_function; }
> varpool_node &symtab_node_def::ref_varpool()
>   { gcc_assert (symbol.type == SYMTAB_VARIABLE);
> return x_variable; }
> 
> 
> 
> add
> symtab_node_base *symtab_node_def::try_symbol()
>   { return &symbol; }
> cgraph_node *symtab_node_def::try_cgraph()
>   { return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
> varpool_node *symtab_node_def::try_varpool()
>   { return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }

I think try_function/try_variable reads better than cgraph/varpool especially 
with the
longer term plan to drop these names when cgraph/varpool no longer exists and 
we have
symbol table.

Honza

Re: gfortran error: Statement order error: declaration after DATA

[Tim Prince]

On 9/11/2012 5:46 PM, David N. Bradley wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am trying to compile the cactuscode package and can not get past the
error :
Statement order error: declaration after DATA
can you point me in the direction of a fix.  I included offending file
as an attachment.

Dave

kb9qhd Amateur Radio Service
Technician class Licence
Grid EN43

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQT9tfAAoJEIHvsckbl2dBLMIH/0LR4lA3w9W6lhaB3lkyX9WB
dQJmYHAM59LsGmi+9fmhODG1KkoVfIMIqI8AaDHAFQiqkN2QCr1BNGTFgifFFcV9
BijJt4OtcZTzS0LwIzLTGOEbBJIT2xP1HQmVm/7gYr90HlWvLMHLoPJgqnNsJyNT
mxWMEJojD/xeKaHE6yUIZxRlbnM/pC7UYSIruQ7YjsxC7gKpHfBeOM9Op4AkwJ0k
H4IaKRDpYOKBbEHP6LLPZFTdosjQgWaFnTBILvLaHjSqa9mskU4yTDLdLHFNjUz9
i5hC2ihlIJBcQx1QVLwt/AvjSDtqPqLPKo3h2OBH0IJzlcS+kOkfeSQ+AvkWghU=
=snlv
-END PGP SIGNATURE-
Surely someone has pointed out, you should require only to sort the file 
by placing the dimension statement ahead of the data statement, if you 
don't wish to adopt more modern syntax.


--
Tim Prince

Re: variable tracking vs. delay slots question

[Steve Ellcey]

On Tue, 2012-09-11 at 20:20 -0600, Jeff Law wrote:

> > These requirements seem to conflict.  Am I right about this or are the
> > comments wrong or am I confused?  I think this problem is the basis of
> > bug 54128, a bootstrap failure on MIPS, though the problem seems generic
> > to any system with delay slots.
> I haven't looked at 54128, but yes, I think you're generally right about 
> the conflict.  Not sure what the implications are in terms of the 
> failure mode -- it would seem to me that we wouldn't get good debug 
> info.  However, I'm not sure offhand how it'd cause a bootstrap error.
> 
> jeff

The bootstrap error is caused by a stage2/stage3 comparison failure.
Because the delay slot pass moved some instructions (but not their
associated debug instructions) we no longer generate the same code
with and without debug info.  The change in code is due to a change
in register allocation which is coming from build_insn_chain where it
looks at all the instructions (debug and regular) to figure out register
availability.  My original fix for the bootstrap problem was to not have
build_insn_chain look at debug instructions but Jakub Jelinek thought
that that was not fixing the real bug but compensating for another
problem.  He was right and that other problem is the variable tracking /
delay slot conflict.

Steve Ellcey
sell...@mips.com

Re: contrib/config-list.mk

[Joseph S. Myers]

On Tue, 11 Sep 2012, Ian Lance Taylor wrote:

> I don't know whether contrib/config-list.mk is dead or not.  But I do
> know that you will only get that error on Debian or Ubuntu systems,
> which by default pass some rather aggressive warning options.

contrib/config-list.mk is meant to be used with a (previously built) 
bootstrapped native compiler from the same version of the sources you are 
building (or at least a similar version), rather that with the system's 
own compiler at all.  The sources are only expected to be -Werror clean 
when built using the same version of GCC, not some other version that may 
be a system compiler.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC stack backtraces

[Diego Novillo]

On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:


Diego already loves it!


Indeed I do!

I'm making changes in VEC that will benefit from this.  I am currently 
keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to 
the methods that want it.  But it would be nice if we could get rid of 
these macros.


Ian, do you expect to be adding this to libiberty so we can use it from 
GCC?  Alternately, we could use Richi's approach I suppose (what 
happened to that patch, btw)?



Thanks.  Diego.

An interesting conversation or usual day without something new? I would rather choose the first one. What do u think?)

[Jacklyn Browne]

Hey gorgeous! 
My name is Jacklyn.
If you looking forward about having great time in a company of smart, cute 
female then I am right before u! 
I liked your photo shots and that's why decided to create this message! I am 
thinking that u wouldn't stay indifferent after checking up mine too. 
So, I wait for you to answer this message and who knows we will go club, drink 
some vodka, talk about different subjects and who knows I gonna invite u to go 
to my appartment! ;)

Re: GCC stack backtraces

[Gabriel Dos Reis]

On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo  wrote:

> Alternately, we could use Richi's approach I suppose (what happened to that
> patch, btw)?

I was under the impression that the patch was good to go in; Richard?

-- Gaby

Re: GCC stack backtraces

[rguenther]

Diego Novillo  wrote:

>On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:
>
>> Diego already loves it!
>
>Indeed I do!
>
>I'm making changes in VEC that will benefit from this.  I am currently 
>keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to 
>the methods that want it.  But it would be nice if we could get rid of 
>these macros.

Only of the checking parts, right? Not of the mem stat ones.

>Ian, do you expect to be adding this to libiberty so we can use it from
>
>GCC?  Alternately, we could use Richi's approach I suppose (what 
>happened to that patch, btw)?

I have to get back to it. Maybe tomorrow ...

Richard.
>
>Thanks.  Diego.


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: GCC stack backtraces

[Diego Novillo]

On Wed, Sep 12, 2012 at 2:31 PM,   wrote:

> Only of the checking parts, right? Not of the mem stat ones.

Correct.  I'm thinking mostly of operator[].

> I have to get back to it. Maybe tomorrow ...

Great, thanks.  I will keep the macros around for now.  They can be
removed later.


Diego.

Re: GCC stack backtraces

[Ian Lance Taylor]

On Wed, Sep 12, 2012 at 9:50 AM, Diego Novillo  wrote:
> On Thu Aug 30 16:18:47 2012, Lawrence Crowl wrote:
>
>> Diego already loves it!
>
>
> Indeed I do!
>
> I'm making changes in VEC that will benefit from this.  I am currently
> keeping the VEC_* macros so that I can pass __FUNCTION__, __LINE__ to the
> methods that want it.  But it would be nice if we could get rid of these
> macros.
>
> Ian, do you expect to be adding this to libiberty so we can use it from GCC?

http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00754.html

Ian

Re: Cgraph Modification Plan

[Lawrence Crowl]

On 9/12/12, Jan Hubicka  wrote:
>> We do not yet seem to have consensus on a long term plan.
>> Would it be reasonable to start on short term prepatory work?
>>
>> In particular, I was think we could do
>>
>>Add converters and testers.
>>Change callers to use those.
>>
>> and maybe
>>
>>Change callers to use type-safe parameters.
>>
>> Where those mean what I earlier stated.
>>
>> Comments?
>
> Yes, it seems sane.
>
>>
>> CONVERTERS AND TESTERS ###
>>
>> add
>> symtab_node_base &symtab_node_def::ref_symbol()
>>  { return symbol; }
>> symtab_node_base &cgraph_node::ref_symbol()
>>  { return symbol; }
>> symtab_node_base &varpool_node::ref_symbol()
>>  { return symbol; }
>>
>> change
>> node->symbol.whatever
>> to
>> node->ref_symbol().whatever
>
> I still do not gather why simple inheritance can't let me to write
> node->whatever again...
>
> If that is GTY limitation, I have no problem having this in
> short term and update it later.  symbol_node is really base of
> functions/variables and new beasts we are going to get soon.
> I implemented it as union only to make GTY happy.

It is a GTY limitation right now.  We can do most of this work before
gengtype supports inheritance, and for that we need ref_symbol.

>>
>> 
>>
>> should not need to add these
>>
>> cgraph_node &symtab_node_def::ref_cgraph()
>>  { gcc_assert (symbol.type == SYMTAB_FUNCTION);
>
> I think checking_assert is enough in these cases. We are getting
> more conversions back and forth and we don't really want to have
> asserts all around code.

The are untested conversions from base to derived.  We should not
be using them, and hence they should be rare.  I mention them only
because there might be places in the code where we get backed into
a corner.  I've changed my notes to use gcc_checking_assert, and
we can revisit the decision whenever we need to.

>>return x_function; }
>> varpool_node &symtab_node_def::ref_varpool()
>>  { gcc_assert (symbol.type == SYMTAB_VARIABLE);
>>return x_variable; }
>>
>> 
>>
>> add
>> symtab_node_base *symtab_node_def::try_symbol()
>>  { return &symbol; }
>> cgraph_node *symtab_node_def::try_cgraph()
>>  { return symbol.type == SYMTAB_FUNCTION ? &x_function : NULL; }
>> varpool_node *symtab_node_def::try_varpool()
>>  { return symbol.type == SYMTAB_VARIABLE ? &x_variable : NULL; }
>
> I think try_function/try_variable reads better than cgraph/varpool
> especially with the longer term plan to drop these names when
> cgraph/varpool no longer exists and we have symbol table.

Okay, I will do that.

-- 
Lawrence Crowl