Re: GCC 4.2.0 RC3 Available

[Richard Earnshaw]

> Mark Mitchell wrote:
> > GCC 4.2.0 RC3 is now available from:
> > 
> >   ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501
> > 
> > This build now contains the fixes for the Ada build problem present in RC2.
> > 
> > At this point, I have no plans for an RC4.  However, I am reviewing the
> > various open issues, and available patches, so I might change my mind
> > about that.

Another problem is that --enable-checking hasn't been set to 'release',
so the stage1 binary is too big to run on my ARM systems (and the
compiler will be unnecessarily slower than it needs to be).

R.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Uros Bizjak]

Bradley Lucier wrote:



What about "significant loss of accuracy" as these options probably 
won't cause a nuclear reactor meltdown ;)


Well, I did some googling, and the technical term I was thinking of 
was "catastrophic cancellation".  So how about


Note that some mathematical routines in such libraries could suffer 
significant loss of accuracy, typically through so-called 
"catastrophic cancellation", when this option is used to set the 
precision to less than extended precision.


I think this is OK. So if nobody objects, this patch is OK for mainline.


I'm sorry, but I don't have checkin privileges.


I have committed following patch attached patch in your name:

2007-05-04  Bradley Lucier  <[EMAIL PROTECTED]>

   * doc/invoke.texi (i386 and x86-64 Options) [-mpc32, -mpc64, 
-mpc80]:

   Add the note about a significant loss of accuracy of some
   mathematical routines when these options are used.

Patch was tested by building the documentation.

Uros.


Index: doc/invoke.texi
===
--- doc/invoke.texi	(revision 124412)
+++ doc/invoke.texi	(working copy)
@@ -10129,13 +10129,22 @@
 @opindex mpc80
 
 Set 80387 floating-point precision to 32, 64 or 80 bits.  When @option{-mpc32}
-is specified, the significand of floating-point operations is rounded to 24
-bits (single precision), @option{-mpc64} rounds the significand of
-floating-point operations to 53 bits (double precision) and @option{-mpc80}
-rounds the significand of floating-point operations to 64 bits (extended
-double precision).  Note that a change of default precision control may
-affect the results returned by some of the mathematical functions.
+is specified, the significands of results of floating-point operations are
+rounded to 24 bits (single precision); @option{-mpc64} rounds the the
+significands of results of floating-point operations to 53 bits (double
+precision) and @option{-mpc80} rounds the significands of results of
+floating-point operations to 64 bits (extended double precision), which is
+the default.  When this option is used, floating-point operations in higher
+precisions are not available to the programmer without setting the FPU
+control word explicitly.
 
+Setting the rounding of floating-point operations to less than the default
+80 bits can speed some programs by 2% or more.  Note that some mathematical
+libraries assume that extended precision (80 bit) floating-point operations
+are enabled by default; routines in such libraries could suffer significant
+loss of accuracy, typically through so-called "catastrophic cancellation",
+when this option is used to set the precision to less than extended precision. 
+
 @item -mstackrealign
 @opindex mstackrealign
 Realign the stack at entry.  On the Intel x86, the

Re: Effects of newly introduced -mpcX 80387 precision flag

[Vincent Lefevre]

> +Setting the rounding of floating-point operations to less than the default
> +80 bits can speed some programs by 2% or more.  Note that some mathematical
> +libraries assume that extended precision (80 bit) floating-point operations
> +are enabled by default; routines in such libraries could suffer significant
> +loss of accuracy, typically through so-called "catastrophic cancellation",
> +when this option is used to set the precision to less than extended 
> precision. 

Perhaps it should be noted that these libraries are specific to x86
processors, since other processors don't have extended precision.

Also, some libraries (e.g. libxslt) assume double precision to be the
default and can return incorrect results in extended precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: GCC 4.1: Problem with old-loop and REG_EQUAL notes

[Andreas Krebbel]

Hi Eric,

> The note doesn't look particularly helpful in this case, given that gcse
> has replaced r974 with r1218 in the insn.  How is it created?

The register replacement is done by gcse but the cse pass invoked from gcse
modifies the REG_EQUAL note.  The limited scope of cse compared to gcse is 
probably the reason why the information put into the insn note isn't helpful.
The REG_EQUAL note added to insn 2308 seems to be particularly pointless.


09.cse1:

(insn 1742 1740 1743 109 (set (reg/f:DI 974)
(const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))) 49 {*movdi_larl} (nil)
(nil))

(insn 1743 1742 1744 109 (set (reg/f:DI 973)
(mem/u/c:DI (reg/f:DI 974) [0 S8 A8])) 51 {*movdi_64} (nil)
(nil))

10.gcse1:

(insn 2308 1740 1743 111 (set (reg/f:DI 974)
(const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))) 49 {*movdi_larl} (nil)
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))
(nil)))

(insn 1743 2308 1744 111 (set (reg/f:DI 973)
(mem/u/c:DI (reg/f:DI 1218) [0 S8 A8])) 51 {*movdi_64} (nil)
(expr_list:REG_EQUAL (mem/u/c:DI (reg/f:DI 974) [0 S8 A8])
(nil)))

