Re: [C++ Patch] for c++/54537
Hi, 2013/5/23 Jason Merrill > > On 05/22/2013 04:53 PM, Fabien Chêne wrote: >> >> Ah, I see, it works. Then we end up with three solutions: >> 1) remove the pow(double,double) overload >> 2) add a specialization template <> pow(double,double) >> 3) add an extern "C" declaration to refer to the C library function >> >> I don't have a strong preference, I would say that all solutions are >> more or less equivalent. In the end, builtins are just reached in >> different ways I guess, depending on the optimisations enabled. >> Given that Paolo already OKed the solution 1), I would go for it. > > > I guess #1 and #2 involve forwarding through a template, whereas #3 avoids > that and might give cleaner code without optimization. But library design > issues might be more important, so library folks should make the call here. Saying that discussions are encouraged -- or even better a decision --, is an understatement... My opinion is that if #3 is the best choice, then it should not be restricted to this case, and should be applied on all cases where functions are forwarded through templates to builtins. Then, It seems to me that such a change should ideally go in a separate patch. Thank you. -- Fabien
[Patch, AArch64] Support AdvSIMD MOVI / MVNI shifting ones variant.
Hi,
This patch adds support for AdvSIMD MOVI/MVNI Vd., #imm8, MSL, #amount.
OK?
Thanks,
Tejas Belagod
ARM.
Changelog:
2013-07-12 Tejas Belagod
gcc/
* config/aarch64/aarch64-protos.h
(aarch64_simd_immediate_valid_for_move): Remove.
* config/aarch64/aarch64.c (simd_immediate_info): New member.
(aarch64_simd_valid_immediate): Recognize idioms for shifting ones
cases.
(aarch64_output_simd_mov_immediate): Print the correct shift specifier.
testsuite/
* gcc.target/aarch64/vect-movi.c: New.diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index e5ae556..c4ea1fa 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -181,9 +181,6 @@ int aarch64_asm_preferred_eh_data_format (int, int);
int aarch64_hard_regno_mode_ok (unsigned, enum machine_mode);
int aarch64_hard_regno_nregs (unsigned, enum machine_mode);
int aarch64_simd_attr_length_move (rtx);
-int aarch64_simd_immediate_valid_for_move (rtx, enum machine_mode, rtx *,
- int *, unsigned char *, int *,
- int *);
int aarch64_uxt_size (int, HOST_WIDE_INT);
rtx aarch64_final_eh_return_addr (void);
rtx aarch64_legitimize_reload_address (rtx *, enum machine_mode, int, int,
int);
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 94db053..9fa18b6 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -93,6 +93,7 @@ struct simd_immediate_info
int shift;
int element_width;
bool mvn;
+ bool msl;
};
/* The current code model. */
@@ -6319,16 +6320,16 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
CHECK (2, 16, 11, bytes[i] == 0xff && bytes[i + 1] == bytes[1], 8, 1);
CHECK (4, 32, 12, bytes[i] == 0xff && bytes[i + 1] == bytes[1]
-&& bytes[i + 2] == 0 && bytes[i + 3] == 0, 0, 0);
+&& bytes[i + 2] == 0 && bytes[i + 3] == 0, 8, 0);
CHECK (4, 32, 13, bytes[i] == 0 && bytes[i + 1] == bytes[1]
-&& bytes[i + 2] == 0xff && bytes[i + 3] == 0xff, 0, 1);
+&& bytes[i + 2] == 0xff && bytes[i + 3] == 0xff, 8, 1);
CHECK (4, 32, 14, bytes[i] == 0xff && bytes[i + 1] == 0xff
-&& bytes[i + 2] == bytes[2] && bytes[i + 3] == 0, 0, 0);
+&& bytes[i + 2] == bytes[2] && bytes[i + 3] == 0, 16, 0);
CHECK (4, 32, 15, bytes[i] == 0 && bytes[i + 1] == 0
-&& bytes[i + 2] == bytes[2] && bytes[i + 3] == 0xff, 0, 1);
+&& bytes[i + 2] == bytes[2] && bytes[i + 3] == 0xff, 16, 1);
CHECK (1, 8, 16, bytes[i] == bytes[0], 0, 0);
@@ -6337,12 +6338,7 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
}
while (0);
- /* TODO: Currently the assembler cannot handle types 12 to 15.
- And there is no way to specify cmode through the compiler.
- Disable them till there is support in the assembler. */
- if (immtype == -1
- || (immtype >= 12 && immtype <= 15)
- || immtype == 18)
+ if (immtype == -1)
return false;
if (info)
@@ -6353,6 +6349,9 @@ aarch64_simd_valid_immediate (rtx op, enum machine_mode
mode, bool inverse,
unsigned HOST_WIDE_INT imm = 0;
+ if (immtype >= 12 && immtype <= 15)
+ info->msl = true;
+
/* Un-invert bytes of recognized vector, if necessary. */
if (invmask != 0)
for (i = 0; i < idx; i++)
@@ -7285,10 +7284,11 @@ aarch64_output_simd_mov_immediate (rtx const_vector,
bool is_valid;
static char templ[40];
const char *mnemonic;
+ const char *shift_op;
unsigned int lane_count = 0;
char element_char;
- struct simd_immediate_info info;
+ struct simd_immediate_info info = { NULL_RTX, 0, 0, false, false };
/* This will return true to show const_vector is legal for use as either
a AdvSIMD MOVI instruction (or, implicitly, MVNI) immediate. It will
@@ -7324,14 +7324,15 @@ aarch64_output_simd_mov_immediate (rtx const_vector,
}
mnemonic = info.mvn ? "mvni" : "movi";
+ shift_op = info.msl ? "msl" : "lsl";
if (lane_count == 1)
snprintf (templ, sizeof (templ), "%s\t%%d0, " HOST_WIDE_INT_PRINT_HEX,
mnemonic, UINTVAL (info.value));
else if (info.shift)
snprintf (templ, sizeof (templ), "%s\t%%0.%d%c, " HOST_WIDE_INT_PRINT_HEX
- ", lsl %d", mnemonic, lane_count, element_char,
- UINTVAL (info.value), info.shift);
+ ", %s %d", mnemonic, lane_count, element_char,
+ UINTVAL (info.value), shift_op, info.shift);
else
snprintf (templ, sizeof (templ), "%s\t%%0.%d%c, " HOST_WIDE_INT_PRINT_HEX,
mnemonic, lane_count, element_char, UINTVAL (info.value));
diff --git a/gcc/testsuite/gcc.target/aarch64/vect-movi.c
b/gcc/testsuite/gcc.target/aarch64/vect-movi.c
new file mode 100644
index 000..59a0bd5
--- /
Re: [Patch, AArch64] Support AdvSIMD MOVI / MVNI shifting ones variant.
On 12/07/13 11:25, Tejas Belagod wrote: Hi, This patch adds support for AdvSIMD MOVI/MVNI Vd., #imm8, MSL, #amount. OK? Thanks, Tejas Belagod ARM. Changelog: 2013-07-12 Tejas Belagod gcc/ * config/aarch64/aarch64-protos.h (aarch64_simd_immediate_valid_for_move): Remove. * config/aarch64/aarch64.c (simd_immediate_info): New member. (aarch64_simd_valid_immediate): Recognize idioms for shifting ones cases. (aarch64_output_simd_mov_immediate): Print the correct shift specifier. testsuite/ * gcc.target/aarch64/vect-movi.c: New. Looks OK to me. /Marcus
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
*ping*
Thank you,
Alexander
2013/6/20 Alexander Ivchenko :
> Hi,
>
> for Android:
>
> FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 (test for excess errors)
> Excess errors:
> <>/gcc/testsuite/g++.dg/tls/thread_local4.C:31:26: error:
> 'pthread_testcancel' was not declared in this scope
> <>/gcc/testsuite/g++.dg/tls/thread_local4.C:40:24: error:
> 'pthread_cancel' was not declared in this scope
>
> the same for thread_local4g.C.
>
> from http://www.kandroid.org/ndk/docs/system/libc/OVERVIEW.html
> "pthread_cancel() will not be supported in Bionic, because doing this
> would involve making the C library significantly bigger for very
> little benefit.
> <...>"
>
> The following patch switches those tests off for Android.
>
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index b8073d1..d217e4d 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2013-06-19 Alexander Ivchenko
> +
> + * g++.dg/tls/thread_local4.C: Disable test for Android.
> + * g++.dg/tls/thread_local4g.C: Ditto.
> +
> 2013-06-11 Tobias Burnus
>
> PR fortran/57508
> diff --git a/gcc/testsuite/g++.dg/tls/thread_local4.C
> b/gcc/testsuite/g++.dg/tls/thread_local4.C
> index acf1cae..cc1a35a 100644
> --- a/gcc/testsuite/g++.dg/tls/thread_local4.C
> +++ b/gcc/testsuite/g++.dg/tls/thread_local4.C
> @@ -1,6 +1,7 @@
> // Test for cleanups with pthread_cancel.
>
> -// { dg-do run }
> +// There is no support of pthread_cancel in Android.
> +// { dg-do run { target { ! *-*-android* } } }
> // { dg-require-effective-target c++11 }
> // { dg-require-effective-target tls_runtime }
> // { dg-require-effective-target pthread }
> diff --git a/gcc/testsuite/g++.dg/tls/thread_local4g.C
> b/gcc/testsuite/g++.dg/tls/thread_local4g.C
> index f5bc3ff..756c6a2 100644
> --- a/gcc/testsuite/g++.dg/tls/thread_local4g.C
> +++ b/gcc/testsuite/g++.dg/tls/thread_local4g.C
> @@ -1,6 +1,7 @@
> // Test for cleanups with pthread_cancel.
>
> -// { dg-do run }
> +// There is no support of pthread_cancel in Android.
> +// { dg-do run { target { ! *-*-android* } } }
> // { dg-require-effective-target c++11 }
> // { dg-require-effective-target tls_runtime }
> // { dg-require-effective-target pthread }
>
>
> is it ok for trunk?
>
>
> --Alexander
Fix PR57886, invalid folding of conversion
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably recent GCC versions. The checking in
convert_to_real is wrong, it compares type precisions of different
classed types. The change with the least impact is to reject only
TYPE_UNSIGNED inner types, but perhaps it would be better to only do the
transformation if the inner type is FLOAT_TYPE_P as well.
Regstrapping on x86-64 in progress. Okay for trunk?
Ciao,
Michael.
PR middle-end/57886
* convert.c (convert_to_real): Reject unsigned inner types.
testsuite/
* c-c++-common/pr57886.c: New test.
Index: convert.c
===
--- convert.c (revision 200240)
+++ convert.c (working copy)
@@ -213,10 +213,11 @@ convert_to_real (tree type, tree expr)
switch (TREE_CODE (expr))
{
/* Convert (float)-x into -(float)x. This is safe for
- round-to-nearest rounding mode. */
+ round-to-nearest rounding mode when the inner type is signed. */
case ABS_EXPR:
case NEGATE_EXPR:
if (!flag_rounding_math
+ && !TYPE_UNSIGNED (itype)
&& TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (expr)))
return build1 (TREE_CODE (expr), type,
fold (convert_to_real (type,
Index: testsuite/c-c++-common/pr57886.c
===
--- testsuite/c-c++-common/pr57886.c(revision 0)
+++ testsuite/c-c++-common/pr57886.c(working copy)
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+float global;
+int main()
+{
+ unsigned long z = 1;
+ float x = -z;
+ global = x;
+ if (global < 0)
+__builtin_abort ();
+ return 0;
+}
Re: Fix PR57886, invalid folding of conversion
Hi,
On Fri, 12 Jul 2013, Michael Matz wrote:
> Hi,
>
> GCC happily transforms (float)-z into -(float)z, even when z is of
> unsigned type (when it's larger than float). That's wrong (the result
> should always be positive, because -z is). It seems to me that this bug
> exists in all reasonably recent GCC versions. The checking in
> convert_to_real is wrong, it compares type precisions of different
> classed types. The change with the least impact is to reject only
> TYPE_UNSIGNED inner types, but perhaps it would be better to only do the
> transformation if the inner type is FLOAT_TYPE_P as well.
So, this is a dup of PR55771, I'm now proposing to add a test for
FLOAT_TYPE_P, not TYPE_UNSIGNED. Restarted the regstrap.
Ciao,
Michael.
--
PR middle-end/55771
* convert.c (convert_to_real): Reject non-float inner types.
testsuite/
* c-c++-common/pr55771.c: New test.
Index: convert.c
===
--- convert.c (revision 200240)
+++ convert.c (working copy)
@@ -213,10 +213,11 @@ convert_to_real (tree type, tree expr)
switch (TREE_CODE (expr))
{
/* Convert (float)-x into -(float)x. This is safe for
- round-to-nearest rounding mode. */
+ round-to-nearest rounding mode when the inner type is float. */
case ABS_EXPR:
case NEGATE_EXPR:
if (!flag_rounding_math
+ && FLOAT_TYPE_P (itype)
&& TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (expr)))
return build1 (TREE_CODE (expr), type,
fold (convert_to_real (type,
Index: testsuite/c-c++-common/pr55771.c
===
--- testsuite/c-c++-common/pr55771.c(revision 0)
+++ testsuite/c-c++-common/pr55771.c(working copy)
@@ -0,0 +1,12 @@
+/* { dg-do run } */
+
+float global;
+int main()
+{
+ unsigned long z = 1;
+ float x = -z;
+ global = x;
+ if (global < 0)
+__builtin_abort ();
+ return 0;
+}
Re: Fix PR57886, invalid folding of conversion
On Fri, Jul 12, 2013 at 03:37:44PM +0200, Michael Matz wrote: > So, this is a dup of PR55771, I'm now proposing to add a test for > FLOAT_TYPE_P, not TYPE_UNSIGNED. Restarted the regstrap. Ok if it passes bootstrap/regtest. I'd say we should apply it to 4.8 too, while it might not be a regression (or at least not a recent one), it is a silent wrong-code issue. Sorry for forgetting about this PR. > PR middle-end/55771 > * convert.c (convert_to_real): Reject non-float inner types. > > testsuite/ > * c-c++-common/pr55771.c: New test. Jakub
Re: Fix PR57886, invalid folding of conversion
On Fri, 12 Jul 2013, Michael Matz wrote: GCC happily transforms (float)-z into -(float)z, even when z is of unsigned type (when it's larger than float). That's wrong (the result should always be positive, because -z is). It seems to me that this bug exists in all reasonably recent GCC versions. The checking in convert_to_real is wrong, it compares type precisions of different classed types. The change with the least impact is to reject only TYPE_UNSIGNED inner types, but perhaps it would be better to only do the transformation if the inner type is FLOAT_TYPE_P as well. If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED (for LONG_MIN)? FLOAT_TYPE_P does seem safer indeed. I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing to refer to it under 2 different names on 2 consecutive lines. -- Marc Glisse
Call GNU ld with -O*
Hello,
this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3
(or more), -Ofast or -Os. Is there a cleaner way to test (optimize > 2 ||
optimize_size) in the driver?
I did a bootstrap on x86_64-unknown-linux-gnu and then manually tested by
looking at the -v output.
I tried a -O3 bootstrap, but even setting CFLAGS, BOOT_CFLAGS,
CFLAGS_FOT_TARGET, and the same 3 versions with CXXFLAGS and LDFLAGS, most
stuff still used the default -O2 -g. And most libraries that are part of
gcc explicitly use -Wl,-O1 for linking already.
2013-07-12 Marc Glisse
PR driver/44080
* gcc.c (LINK_OPT_SPEC): New macro.
(LINK_COMMAND_SPEC): Use it.
--
Marc GlisseIndex: gcc.c
===
--- gcc.c (revision 200921)
+++ gcc.c (working copy)
@@ -715,36 +715,45 @@ proper position among the other output f
/* Linker command line options for -fsanitize= late on the command line. */
#ifndef SANITIZER_SPEC
#define SANITIZER_SPEC "\
%{!nostdlib:%{!nodefaultlibs:%{fsanitize=address:" LIBASAN_SPEC "\
%{static:%ecannot specify -static with -fsanitize=address}\
%{fsanitize=thread:%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{fsanitize=thread:" LIBTSAN_SPEC "\
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}"
#endif
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC "%{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}} "
+#else
+#define LINK_OPT_SPEC ""
+#endif
+#endif
+
/* -u* was put back because both BSD and SysV seem to support it. */
/* %{static:} simply prevents an error message if the target machine
doesn't handle -static. */
/* We want %{T*} after %{L*} and %D so that it can be used to specify linker
scripts which exist in user specified directories, or in standard
directories. */
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2. */
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) " \
LINK_PLUGIN_SPEC \
"%{flto|flto=*:%
Re: Fix PR middle-end/57370
Ping.
On Thu, Jun 27, 2013 at 10:15 AM, Easwaran Raman wrote:
> A newly generated statement in build_and_add_sum function of
> tree-ssa-reassoc.c has to be assigned the UID of its adjacent
> statement. In one instance, it was assigned the wrong uid (of an
> earlier phi statement) which messed up the IR and caused the test
> program to hang. Bootstraps and no test regressions on x86_64/linux.
> Ok for trunk?
>
> Thanks,
> Easwaran
>
>
> 2013-06-27 Easwaran Raman
>
> PR middle-end/57370
> * tree-ssa-reassoc.c (build_and_add_sum): Do not use the UID of a phi
> node for a non-phi gimple statement.
>
> testsuite/ChangeLog:
> 2013-06-27 Easwaran Raman
>
> PR middle-end/57370
> * gfortran.dg/reassoc_12.f90: New testcase.
>
>
> Index: gcc/testsuite/gfortran.dg/reassoc_12.f90
> ===
> --- gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
> +++ gcc/testsuite/gfortran.dg/reassoc_12.f90 (revision 0)
> @@ -0,0 +1,74 @@
> +! { dg-do compile }
> +! { dg-options "-O2 -ffast-math" }
> +! PR middle-end/57370
> +
> + SUBROUTINE xb88_lr_adiabatic_lda_calc(e_ndrho_ndrho_ndrho, &
> + grad_deriv,npoints, sx)
> +IMPLICIT REAL*8 (t)
> +INTEGER, PARAMETER :: dp=8
> +REAL(kind=dp), DIMENSION(1:npoints) :: e_ndrho_ndrho_ndrho, &
> + e_ndrho_ndrho_rho
> + DO ii=1,npoints
> + IF( grad_deriv >= 2 .OR. grad_deriv == -2 ) THEN
> +t1425 = t233 * t557
> +t1429 = beta * t225
> +t1622 = t327 * t1621
> +t1626 = t327 * t1625
> +t1632 = t327 * t1631
> +t1685 = t105 * t1684
> +t2057 = t1636 + t8 * (t2635 + t3288)
> + END IF
> + IF( grad_deriv >= 3 .OR. grad_deriv == -3 ) THEN
> +t5469 = t5440 - t5443 - t5446 - t5449 - &
> +t5451 - t5454 - t5456 + t5459 - &
> +t5462 + t5466 - t5468
> +t5478 = 0.240e2_dp * t1616 * t973 * t645 * t1425
> +t5489 = 0.16e2_dp * t1429 * t1658
> +t5531 = 0.160e2_dp * t112 * t1626
> +t5533 = 0.160e2_dp * t112 * t1632
> +t5537 = 0.160e2_dp * t112 * t1622
> +t5541 = t5472 - t5478 - t5523 + t5525 + &
> +t5531 + t5533 + t5535 + t5537 + &
> +t5540
> +t5565 = t112 * t1685
> +t5575 = t5545 - t5548 + t5551 + t5553 - &
> +t5558 + t5560 - t5562 + t5564 - &
> +0.80e1_dp * t5565 + t5568 + t5572 + &
> +t5574
> +t5611 = t5579 - t5585 + t5590 - t5595 + &
> +t5597 - t5602 + t5604 + t5607 + &
> +t5610
> +t5613 = t5469 + t5541 + t5575 + t5611
> +t6223 = t6189 - &
> +0.36e0_dp * t83 * t84 * t5613 + &
> +t6222
> +t6227 = - t8 * (t5305 + t6223)
> +e_ndrho_ndrho_rho(ii) = e_ndrho_ndrho_rho(ii) + &
> + t6227 * sx
> +t6352 = t5440 - t5443 - t5446 - t5449 - &
> +t5451 - t5454 + &
> +0.40e1_dp * t102 * t327 * t2057 * t557 - &
> +t5456 + t5459 - t5462 + t5466 - &
> +t5468
> +t6363 = t5480 - t5489 + &
> +0.96e2_dp * t1054 * t640 * t3679
> +t6367 = t5472 - t5474 - t5478 - t5523 + &
> +t5525 + t5531 + t5533 + t5535 + &
> +t5537 - 0.20e1_dp * t102 * t105 * t6363 + &
> +t5540
> +t6370 = t5545 - t5548 + t5551 + t5553 - &
> +t5558 + t5560 - t5562 + t5564 - &
> +0.40e1_dp * t5565 + &
> +t5568 + t5572 + t5574
> +t6373 = t5579 - t5585 + t5590 - t5595 + &
> +t5597 - t5602 + t5604 + t5607 + &
> +t5610
> +t6375 = t6352 + t6367 + t6370 + t6373
> +t6380 = - 0.36e0_dp * t83 * t84 * t6375 + t5701
> +t6669 = -t4704 - t8 * (t6344 + t6380 + t6665)
> +e_ndrho_ndrho_ndrho(ii) = e_ndrho_ndrho_ndrho(ii) + &
> + t6669 * sx
> + END IF
> + END DO
> + END SUBROUTINE xb88_lr_adiabatic_lda_calc
> +
> Index: gcc/tree-ssa-reassoc.c
> ===
> --- gcc/tree-ssa-reassoc.c(revision 200429)
> +++ gcc/tree-ssa-reassoc.c(working copy)
> @@ -1207,7 +1207,7 @@ build_and_add_sum (tree type, tree op1, tree op2,
>if (gimple_code (op1def) == GIMPLE_PHI)
> {
>gsi = gsi_after_labels (gimple_bb (op1def));
> - gimple_set_uid (sum, gimple_uid (op1def));
> + gimple_set_uid (sum, gimple_uid (gsi_stmt (gsi)));
>gsi_in
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
> +/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast.
> */
> +#ifndef LINK_OPT_SPEC
> +#if HAVE_GNU_LD
> +#define LINK_OPT_SPEC "%{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}} "
Wouldn't something like "%{O*:%{O|O0|O1|O2|Og:;:-O2}}" work?
Jakub
Re: FW: [PATCH GCC]Relax the probability condition in CE pass when optimizing for code size
> 2013-07-12 Bin Cheng > > * ifcvt.c (ifcvt_after_combine): New static variable. > (cheap_bb_rtx_cost_p): Set scale to REG_BR_PROB_BASE when optimizing > for size. > (if_convert): New parameter after_combine. Set ifcvt_after_combine. > (rest_of_handle_if_conversion, rest_of_handle_if_after_combine, > rest_of_handle_if_after_reload): Pass new argument for if_convert. OK for mainline modulo the missing 'e' at the end of "interfere". -- Eric Botcazou
Re: Fix PR57886, invalid folding of conversion
Hi, On Fri, 12 Jul 2013, Marc Glisse wrote: > If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED > (for LONG_MIN)? Right, ... > FLOAT_TYPE_P does seem safer indeed. ... hence this is it now. > > I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing to > refer to it under 2 different names on 2 consecutive lines. True, I made that change. r200926. Ciao, Michael.
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Jakub Jelinek wrote:
On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC "%{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}} "
Wouldn't something like "%{O*:%{O|O0|O1|O2|Og:;:-O2}}" work?
It does (I only did a non-bootstrap c,c++ build and some manual tests with
-v). Thanks, I didn't know this syntax.
Is the new version ok? Any tests I should do that would be more useful
than running the testsuite? (I tried with several -O options in various
orders and made sure that a -Wl,-On ended up later in the command line)
--
Marc GlisseIndex: gcc.c
===
--- gcc.c (revision 200921)
+++ gcc.c (working copy)
@@ -715,36 +715,45 @@ proper position among the other output f
/* Linker command line options for -fsanitize= late on the command line. */
#ifndef SANITIZER_SPEC
#define SANITIZER_SPEC "\
%{!nostdlib:%{!nodefaultlibs:%{fsanitize=address:" LIBASAN_SPEC "\
%{static:%ecannot specify -static with -fsanitize=address}\
%{fsanitize=thread:%e-fsanitize=address is incompatible with
-fsanitize=thread}}\
%{fsanitize=thread:" LIBTSAN_SPEC "\
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}"
#endif
+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or -Ofast. */
+#ifndef LINK_OPT_SPEC
+#if HAVE_GNU_LD
+#define LINK_OPT_SPEC "%{O*:%{O|O0|O1|O2|Og:;:-O2}} "
+#else
+#define LINK_OPT_SPEC ""
+#endif
+#endif
+
/* -u* was put back because both BSD and SysV seem to support it. */
/* %{static:} simply prevents an error message if the target machine
doesn't handle -static. */
/* We want %{T*} after %{L*} and %D so that it can be used to specify linker
scripts which exist in user specified directories, or in standard
directories. */
/* We pass any -flto flags on to the linker, which is expected
to understand them. In practice, this means it had better be collect2. */
/* %{e*} includes -export-dynamic; see comment in common.opt. */
#ifndef LINK_COMMAND_SPEC
#define LINK_COMMAND_SPEC "\
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) " \
LINK_PLUGIN_SPEC \
"%{flto|flto=*:%
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 06:12:26PM +0200, Marc Glisse wrote:
> On Fri, 12 Jul 2013, Jakub Jelinek wrote:
>
> >On Fri, Jul 12, 2013 at 04:54:21PM +0200, Marc Glisse wrote:
> >>+/* GNU ld has -O1 and gold -O2, but we only pass it with -O3, -Os or
> >>-Ofast. */
> >>+#ifndef LINK_OPT_SPEC
> >>+#if HAVE_GNU_LD
> >>+#define LINK_OPT_SPEC "%{O*:%{!O0:%{!O1:%{!O2:%{!Og:%{!O:-O2}} "
> >
> >Wouldn't something like "%{O*:%{O|O0|O1|O2|Og:;:-O2}}" work?
>
> It does (I only did a non-bootstrap c,c++ build and some manual
> tests with -v). Thanks, I didn't know this syntax.
gcc.c has a huge comment that describes the syntax.
> Is the new version ok? Any tests I should do that would be more
> useful than running the testsuite? (I tried with several -O options
> in various orders and made sure that a -Wl,-On ended up later in the
> command line)
I'd say it is important to try say -O17 -O0, -O -O5 etc. and see whether
it works as desired. If that works, the patch is ok, with proper ChangeLog
entry.
Jakub
Re: Call GNU ld with -O*
Hi! On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse wrote: > this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 > (or more), -Ofast or -Os. I wondered about this before: why are no -O flags are passed to the (GNU) linker. What's the rationale for the mapping you propose of GCC and linker optimization flags? Why not a one-to-one mapping? Grüße, Thomas pgp2XQnZnIt4F.pgp Description: PGP signature
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 09:49:28AM -0700, Thomas Schwinge wrote: > Hi! > > On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse > wrote: > > this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 > > (or more), -Ofast or -Os. > > I wondered about this before: why are no -O flags are passed to the (GNU) > linker. > > What's the rationale for the mapping you propose of GCC and linker > optimization flags? Why not a one-to-one mapping? Because there is no 1:1 mapping. I bet ld doesn't grok -Os or -Ofast or -Og, and what -O* does in the linker doesn't have direct correspondence to what -O* does in the compiler. Last time I've looked, -O* in the linker just enabled some link time expensive computation of the hash table, so enabling -O in the linker for -O1 in the compiler is definitely not a good idea, similarly for -Og, those definitely want speed rather than better hash table. Jakub
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Jakub Jelinek wrote: gcc.c has a huge comment that describes the syntax. I know, my first reflex after reading your email was to re-read that comment to understand what you had written ;-) Is the new version ok? Any tests I should do that would be more useful than running the testsuite? (I tried with several -O options in various orders and made sure that a -Wl,-On ended up later in the command line) I'd say it is important to try say -O17 -O0, -O -O5 etc. and see whether it works as desired. Yes, that's what I had checked. If that works, the patch is ok, with proper ChangeLog entry. Oups, it was in the first email and I forgot to copy it in the second version. Thanks, -- Marc Glisse
Re: Call GNU ld with -O*
Hi! On Fri, 12 Jul 2013 18:53:58 +0200, Jakub Jelinek wrote: > On Fri, Jul 12, 2013 at 09:49:28AM -0700, Thomas Schwinge wrote: > > On Fri, 12 Jul 2013 16:54:21 +0200 (CEST), Marc Glisse > > wrote: > > > this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 > > > (or more), -Ofast or -Os. > > > > I wondered about this before: why are no -O flags are passed to the (GNU) > > linker. > > > > What's the rationale for the mapping you propose of GCC and linker > > optimization flags? Why not a one-to-one mapping? > > Because there is no 1:1 mapping. I bet ld doesn't grok -Os or -Ofast or > -Og, and what -O* does in the linker doesn't have direct correspondence to > what -O* does in the compiler. Last time I've looked, -O* in the linker > just enabled some link time expensive computation of the hash table, > so enabling -O in the linker for -O1 in the compiler is definitely not a > good idea, similarly for -Og, those definitely want speed rather than better > hash table. OK, there currently is no one-to-one mapping -- but why not establish one? Then the linker would enable the expensive optimizations only for -O2 and higher -- which would break backwards compatibility, bummer... (Though, I could see potential uses in the linker for -Ofast and -Og, too.) Grüße, Thomas pgp4qvJatWdvY.pgp Description: PGP signature
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse wrote: > > this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 > (or more), -Ofast or -Os. I don't understand why that is a good idea. The linker -O option is only distantly related to the compiler -O option. It was probably a mistake to have a linker -O option at all. Ian
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Ian Lance Taylor wrote: On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse wrote: this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 (or more), -Ofast or -Os. I don't understand why that is a good idea. Well, you thought it was 3 years ago ;-) http://gcc.gnu.org/ml/gcc/2010-05/msg00193.html The linker -O option is only distantly related to the compiler -O option. It was probably a mistake to have a linker -O option at all. Doesn't the linker produce something that is faster to link and/or smaller, with this flag? -- Marc Glisse
[PATCH, AArch64] Add vabs_s64 intrinsic
This patch implements the following intrinsic:
int64x1_t vabs_s64 (int64x1 a)
It uses __builtin_llabs(), which will lead to "abs Dn, Dm" being generated
for
this now that my other patch has been committed.
Test case added to scalar_intrinsics.c.
OK for trunk?
Cheers,
Ian
2013-07-12 Ian Bolton
gcc/
* config/aarch64/arm_neon.h (vabs_s64): New function.
testsuite/
* gcc.target/aarch64/scalar_intrinsics.c (test_vabs_s64): Added new
test.Index: gcc/config/aarch64/arm_neon.h
===
--- gcc/config/aarch64/arm_neon.h (revision 200594)
+++ gcc/config/aarch64/arm_neon.h (working copy)
@@ -17886,6 +17886,12 @@ vabsq_f64 (float64x2_t __a)
return __builtin_aarch64_absv2df (__a);
}
+__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
+vabs_s64 (int64x1_t a)
+{
+ return __builtin_llabs (a);
+}
+
/* vadd */
__extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
Index: gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c
===
--- gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c(revision
200594)
+++ gcc/testsuite/gcc.target/aarch64/scalar_intrinsics.c(working copy)
@@ -32,6 +32,18 @@ test_vaddd_s64_2 (int64x1_t a, int64x1_t
vqaddd_s64 (a, d));
}
+/* { dg-final { scan-assembler-times "\\tabs\\td\[0-9\]+, d\[0-9\]+" 1 } } */
+
+int64x1_t
+test_vabs_s64 (int64x1_t a)
+{
+ uint64x1_t res;
+ force_simd (a);
+ res = vabs_s64 (a);
+ force_simd (res);
+ return res;
+}
+
/* { dg-final { scan-assembler-times "\\tcmeq\\td\[0-9\]+, d\[0-9\]+,
d\[0-9\]+" 1 } } */
uint64x1_t
Re: RFC: Add of type-demotion pass
On Tue, 9 Jul 2013, Kai Tietz wrote: I would be glad if you could give me a couple hints. I try. Thanks :-) I wonder why you implemented this as a separate pass instead of adding it to tree-ssa-forwprop. demote_cast is (or should be) a special case of combine_conversions, so it would be nice to avoid the code duplication (there is also a version in fold-const.c). demote_into could be called from roughly the same place as simplify_conversion_from_bitmask. And you could reuse get_prop_source_stmt, can_propagate_from, remove_prop_source_from_use, etc. Initial patch (from last year) actual implemented that in forwprop. Ah, reading the conversation from last year helped me understand a bit better. I was then kindly asked to put this into a separate pass. There are some good reason why forward-propagation isn't the right place for it. Eg, forwprop does type-raising by default. Even in cases where that increases the size of the operation? I see a hoist_conversion_for_bitop_p that seems to try and prevent it. So by implementing type-demotion there too, would lead to raise-condition. So there would be required additionally that within forwprop a straight line-depth conversion is done for statement-lists. All this doesn't fit pretty well into current concept of forward-propagation ... The cast demotion is of course something of interest for folding and might be fitting into forward-propagation-pass too. The main cause why it is implemented within demotion pass is, that this pass introduces such cast-demotion-folding opportunities due its "unsigned"-type expansion. So we want to fold that within pass and not waiting until a later pass optimizes such redundant sequences away. I hope we can at least find a way to share code between the passes. If I understand, the main reason is because you want to go through the statements in reverse order, since this is the way the casts are being propagated (would forwprop also work, just more slowly, or would it miss opportunities across basic blocks?). It would miss some opportunities, Could you explain in what case? I guess my trouble understanding this is the same as in the next question, and I am missing a fundamental point... and causes penalty on speed due concept of forwprop. I have some trouble understanding why something as complicated as build_and_add_sum (which isn't restricted to additions by the way) is needed. Could you add a comment to the code explaining why you need to insert the statements precisely there and not for instance just before their use? Is that to try and help CSE? Yes, this function is a bit more complex as actual required for now in general. Nevertheless required. And I expect that demotion-pass will improve and so even the right now "unlikely" cases might be required more frequent. I had in front lighter version of statement addition, but it failed in some cases.In some (rare) cases we would otherwise choose wrong basic-block to add the new "cast"-statements. Well, there is another place (reassoc) where you can find nearly the same function, and its needs are exactly the same as within demote-pass. I had a look at the reassoc pass and failed to understand the logic there as well :-( I don't really understand how the basic block can be wrong. If we only handle the single use case with no side effects and no weird jump in between, nothing but the user should notice if you move the definition next to the use. So is this a way to handle weirder jumps than you could otherwise? I have added an additional early pass "typedemote1" to this patch for simple cases types can be easily sunken into statement without special unsigned-cast for overflow-case. Jakub asked for it. Tests have shown that this pass does optimizations in pretty few cases. As example in testsuite see for example pr46867.c testcase. The second pass (I put it behind first vrp pass to avoid testcase-conflicts) uses 'unsigned'-type casts to avoid undefined overflow behavior. This pass has much more hits in standard code, My little understanding from the old conversation and Jeff's post in this thread is that there are 2 ways to think about this optimization: 1) the canonical representation is with the smallest type possible. Using forwprop could make sense there (even if it may need help from another pass for some complicated cases, and it isn't the most efficient way). There is possibly a late pass to change all the types too small for the hardware into int. 2) we compute for each operation what minimal size it needs. Then, we may do some optimizations (truncate constants), possibly convert the operations to some smaller type (many at once), but not necessarily. This requires a separate pass but doesn't look like what you are doing. On Tue, 9 Jul 2013, Jeff Law wrote: On 07/08/2013 02:52 PM, Marc Glisse wrote: I wonder why you implemented this as a separate pass instead of adding it to tree-ssa-forw
Re: [c++-concepts] requires expressions
On 07/11/2013 02:59 PM, Andrew Sutton wrote: pp_cxx_requirement_parameter_list (cxx_pretty_printer *pp, tree t) This should be merged with pp_cxx_parameter_declaration_clause. +reqparms_to_string (tree p) And this should have a more generic name. + // requries clause. "requires" + if (check_requirements (t, args)) +return; + + ++processing_template_decl; + tree subst = instantiate_requirements (t, args); + --processing_template_decl; Surely you need to instantiate before checking, here and elsewhere. + inform (loc, "%qE is not valid syntax", TREE_OPERAND (t, 0)); I don't think I would mention "syntax" here, since a syntax error would have been diagnosed at parse time rather than constraint checking time. +// In an unevaluated context, the substitution of parm decls are not +// properly chained during substitution. Do that here. +static tree +fix_local_parms (tree sparms) A lot of the new code in pt.c doesn't seem like it needs to be there; let's put as much in constraint.cc as we can. Let's move some of the bits out of semantics.c as well. Incidentally, I notice a funny thing about the headers of the new files: /* Process declarations and variables for C++ compiler. ... // Components for processing constraints and evaluating constraints. The second line should move to the top of the file, replacing the first line. Jason
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 11:21 AM, Marc Glisse wrote: > On Fri, 12 Jul 2013, Ian Lance Taylor wrote: > >> On Fri, Jul 12, 2013 at 7:54 AM, Marc Glisse wrote: >>> >>> >>> this patch makes the driver pass -O2 to GNU ld if gcc was called with -O3 >>> (or more), -Ofast or -Os. >> >> >> I don't understand why that is a good idea. > > > Well, you thought it was 3 years ago ;-) > http://gcc.gnu.org/ml/gcc/2010-05/msg00193.html Ah well, coming to it fresh I'm not sure it is. >> The linker -O option is only distantly related to the compiler -O option. >> It was probably a mistake to have a linker -O option at all. > > > Doesn't the linker produce something that is faster to link and/or smaller, > with this flag? For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If you use -O2 or greater it will optimize string tables (e.g., the table holding the names of symbols) such that if the table stores two strings S1 and S2, and S2 is a suffix of S1, it will store only S1, and change pointers to S2 to point to the suffix of S1. So you are correct that the result will be smaller, but not faster to link. People routinely compile with -O or -O2. It's not clear to me that they should routinely link with -O or -O2. These decisions are not the default in the linker because they aren't good tradeoffs for most people. Ian
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: > For gold I think it has two effects. If you use compressed debug > sections, it will compress them with zlib level 9 rather than 1. If Marc's patch enabled it only for -O3/-Ofast (which are already compile time expensive options, thus it perhaps it doesn't hurt that much to spend extra time in the linker too) and -Os (then you are really looking for small, and if ld -O2 provides that, then perhaps it is desirable too). > you use -O2 or greater it will optimize string tables (e.g., the table > holding the names of symbols) such that if the table stores two > strings S1 and S2, and S2 is a suffix of S1, it will store only S1, > and change pointers to S2 to point to the suffix of S1. So you are > correct that the result will be smaller, but not faster to link. Oh, gold doesn't do this by default? ld.bfd does (unless it changed since I've implemented many years ago). Jakub
Re: Call GNU ld with -O*
On Fri, Jul 12, 2013 at 12:30 PM, Jakub Jelinek wrote: > On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: >> For gold I think it has two effects. If you use compressed debug >> sections, it will compress them with zlib level 9 rather than 1. If > > Marc's patch enabled it only for -O3/-Ofast (which are already compile time > expensive options, thus it perhaps it doesn't hurt that much to spend extra > time in the linker too) and -Os (then you are really looking for small, > and if ld -O2 provides that, then perhaps it is desirable too). OK, let me put it this way: perhaps there is some set of linker options that we should enable by default when linking with -O. But I don't see any particular reason that they are specifically the linker options that are selected by -O. >> you use -O2 or greater it will optimize string tables (e.g., the table >> holding the names of symbols) such that if the table stores two >> strings S1 and S2, and S2 is a suffix of S1, it will store only S1, >> and change pointers to S2 to point to the suffix of S1. So you are >> correct that the result will be smaller, but not faster to link. > > Oh, gold doesn't do this by default? ld.bfd does (unless it changed since > I've implemented many years ago). Correct: gold does not do it by default. For us link time matters most for large C++ programs. For those programs, the optimization only fired a tiny percentage of the time, but it took something like 4% of total link time. It wasn't worth it by default. Ian
Re: [C++ Patch] for c++/54537
Hi, "Fabien Chêne" ha scritto: >Then, It seems to me that such a change should ideally go in a separate >patch. Yes. Frankly I thought it was already clear that for the purpose of fixing this c++ issue we weren't inventing anything new in the library. Just in case isn't fully clear to everybody, we are talking about a very special case in the *tr1* code, which by now is barely maintained. If we want to be super safe and we want the c++ improvement for 4.9, we have to commit the whole package now. Paolo
Re: Call GNU ld with -O*
On Fri, 12 Jul 2013, Ian Lance Taylor wrote: On Fri, Jul 12, 2013 at 12:30 PM, Jakub Jelinek wrote: On Fri, Jul 12, 2013 at 12:25:16PM -0700, Ian Lance Taylor wrote: For gold I think it has two effects. If you use compressed debug sections, it will compress them with zlib level 9 rather than 1. If Marc's patch enabled it only for -O3/-Ofast (which are already compile time expensive options, thus it perhaps it doesn't hurt that much to spend extra time in the linker too) and -Os (then you are really looking for small, and if ld -O2 provides that, then perhaps it is desirable too). OK, let me put it this way: perhaps there is some set of linker options that we should enable by default when linking with -O. But I don't see any particular reason that they are specifically the linker options that are selected by -O. I completely agree with this. We could pass --compress-level=9 --merge-string-suffix --optimize-hashtables and a number of others (names invented). -O2 just happens to include things (both for bfd and gold, but the original motivation was bfd) that to me make sense to enable when linking with gcc -O3 (highest level, not the day-to-day fast compilation). If you think they don't, then let's reject this patch. Do you have any suggestions for linker flags that we could pass for high optimization levels where we don't mind if the linker takes a bit longer? (I guess that if an option was suitable for gcc -O2, you might have made it the default in the linker, hence my focus on -O3) -- Marc Glisse
[patch, fortran] PR 52669, warn about unused PRIVATE module variables
Hello world,
here is a rather self-evident patch for PR 52669.
Regression-tested. OK for trunk?
Thomas
2013-07-12 Thomas Koenig
PR fortran/52669
* trans-decl.c (gfc_create_module_variable): Optionally
warn about private module variable which is not used.
2013-07-12 Thomas Koenig
PR fortran/52669
* fortran.dg/module_variable_1.f90: New test.
Index: trans-decl.c
===
--- trans-decl.c (Revision 200743)
+++ trans-decl.c (Arbeitskopie)
@@ -4212,6 +4212,11 @@ gfc_create_module_variable (gfc_symbol * sym)
internal_error ("backend decl for module variable %s already exists",
sym->name);
+ if (warn_unused_variable && !sym->attr.referenced
+ && sym->attr.access == ACCESS_PRIVATE)
+gfc_warning ("Unused PRIVATE module variable '%s' declared at %L",
+ sym->name, &sym->declared_at);
+
/* We always want module variables to be created. */
sym->attr.referenced = 1;
/* Create the decl. */
! { dg-do compile }
! { dg-options "-Wall" }
module foo
integer, private :: i ! { dg-warning "Unused PRIVATE" }
integer, private :: j = 0
contains
subroutine bar
j = j + 1
end subroutine bar
end module foo
[committed] mips_expand_call: Remove empty statement
Hi,
Committed as obvious.
2013-07-12 Maciej W. Rozycki
gcc/
* config/mips/mips.c (mips_expand_call): Remove empty statement.
Maciej
gcc-mips-expand-call-syntax.patch
Index: gcc-fsf-trunk-quilt/gcc/config/mips/mips.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/config/mips/mips.c 2013-07-12
21:10:19.890906148 +0100
+++ gcc-fsf-trunk-quilt/gcc/config/mips/mips.c 2013-07-12 21:13:00.400592186
+0100
@@ -6902,7 +6902,7 @@ mips_expand_call (enum mips_call_type ty
gcc_assert (!lazy_p && type == MIPS_CALL_NORMAL);
return insn;
}
-;
+
orig_addr = addr;
if (!call_insn_operand (addr, VOIDmode))
{
[sso] Merge from trunk @200927
Bootstrapped/regtested on x86_64-suse-linux, applied on the branch. -- Eric Botcazou
Fix GCC bug causing bootstrap failure with vectorizer turned on
GCC bootstrap failed with loop vectorizer turned on by default at O2.
The symptom is that the comparison between stage2&3 compilers fails.
The root cause is a bug in the file "tree-vect-data-refs.c", where a
qsort() function call is used to sort a group of data references using
a comparison function called "dr_group_sort_cmp()". In this function,
the iterative hash values of tree nodes are used for comparisons. For
a declaration tree node, its UID participates in the calculation of
the hash value. However, a specific declaration may have different
UIDs whether the debug information is switched on/off (-gtoggle). In
consequence, the results of comparisons may vary in stage 2&3 during
bootstrapping.
The following patch fixed the bug. Compiler bootstraps and there is no
regressions in regression test. Compiler also bootstraps fine when
turning on vectorizer by default. Since this patch may produce
difference result (but still correct) than before due to the
modification to the comparison function, four test cases are adjusted
accordingly. OK for trunk?
Cong
Index: gcc/testsuite/gcc.target/i386/l_fma_double_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_1.c (working copy)
@@ -10,9 +10,9 @@
#include "l_fma_1.h"
/* { dg-final { scan-assembler-times "vfmadd132pd" 4 } } */
-/* { dg-final { scan-assembler-times "vfmadd213pd" 4 } } */
+/* { dg-final { scan-assembler-times "vfmadd231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfmsub132pd" 4 } } */
-/* { dg-final { scan-assembler-times "vfmsub213pd" 4 } } */
+/* { dg-final { scan-assembler-times "vfmsub231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd132pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmsub132pd" 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_1.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_1.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_float_1.c (working copy)
@@ -9,9 +9,9 @@
#include "l_fma_1.h"
/* { dg-final { scan-assembler-times "vfmadd132ps" 4 } } */
-/* { dg-final { scan-assembler-times "vfmadd213ps" 4 } } */
+/* { dg-final { scan-assembler-times "vfmadd231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfmsub132ps" 4 } } */
-/* { dg-final { scan-assembler-times "vfmsub213ps" 4 } } */
+/* { dg-final { scan-assembler-times "vfmsub231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd132ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmsub132ps" 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_double_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_double_3.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_double_3.c (working copy)
@@ -10,9 +10,9 @@
#include "l_fma_3.h"
/* { dg-final { scan-assembler-times "vfmadd132pd" 4 } } */
-/* { dg-final { scan-assembler-times "vfmadd213pd" 4 } } */
+/* { dg-final { scan-assembler-times "vfmadd231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfmsub132pd" 4 } } */
-/* { dg-final { scan-assembler-times "vfmsub213pd" 4 } } */
+/* { dg-final { scan-assembler-times "vfmsub231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd132pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd231pd" 4 } } */
/* { dg-final { scan-assembler-times "vfnmsub132pd" 4 } } */
Index: gcc/testsuite/gcc.target/i386/l_fma_float_3.c
===
--- gcc/testsuite/gcc.target/i386/l_fma_float_3.c (revision 200893)
+++ gcc/testsuite/gcc.target/i386/l_fma_float_3.c (working copy)
@@ -9,9 +9,9 @@
#include "l_fma_3.h"
/* { dg-final { scan-assembler-times "vfmadd132ps" 4 } } */
-/* { dg-final { scan-assembler-times "vfmadd213ps" 4 } } */
+/* { dg-final { scan-assembler-times "vfmadd231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfmsub132ps" 4 } } */
-/* { dg-final { scan-assembler-times "vfmsub213ps" 4 } } */
+/* { dg-final { scan-assembler-times "vfmsub231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd132ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmadd231ps" 4 } } */
/* { dg-final { scan-assembler-times "vfnmsub132ps" 4 } } */
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 200893)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -2311,6 +2311,80 @@
return vect_analyze_group_access (dr);
}
+
+
+/* Compare two tree nodes. This function is used to compare two
+ data-references as below. */
+
+static int
+compare_tree (tree t1, tree t2)
+{
+ int i, cmp;
+ enum tree_code code;
+ char tclass;
+
+ if (t1 == t2)
+re
[PATCH] Fix for PR57698
Patch attached to fix this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Here is what is going on. In rev. 200179, this change to tree-inline.c
Index: tree-inline.c
===
--- tree-inline.c (revision 200178)
+++ tree-inline.c (revision 200179)
@@ -3905,8 +3905,6 @@
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
- /* Avoid warnings during early inline pass. */
- && cgraph_global_info_ready
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
made inline failure errors during early inlining reportable. Now,
this function is called when the early_inliner calls
optimize_inline_calls. The reason for the failure,
CIF_INDIRECT_UNKNOWN_CALL, should not be reported because it is not a
valid reason,(see can_inline_edge_p in ipa-inline.c for the list of
reasons we intend to report) but it gets reported because of the above
change.
The reported bug happens only when optimization is turned on as the
early inliner pass invokes incremental inlining which calls
optimize_inline_calls and triggers the above failure.
So, the fix is then as simple as:
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
+ /* During early inline pass, report only when optimization is
+not turned on. */
+ && (cgraph_global_info_ready
+ || !optimize)
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
Seems like the right fix to me. Ok? The whole patch with test case
included is attached.
Thanks
Sri
* tree-inline.c (expand_call_inline): Emit errors during
early_inlining only if optimization is not turned on.
* gcc.c-torture/compile/pr57698.c: New test.
* gcc.c-torture/compile/pr43791.c: Remove prune output
directive.
* gcc.c-torture/compile/pr44043.c: Ditto.
Index: testsuite/gcc.c-torture/compile/pr57698.c
===
--- testsuite/gcc.c-torture/compile/pr57698.c (revision 0)
+++ testsuite/gcc.c-torture/compile/pr57698.c (revision 0)
@@ -0,0 +1,19 @@
+typedef int (*IsAcceptableThis) (const int );
+inline int
+fn1 (IsAcceptableThis p1)
+{
+p1 (0);
+return 0;
+}
+
+__attribute__ ((always_inline))
+inline int fn2 (const int a)
+{
+return 0;
+}
+
+void
+fn3 ()
+{
+fn1 (fn2);
+}
Index: testsuite/gcc.c-torture/compile/pr44043.c
===
--- testsuite/gcc.c-torture/compile/pr44043.c (revision 200912)
+++ testsuite/gcc.c-torture/compile/pr44043.c (working copy)
@@ -85,5 +85,3 @@ int raw_sendmsg(struct sock *sk, struct msghdr *ms
{
raw_send_hdrinc(sk, msg->msg_iov, len, (void *)0, msg->msg_flags);
}
-
-/* { dg-prune-output "(inlining failed in call to always_inline.*indirect
function call with a yet undetermined callee|called from here)" } */
Index: testsuite/gcc.c-torture/compile/pr43791.c
===
--- testsuite/gcc.c-torture/compile/pr43791.c (revision 200912)
+++ testsuite/gcc.c-torture/compile/pr43791.c (working copy)
@@ -18,5 +18,3 @@ void fasttrylock(void (*slowfn)()) {
void trylock(void) {
fasttrylock(slowtrylock);
}
-
-/* { dg-prune-output "(inlining failed in call to always_inline.*indirect
function call with a yet undetermined callee|called from here)" } */
Index: tree-inline.c
===
--- tree-inline.c (revision 200912)
+++ tree-inline.c (working copy)
@@ -3905,6 +3905,10 @@ expand_call_inline (basic_block bb, gimple stmt, c
for inlining, but we can't do that because frontends overwrite
the body. */
&& !cg_edge->callee->local.redefined_extern_inline
+ /* During early inline pass, report only when optimization is
+not turned on. */
+ && (cgraph_global_info_ready
+ || !optimize)
/* PR 20090218-1_0.c. Body can be provided by another module. */
&& (reason != CIF_BODY_NOT_AVAILABLE || !flag_generate_lto))
{
Re: RFA: Fix rtl-optimization/57425 (SPEC perl problem on MIPS)
Joern,
Has anyone reported any problems to you about this patch? I am running into
a problem running the perl benchmark from SPEC2006 and I have tracked it down
to this June 16 patch (SVN 200133,
GIT ddba76b84c757d93b4247713d558724776149b62). I am building a GCC cross
compiler running on x86 linux and targeting mips-mti-linux-gnu.
I haven't been able to cut down perl into a smaller test case yet but starting
with this version of GCC, if I build perl with -O2 or -O3 and then run it with
this perl input:
% cat x.pl
#!./perl
{
eval {
use Math::BigInt;
$y = pack('w*', Math::BigInt::->new(50));
};
}
1;
I get:
% ./perlbench_base.sellcey_reload x.pl
*** Error in `./perlbench_base.sellcey_reload': malloc(): memory corruption
(fast): 0x00642390 ***
and perl seems to go into an infinite loop. Before your change perl
ran and exited cleanly. I will try to create a smaller example but I wanted
to see if you (or someone else on gcc-patches) was seeing anything like
this on any other targets.
Steve Ellcey
sell...@mips.com
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
On Jun 20, 2013, at 4:30 AM, Alexander Ivchenko wrote: > for Android: > +2013-06-19 Alexander Ivchenko > + > + * g++.dg/tls/thread_local4.C: Disable test for Android. > + * g++.dg/tls/thread_local4g.C: Ditto. > is it ok for trunk? Ok.
Re: [Patch, microblaze]: Add TARGET_ASM_OUTPUT_MI_THUNK to support varargs thunk
On 03/18/13 05:49, David Holsgrove wrote: Changelog 2013-03-18 David Holsgrove * gcc/config/microblaze/microblaze.c: Add microblaze_asm_output_mi_thunk and define TARGET_ASM_OUTPUT_MI_THUNK and TARGET_ASM_CAN_OUTPUT_MI_THUNK Sorry it has taken so long to review this patch. The gcc microblaze-xilinx-elf build with this patch fails here: +microblaze_asm_output_mi_thunk (FILE *file, tree thunk_fndecl ATTRIBUTE_UNUSED, + HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, + tree function) ... + emit_insn (gen_jump (funexp)); (actually, in output_operand() downstream from this statement) while compiling c++98/strstream.cc, with an error that the "%l" operand was not a label. This is the first occasion when this routine is called. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [patch, fortran] PR 52669, warn about unused PRIVATE module variables
Am 12.07.2013 23:07, Thomas Koenig wrote: here is a rather self-evident patch for PR 52669. Regression-tested. OK for trunk? I think you should also handle: module m private integer :: k end module m and module m2 integer :: ll end module m2 when compiled with -fmodule-private. I think that's not yet handled by your code. It is probably sufficient to move the following code (in the same function) up before your check: if (sym->attr.access == ACCESS_UNKNOWN && (sym->ns->default_access == ACCESS_PRIVATE || (sym->ns->default_access == ACCESS_UNKNOWN && gfc_option.flag_module_private))) sym->attr.access = ACCESS_PRIVATE; Otherwise, it looks okay to me. Tobias PS: We will have to change the check when submodules are supported. But it is detectable in a module whether it is used as submodule; one can even handle as additional special case that there is a submodule, but it is in the same file. 2013-07-12 Thomas Koenig PR fortran/52669 * trans-decl.c (gfc_create_module_variable): Optionally warn about private module variable which is not used. 2013-07-12 Thomas Koenig PR fortran/52669 * fortran.dg/module_variable_1.f90: New test.
