Re: question about -ffast-math implementation

On Sun, Jun 1, 2014 at 11:09 PM, Janne Blomqvist wrote: > On Sun, Jun 1, 2014 at 9:52 AM, Mike Izbicki wrote: >> I'm trying to copy gcc's behavior with the -ffast-math compiler flag >> into haskell's ghc compiler. The only documentation I can find about >> it is at: >> >> https://gcc.gnu.org/onl

Re: question about -ffast-math implementation

> Though for the gory details and authoritative answers I suppose you'd have to look into the source code. Where would I find the code for this?

GCC 4.7.4 Status Report, branch frozen for release (candidate)

Status == The GCC 4.7 branch is now frozen as I am preparing a first release candidate for GCC 4.7.4. All changes from now on require release manager approval. After GCC 4.7.4 is released the branch will be closed. Previous Report === https://gcc.gnu.org/ml/gcc/2013-04/msg001

lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

Hi all, I have seen this in 4.8.2 but seems to be present since 4.7.0 (was added by revision 184177 in libitm/configure.tgt): # Map the target cpu to an ARCH sub-directory. At the same time, # work out any special compilation flags as necessary. case "${target_cpu}" in ... sparc)

GCC 4.7.4 Release Candidate available from gcc.gnu.org

GCC 4.7.4 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.7.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.4-RC-20140602 and shortly its mirrors. It has been generated from SVN revision 211126. I have so far bootstrapped and tested the release

Re: [RFC] PR61300 K&R incoming args

On 05/31/2014 08:56 AM, Alan Modra wrote: It's fine to change ABI when compiling an old-style function definition for which a prototype exists (relative to the non-prototype case). It happens on i386, too. That might be so, but when compiling the function body you must assume the worst case,

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

> # Map the target cpu to an ARCH sub-directory. At the same time, > # work out any special compilation flags as necessary. > > case "${target_cpu}" in > > ... > > sparc) > case " ${CC} ${CFLAGS} " in > *" -m64 "*) > ;; > *) > if test -z "$w

[GSoC] decision tree first steps

I have few questions regarding genmatch: a) Why is 4 hard-coded here: ? in write_nary_simplifiers: fprintf (f, " tree captures[4] = {};\n"); b) Should we add syntax for a symbol to denote multiple operators ? For exampleim in simplify_rotate: (X << CNT1) OP (X >> CNT2) with OP being +, |, ^

Re: question about -ffast-math implementation

On 6/2/2014 3:00 AM, Andrew Pinski wrote: On Sun, Jun 1, 2014 at 11:09 PM, Janne Blomqvist wrote: On Sun, Jun 1, 2014 at 9:52 AM, Mike Izbicki wrote: I'm trying to copy gcc's behavior with the -ffast-math compiler flag into haskell's ghc compiler. The only documentation I can find about it i

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

Hi Eric >> Removing "-mcpu=v9" allows the build to finalize. > > IIRC both libraries require the V9 architecture to work > properly/efficiently. I have successfully built without the switch, but I am not sure of the effects at runtime. If V9 is indeed required, is there a way to build without th

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

On 2 June 2014 12:38, Carlos Sánchez de La Lama wrote: > If V9 is indeed required, is there a way to build without those libs? Or > has pre V9 support been dropped at some point? --disable-libitm --disable-libatomic

Re: [GSoC] decision tree first steps

