Re: [PATCH, Fortran, pr78672, ctp1, v2] Gfortran test suite failures with a sanitized compiler
Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all,
thanks for all the input you gave on the patch I have present. I tried to
address all of it in the new version of the patch attached.
Mikael: data.c::create_character_initializer()
I have remove the test for rvalue->value.character.string and went to
gfc_assign_data_value () line 483 to prevent calling the routine when rvalue is
not an EXPR_CONSTANT (third chunk of the patch).
interface.c::compare_actual_formal()
I have reverted the change to look at actual_arr_ref when looking for assumed
size arrays which are dummy argument arrays. That chunk (#5) is now only
additionally checking whether f.sym is really of type BT_CHARACTER before
accessing its ts.u.cl.lenght.
For the second occurrence of actual_arr_ref I have extended
gfc_find_array_ref() with a flag to pass the search when no array ref is found
(Chunks #1, 2 and 6).
Jerry: trans-expr.c::gfc_conv_cst_int_power()
I have added comment to new C++ code. Would you like to add something to it?
The updated patch bootstraps and regtests fine on x86_64-linux/f23 on a regular
and on an instrumented gfortran. How do you like this patch?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/fortran/ChangeLog:
2016-12-11 Andre Vehreschild
PR fortran/78672
* array.c (gfc_find_array_ref): Add flag to return NULL when no ref is
found instead of erroring out.
* data.c (gfc_assign_data_value): Only constant expressions are valid
for initializers.
* gfortran.h: Reflect change of gfc_find_array_ref's signature.
* interface.c (compare_actual_formal): Access the non-elemental
array-ref. Prevent taking a REF_COMPONENT for a REF_ARRAY. Correct
indentation.
* module.c (load_omp_udrs): Clear typespec before reading into it.
* trans-decl.c (gfc_build_qualified_array): Prevent accessing the array
when it is a coarray.
* trans-expr.c (gfc_conv_cst_int_power): Use wi::abs()-function instead
of crutch preventing sanitizer's bickering here.
* trans-stmt.c (gfc_trans_deallocate): Only get data-component when it
is a descriptor-array here.
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index e6917a5..b2f5613 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2563,7 +2563,7 @@ cleanup:
characterizes the reference. */
gfc_array_ref *
-gfc_find_array_ref (gfc_expr *e)
+gfc_find_array_ref (gfc_expr *e, bool allow_null)
{
gfc_ref *ref;
@@ -2573,7 +2573,12 @@ gfc_find_array_ref (gfc_expr *e)
break;
if (ref == NULL)
-gfc_internal_error ("gfc_find_array_ref(): No ref found");
+{
+ if (allow_null)
+ return NULL;
+ else
+ gfc_internal_error ("gfc_find_array_ref(): No ref found");
+}
return &ref->u.ar;
}
diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce88..ea19732 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -483,7 +483,10 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
if (ref || last_ts->type == BT_CHARACTER)
{
- if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length != NULL))
+ /* An initializer has to be constant. */
+ if (rvalue->expr_type != EXPR_CONSTANT
+ || (lvalue->ts.u.cl->length == NULL
+ && !(ref && ref->u.ss.length != NULL)))
return false;
expr = create_character_initializer (init, last_ts, ref, rvalue);
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 670c13a..6a8d6eb 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3207,7 +3208,7 @@ bool gfc_check_constructor (gfc_expr *, bool (*)(gfc_expr *));
bool gfc_array_size (gfc_expr *, mpz_t *);
bool gfc_array_dimen_size (gfc_expr *, int, mpz_t *);
bool gfc_array_ref_shape (gfc_array_ref *, mpz_t *);
-gfc_array_ref *gfc_find_array_ref (gfc_expr *);
+gfc_array_ref *gfc_find_array_ref (gfc_expr *, bool a = false);
tree gfc_conv_array_initializer (tree type, gfc_expr *);
bool spec_size (gfc_array_spec *, mpz_t *);
bool spec_dimen_size (gfc_array_spec *, int, mpz_t *);
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 8afba84..b1d11c5 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2803,6 +2803,7 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
int i, n, na;
unsigned long actual_size, formal_size;
bool full_array = false;
+ gfc_array_ref *actual_arr_ref;
actual = *ap;
@@ -2942,37 +2943,38 @@ compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
and assumed-shape dummies, the string length needs to match
exactly. */
if (a->expr->ts.type == BT_CHARACTER
- && a->expr->ts.u.cl && a->expr->ts.u.cl->length
- && a->expr->ts.u.cl->length->expr_type == EXPR_CONSTANT
- && f->sym->ts.u.cl && f->sym->ts.u.cl && f->sym->ts.u.cl->length
- && f->sym->ts.u.cl->l
Re: [ARM] mno-pic-data-is-text-relative & msingle-pic-base
Goo day! Are there some news on this? Can we apply docs (and tests, maybe) improvements from this patch? -- Alexander Kurakin
Re: [PATCH, Fortran, pr78672, ctp1, v2] Gfortran test suite failures with a sanitized compiler
Hi Andre, Thanks for doing this work with the instrumented compiler. It was a great help with PR78350. As for the patch - OK for trunk. Paul On 11 December 2016 at 14:01, Andre Vehreschild wrote: > Hi Mikael, hi Jerry, hi Steve, hi Jane, hi Thomas, hi Paul, hi all, > > thanks for all the input you gave on the patch I have present. I tried to > address all of it in the new version of the patch attached. > > Mikael: data.c::create_character_initializer() > I have remove the test for rvalue->value.character.string and went to > gfc_assign_data_value () line 483 to prevent calling the routine when rvalue > is > not an EXPR_CONSTANT (third chunk of the patch). > > interface.c::compare_actual_formal() > I have reverted the change to look at actual_arr_ref when looking for assumed > size arrays which are dummy argument arrays. That chunk (#5) is now only > additionally checking whether f.sym is really of type BT_CHARACTER before > accessing its ts.u.cl.lenght. > > For the second occurrence of actual_arr_ref I have extended > gfc_find_array_ref() with a flag to pass the search when no array ref is found > (Chunks #1, 2 and 6). > > Jerry: trans-expr.c::gfc_conv_cst_int_power() > I have added comment to new C++ code. Would you like to add something to it? > > The updated patch bootstraps and regtests fine on x86_64-linux/f23 on a > regular > and on an instrumented gfortran. How do you like this patch? > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- If you're walking down the right path and you're willing to keep walking, eventually you'll make progress. Barack Obama
Re: [PATCH] Add support for Fuchsia (OS)
On Thu, 8 Dec 2016, Josh Conner wrote: This patch adds support to gcc for the Fuchsia OS (https://fuchsia.googlesource.com/). Once this is in, can you please suggest a news item for our main page? (You could cook a patch following https://gcc.gnu.org/about.html or suggest wording or an HTML snippet, and I'll take it from there.) Similarly, would be good to add this to gcc-7/changes.html. Gerald
Re: [PATCH, middle-end]: Fix PR78738, unrecognized insn with -ffast-math
On Fri, Dec 9, 2016 at 11:09 AM, Richard Biener
wrote:
> On Thu, Dec 8, 2016 at 10:44 PM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch fixes fall-out from excess-precision improvements
>> patch. As shown in the PR, the code throughout the compiler assumes
>> FLAG_PRECISION_FAST when flag_unsafe_math_optimizations flag is in
>> effect. The patch puts back two lines, removed by excess-precision
>> improvements patch.
>>
>> 2016-12-08 Uros Bizjak
>>
>> PR middle-end/78738
>> * toplev.c (init_excess_precision): Initialize flag_excess_precision
>> to EXCESS_PRECISION_FAST for flag_unsafe_math_optimizations.
>>
>> testsuite/ChangeLog:
>>
>> 2016-12-08 Uros Bizjak
>>
>> PR middle-end/78738
>> * gcc.target/i386/pr78738.c: New test.
>>
>> Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>>
>> OK for mainline?
>
> Hmm, I think it belongs to set_unsafe_math_optimization_flags instead
> (and be consistent if -fexcess-precision was manually specified).
>
> Also where do we assume connection between -funsafe-math-optimizations
> and FLAG_PRECISION_FAST? We have two flags so we should fix any
> user that looks at one but means the other.
The failure is caused by the call to ix86_emit_i387_round in
"lround2" expander. This expander is
enabled for x87 math when flag_unsafe_math_optimizations is enabled.
In the called ix86_emit_i387_round, DFmode PLUS pattern is manually
emitted:
emit_insn (gen_rtx_SET (e2, gen_rtx_PLUS (inmode, e1, half)));
but due to the definition of X87_ENABLE_ARITH, DFmode fadd pattern
remains disabled.
It is possible to fix the failure by enabling X87_ENABLE_ARITH (and
X87_ENABLE_FLOAT) for flag_unsafe_math_optimizations (as is the case
in the attached v2 patch), but since gcc-6.x does
if (flag_unsafe_math_optimizations)
flag_excess_precision = EXCESS_PRECISION_FAST;
I though it was worth mentioning the difference between gcc-6 and
gcc-7. Probably, x87 is the only target that cares for it, in which
case the attached patch is sufficient.
Uros.
--cut here--
Index: i386.h
===
--- i386.h (revision 243523)
+++ i386.h (working copy)
@@ -693,13 +693,16 @@
/* Whether to allow x87 floating-point arithmetic on MODE (one of
SFmode, DFmode and XFmode) in the current excess precision
configuration. */
-#define X87_ENABLE_ARITH(MODE) \
- (flag_excess_precision == EXCESS_PRECISION_FAST || (MODE) == XFmode)
+#define X87_ENABLE_ARITH(MODE) \
+ (flag_unsafe_math_optimizations \
+ || flag_excess_precision == EXCESS_PRECISION_FAST \
+ || (MODE) == XFmode)
/* Likewise, whether to allow direct conversions from integer mode
IMODE (HImode, SImode or DImode) to MODE. */
#define X87_ENABLE_FLOAT(MODE, IMODE) \
- (flag_excess_precision == EXCESS_PRECISION_FAST \
+ (flag_unsafe_math_optimizations \
+ || flag_excess_precision == EXCESS_PRECISION_FAST \
|| (MODE) == XFmode \
|| ((MODE) == DFmode && (IMODE) == SImode) \
|| (IMODE) == HImode)
--cut here--
Re: [Patch][i386] PR 70118: Fix ubsan warning on SSE2 loadl_epi64 and storel_epi64
On Fri, Dec 9, 2016 at 11:49 PM, Allan Sandfeld Jensen wrote: > On Tuesday 06 December 2016, Uros Bizjak wrote: >> Hello! >> >> > 2016-11-30 Allan Sandfeld Jensen >> > >> >PR target/70118 >> >* gcc/config/i386/mmintrin.h (__m64_u): New type >> >* gcc/config/i386/emmintrin.h (_mm_loadl_epi64, _mm_storel_epi64): >> >Make the allowed unaligned memory access explicit. >> >> OK. >> > Thanks > > Note I don't have write access. Committed to mainline SVN as r243527. Uros.
Re: [PATCH] Fix assembler arguments for -m16
On Sun, 6 Nov 2016, Uros Bizjak wrote:
> Looks good to me, so OK if tested on non-glibc system.
Thanks, Uros!
Turns out at least in my testing our testsuite is a little non-
deterministic :-(, but after tests without the patch, with the
patch, again with the patch, and without the patch again on
x86_64-unknown-freebsd11.0
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01191.html
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01197.html
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01218.html
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01224.html
I am sufficiently confident none of that noise is related to this patch
and committed it for Roger. (Thanks again, Roger!)
Uros, okay to also push to the GCC 6 branch for the coming release
and later the GCC 5 branch as well? For reference, the committed
patch below.
Gerald
2016-12-11 Roger Pau Monné
* config/i386/x86-64.h: Append --32 to the assembler options when
-m16 is used on non-glibc systems as well.
Index: config/i386/x86-64.h
===
--- config/i386/x86-64.h(revision 243527)
+++ config/i386/x86-64.h(working copy)
@@ -49,7 +49,7 @@
#define WCHAR_TYPE_SIZE 32
#undef ASM_SPEC
-#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
+#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"
#undef ASM_OUTPUT_ALIGNED_BSS
#define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \
Re: [PATCH, Fortran, pr78672, ctp1, v2] Gfortran test suite failures with a sanitized compiler
> Jerry: trans-expr.c::gfc_conv_cst_int_power() > I have added comment to new C++ code. Would you like to add something to it? Note that the wi changes have occurred at revision r210113. > > The updated patch bootstraps and regtests fine on x86_64-linux/f23 on a > regular > and on an instrumented gfortran. How do you like this patch? Results at https://gcc.gnu.org/bugzilla/attachment.cgi?id=40304. Thanks, Dominique > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de
Re: [wwwdocs] Remove Java
On Mon, 5 Dec 2016, Gerald Pfeifer wrote: > Applied now, and more changes to follow later. Done thusly, which removes quite a bit of the remaining bits. Remove java/port-files.html, java/port-signals.html, java/port-threads.html, java/libgcj-classpath-compare.html, java/merge-status.html and the java/compare and java/gui-compare subtrees. Gerald
Re: [PATCH] Fix assembler arguments for -m16
On Mon, 7 Nov 2016, Andreas Tobler wrote: > Results w/o patch: > https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00627.html > > Results with patch: > https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00672.html Thanks, Andreas, quite useful. For reference, the reason I did not go ahead with the patch right away, but did some more testing are those non-deterministic (at least on FreeBSD) tests we've got: In your testing, the patch "changed" the following: -FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c -O2 -std=c99 execution test +FAIL: c-c++-common/cilk-plus/CK/fib.c -g execution test -FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test The first two I've never seen, 22_locale/locale/cons/12658_thread-1.cc actually went the other direction (from PASS to FAIL) in my original tests. So, at least on FreeBSD 22_locale/locale/cons/12658_thread-1.cc pretty much is useful and pretty much random. Gerald
[PATCH, i386]: Improve cost function for STV transform of shifts with constant count operand
Hello!
Attached patch improves cost function for STV transform of shifts with
constant count operand. The new cost function reduces the gain by
COST_N_INSN(1) for shifts larger than or equal to 32.
2016-12-11 Uros Bizjak
PR target/70799
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p)
: Consider all constant shifts.
Add FIXME comment.
(dimode_scalar_chain::compute_convert_gain): Reduce gain for
constant shifts larger or equal than 32.
testsuite/ChangeLog:
2016-12-11 Uros Bizjak
PR target/70799
* gcc.target/i386/pr70799-3.c: New test.
Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline SVN.
Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 243523)
+++ config/i386/i386.c (working copy)
@@ -2809,10 +2809,9 @@ dimode_scalar_to_vector_candidate_p (rtx_insn *ins
{
case ASHIFT:
case LSHIFTRT:
- /* Consider only non-variable shifts narrower
-than general register width. */
- if (!(CONST_INT_P (XEXP (src, 1))
- && IN_RANGE (INTVAL (XEXP (src, 1)), 0, 31)))
+ /* FIXME: consider also variable shifts. */
+ if (!CONST_INT_P (XEXP (src, 1))
+ || !IN_RANGE (INTVAL (XEXP (src, 1)), 0, 63))
return false;
break;
@@ -3409,6 +3408,9 @@ dimode_scalar_chain::compute_convert_gain ()
gain += ix86_cost->add;
if (CONST_INT_P (XEXP (src, 0)))
gain -= vector_const_cost (XEXP (src, 0));
+ if (CONST_INT_P (XEXP (src, 1))
+ && INTVAL (XEXP (src, 1)) >= 32)
+ gain -= COSTS_N_INSNS (1);
}
else if (GET_CODE (src) == PLUS
|| GET_CODE (src) == MINUS
Index: testsuite/gcc.target/i386/pr70799-3.c
===
--- testsuite/gcc.target/i386/pr70799-3.c (nonexistent)
+++ testsuite/gcc.target/i386/pr70799-3.c (working copy)
@@ -0,0 +1,17 @@
+/* PR target/pr70799 */
+/* { dg-do compile { target { ia32 } } } */
+/* { dg-options "-O2 -march=slm -fno-split-wide-types -mno-stackrealign" } */
+/* { dg-final { scan-assembler "psllq" } } */
+/* { dg-final { scan-assembler "psrlq" } } */
+
+unsigned long long a, b, c;
+
+void test1 (void)
+{
+ a = (b << 55) | c;
+}
+
+void test2 (void)
+{
+ a = (b >> 55) | c;
+}
[patch, doc] Move -pthread documentation to linker options
PR 16519 notes that -pthread has only ever been documented as an RS6000
and Solaris 2 option. In fact it's supported by most/all(?)
POSIX-flavored targets, including GNU/Linux, BSD variants, Darwin, etc.
It's probably best to document it as a generic option, with the
expectation that GCC supports -pthread if the underlying operating
system or C library provides an implementation of the POSIX threads API.
After scratching my head about it, it seemed that it's best categorized
as a linker option even though it also affects the preprocessor on some
targets. I'll wait a day or two before committing the attached patch,
in case anybody wants to argue that this is the wrong way to categorize it.
-Sandra
2016-12-11 Sandra Loosemore
PR other/16519
gcc/
* doc/invoke.texi (Option Summary): Move -pthread to Linker Options.
(Options for Linking): Document -pthread here
(RS/6000 and PowerPC Options): ...not here.
(Solaris 2 Options): ...or here.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 243520)
+++ gcc/doc/invoke.texi (working copy)
@@ -481,7 +481,7 @@ Objective-C and Objective-C++ Dialects}.
@item Linker Options
@xref{Link Options,,Options for Linking}.
@gccoptlist{@var{object-file-name} -fuse-ld=@var{linker} -l@var{library} @gol
--nostartfiles -nodefaultlibs -nostdlib -pie -rdynamic @gol
+-nostartfiles -nodefaultlibs -nostdlib -pie -pthread -rdynamic @gol
-s -static -static-libgcc -static-libstdc++ @gol
-static-libasan -static-libtsan -static-liblsan -static-libubsan @gol
-static-libmpx -static-libmpxwrappers @gol
@@ -1012,7 +1012,7 @@ See RS/6000 and PowerPC Options.
-mfloat-gprs=yes -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double @gol
-mprototype -mno-prototype @gol
-msim -mmvme -mads -myellowknife -memb -msdata @gol
--msdata=@var{opt} -mvxworks -G @var{num} -pthread @gol
+-msdata=@var{opt} -mvxworks -G @var{num} @gol
-mrecip -mrecip=@var{opt} -mno-recip -mrecip-precision @gol
-mno-recip-precision @gol
-mveclibabi=@var{type} -mfriz -mno-friz @gol
@@ -1085,7 +1085,7 @@ See RS/6000 and PowerPC Options.
@emph{Solaris 2 Options}
@gccoptlist{-mclear-hwcap -mno-clear-hwcap -mimpure-text -mno-impure-text @gol
--pthreads -pthread}
+-pthreads}
@emph{SPARC Options}
@gccoptlist{-mcpu=@var{cpu-type} @gol
@@ -11526,6 +11526,14 @@ or model suboptions) when you specify th
@opindex no-pie
Don't produce a position independent executable.
+@item -pthread
+@opindex pthread
+Link with the POSIX threads library. This option is supported on
+GNU/Linux targets, most other Unix derivatives, and also on
+x86 Cygwin and MinGW targets. On some targets this option also sets
+flags for the preprocessor, so it should be used consistently for both
+compilation and linking.
+
@item -rdynamic
@opindex rdynamic
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
@@ -22040,11 +22048,6 @@ reliably associate function call with ar
TLS optimization, which in turn allows GCC to better schedule the
sequence.
-@item -pthread
-@opindex pthread
-Adds support for multithreading with the @dfn{pthreads} library.
-This option sets flags for both the preprocessor and linker.
-
@item -mrecip
@itemx -mno-recip
@opindex mrecip
@@ -23186,14 +23189,7 @@ These switches are supported in addition
@table @gcctabopt
@item -pthreads
@opindex pthreads
-Add support for multithreading using the POSIX threads library. This
-option sets flags for both the preprocessor and linker. This option does
-not affect the thread safety of object code produced by the compiler or
-that of libraries supplied with it.
-
-@item -pthread
-@opindex pthread
-This is a synonym for @option{-pthreads}.
+This is a synonym for @option{-pthread}.
@end table
@node SPARC Options
[committed] parisc: -mcaller-copies option
The attached change implements a new -mcaller-copies option on hppa. The
default 32-bit runtime
specifies that the callee copies arguments passed by hidden reference. This is
optimal but it causes
problems with openmp. See PR middle-end/68733:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68733
It's not clear openmp can be fixed to work with callee copies targets.
This option provides a work around. The general consensus is that caller
copies is better tested
and it seems probable that we will switch to caller copies on Debian when we
switch to gcc-7.
Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11
with no observed
regression. When enabled, it fixes the failures noted in PR 68733.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2012-12-11 John David Anglin
* config/pa/pa.c (pa_callee_copies): New function.
* config/pa/pa.opt (mcaller-copies): New option.
* doc/invoke.texi (mcaller-copies): Document option.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 243232)
+++ config/pa/pa.c (working copy)
@@ -195,6 +195,8 @@
static bool pa_legitimate_constant_p (machine_mode, rtx);
static unsigned int pa_section_type_flags (tree, const char *, int);
static bool pa_legitimate_address_p (machine_mode, rtx, bool);
+static bool pa_callee_copies (cumulative_args_t, machine_mode,
+ const_tree, bool);
/* The following extra sections are only used for SOM. */
static GTY(()) section *som_readonly_data_section;
@@ -343,7 +345,7 @@
#undef TARGET_PASS_BY_REFERENCE
#define TARGET_PASS_BY_REFERENCE pa_pass_by_reference
#undef TARGET_CALLEE_COPIES
-#define TARGET_CALLEE_COPIES hook_bool_CUMULATIVE_ARGS_mode_tree_bool_true
+#define TARGET_CALLEE_COPIES pa_callee_copies
#undef TARGET_ARG_PARTIAL_BYTES
#define TARGET_ARG_PARTIAL_BYTES pa_arg_partial_bytes
#undef TARGET_FUNCTION_ARG
@@ -10720,4 +10722,19 @@
return NULL_RTX;
}
+/* Implement TARGET_CALLEE_COPIES. The callee is responsible for copying
+ arguments passed by hidden reference in the 32-bit HP runtime. Users
+ can override this behavior for better compatibility with openmp at the
+ risk of library incompatibilities. Arguments are always passed by value
+ in the 64-bit HP runtime. */
+
+static bool
+pa_callee_copies (cumulative_args_t cum ATTRIBUTE_UNUSED,
+ machine_mode mode ATTRIBUTE_UNUSED,
+ const_tree type ATTRIBUTE_UNUSED,
+ bool named ATTRIBUTE_UNUSED)
+{
+ return !TARGET_CALLER_COPIES;
+}
+
#include "gt-pa.h"
Index: config/pa/pa.opt
===
--- config/pa/pa.opt(revision 243232)
+++ config/pa/pa.opt(working copy)
@@ -41,6 +41,10 @@
Target Ignore
Does nothing. Preserved for backward compatibility.
+mcaller-copies
+Target Report Mask(CALLER_COPIES)
+Caller copies function arguments passed by hidden reference.
+
mdisable-fpregs
Target Report Mask(DISABLE_FPREGS)
Disable FP regs.
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 243232)
+++ doc/invoke.texi (working copy)
@@ -761,7 +761,7 @@
@emph{HPPA Options}
@gccoptlist{-march=@var{architecture-type} @gol
--mdisable-fpregs -mdisable-indexing @gol
+-mcaller-copies -mdisable-fpregs -mdisable-indexing @gol
-mfast-indirect-calls -mgas -mgnu-ld -mhp-ld @gol
-mfixed-range=@var{register-range} @gol
-mjump-in-delay -mlinker-opt -mlong-calls @gol
@@ -17363,6 +17363,14 @@
@opindex mpa-risc-2-0
Synonyms for @option{-march=1.0}, @option{-march=1.1}, and @option{-march=2.0}
respectively.
+@item -mcaller-copies
+@opindex mcaller-copies
+The caller copies function arguments passed by hidden reference. This
+option should be used with care as it is not compatible with the default
+32-bit runtime. However, only aggregates larger than eight bytes are
+passed by hidden reference and the option provides better compatibility
+with openmp.
+
@item -mjump-in-delay
@opindex mjump-in-delay
This option is ignored and provided for compatibility purposes only.
[PATCH, rs6000] Fix PR78695
Hi,
PR78695 demonstrates a bug in swap analysis where we assume that a
data-flow definition contains a nonzero insn_info. This assumption
is wrong at least when -fstack-protector is in effect, as the
definition of the base register of the stack protector is not
associated with any insn. This patch fixes the problem in the
obvious way.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk? The problem was introduced
in GCC 7, so no backports are needed.
Thanks,
Bill
[gcc]
2016-12-11 Bill Schmidt
PR target/78695
* config/rs6000/rs6000.c (find_alignment_op): Discard from
consideration any definition that doesn't have an associated
insn.
[gcc/testsuite]
2016-12-11 Bill Schmidt
PR target/78695
* gcc.target/powerpc/swaps-stack-protector.c: New test.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 243506)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg)
if (!base_def_link || base_def_link->next)
break;
+ /* With stack-protector code enabled, and possibly in other
+circumstances, there may not be an associated insn for
+the def. */
+ if (!base_def_link->ref->base.insn_info)
+ break;
+
rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
and_operation = alignment_mask (and_insn);
if (and_operation != 0)
Index: gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c(working copy)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-fstack-protector -O3" } */
+
+/* PR78695: This code used to ICE in rs6000.c:find_alignment_op because
+ the stack protector address definition isn't associated with an insn. */
+
+void *a();
+long b() {
+ char c[1];
+ char *d = a(), *e = c;
+ long f = e ? b(e) : 0;
+ if (f > 54)
+f = 1;
+ while (f--)
+*d++ = *e++;
+}
[Darwin,PPC] Remove use of LR in restore_world.
Hi Folks, another from my darwin-ppc stack... r239866 removed most of the uses of LR in returns and sibcalls Darwin had an additional use of LR in the restore_world machinery. This patch removes it from the pattern in altivec.md and the relevant predicate. OK / Comments? Iain gcc/ 2016-12-11 Iain Sandoe * config/rs6000/altivec.md (*restore_world): Remove LR use. * config/rs6000/predicates.md (restore_world_operation): Adjust op count, remove one USE. --- gcc/config/rs6000/altivec.md| 1 - gcc/config/rs6000/predicates.md | 3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index 802aa74..0646f4c 100644 --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -406,7 +406,6 @@ (define_insn "*restore_world" [(match_parallel 0 "restore_world_operation" [(return) - (use (reg:SI LR_REGNO)) (use (match_operand:SI 1 "call_operand" "s")) (clobber (match_operand:SI 2 "gpc_reg_operand" "=r"))])] "TARGET_MACHO && (DEFAULT_ABI == ABI_DARWIN) && TARGET_32BIT" diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md index 57a463b..0716c46 100644 --- a/gcc/config/rs6000/predicates.md +++ b/gcc/config/rs6000/predicates.md @@ -1338,13 +1338,12 @@ rtx elt; int count = XVECLEN (op, 0); - if (count != 59) + if (count != 58) return 0; index = 0; if (GET_CODE (XVECEXP (op, 0, index++)) != RETURN || GET_CODE (XVECEXP (op, 0, index++)) != USE - || GET_CODE (XVECEXP (op, 0, index++)) != USE || GET_CODE (XVECEXP (op, 0, index++)) != CLOBBER) return 0; -- 2.8.1
Re: [PATCH, rs6000] Fix PR78695
Hi Bill, On Sun, Dec 11, 2016 at 01:35:59PM -0600, Bill Schmidt wrote: > --- gcc/config/rs6000/rs6000.c(revision 243506) > +++ gcc/config/rs6000/rs6000.c(working copy) > @@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg) >if (!base_def_link || base_def_link->next) > break; > > + /* With stack-protector code enabled, and possibly in other > + circumstances, there may not be an associated insn for > + the def. */ > + if (!base_def_link->ref->base.insn_info) > + break; Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work, DF_REF_INSN_INFO? Segher
Re: [patch, doc] Move -pthread documentation to linker options
Hi Sandra, > PR 16519 notes that -pthread has only ever been documented as an RS6000 and > Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored > targets, including GNU/Linux, BSD variants, Darwin, etc. It's probably best > to document it as a generic option, with the expectation that GCC supports > -pthread if the underlying operating system or C library provides an > implementation of the POSIX threads API. > > After scratching my head about it, it seemed that it's best categorized as > a linker option even though it also affects the preprocessor on some > targets. I'll wait a day or two before committing the attached patch, in > case anybody wants to argue that this is the wrong way to categorize it. I don't like categorizing it as a linker option: as you say, it affects the preprocessor as well (adding -D_REENTRANT on most systems), and in the past (not completely sure about the present) there were subtle bugs if you forgot to add -pthread during compilation. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] PR78056: Finish fixing build failure on Power7
Hi Kelvin,
On Fri, Dec 09, 2016 at 11:39:36AM -0700, Kelvin Nilsen wrote:
> +#ifndef HAVE_AS_POWER9
> +#define HAVE_AS_POWER9 0
> +#endif
> +#ifndef HAVE_AS_POWER8
> +#define HAVE_AS_POWER8 0
> +#endif
> +#ifndef HAVE_AS_POPCNTD
> +#define HAVE_AS_POPCNTD 0
> +#endif
> +#ifndef HAVE_AS_DFP
> +#define HAVE_AS_DFP 0
> +#endif
> +#ifndef HAVE_AS_POPCNTB
> +#define HAVE_AS_POPCNTB 0
> +#endif
Hrm. The only other file that uses these is rs6000.h, and it uses ifdef;
it's a bit confusing to redefine it here.
> + if (!have_cpu)
> + {
> + /* PowerPC 64-bit LE requires at least ISA 2.07. */
> + const char *default_cpu = ((!TARGET_POWERPC64)
> + ? "powerpc"
> + : ((BYTES_BIG_ENDIAN)
> + ? "powerpc64"
> + : "powerpc64le"));
Please lose all parens here (except maybe the very outer ones, emacs needs
that it seems?)
> + gcc_assert (d->icode > 0);
gcc_assert (d->icode != CODE_FOR_nothing); (throughout)
> + /* It is expected that these dst built-in functions have
> + d->icode equal to CODE_FOR_nothing. */
> + /* It is expected that these htm built-in functions have
> + d->icode equal to CODE_FOR_nothing. */
Should they? Expected who what where? _Should_ have or _can_ have?
I think you mean
/* d->icode can be CODE_FOR_nothing here. */
> +/* It is desirable to require-effective-target to be p5_ok, but there's
> + no such effective target, so we're just assuming that the effective
> + target is at minimum power5 ok. This test will fail if the
> + effective target is not power 5 ok, but there is no dg directive to
> + "unsupport" this test on such a platform. */
You could write one...
> +/* This test follows the pattern of pr78056-2.c, which has been
> + * exercised with binutils 2.25. This test, however, has not
> + * been exercised because the author of the test does not have access
> + * to a development environment that succesfully bootstraps gcc
> + * while at the same lacking assembler support for power 6. */
Heh. Yeah, supporting downlevel assemblers makes the testing matrix
explode. We probably should refuse any binutils that does not at least
support p8 (on Linux only?) (To be clear, I'm not asking you to do this).
Segher
Re: [patch, doc] Move -pthread documentation to linker options
On 12/11/2016 01:28 PM, Rainer Orth wrote: Hi Sandra, PR 16519 notes that -pthread has only ever been documented as an RS6000 and Solaris 2 option. In fact it's supported by most/all(?) POSIX-flavored targets, including GNU/Linux, BSD variants, Darwin, etc. It's probably best to document it as a generic option, with the expectation that GCC supports -pthread if the underlying operating system or C library provides an implementation of the POSIX threads API. After scratching my head about it, it seemed that it's best categorized as a linker option even though it also affects the preprocessor on some targets. I'll wait a day or two before committing the attached patch, in case anybody wants to argue that this is the wrong way to categorize it. I don't like categorizing it as a linker option: as you say, it affects the preprocessor as well (adding -D_REENTRANT on most systems), and in the past (not completely sure about the present) there were subtle bugs if you forgot to add -pthread during compilation. Do you have a suggestion for a better place to put it? Preferably *one* place, instead of duplicating the docs in 10+ places with target-specific options? -Sandra
Re: [PATCH, rs6000] Fix PR78695
Hi Segher,
On 12/11/16 2:00 PM, Segher Boessenkool wrote:
> Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work,
> DF_REF_INSN_INFO?
>
OK, currently regstrapping the following, which also fixes the problem with
a non-bootstrap compiler. Is this ok for trunk if it succeeds?
Thanks,
Bill
[gcc]
2016-12-11 Bill Schmidt
PR target/78695
* config/rs6000/rs6000.c (find_alignment_op): Discard from
consideration any artificial definition.
[gcc/testsuite]
2016-12-11 Bill Schmidt
PR target/78695
* gcc.target/powerpc/swaps-stack-protector.c: New test.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 243506)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg)
if (!base_def_link || base_def_link->next)
break;
+ /* With stack-protector code enabled, and possibly in other
+circumstances, there may not be an associated insn for
+the def. */
+ if (DF_REF_CLASS (base_def_link->ref) == DF_REF_ARTIFICIAL)
+ break;
+
rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
and_operation = alignment_mask (and_insn);
if (and_operation != 0)
Index: gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c(working copy)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-fstack-protector -O3" } */
+
+/* PR78695: This code used to ICE in rs6000.c:find_alignment_op because
+ the stack protector address definition isn't associated with an insn. */
+
+void *a();
+long b() {
+ char c[1];
+ char *d = a(), *e = c;
+ long f = e ? b(e) : 0;
+ if (f > 54)
+f = 1;
+ while (f--)
+*d++ = *e++;
+}
[patch, fortran] Fix ICEs with -fimplicit-none
Hello world,
the attached patch fixes a 5/6/7 regression with -fimplicit-none.
Regression-tested. OK for all affected branches?
Regards
Thomas
2016-12-11 Thomas Koenig
PR fortran/78239
* decl.c(char_len_param_value): Also check for -fimplicit-none
when determining if implicit none is in force.
2016-12-11 Thomas Koenig
PR fortran/78239
* gfortran.dg/fimplicit_none_1.f90: New test.
* gfortran.dg/fimplicit_none_2.f90: New test.
Index: decl.c
===
--- decl.c (Revision 243516)
+++ decl.c (Arbeitskopie)
@@ -922,7 +922,8 @@ char_len_param_value (gfc_expr **expr, bool *defer
if (!t && e->ts.type == BT_UNKNOWN
&& e->symtree->n.sym->attr.untyped == 1
- && (e->symtree->n.sym->ns->seen_implicit_none == 1
+ && (flag_implicit_none
+ || e->symtree->n.sym->ns->seen_implicit_none == 1
|| e->symtree->n.sym->ns->parent->seen_implicit_none == 1))
{
gfc_free_expr (e);
! { dg-do compile }
! { dg-options "-fimplicit-none" }
! PR fortran/78239 - used to ICE
subroutine s(n) ! { dg-error "has no IMPLICIT type" }
character(n) :: c ! { dg-error "Scalar INTEGER expression expected" }
c = 'c' ! { dg-error "has no IMPLICIT type" }
end
! { dg-do compile }
! { dg-options "-fimplicit-none" }
! PR fortran/78239 - used to ICE
program p
character(*), parameter :: z(2) = [character(n) :: 'x', 'y'] ! { dg-error "Scalar INTEGER expression expected" }
end
Re: [PATCH, rs6000] Fix PR78695
Hi Segher,
This indeed bootstrapped on powerpc64le-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks for the review!
Bill
On 12/11/16 3:31 PM, Bill Schmidt wrote:
> Hi Segher,
>
> On 12/11/16 2:00 PM, Segher Boessenkool wrote:
>> Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work,
>> DF_REF_INSN_INFO?
>>
> OK, currently regstrapping the following, which also fixes the problem with
> a non-bootstrap compiler. Is this ok for trunk if it succeeds?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2016-12-11 Bill Schmidt
>
> PR target/78695
> * config/rs6000/rs6000.c (find_alignment_op): Discard from
> consideration any artificial definition.
>
> [gcc/testsuite]
>
> 2016-12-11 Bill Schmidt
>
> PR target/78695
> * gcc.target/powerpc/swaps-stack-protector.c: New test.
>
>
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 243506)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg)
>if (!base_def_link || base_def_link->next)
> break;
>
> + /* With stack-protector code enabled, and possibly in other
> + circumstances, there may not be an associated insn for
> + the def. */
> + if (DF_REF_CLASS (base_def_link->ref) == DF_REF_ARTIFICIAL)
> + break;
> +
>rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
>and_operation = alignment_mask (and_insn);
>if (and_operation != 0)
> Index: gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c
> ===
> --- gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c (revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/swaps-stack-protector.c (working copy)
> @@ -0,0 +1,16 @@
> +/* { dg-do compile } */
> +/* { dg-options "-fstack-protector -O3" } */
> +
> +/* PR78695: This code used to ICE in rs6000.c:find_alignment_op because
> + the stack protector address definition isn't associated with an insn. */
> +
> +void *a();
> +long b() {
> + char c[1];
> + char *d = a(), *e = c;
> + long f = e ? b(e) : 0;
> + if (f > 54)
> +f = 1;
> + while (f--)
> +*d++ = *e++;
> +}
>
Re: [PATCH, rs6000] Fix PR78695
On Sun, Dec 11, 2016 at 03:31:35PM -0600, Bill Schmidt wrote: > On 12/11/16 2:00 PM, Segher Boessenkool wrote: > > Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work, > > DF_REF_INSN_INFO? > > > OK, currently regstrapping the following, which also fixes the problem with > a non-bootstrap compiler. Is this ok for trunk if it succeeds? > --- gcc/config/rs6000/rs6000.c(revision 243506) > +++ gcc/config/rs6000/rs6000.c(working copy) > @@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg) >if (!base_def_link || base_def_link->next) > break; > > + /* With stack-protector code enabled, and possibly in other > + circumstances, there may not be an associated insn for > + the def. */ > + if (DF_REF_CLASS (base_def_link->ref) == DF_REF_ARTIFICIAL) > + break; if (DF_REF_IS_ARTIFICIAL (base_def_link->ref)) Okay with that (no need to retest, just see if it compiles ;-) ) Thanks, Segher
Re: [PATCH, rs6000] Fix PR78695
Ah, I misread your comment and went hunting for DF_REF_ARTIFICIAL. Sorry! Will fix. Thanks again, Bill > On Dec 11, 2016, at 5:29 PM, Segher Boessenkool > wrote: > > On Sun, Dec 11, 2016 at 03:31:35PM -0600, Bill Schmidt wrote: >> On 12/11/16 2:00 PM, Segher Boessenkool wrote: >>> Maybe this should use DF_REF_IS_ARTIFICIAL? Or if that doesn't work, >>> DF_REF_INSN_INFO? >>> >> OK, currently regstrapping the following, which also fixes the problem with >> a non-bootstrap compiler. Is this ok for trunk if it succeeds? > >> --- gcc/config/rs6000/rs6000.c (revision 243506) >> +++ gcc/config/rs6000/rs6000.c (working copy) >> @@ -41433,6 +41433,12 @@ find_alignment_op (rtx_insn *insn, rtx base_reg) >> if (!base_def_link || base_def_link->next) >> break; >> >> + /* With stack-protector code enabled, and possibly in other >> + circumstances, there may not be an associated insn for >> + the def. */ >> + if (DF_REF_CLASS (base_def_link->ref) == DF_REF_ARTIFICIAL) >> +break; > > if (DF_REF_IS_ARTIFICIAL (base_def_link->ref)) > > Okay with that (no need to retest, just see if it compiles ;-) ) > > Thanks, > > > Segher >
Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622)
So I think the return value needs a bit of clarification here. Take
guidance from our discussion on this thread.
OK with that fixed.
jeff
The "strange test failures" that I wrote about in a separate thread
late last week prompted me to re-review the patch and add more test
cases. Those in turn exposed a bug in the adjust_range_for_overflow
function involving types of the same precision but different sign
where converting an unsigned range with an upper bound in excess of
the directive's TYPE_MAX would incorrectly accept the converted range
even though the new upper bound was less than the lower bound.
The updated patch corrects this oversight. In addition, it adjusts
the handling of the obscure corner case of zero precision and zero
argument which results in zero bytes (except in some even more
obscure cases involving some flags for some conversions). For
instance:
printf ("%.0i", 0);
results in zero bytes, but
printf ("%+.0i", 0);
results in 1 byte (and prints '+'). This is tracked in bug 78606.
Although the differences between the approved patch and the update
are very small I repost it in case one of you would like to double
check them. If not I'll commit the updated patch later in the week.
Martin
PR middle-end/78622 - -Wformat-length/-fprintf-return-value incorrect with overflow/wrapping
PR middle-end78606 - -Wformat-length/-fprintf-return-value incorrect for %+.0i and %.0o with zero value
gcc/ChangeLog:
PR middle-end/78622
* gimple-ssa-sprintf.c (min_bytes_remaining): Use res.knownrange
rather than res.bounded.
(get_width_and_precision): Set precision to -1 when negative.
(adjust_range_for_overflow): New function.
(format_integer): Correct the handling of the space, plus, and pound
flags, and the special case of zero precision.
Always set res.bounded to true unless either precision or width
is specified and unknown.
Call adjust_range_for_overflow.
Avoid use zero as the shortest value when precision is specified
but unknown.
(format_directive): Remove vestigial quoting. Always inform of
argument value or range when it's available.
(add_bytes): Correct the computation of boundrange used to
decide whether a warning is of a "maybe" or "defnitely" kind.
gcc/testsuite/ChangeLog:
PR middle-end/78622
* gcc.c-torture/execute/pr78622.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Remove "benign" undefined
behavior inadvertently introduced in a previous commit. Tighten
up final checking.
* gcc.dg/tree-ssa/builtin-sprintf-5.c: Rename macros for clarity.
Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-6.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-5.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: Remove xfails and
add a final optimization check.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.
* gcc.dg/tree-ssa/pr78622.c: New test.
diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 99a635a..905917d 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -637,7 +637,7 @@ min_bytes_remaining (unsigned HOST_WIDE_INT navail, const format_result &res)
if (HOST_WIDE_INT_MAX <= navail)
return navail;
- if (1 < warn_format_length || res.bounded)
+ if (1 < warn_format_length || res.knownrange)
{
/* At level 2, or when all directives output an exact number
of bytes or when their arguments were bounded by known
@@ -785,7 +785,7 @@ get_width_and_precision (const conversion_spec &spec,
{
prec = tree_to_shwi (spec.star_precision);
if (prec < 0)
- prec = 0;
+ prec = -1;
}
else
prec = HOST_WIDE_INT_MIN;
@@ -795,6 +795,69 @@ get_width_and_precision (const conversion_spec &spec,
*pprec = prec;
}
+/* With the range [*ARGMIN, *ARGMAX] of an integer directive's actual
+ argument, due to the conversion from either *ARGMIN or *ARGMAX to
+ the type of the directive's formal argument it's possible for both
+ to result in the same number of bytes or a range of bytes that's
+ less than the number of bytes that would result from formatting
+ some other value in the range [*ARGMIN, *ARGMAX]. This can be
+ determined by checking for the actual argument being in the range
+ of the type of the directive. If it isn't it must be assumed to
+ take on the full range of the directive's type.
+ Return true when the range has been adjusted to the full unsigned
+ range of DIRTYPE, or [0, DIRTYPE_MAX], and false otherwise. */
+
+static bool
+adjust_range_for_overflow (tree dirtype, tree *argmin, tree *argmax)
+{
+ tree argtype = TREE_TYPE (*argmin);
+ unsigned argprec = TYPE_PRECISION (argtype);
+ unsigned dirprec = TYPE_PRECISION (dirtype);
+
+ /* If the actual argument and the directive's argument have the same
+ precision and sign there can be no overflow and so there is nothing
+ t
[nios2, committed] fix structure sharing ICE
Since the last time I built GCC for nios2-linux-gnu target, it had
started dying while building libgcc, with an ICE complaining about
shared rtx structure in a CONST expression involving
UNSPEC_PIC_CALL_SYM. I tracked it down to failing to copy the source
rtx for one of the pieces of a hi/lo register load pair. Fixed thusly.
-Sandra
2016-12-11 Sandra Loosemore
gcc/
* config/nios2/nios2.c (nios2_emit_move_sequence): Call copy_rtx
to avoid shared structure error.
Index: gcc/config/nios2/nios2.c
===
--- gcc/config/nios2/nios2.c (revision 243520)
+++ gcc/config/nios2/nios2.c (working copy)
@@ -2334,7 +2334,8 @@ nios2_emit_move_sequence (rtx *operands,
from = nios2_legitimize_constant_address (from);
if (CONSTANT_P (from))
{
- emit_insn (gen_rtx_SET (to, gen_rtx_HIGH (Pmode, from)));
+ emit_insn (gen_rtx_SET (to,
+ gen_rtx_HIGH (Pmode, copy_rtx (from;
emit_insn (gen_rtx_SET (to, gen_rtx_LO_SUM (Pmode, to, from)));
set_unique_reg_note (get_last_insn (), REG_EQUAL,
copy_rtx (operands[1]));
Re: [committed] parisc: -mcaller-copies option
On 12/11/2016 12:30 PM, John David Anglin wrote: +@item -mcaller-copies +@opindex mcaller-copies +The caller copies function arguments passed by hidden reference. This +option should be used with care as it is not compatible with the default +32-bit runtime. However, only aggregates larger than eight bytes are +passed by hidden reference and the option provides better compatibility +with openmp. Please fix this to spell "OpenMP" correctly. -Sandra
Re: [committed] parisc: -mcaller-copies option
On 2016-12-11, at 9:22 PM, Sandra Loosemore wrote: > Please fix this to spell "OpenMP" correctly. Done. -- John David Anglin dave.ang...@bell.net
[PATCH] [AArch64] Implement popcount pattern
Hi,
Please find attached the patch that implements the support for popcount
patterns in AArch64.
The implementation improves OVS-DPDK on ThunderX by 3%. It would have a
similar effect on other AArch64 targets.
Please review the patch and let us know if its okay?
2016-12-12 Andrew Pinski
gcc
* config/aarch64/aarch64.md (popcount2): New pattern.
gcc/testsuite
* gcc.target/aarch64/popcount.c : New Testcase.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 65eb326..c688ddc 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -3785,6 +3785,39 @@
}
)
+/* Pop count be done via the pop count instruction in NEON. */
+/*
+ mov v.1d, x0
+ Cnt v1.8b, v.8b
+ Addv b2, v1.8b
+ Mov w0, v2.b[0]
+*/
+(define_expand "popcount2"
+ [(match_operand:GPI 0 "register_operand")
+ (match_operand:GPI 1 "register_operand")]
+ "TARGET_SIMD"
+{
+ rtx v = gen_reg_rtx (V8QImode);
+ rtx v1 = gen_reg_rtx (V8QImode);
+ rtx r = gen_reg_rtx (QImode);
+ rtx in = operands[1];
+ rtx out = operands[0];
+ if(mode == SImode)
+{
+ rtx tmp;
+ tmp = gen_reg_rtx (DImode);
+ /* If we have SImode, zero extend to DImode, pop count does
+ not change if we have extra zeros. */
+ emit_insn (gen_zero_extendsidi2 (tmp, in));
+ in = tmp;
+}
+ emit_move_insn (v, gen_lowpart (V8QImode, in));
+ emit_insn (gen_popcountv8qi2 (v1, v));
+ emit_insn (gen_reduc_plus_scal_v8qi (r, v1));
+ emit_insn (gen_zero_extendqi2 (out, r));
+ DONE;
+})
+
(define_insn "clrsb2"
[(set (match_operand:GPI 0 "register_operand" "=r")
(clrsb:GPI (match_operand:GPI 1 "register_operand" "r")))]
diff --git a/gcc/testsuite/gcc.target/aarch64/popcount.c b/gcc/testsuite/gcc.target/aarch64/popcount.c
new file mode 100644
index 000..2d71168
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/popcount.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int foo(int x)
+{
+ return __builtin_popcount(x);
+}
+
+/* { dg-final { scan-assembler-not "popcountdi2" } } */
+/* { dg-final { scan-assembler "cnt\t" } } */
[PING**2] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)
Ping... On 12/05/16 14:41, Bernd Edlinger wrote: > Hi, > > this was the latest version of my patch: > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02796.html > > > Thanks > Bernd.
[SPARC] Adjust T constraint
The main purpose of the T constraint is to make sure that a memory reference is aligned on a 64-bit boundary in 32-bit mode. But define_memory_constraint is not appropriate for such a constraint, because reload may think that it can satisfy it by reloading the address, which is of course wrong; this apparently never happens with old reload, but does with LRA and is responsible for the last couple of regressions in the testsuite in 32-bit mode. Tested on SPARC/Solaris w/ and w/o -mlra, applied on the mainline. 2016-12-12 Eric Botcazou * config/sparc/constraints.md (T): Use special memory constraint. (U): Minor tweak. (W): Add TARGET_ARCH64 test. * config/sparc/sparc.md (*movdi_insn_sp32): Replace 'W' with 'T'. (*movdf_insn_sp32): Likewise. (*mov_insn_sp32): Likewise. Replace 'e' with 'f' in conjunction with offsettable memory references. -- Eric BotcazouIndex: config/sparc/constraints.md === --- config/sparc/constraints.md (revision 243513) +++ config/sparc/constraints.md (working copy) @@ -128,11 +128,11 @@ (define_constraint "S" (and (match_code "const_double") (match_test "fp_high_losum_p (op)"))) -;; Not needed in 64-bit mode -(define_memory_constraint "T" +;; We need a special memory constraint because of the alignment requirement +(define_special_memory_constraint "T" "Memory reference whose address is aligned to 8-byte boundary" - (and (match_test "TARGET_ARCH32") - (match_code "mem") + (and (match_code "mem") + (match_test "TARGET_ARCH32") (match_test "memory_ok_for_ldd (op)"))) ;; This awkward register constraint is necessary because it is not @@ -174,16 +174,17 @@ (define_memory_constraint "T" ;; reg_class_for_constraint, and checks it against NO_REGS. (define_constraint "U" "Pseudo-register or hard even-numbered integer register" - (and (match_test "TARGET_ARCH32") - (match_code "reg") + (and (match_code "reg") (ior (match_test "REGNO (op) < FIRST_PSEUDO_REGISTER") (not (match_test "reload_in_progress && reg_renumber [REGNO (op)] < 0"))) + (match_test "TARGET_ARCH32") (match_test "register_ok_for_ldd (op)"))) -;; Equivalent to 'T' but available in 64-bit mode +;; Equivalent to 'T' but in 64-bit mode without alignment requirement (define_memory_constraint "W" "Memory reference for 'e' constraint floating-point register" (and (match_code "mem") + (match_test "TARGET_ARCH64") (match_test "memory_ok_for_ldd (op)"))) (define_memory_constraint "w" Index: config/sparc/sparc.md === --- config/sparc/sparc.md (revision 243513) +++ config/sparc/sparc.md (working copy) @@ -1705,9 +1705,9 @@ (define_expand "movdi" (define_insn "*movdi_insn_sp32" [(set (match_operand:DI 0 "nonimmediate_operand" - "=T,o,U,T,r,o,r,r,?*f,?T,?*f,?o,?*e,?*e, r,?*f,?*e,?W,*b,*b") + "=T,o,U,T,r,o,r,r,?*f,?T,?*f,?o,?*e,?*e, r,?*f,?*e,?T,*b,*b") (match_operand:DI 1 "input_operand" - " J,J,T,U,o,r,i,r, T,*f, o,*f, *e, *e,?*f, r, W,*e, J, P"))] + " J,J,T,U,o,r,i,r, T,*f, o,*f, *e, *e,?*f, r, T,*e, J, P"))] "TARGET_ARCH32 && (register_operand (operands[0], DImode) || register_or_zero_operand (operands[1], DImode))" @@ -2336,9 +2336,9 @@ (define_expand "movdf" (define_insn "*movdf_insn_sp32" [(set (match_operand:DF 0 "nonimmediate_operand" - "=T,o,b,b,e,e,*r, f, e,W,U,T, f,o, *r,*r, o") + "=T,o,b,b,e,e,*r, f, e,T,U,T, f,o, *r,*r, o") (match_operand:DF 1 "input_operand" - " G,G,G,C,e,e, f,*r,W#F,e,T,U,o#F,f,*rF, o,*r"))] + " G,G,G,C,e,e, f,*r,T#F,e,T,U,o#F,f,*rF, o,*r"))] "TARGET_ARCH32 && (register_operand (operands[0], DFmode) || register_or_zero_or_all_ones_operand (operands[1], DFmode))" @@ -8543,9 +8543,9 @@ (define_insn "*mov_insn_sp64" (define_insn "*mov_insn_sp32" [(set (match_operand:VM64 0 "nonimmediate_operand" - "=T,o,e,e,e,*r, f,e,W,U,T,e,o,*r,*r, o") + "=T,o,e,e,e,*r, f,e,T,U,T,f,o,*r,*r, o") (match_operand:VM64 1 "input_operand" - " Y,Y,Y,Z,e, f,*r,W,e,T,U,o,e,*r, o,*r"))] + " Y,Y,Y,Z,e, f,*r,T,e,T,U,o,f,*r, o,*r"))] "TARGET_VIS && TARGET_ARCH32 && (register_operand (operands[0], mode)
Re: [PR78365] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413
Hi Richard,
I am fine with the new patch but you'll need an approval from Honza
or Richi.
I find it a bit saddening that we cannot really rely on
gimple_call_fntype but at least I do not see any other way.
The patch looks somewhat backward. It populates the param type from
the callee but the only thing we really know is the _originating_ type
from the callers DECL_ARGUMENTS (if the JF is based on a parameter
I am not sure I understood this. I think we get param_type from callees
DECL_ARGUMENTS.
which is the only case where we do not know the type of the actual
value statically -- we only know the type we expect).
So the type would be present only on IPA_JF_PASS_THROUGH JFs
(? does that also cover modified params?).
At propagation time when applying the jump-function we have to make
sure to first convert the actual parameter value to that expected type
(or drop to BOTTOM if we can't do that conversion due to excess mismatches).
From ipa vrp point of view, that is what is being done with the patch
(In this version, I also changed the POINTER_TYPE_P to use param_type).
At the point we create ipa_compute_jump_functions_for_edge, we are
covering the VR for arguments to param_type.
In propagate_vr_accross_jump_function also, we are doing the conversion.
Thanks,
Kugan
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 2ec671f..9853467 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1846,11 +1846,11 @@ propagate_bits_accross_jump_function (cgraph_edge *cs,
int idx, ipa_jump_func *j
static bool
propagate_vr_accross_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
- struct ipcp_param_lattices *dest_plats,
- tree param_type)
+ struct ipcp_param_lattices *dest_plats)
{
struct ipcp_param_lattices *src_lats;
ipcp_vr_lattice *dest_lat = &dest_plats->m_value_range;
+ tree param_type = jfunc->param_type;
if (dest_lat->bottom_p ())
return false;
@@ -2247,7 +2247,6 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
{
struct ipa_jump_func *jump_func = ipa_get_ith_jump_func (args, i);
struct ipcp_param_lattices *dest_plats;
- tree param_type = ipa_get_callee_param_type (cs, i);
dest_plats = ipa_get_parm_lattices (callee_info, i);
if (availability == AVAIL_INTERPOSABLE)
@@ -2264,8 +2263,7 @@ propagate_constants_accross_call (struct cgraph_edge *cs)
dest_plats);
if (opt_for_fn (callee->decl, flag_ipa_vrp))
ret |= propagate_vr_accross_jump_function (cs,
- jump_func, dest_plats,
- param_type);
+ jump_func, dest_plats);
else
ret |= dest_plats->m_value_range.set_to_bottom ();
}
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 642111d..d9a817a 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1659,26 +1659,13 @@ determine_locally_known_aggregate_parts (gcall *call,
tree arg,
/* Return the Ith param type of callee associated with call graph
edge E. */
-tree
+static tree
ipa_get_callee_param_type (struct cgraph_edge *e, int i)
{
int n;
- tree type = (e->callee
- ? TREE_TYPE (e->callee->decl)
- : gimple_call_fntype (e->call_stmt));
- tree t = TYPE_ARG_TYPES (type);
-
- for (n = 0; n < i; n++)
-{
- if (!t)
-break;
- t = TREE_CHAIN (t);
-}
- if (t)
-return TREE_VALUE (t);
if (!e->callee)
-return NULL;
- t = DECL_ARGUMENTS (e->callee->decl);
+ return NULL;
+ tree t = DECL_ARGUMENTS (e->callee->decl);
for (n = 0; n < i; n++)
{
if (!t)
@@ -1732,6 +1719,7 @@ ipa_compute_jump_functions_for_edge (struct
ipa_func_body_info *fbi,
useful_context = true;
}
+ jfunc->param_type = param_type;
if (POINTER_TYPE_P (TREE_TYPE (arg)))
{
bool addr_nonzero = false;
@@ -1748,8 +1736,8 @@ ipa_compute_jump_functions_for_edge (struct
ipa_func_body_info *fbi,
{
jfunc->vr_known = true;
jfunc->m_vr.type = VR_ANTI_RANGE;
- jfunc->m_vr.min = build_int_cst (TREE_TYPE (arg), 0);
- jfunc->m_vr.max = build_int_cst (TREE_TYPE (arg), 0);
+ jfunc->m_vr.min = build_int_cst (param_type, 0);
+ jfunc->m_vr.max = build_int_cst (param_type, 0);
jfunc->m_vr.equiv = NULL;
}
else
@@ -4717,6 +4705,7 @@ ipa_write_jump_function (struct output_block *ob,
int i, count;
streamer_write_uhwi (ob, jump_func->type);
+ stream_write_tree (ob, jump_func->param_type, true);
switch (jump_func->type)
{
case IPA_JF_UNKNOWN:
@@ -4800,6 +4789,7 @@ ipa_read_jump_function (struct lto_input_block *ib,
int i, cou
