Re: fix libquadmath build regression

2012-12-30 Thread Paolo Bonzini 
Il 30/12/2012 01:13, Alexandre Oliva ha scritto:
 On Dec 24, 2012, Paolo Bonzini bonz...@gnu.org wrote:
 
 Il 21/12/2012 06:17, Alexandre Oliva ha scritto:
 The problem is that glibc has an extern inline definition of
 fraiseexcept that is introduced by including fenv.h (it's in
 bits/fenv.h), and this definition requires SSE support regardless of
 target arch of word width, so it doesn't work for an i686 native that
 doesn't assume SSE registers and instructions are available.

 This bug is fixed in newer versions of glibc, but I figured it wouldn't
 hurt to have a work-around in place for libquadmath to build
 
 Would it be possible to fix it in fixincludes instead?
 
 Heh, who'd have thought of using fixincludes to fix broken include
 files? :-)  (hint: not me :-)  *blush*
 
 Thanks for the suggestion, this patch fixes the problem.  Regstrapped on
 x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

Not my territory anymore, but it looks much better!  CCing Bruce.

Paolo

Re: [Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C)

2012-12-30 Thread Tobias Burnus 

Janne Blomqvist wrote:

On Fri, Dec 28, 2012 at 12:31 AM, Tobias Burnus bur...@net-b.de wrote:

a) The Fortran standard only defines LOGICAL(kind=C_Bool) as being
interoperable with C - no other LOGICAL type. That matches GCC: With gcc
(the C compiler) only _Bool is a BOOLEAN_TYPE with TYPE_PRECISION == 1.
Hence, this patch rejects other logical kinds as dummy argument/result
variable in BIND(C) procedures if -std=f2003/f2008/f2008ts is specified
(using -pedantic, one gets a warning).

Sorry, I don't understand, what is the -pedantic warning about if it's
already rejected? Or do you mean std=gnu -pedantic?