constprop_register first tries to replace r974 with a symbol_ref.  This failes
and the symbol_ref is added as REG_EQUAL note in gcse.c:2686:

/* If we've failed to do replacement, have a single SET, don't already
   have a note, and have no special SET, add a REG_EQUAL note to not
   lose information.  */
if (!success && note == 0 && set != 0
&& GET_CODE (SET_DEST (set)) != ZERO_EXTRACT
&& GET_CODE (SET_DEST (set)) != STRICT_LOW_PART)
  note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src));

resulting in:

(insn 1743 2308 1744 109 (set (reg/f:DI 973)
(mem/u/c:DI (reg/f:DI 974) [0 S8 A8])) 51 {*movdi_64} (nil)
(expr_list:REG_EQUAL (mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110)) [0 S8 A8])
(nil)))

local_cprop_pass then replaces r974 with r1218.

The cleanup cse pass called in gcse.c:6676 then modifies the REG_EQUAL note.
cse calls fold_rtx for the REG_EQUAL note in cse.c:4936 looking for a 
replacement
of the symbol_ref. cse only sees that this value has already been copied to r974
and puts that register into the REG_EQUAL note.


> Is (reg/f:DI 974) loop invariant or only conditionally invariant?
It is only conditionally invariant since it is set in the loop body - to a 
constant
value though.  set_in_loop is -2 and loop_invariant_p returns 2 as expected.

Bye,

-Andreas-

Updating an operand in RTL for a builtin function

[Mohamed Shafi]

Hello all,

I am trying to implement a builtin function __macf for a private target.
I have added the required target hooks for this.
Say for the following code

int main()
{
 int operand1 = 2;
 int operand2 = 3;
 int operand3 = 4;
 int result;

  /* operand3 = operand3 + (operand1 * operand2)*/

 result = __macf(operand1, operand2, operand3);

}

Requirement :  I need the value of operand3 and result to be same
after calling the builtin.
But this is not happening.
In this case, all the 3 operands are loaded from memory for the
operation. After the operation is complete, operand3 gets modified.
But the modified value of operand3 is not saved/updated.Only the
variable "result" is updated

How do i do this?

The pattern that i have used for this purpose is
(define_insn "macfsi"
  [(set (match_operand:SI 0 "data_reg" "=f")
(plus:SI (mult:SI (match_operand:SI 1 "data_reg" "f")
(match_operand:SI 2 "data_reg" "f"))
(match_operand:SI 3 "data_reg" "0")))]
""
"macf\\t%1, %2, %3"
  [(set_attr "type" "arith")
   (set_attr "length" "2")]
)

The instruction macf will store the result in last operand i.e %3+=%2 * %1

Regards,
Shafi

Re: GCC 4.1: Problem with old-loop and REG_EQUAL notes

[Eric Botcazou]

> The register replacement is done by gcse but the cse pass invoked from gcse
> modifies the REG_EQUAL note.  The limited scope of cse compared to gcse is
> probably the reason why the information put into the insn note isn't
> helpful. The REG_EQUAL note added to insn 2308 seems to be particularly
> pointless.
>
> [...]
>
> The cleanup cse pass called in gcse.c:6676 then modifies the REG_EQUAL
> note. cse calls fold_rtx for the REG_EQUAL note in cse.c:4936 looking for a
> replacement of the symbol_ref. cse only sees that this value has already
> been copied to r974 and puts that register into the REG_EQUAL note.

Interesting game, thanks for the explanation.

> It is only conditionally invariant since it is set in the loop body - to a
> constant value though.  set_in_loop is -2 and loop_invariant_p returns 2 as
> expected.

OK.  Then would it be enough to weaken the condition of the removal test to

  if (loop_invariant_p (loop, ...) != 1)

in order to solve your problem?

-- 
Eric Botcazou

Re: Updating an operand in RTL for a builtin function

[Andrew Haley]

Mohamed Shafi writes:

 > I am trying to implement a builtin function __macf for a private target.
 > I have added the required target hooks for this.
 > Say for the following code
 > 
 > int main()
 > {
 >   int operand1 = 2;
 >   int operand2 = 3;
 >   int operand3 = 4;
 >   int result;
 > 
 >/* operand3 = operand3 + (operand1 * operand2)*/
 > 
 >   result = __macf(operand1, operand2, operand3);
 > 
 > }
 > 
 > Requirement :  I need the value of operand3 and result to be same
 > after calling the builtin.
 > But this is not happening.

What do you mean, exactly?  C only has call by value, and gcc's
builtins can only return one value.  Builtins don't change their
arguments.  If you want to update one of the arguments you'll have to
pass a pointer to the builtin.

I think I must be misunderstanding your question.

Andrew.

Build status for GCC 3.4.5

[Michael Kettner]

x86_64-unknown-linux-gnu

Configured 
with: /home/kettner/tmp/gcc-3.4.5/configure --enable-languages=c,c++ 
--prefix=/home/kettner/devel/gcc-3.4.5/
Thread model: posix
gcc version 3.4.5

languages: c,c++

openSUSE 10.2 (X86-64) - Kernel \r (\l).