Hi, Prathamesh Kulkarni skribis: > Example: > /* x & 0 -> 0 */ > (match_and_simplify > (bit_and @0 @1) > if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && (@1 == integer_zero_node)) > { integer_zero_node; }) > > /* x & -1 -> x */ > (match_and_simplify > (bit_and @0 @1) > if (INTEGRAL_TYPE_P (TRE

Re: [GSoC] decision tree first steps

On Mon, Jun 2, 2014 at 1:16 PM, Prathamesh Kulkarni wrote: > I have few questions regarding genmatch: > > a) Why is 4 hard-coded here: ? > in write_nary_simplifiers: > fprintf (f, " tree captures[4] = {};\n"); Magic number (this must be big enough for all cases ...). Honestly this should b

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

Thanks Jonathan, >> If V9 is indeed required, is there a way to build without those libs? Or >> has pre V9 support been dropped at some point? > > --disable-libitm --disable-libatomic Ok, so those two switches will be required for non-v9 SPARC targets. I still think this should be taken care of

Re: [GSoC] decision tree first steps

On Mon, Jun 2, 2014 at 2:12 PM, Ludovic Courtès wrote: > Hi, > > Prathamesh Kulkarni skribis: > >> Example: >> /* x & 0 -> 0 */ >> (match_and_simplify >> (bit_and @0 @1) >> if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && (@1 == integer_zero_node)) >> { integer_zero_node; }) >> >> /* x & -1 -> x */

FloatingPointMath and transformations

I've looked at https://gcc.gnu.org/wiki/FloatingPointMath and there may be some mistakes or missing info. First, it is said that x / C is replaced by x * (1.0 / C) when C is a power of two. But this condition is not sufficient: if 1.0 / C overflows, the transformation is incorrect. From some t

Re: FloatingPointMath and transformations

On Jun 2, 2014, at 10:06 AM, Vincent Lefevre wrote: > I've looked at > > https://gcc.gnu.org/wiki/FloatingPointMath > > and there may be some mistakes or missing info. That’s quite possible. I created the page many years ago, based on my understanding of GCC at that time. > > First, it is

Re: FloatingPointMath and transformations

On Mon, Jun 02, 2014 at 10:33:37AM -0400, Geert Bosch wrote: > > First, it is said that x / C is replaced by x * (1.0 / C) when C is > > a power of two. But this condition is not sufficient: if 1.0 / C > > overflows, the transformation is incorrect. From some testing, > > it seems that GCC detects

Re: [RFC] PR61300 K&R incoming args

On Mon, Jun 02, 2014 at 12:00:41PM +0200, Florian Weimer wrote: > On 05/31/2014 08:56 AM, Alan Modra wrote: > > >>It's fine to change ABI when compiling an old-style function > >>definition for which a prototype exists (relative to the > >>non-prototype case). It happens on i386, too. > > > >That

Re: [GSoC] decision tree first steps

Richard Biener skribis: > (match-and-simplify > (bit_and @0 integer_zerop@1) > @1) > (match-and-simplify > (bit_and @0 integer_all_onesp@1) > @0) > > is IMHO easier to parse while your version more like matches > what the code generator creates. Ah yes, the ability to specify predicates

Cross-testing libsanitizer

Hi, I am updating my (small) patch to enable libsanitizer on AArch64, but I am wondering about the testing. Indeed, when testing on my laptop, execution tests fail because libsanitizer wants to allocated 8GB of memory (I am using qemu as execution engine). When running on servers with more RAM, t

Re: FloatingPointMath and transformations

Jakub Jelinek writes: > If C is a power of two, then 1.0 / C should IMHO never overflow, It does if C is subnormal. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."

Re: PowerPC IEEE 128-bit floating point: Language standards

I have not been following the language standards recently. For any of the recent language standards, or the standards that are being worked on, will there be requirements for an IEEE 128-bit binary floating point type? For the C/C++ languages, is this type long double, or is another type being pr

Re: PowerPC IEEE 128-bit floating point: Language standards

On 06/02/2014 11:45 AM, Michael Meissner wrote: I have not been following the language standards recently. For any of the recent language standards, or the standards that are being worked on, will there be requirements for an IEEE 128-bit binary floating point type? For the C/C++ languages, is

Re: PowerPC IEEE 128-bit floating point: Language standards

On 2 June 2014 16:45, Michael Meissner wrote: > I have not been following the language standards recently. For any of the > recent language standards, or the standards that are being worked on, will > there be requirements for an IEEE 128-bit binary floating point type? The recent http://www.open

Re: [RFC]Better support for big-endian targets in GCC vectorizer

On Tue, 27 May 2014, Bin.Cheng wrote: > There are some other similar cases in vectorizer and all of them look > suspicious since intuitively, vectorizer should neither care about > target endianess nor do such shuffle. Anyway, this is how we do > vectorization currently. Agreed. The semantics o

Re: question about -ffast-math implementation

On Mon, Jun 2, 2014 at 12:18 AM, Mike Izbicki wrote: >> Though for the gory details and authoritative answers I suppose you'd > have to look into the source code. > > Where would I find the code for this? This is the GCC source code. There isn't one file that implements -ffast-math. -ffast-math

Re: PowerPC IEEE 128-bit floating point: Two 128-bit floating point types

[resending without the long CC list, since the mailing list doesn't like it] On Fri, 30 May 2014, Michael Meissner wrote: > I assume the way forward is to initially have a __float128 type that gives > IEEE > 128-bit support for those that need/want it, and keep long double to be the > current f

GNU Tools Cauldron 2014 - Presentation schedule

I have posted the presentation schedule at https://gcc.gnu.org/wiki/cauldron2014 Presenters, please make sure that your talk is listed and at a time slot that does not conflict with your travel or other restrictions. We are also finalizing details on the Reception and Dinner venues (Fri night a

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

> I have successfully built without the switch, but I am not sure of the > effects at runtime. For sure libitm cannot work, there is a 'flushw' in config/sparc/sjlj.S. > If V9 is indeed required, is there a way to build without those libs? Or > has pre V9 support been dropped at some point? No,

Re: PowerPC IEEE 128-bit floating point: Internal GCC types

On Fri, 30 May 2014, Michael Meissner wrote: > One issue is the current mode setup is when you create new floating point > types, the widening system kicks in and the compiler will generate all sorts > of > widening from one 128-bit floating point format to another (because internally > the preci

Re: [RFC] PR61300 K&R incoming args

On Mon, 2 Jun 2014, Florian Weimer wrote: > On 05/31/2014 08:56 AM, Alan Modra wrote: > > > > It's fine to change ABI when compiling an old-style function > > > definition for which a prototype exists (relative to the > > > non-prototype case). It happens on i386, too. > > > > That might be so,

Re: PowerPC IEEE 128-bit floating point: Language standards

On Mon, 2 Jun 2014, Michael Meissner wrote: > I have not been following the language standards recently. For any of the > recent language standards, or the standards that are being worked on, will > there be requirements for an IEEE 128-bit binary floating point type? For the > C/C++ languages,

Re: FloatingPointMath and transformations

On 2014-06-02 17:34:31 +0200, Andreas Schwab wrote: > Jakub Jelinek writes: > > > If C is a power of two, then 1.0 / C should IMHO never overflow, > > It does if C is subnormal. More precisely, in case of double precision, if C = DBL_MIN / 2, 1.0 / C doesn't overflow, but if C = DBL_MIN / 4 (or

Re: question about -ffast-math implementation

Right, but I've never taken a look at the gcc codebase. Where would I start looking for the relevant files? Is there a general introduction to the codebase anywhere that I should start with? On Mon, Jun 2, 2014 at 11:20 AM, Ian Lance Taylor wrote: > On Mon, Jun 2, 2014 at 12:18 AM, Mike Izbicki

Re: question about -ffast-math implementation

Mike Izbicki writes: > Right, but I've never taken a look at the gcc codebase. Where would I > start looking for the relevant files? Is there a general introduction > to the codebase anywhere that I should start with? grep for all the flags set in the two functions below (from gcc/opts.c), wit

Re: Zero/Sign extension elimination using value ranges

On 23/05/14 07:23, Richard Henderson wrote: > On 05/22/2014 03:12 AM, Jakub Jelinek wrote: >> No way. SUBREG_PROMOTED_UNSIGNED_P right now resides in two separate bits, >> volatil and unchanging. Right now volatile != 0, unchanging ignored >> is -1, volatile == 0, then the value is unchanging. >>

Re: PowerPC IEEE 128-bit floating point: Internal GCC types

On 2014-06-02 21:20:57 +, Joseph S. Myers wrote: > ([...] Conversion from __float128 to __ibm128 would presumably be > done in the usual way of converting to double, and, if the result is > finite, subtracting the double from the __float128 value, converting > the remainder, and renormalizing i

Re: FloatingPointMath and transformations

On 2014-06-02 10:33:37 -0400, Geert Bosch wrote: > It should, or it would be a bug. Please feel free to add/correct > anything on this page. I am not a member of EditorGroup. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Re: Cross-testing libsanitizer

Christophe, > Indeed, when testing on my laptop, execution tests fail because > libsanitizer wants to allocated 8GB of memory (I am using qemu as > execution engine). Is this 8G of RAM? If yes - I'd be curious to know which part of libsanitizer needs so much memory. -Y