The latter. Actually, I use gfc_notify_std(GFC_STD_GNU, ... and just 
observed the -pedantic result. (I have to admit that I never quite 
understood - and still don't - what -pedantic exactly does.)



b) As GNU extension, other logical kinds are accepted in BIND(C) procedures;
however, as the main use of LOGICAL(kind=4) (for BIND(C) procedures) is to
handle logical expressions which use C's int, one has to deal with all
integer values and not only 0 and 1. Hence, a normal integer type is used
internally in that case. That has been done to avoid surprises of users and
hard to trace bugs.

Does this actually work robustly?


I think it does in the sense that it mitigates the problems related to 
LOGICAL(kind=4) and BIND(C) procedures. No, if one thinks of it as full 
cure for the problem. The only way to ensure this is to turn all of 
gfortran's LOGICALs into integers - and even that won't prevent issues 
related to interoperability with C's _Bool as that one expects only 0 
and 1. Thus, either C-Fortran or Fortran - Fortran 
logical(kind=C_Bool) could still lead to problems.



E.g. if you have a logical but really integer under the covers, what happens if you 
equivalence it with a normal logical variable.


Well, equivalencing of actual arguments / result variables is not 
allowed (I think, not checked). Besides, if you have equivalenced two 
variables, if you have set one, you may not access the other, e.g.:


logical :: A
integer :: B
equivalence (A,B)
A = .true.
B = 1
if (A) ...

is invalid as A is not defined, even if A = .true. and B = 1 have 
exactly the same storage size and bit patterns and, hence, in practice 
A would be a well defined .true.



Or pass it as an argument to a procedure expecting a normal logical etc.


If the value is only 1 or 0, there shouldn't be any problems. Only if 
one uses in turn .not. dummy there might be one.


The idea of the patch was only to mitigate the problems - a full cure is 
not possible (cf. above). I think the most likely problematic code is

   if (.not. c_function())
which is fixed by the patch. And the hope is that fold-converting to a 
type-precision=1, Boolean-type logical fixes most of the remaining issues.


I think the current solution which only affects non-C_BOOL-kind actual 
arguments and result variables of BIND(C) procedures is a good compromise.


* * *

But if others do not like this approach, one could turn the 
gfc_notify_std into a gfc_error are completely reject logicals with 
kinds /= C_Bool for dummy arguments/result variables in BIND(C) 
procedures. Would you prefer that approach?


(Doing so will break user code (e.g. Open MPI) and make users unhappy 
but it will be a tad safer as the current patch.)


Tobias

Re: [RFC, x86] Changes for AVX and AVX2 processors

2012-12-30 Thread Uros Bizjak 
On Sat, Dec 29, 2012 at 5:50 PM, Vladimir Yakovlev vbyakov...@gmail.com wrote:
 I did canges. Please take a look.

Please attach the patch, relative to mainline, not an incremental
patch vs. your previous version.

Thanks,
Uros.

Re: [RFC, x86] Changes for AVX and AVX2 processors

2012-12-30 Thread Uros Bizjak 
On Sat, Dec 29, 2012 at 5:57 PM, Vladimir Yakovlev vbyakov...@gmail.com wrote:
 I did changes. Please take a look.

 2012/12/29, Uros Bizjak ubiz...@gmail.com:
 On Sat, Dec 29, 2012 at 6:26 AM, Vladimir Yakovlev vbyakov...@gmail.com
 wrote:

 processor_alias_table contains the same processor type for all
 corei7, corei7-avx, core-avx-i and core-avx2. At least, it has
 consequence on checking x86_avx256_split_unaligned_load 
 ix86_tune_mask: for all these processors it results the same. Moreover
 we cannot turn new features on for AVX/AVX2 using
 initial_ix86_tune_features.

 corei7, corei7-avx and core-avx-i are all based on sandybridge (=
 PROCESSOR_COREI7) architecture. The only problematic entry is
 core-avx2, which should be based on new architecture. I propose
 PROCESSOR_HASWELL, in the same way as we have PROCESSOR_NOCONA.

@@ -2467,6 +2470,7 @@
   nocona,
   core2,
   corei7,
+  coreavx2,
   atom,
   geode,
   k6,

This string should match processor_alias_table name, so core-avx2.

@@ -28709,6 +28716,10 @@
  arg_str = corei7;
  priority = P_PROC_SSE4_2;
  break;
+   case PROCESSOR_HASWELL:
+ arg_str = core_avx2;
+ priority = P_PROC_SSE4_2;
+ break;
case PROCESSOR_ATOM:
  arg_str = atom;
  priority = P_PROC_SSSE3;

This is part of a processor dispatcher functionality. To support this
functionality, some more changes are needed, so it is IMO best to
leave this part out for now. I would also like the author of processor
dispatcher to review changes in this area.

On a related note, it looks to me that corei7 should declare
P_PROC_AVX here (this change should be part of another patch).

Other than that , the patch looks OK, but please repost final version
with a correct ChangeLog.

Uros.

Re: [RFC, x86] Changes for AVX and AVX2 processors

2012-12-30 Thread Vladimir Yakovlev 
I fixed typos and added CalangeLog.

2012-12-27  Vladimir Yakovlev  vladimir.b.yakov...@intel.com

* config/i386/i386-c.c (ix86_target_macros_internal): New case.
 (ix86_target_macros_internal): Likewise.

* config/i386/i386.c (m_CORE2I7): Removed.
(m_CORE_HASWELL): New macro.
(m_CORE_ALL): Likewise.
(initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL.
(initial_ix86_arch_features): Likewise.
(processor_target_table): Initializations for Core avx2.
(cpu_names): New names core-avx2.
(ix86_option_override_internal): Changed PROCESSOR_COREI7 by
PROCESSOR_CORE_HASWELL.
(ix86_issue_rate): New case.
(ia32_multipass_dfa_lookahead): Likewise.
(ix86_sched_init_global): Likewise.
(get_builtin_code_for_version): Likewise.

* config/i386/i386.h (TARGET_HASWELL): New macro.
(target_cpu_default): New TARGET_CPU_DEFAULT_haswell.
(processor_type): New PROCESSOR_HASWELL.


2012/12/30 Uros Bizjak ubiz...@gmail.com:
 On Sat, Dec 29, 2012 at 5:57 PM, Vladimir Yakovlev vbyakov...@gmail.com 
 wrote:
 I did changes. Please take a look.

 2012/12/29, Uros Bizjak ubiz...@gmail.com:
 On Sat, Dec 29, 2012 at 6:26 AM, Vladimir Yakovlev vbyakov...@gmail.com
 wrote:

 processor_alias_table contains the same processor type for all
 corei7, corei7-avx, core-avx-i and core-avx2. At least, it has
 consequence on checking x86_avx256_split_unaligned_load 
 ix86_tune_mask: for all these processors it results the same. Moreover
 we cannot turn new features on for AVX/AVX2 using
 initial_ix86_tune_features.

 corei7, corei7-avx and core-avx-i are all based on sandybridge (=
 PROCESSOR_COREI7) architecture. The only problematic entry is
 core-avx2, which should be based on new architecture. I propose
 PROCESSOR_HASWELL, in the same way as we have PROCESSOR_NOCONA.

 @@ -2467,6 +2470,7 @@
nocona,
core2,
corei7,
 +  coreavx2,
atom,
geode,
k6,

 This string should match processor_alias_table name, so core-avx2.

 @@ -28709,6 +28716,10 @@
   arg_str = corei7;
   priority = P_PROC_SSE4_2;
   break;
 +   case PROCESSOR_HASWELL:
 + arg_str = core_avx2;
 + priority = P_PROC_SSE4_2;
 + break;
 case PROCESSOR_ATOM:
   arg_str = atom;
   priority = P_PROC_SSSE3;

 This is part of a processor dispatcher functionality. To support this
 functionality, some more changes are needed, so it is IMO best to
 leave this part out for now. I would also like the author of processor
 dispatcher to review changes in this area.

 On a related note, it looks to me that corei7 should declare
 P_PROC_AVX here (this change should be part of another patch).

 Other than that , the patch looks OK, but please repost final version
 with a correct ChangeLog.

 Uros.


patch
Description: Binary data

Re: [PATCH] Fix handling of EXPAND_MEMORY for TFmode memory constraint in asm

2012-12-30 Thread John David Anglin 

Ping.

On 1-Dec-12, at 5:46 PM, John David Anglin wrote:


The attached change fixes the compilation of the following asm
in libquadmath/math/fmaq.c:

asm volatile ( : : m (v.value));

The issue arises because there is no support for directly loading  
TFmode

objects.

Ok for trunk?

Dave
--
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752  
(FAX: 952-6602)


2012-12-01  John David Anglin  dave.ang...@nrc-cnrc.gc.ca

PR middle-end/55198
* expr.c (expand_expr_real_1): Don't use bitfield extraction for non
BLKmode objects when EXPAND_MEMORY is specified.

Index: expr.c
===
--- expr.c  (revision 193685)
+++ expr.c  (working copy)
@@ -9928,7 +9928,8 @@
 GET_MODE_CLASS (mode) != MODE_COMPLEX_INT
 GET_MODE_CLASS (mode) != MODE_COMPLEX_FLOAT
 modifier != EXPAND_CONST_ADDRESS
-modifier != EXPAND_INITIALIZER)
+modifier != EXPAND_INITIALIZER
+modifier != EXPAND_MEMORY)
/* If the field is volatile, we always want an aligned
   access.  Do this in following two situations:
   1. the access is not already naturally



--
John David Anglin   dave.ang...@bell.net

Re: [PATCH, libbacktrace] Don't call __sync_lock_test_and_set if we don't have sync functions

2012-12-30 Thread John David Anglin 

Ping.

On 9-Dec-12, at 2:08 PM, John David Anglin wrote:


On hppa*-*-hpux*, we don't have sync functions.  However,
__sync_lock_test_and_set is called in backtrace_alloc and
backtrace_free.  This causes an abort before ICE proccessing
is fully complete.

hppa64 is an ELF target and backtraces are nominally supported.

The attached change avoids calling __sync_lock_test_and_set
if we don't have sync functions.  As a result, the memory is
leaked.

This fixes the btest failure.

OK for trunk?

Dave
--  
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752  
(FAX: 952-6602)


2012-12-09  John David Anglin  dave.ang...@nrc-cnrc.gc.ca

* mmap.c: Define HAVE_SYNC_FUNCTIONS if not defined.
(backtrace_alloc): Don't call __sync_lock_test_and_set if we don't
have sync functions.
(backtrace_free): Likewise.

Index: mmap.c
===
--- mmap.c  (revision 194055)
+++ mmap.c  (working copy)
@@ -49,6 +49,10 @@
#define MAP_ANONYMOUS MAP_ANON
#endif

+#ifndef HAVE_SYNC_FUNCTIONS
+#define HAVE_SYNC_FUNCTIONS 0
+#endif
+
/* A list of free memory blocks.  */