Linux lin4 2.6.18.8-0.1-default #1 SMP Fri Mar 2 13:51:59 UTC 2007 x86_64 
x86_64 x86_64 GNU/Linux

glibc-2.5-25

Bootstrap: 3.4.5

Regards,
 Michael


-- 
Dr.-Ing. Michael Kettner
Ingenieurgesellschaft für Verkehrs- und Eisenbahnwesen mbH

Vahrenwalder Platz 3
30165 Hannover
Germany

fon:   +49/(0)511 / 98 42 28 - 16 oder/or - 10
fax:   +49/(0)511 / 98 42 28 - 29
web:   www.ivembh.de
email: [EMAIL PROTECTED]

Rechtsform: Gesellschaft mit beschränkter Haftung
Sitz des Unternehmens: Hannover
Amtsgericht Hannover, HRB 56965

Geschäftsführer:
Prof. Dr.-Ing. Thomas Siefer
PD Dr.-Ing. Alfons Radtke

--
This message is confidential. It may not be disclosed to,
or used by, anyone other than the addressee. If you receive
this message in error, please advise us immediately.

Internet email are not necessarily secure. We do not accept
responsibility for changes to any email which occur after
the email has been sent. Attachments to this email could
contain software viruses which could damage your system.
We have checked the attachments for viruses before sending,
but you should virus check them before opening.

Re: Expression with 2 operations

[Tom Tromey]

> "Antoine" == Antoine Eiche <[EMAIL PROTECTED]> writes:

Without more information I don't know how to answer your question.
But I do have a question for you...

Antoine> I must calculate the address of an element's array.
Antoine> If the size of an element is one integer it's good.
Antoine> I do like that:
Antoine> new_rhs=fold_build2(PLUS_EXPR,TREE_TYPE(TREE_OPERAND(rhs,1)),
Antoine>build1(ADDR_EXPR, build_pointer_type (TREE_TYPE
Antoine> (array)),array),
Antoine>index);

Why not use ARRAY_REF here?  Then you don't have to worry about the
size of an element of the array.

Tom

Re: Effects of newly introduced -mpcX 80387 precision flag

[Andrew Pinski]

On 5/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:

Perhaps it should be noted that these libraries are specific to x86
processors, since other processors don't have extended precision.


m68k does too, just nobody uses it any more or the ones they use don't
have the co-processor or have a different FP instructions now.  In
fact this where the problem started, i387 just continued in the same
fashion.

-- Pinski

Re: GCC 4.1: Problem with old-loop and REG_EQUAL notes

[Andreas Krebbel]

Hi,

> OK.  Then would it be enough to weaken the condition of the removal test to
> 
>   if (loop_invariant_p (loop, ...) != 1)
> 
> in order to solve your problem?
Sure, that would be an alternative compared to always removing the
REG_EQUAL notes when hoisting an insn and it would fix my particular testcase
as well.

But I don't see why this can't happen with unconditional loop invariants?
Maybe it can be consider safe since loop.c is *always* able to hoist 
unconditional
loop invariants?!

Bye,

-Andreas-

Re: GCC 4.1: Problem with old-loop and REG_EQUAL notes

[Eric Botcazou]

> Sure, that would be an alternative compared to always removing the
> REG_EQUAL notes when hoisting an insn and it would fix my particular
> testcase as well.

Then it's pre-approved for the branch if your testcase exhibits a regression.

> But I don't see why this can't happen with unconditional loop invariants?
> Maybe it can be consider safe since loop.c is *always* able to hoist
> unconditional loop invariants?!

I guess that real loop invariants are not supposed to be modified in the loop 
at all, so it's OK to move up insns consuming them to the loop pre-header.

-- 
Eric Botcazou

Re: GCC 4.2.0 RC3 Available

[Aaron Gray]

GCC 4.2.0 RC3 is now available from:

 ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501


It does not build LLVM there seems to be a stdlib++ problem.

I cannot really file a BugZilla report as I have not distilled the code down 
to make an accurate report.


Aaron

gcc-4.3-20070504 is now available

[gccadmin]

Snapshot gcc-4.3-20070504 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070504/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 124449

You'll find:

gcc-4.3-20070504.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20070504.tar.bz2 C front end and core compiler

gcc-ada-4.3-20070504.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20070504.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20070504.tar.bz2  C++ front end and runtime

gcc-java-4.3-20070504.tar.bz2 Java front end and runtime

gcc-objc-4.3-20070504.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20070504.tar.bz2The GCC testsuite

Diffs from 4.3-20070427 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Effects of newly introduced -mpcX 80387 precision flag

[Roman Zippel]

Hi,

On Fri, 4 May 2007, Andrew Pinski wrote:

> On 5/4/07, Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> > Perhaps it should be noted that these libraries are specific to x86
> > processors, since other processors don't have extended precision.
> 
> m68k does too, just nobody uses it any more or the ones they use don't
> have the co-processor or have a different FP instructions now.  In
> fact this where the problem started, i387 just continued in the same
> fashion.

Huh? m68k still uses extended precisions and will continue to do so, it's 
ColdFire that doesn't have it anymore.

bye, Roman