struct backtrace_freelist_struct
@@ -96,7 +100,7 @@
 using mmap.  __sync_lock_test_and_set returns the old state of
 the lock, so we have acquired it if it returns 0.  */

-  if (!__sync_lock_test_and_set (state-lock_alloc, 1))
+  if (HAVE_SYNC_FUNCTIONS  !__sync_lock_test_and_set (state- 
lock_alloc, 1))

{
  for (pp = state-freelist; *pp != NULL; pp = (*pp)-next)
{
@@ -158,7 +162,7 @@
 If we can't acquire the lock, just leak the memory.
 __sync_lock_test_and_set returns the old state of the lock, so we
 have acquired it if it returns 0.  */
-  if (!__sync_lock_test_and_set (state-lock_alloc, 1))
+  if (HAVE_SYNC_FUNCTIONS  !__sync_lock_test_and_set (state- 
lock_alloc, 1))

{
  backtrace_free_locked (state, addr, size);




--
John David Anglin   dave.ang...@bell.net

Re: [RFC, x86] Changes for AVX and AVX2 processors

2012-12-30 Thread Uros Bizjak 
On Sun, Dec 30, 2012 at 5:05 PM, Vladimir Yakovlev vbyakov...@gmail.com wrote:
 I fixed typos and added CalangeLog.

 2012-12-27  Vladimir Yakovlev  vladimir.b.yakov...@intel.com

 * config/i386/i386-c.c (ix86_target_macros_internal): New case.
  (ix86_target_macros_internal): Likewise.

 * config/i386/i386.c (m_CORE2I7): Removed.
 (m_CORE_HASWELL): New macro.
 (m_CORE_ALL): Likewise.
 (initial_ix86_tune_features): m_CORE2I7 is replaced by m_CORE_ALL.
 (initial_ix86_arch_features): Likewise.
 (processor_target_table): Initializations for Core avx2.
 (cpu_names): New names core-avx2.
 (ix86_option_override_internal): Changed PROCESSOR_COREI7 by
 PROCESSOR_CORE_HASWELL.
 (ix86_issue_rate): New case.
 (ia32_multipass_dfa_lookahead): Likewise.
 (ix86_sched_init_global): Likewise.
 (get_builtin_code_for_version): Likewise.

 * config/i386/i386.h (TARGET_HASWELL): New macro.
 (target_cpu_default): New TARGET_CPU_DEFAULT_haswell.
 (processor_type): New PROCESSOR_HASWELL.

Please remove this part, it should be part of processor dispatcher part:

@@ -28705,6 +28712,10 @@ get_builtin_code_for_version (tree decl, tree
*predicate_list)
  arg_str = corei7;
  priority = P_PROC_SSE4_2;
  break;
+   case PROCESSOR_HASWELL:
+ arg_str = core-avx2;
+ priority = P_PROC_SSE4_2;
+ break;
case PROCESSOR_ATOM:
  arg_str = atom;
  priority = P_PROC_SSSE3;

Uros.

Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64

2012-12-30 Thread Uros Bizjak 
On Fri, Dec 28, 2012 at 9:27 PM, Richard Henderson r...@redhat.com wrote:
 On 12/27/2012 12:08 AM, Uros Bizjak wrote:
 The alternative approach is changing cpuid definition in cpuid.h (as
 in attached patch) to preserve %rbx, but we can't detect various code
 model settings there. Since the change depends on the definition of
 __PIC__, we unnecessary preserve %rbx also for -mcmodel=small.

 Certainly we can.  We also control the preprocessor defines.
 All that's needed is that we create one for the code model.

Something like attached?

I have also included all suggestions (earlyclobber and operand prefix
on temporary register).

2012-12-30  Uros Bizjak  ubiz...@gmail.com

PR target/55712
* config/i386/i386-c.c (ix86_target_macros_internal): Depending on
selected code model, define __code_mode_small__, __code_model_medium__,
__code_model_large__, __code_model_32__ or __code_model_kernel__.
* config/i386/cpuid.h (__cpuid, __cpuid_count) [__i386__]: Prefix
xchg temporary register with %k.  Declare temporary register as
early clobbered.
[__x86_64__]: For medium and large code models, preserve %rbx register.

Tested on x86_64-pc-linux-gnu {,-m32}.

Uros.
Index: config/i386/cpuid.h
===
--- config/i386/cpuid.h (revision 194757)
+++ config/i386/cpuid.h (working copy)
@@ -136,35 +136,50 @@
 /* %ebx may be the PIC register.  */
 #if __GNUC__ = 3
 #define __cpuid(level, a, b, c, d) \
-  __asm__ (xchg{l}\t{%%}ebx, %1\n\t  \
+  __asm__ (xchg{l}\t{%%}ebx, %k1\n\t \
   cpuid\n\t  \
-  xchg{l}\t{%%}ebx, %1\n\t   \
-  : =a (a), =r (b), =c (c), =d (d) \
+  xchg{l}\t{%%}ebx, %k1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
   : 0 (level))
 
 #define __cpuid_count(level, count, a, b, c, d)\
-  __asm__ (xchg{l}\t{%%}ebx, %1\n\t  \
+  __asm__ (xchg{l}\t{%%}ebx, %k1\n\t \
   cpuid\n\t  \
-  xchg{l}\t{%%}ebx, %1\n\t   \
-  : =a (a), =r (b), =c (c), =d (d) \
+  xchg{l}\t{%%}ebx, %k1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
   : 0 (level), 2 (count))
 #else
 /* Host GCCs older than 3.0 weren't supporting Intel asm syntax
nor alternatives in i386 code.  */
 #define __cpuid(level, a, b, c, d) \
-  __asm__ (xchgl\t%%ebx, %1\n\t  \
+  __asm__ (xchgl\t%%ebx, %k1\n\t \
   cpuid\n\t  \
-  xchgl\t%%ebx, %1\n\t   \
-  : =a (a), =r (b), =c (c), =d (d) \
+  xchgl\t%%ebx, %k1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
   : 0 (level))
 
 #define __cpuid_count(level, count, a, b, c, d)\
-  __asm__ (xchgl\t%%ebx, %1\n\t  \
+  __asm__ (xchgl\t%%ebx, %k1\n\t \
   cpuid\n\t  \
-  xchgl\t%%ebx, %1\n\t   \
-  : =a (a), =r (b), =c (c), =d (d) \
+  xchgl\t%%ebx, %k1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
   : 0 (level), 2 (count))
 #endif
+#elif defined(__x86_64__)  (defined(__code_model_medium__) || 
defined(__code_model_large__))  defined(__PIC__)
+/* %ebx may be the PIC register.  */
+#define __cpuid(level, a, b, c, d) \
+  __asm__ (xchg{q}\t{%%}rbx, %q1\n\t \
+  cpuid\n\t  \
+  xchg{q}\t{%%}rbx, %q1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
+  : 0 (level))
+
+#define __cpuid_count(level, count, a, b, c, d)\
+  __asm__ (xchg{q}\t{%%}rbx, %q1\n\t \
+  cpuid\n\t  \
+  xchg{q}\t{%%}rbx, %q1\n\t  \
+  : =a (a), =r (b), =c (c), =d (d)\
+  : 0 (level), 2 (count))
 #else
 #define __cpuid(level, a, b, c, d) \
   __asm__ (cpuid\n\t \
Index: config/i386/i386-c.c
===
--- config/i386/i386-c.c(revision 194757)
+++ config/i386/i386-c.c(working copy)
@@ -243,6 +243,30 @@ ix86_target_macros_internal (HOST_WIDE_INT isa_fla
   break;
 }
 
+  switch (ix86_cmodel)
+{
+case CM_SMALL:
+case CM_SMALL_PIC:
+  def_or_undef (parse_in, __code_model_small__);
+  break;
+case CM_MEDIUM:
+case CM_MEDIUM_PIC:
+  def_or_undef (parse_in, __code_model_medium__);
+  break;
+case CM_LARGE:
+case CM_LARGE_PIC:
+  def_or_undef

Re: RFA: Fix uint128_t range checking in VRP

2012-12-30 Thread Richard Biener 
On Sun, Dec 23, 2012 at 5:48 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
 The minimum uint128_t value is an all-zeros double_int and the maximum
 value is an all-ones double_int.  Truncating these values to int and
 then sign-extending them gives the same all-zeros and all-ones values,
 so tree-vrp.c:range_fits_type_p concludes that uint128_t fits in an int.

 This showed up as a miscompilation of __fractutasf on mips64-linux-gnu,
 which in turn showed up in convert-float-4.c.

 There was already code to handle this problem when changing the sign
 and keeping the precision, but I think the rule applies regardless
 of precision.

 Tested on x86_64-linux-gnu and mips64-linux-gnu.  OK to install?

Ok.

Thanks,
Richard.

 Richard


 gcc/
 * tree-vrp.c (range_fits_type_p): Require the MSB of the double_int
 to be clear for sign changes.

 gcc/testsuite/
 * gcc.dg/torture/fp-int-convert-2.c: New test.

 Index: gcc/tree-vrp.c
 ===
 --- gcc/tree-vrp.c  2012-12-23 11:50:39.046419271 +
 +++ gcc/tree-vrp.c  2012-12-23 11:51:17.814677008 +
 @@ -8766,9 +8766,11 @@ range_fits_type_p (value_range_t *vr, un
|| TREE_CODE (vr-max) != INTEGER_CST)
  return false;

 -  /* For precision-preserving sign-changes the MSB of the double-int
 - has to be clear.  */
 -  if (src_precision == precision
 +  /* For sign changes, the MSB of the double_int has to be clear.
 + An unsigned value with its MSB set cannot be represented by
 + a signed double_int, while a negative value cannot be represented
 + by an unsigned double_int.  */
 +  if (TYPE_UNSIGNED (src_type) != unsigned_p
 (TREE_INT_CST_HIGH (vr-min) | TREE_INT_CST_HIGH (vr-max))  0)
  return false;

 Index: gcc/testsuite/gcc.dg/torture/fp-int-convert-2.c
 ===
 --- /dev/null   2012-12-03 19:06:31.446621561 +
 +++ gcc/testsuite/gcc.dg/torture/fp-int-convert-2.c 2012-12-23 
 13:46:35.449077882 +
 @@ -0,0 +1,18 @@
 +/* { dg-do run } */
 +/* { dg-require-effective-target int128 } */
 +
 +extern void abort (void);
 +
 +float __attribute__((noinline))
 +f (__uint128_t x)
 +{
 +  return x + 1;
 +}
 +
 +int
 +main (void)
 +{
 +  if (f (0xu) == 0)
 +abort ();
 +  return 0;
 +}

Re: RFA: Fix reuse of target variable in builtins.c

2012-12-30 Thread Richard Biener 
On Sun, Dec 23, 2012 at 6:02 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
 Some of the maths builtins try to expand via an optab and fall back
 to an expand_call.  The optabs path tends to clobber target,
 so the original target is lost by the time we call expand_call.  E.g.:

   /* Compute into TARGET.
  Set TARGET to wherever the result comes back.  */
   target = expand_binop (mode, builtin_optab, op0, op1,
  target, 0, OPTAB_DIRECT);

   /* If we were unable to expand via the builtin, stop the sequence
  (without outputting the insns) and call to the library function
  with the stabilized argument list.  */
   if (target == 0)
 {
   end_sequence ();
   return expand_call (exp, target, target == const0_rtx);
 }

 where the expand_call seems to be trying to use the original call target
 (as it should IMO) but actually always uses null.

 This patch tries to fix the cases I could see.  Tested on x86_64-linux-gnu
 and mips64-linux-gnu.  OK to install?

Ok.

Thanks,
Richard.

 Richard


 gcc/
 * builtins.c (expand_builtin_mathfn, expand_builtin_mathfn_2)
 (expand_builtin_mathfn_ternary, expand_builtin_mathfn_3)
 (expand_builtin_int_roundingfn_2): Keep the original target around
 for the fallback case.

 Index: gcc/builtins.c
 ===
 --- gcc/builtins.c  2012-12-23 16:56:30.218846420 +
 +++ gcc/builtins.c  2012-12-23 16:57:47.849415792 +
 @@ -2031,7 +2031,7 @@ expand_builtin_mathfn (tree exp, rtx tar
if (optab_handler (builtin_optab, mode) != CODE_FOR_nothing
 (!errno_set || !optimize_insn_for_size_p ()))
  {
 -  target = gen_reg_rtx (mode);
 +  rtx result = gen_reg_rtx (mode);

/* Wrap the computation of the argument in a SAVE_EXPR, as we may
  need to expand the argument again.  This way, we will not perform
 @@ -2042,20 +2042,20 @@ expand_builtin_mathfn (tree exp, rtx tar

start_sequence ();

 -  /* Compute into TARGET.
 -Set TARGET to wherever the result comes back.  */
 -  target = expand_unop (mode, builtin_optab, op0, target, 0);
 +  /* Compute into RESULT.
 +Set RESULT to wherever the result comes back.  */
 +  result = expand_unop (mode, builtin_optab, op0, result, 0);

 -  if (target != 0)
 +  if (result != 0)
 {
   if (errno_set)
 -   expand_errno_check (exp, target);
 +   expand_errno_check (exp, result);

   /* Output the entire sequence.  */
   insns = get_insns ();
   end_sequence ();
   emit_insn (insns);
 - return target;
 + return result;
 }

/* If we were unable to expand via the builtin, stop the sequence
 @@ -2078,7 +2078,7 @@ expand_builtin_mathfn (tree exp, rtx tar
  expand_builtin_mathfn_2 (tree exp, rtx target, rtx subtarget)
  {
optab builtin_optab;
 -  rtx op0, op1, insns;
 +  rtx op0, op1, insns, result;
int op1_type = REAL_TYPE;
tree fndecl = get_callee_fndecl (exp);
tree arg0, arg1;
 @@ -2134,7 +2134,7 @@ expand_builtin_mathfn_2 (tree exp, rtx t
if (optab_handler (builtin_optab, mode) == CODE_FOR_nothing)
  return NULL_RTX;

 -  target = gen_reg_rtx (mode);
 +  result = gen_reg_rtx (mode);

if (! flag_errno_math || ! HONOR_NANS (mode))
  errno_set = false;
 @@ -2151,29 +2151,29 @@ expand_builtin_mathfn_2 (tree exp, rtx t

start_sequence ();

 -  /* Compute into TARGET.
 - Set TARGET to wherever the result comes back.  */
 -  target = expand_binop (mode, builtin_optab, op0, op1,
 -target, 0, OPTAB_DIRECT);
 +  /* Compute into RESULT.
 + Set RESULT to wherever the result comes back.  */
 +  result = expand_binop (mode, builtin_optab, op0, op1,
 +result, 0, OPTAB_DIRECT);

/* If we were unable to expand via the builtin, stop the sequence
   (without outputting the insns) and call to the library function
   with the stabilized argument list.  */
 -  if (target == 0)
 +  if (result == 0)
  {
end_sequence ();
return expand_call (exp, target, target == const0_rtx);
  }

if (errno_set)
 -expand_errno_check (exp, target);
 +expand_errno_check (exp, result);

/* Output the entire sequence.  */
insns = get_insns ();
end_sequence ();
emit_insn (insns);

 -  return target;
 +  return result;
  }

  /* Expand a call to the builtin trinary math functions (fma).
 @@ -2187,7 +2187,7 @@ expand_builtin_mathfn_2 (tree exp, rtx t
  expand_builtin_mathfn_ternary (tree exp, rtx target, rtx subtarget)
  {
optab builtin_optab;
 -  rtx op0, op1, op2, insns;
 +  rtx op0, op1, op2, insns, result;
tree fndecl = get_callee_fndecl (exp);
tree arg0, arg1, arg2;
enum machine_mode mode;
 @@ -2214,7 +2214,7 @@ expand_builtin_mathfn_ternary (tree exp,
if (optab_handler (builtin_optab, mode)

Re: fixincludes for libquadmath build regression

2012-12-30 Thread Bruce Korb 
On 12/30/12 01:42, Paolo Bonzini wrote:
 Not my territory anymore, but it looks much better!  CCing Bruce.

Hi Alexandre,

Long time.  It's no wonder you've forgotten this little world! :)

Anyway, please make the expressions more readable and strip
out the generated text from the review message.

Readability guidance:  indent text and break lines logically.
Consider here-strings.  e.g. not:

c_fix_arg = # ifdef __SSE_MATH__\n%0\n
# else\n%1__asm__ __volatile__ (\fdiv st, st(0); fwait\\n
%1\t\t\t: \=t\ (__f) : \0\ (__f));\n
# endif;

instead:

c_fix_arg = # ifdef __SSE_MATH__\n%0\n
# else\n
%1__asm__ __volatile__ (\fdiv st, st(0); fwait\\n
%1\t\t\t: \=t\ (__f) : \0\ (__f));\n
# endif;

or even better:

c_fix_arg = - _EOText_
# ifdef __SSE_MATH__\n
%0
# else
%1__asm__ __volatile__ (fdiv st, st(0); fwait
%1  =t (__f) : 0 (__f));
# endif
_EOText_;