Re: [PATCH] Fix PR61441 introduced regression (PR tree-optimization/69070)
On December 31, 2015 10:29:19 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The PR61441 change added REAL_VALUE_ISSIGNALING_NAN checks for both
>operands, but only arg1 is guaranteed to be a REAL_CST at this point.
>If arg0 is not a REAL_CST, I think we can allow all the opts the
>function
>does, as all transformations replace the pow with some other expression
>that uses the argument some way (sqrt, cbrt, cbrt of sqrt,
>multiplication by
>itself, ...), so sNaN exteptions should be preserved.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
>2015-12-31 Jakub Jelinek
>
> PR tree-optimization/69070
> * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Only test
> REAL_VALUE_ISSIGNALING_NAN on arg0 if arg0 is a REAL_CST.
>
> * gcc.dg/pr69070.c: New test.
>
>--- gcc/tree-ssa-math-opts.c.jj2015-12-22 19:18:51.0 +0100
>+++ gcc/tree-ssa-math-opts.c 2015-12-29 14:15:49.587126962 +0100
>@@ -1538,7 +1538,8 @@ gimple_expand_builtin_pow (gimple_stmt_i
> /* Don't perform the operation if flag_signaling_nans is on
> and the operand is a signaling NaN. */
> if (HONOR_SNANS (TYPE_MODE (TREE_TYPE (arg1)))
>- && (REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (arg0))
>+ && ((TREE_CODE (arg0) == REAL_CST
>+ && REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (arg0)))
> || REAL_VALUE_ISSIGNALING_NAN (TREE_REAL_CST (arg1
> return NULL_TREE;
>
>--- gcc/testsuite/gcc.dg/pr69070.c.jj 2015-12-29 14:22:38.313434143
>+0100
>+++ gcc/testsuite/gcc.dg/pr69070.c 2015-12-29 14:22:24.0 +0100
>@@ -0,0 +1,9 @@
>+/* PR tree-optimization/69070 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fsignaling-nans" } */
>+
>+double
>+foo (double d)
>+{
>+ return __builtin_pow (d, 2);
>+}
>
> Jakub
Re: [PATCH] Fix ubsan ICE with non-C/C++ FEs (PR sanitizer/69055)
On December 31, 2015 10:17:34 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>ubsan_instrument_float_cast is called from convert.c, therefore for all
>FEs
>that uses convert.c. For C/C++, the ubsan builtins are already
>initialized
>through their inclusion from builtins.def, but for other builtins they
>can
>be still uninitialized. This patch adds a call that ensures the
>builtins
>are initialized when we need them in ubsan_instrument_float_cast.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/5?
OK. Though I wonder if ubsan makes sense for non-C-family languages.
Richard.
>2015-12-31 Jakub Jelinek
>
> PR sanitizer/69055
> * ubsan.c (ubsan_instrument_float_cast): Call
> initialize_sanitizer_builtins.
>
> * gfortran.dg/pr69055.f90: New test.
>
>--- gcc/ubsan.c.jj 2015-11-09 13:39:32.0 +0100
>+++ gcc/ubsan.c2015-12-28 10:22:23.024610469 +0100
>@@ -1588,6 +1588,7 @@ ubsan_instrument_float_cast (location_t
> {
> location_t *loc_ptr = NULL;
> unsigned num_locations = 0;
>+ initialize_sanitizer_builtins ();
> /* Figure out if we can propagate location to ubsan_data and use new
> style handlers in libubsan. */
> if (ubsan_use_new_style_p (loc))
>--- gcc/testsuite/gfortran.dg/pr69055.f90.jj 2015-12-28
>10:28:58.925048460 +0100
>+++ gcc/testsuite/gfortran.dg/pr69055.f90 2015-12-28 10:28:53.082130547
>+0100
>@@ -0,0 +1,10 @@
>+! { dg-do compile }
>+! { dg-options "-fsanitize=float-cast-overflow" }
>+
>+subroutine pr69055
>+ implicit none
>+ integer :: n
>+ real(8) :: b
>+ b = huge(1.0D0)
>+ n = b
>+end subroutine pr69055
>
> Jakub
[Bug fortran/68864] [6 Regression] ICE: in gfc_get_descriptor_dimension, at fortran/trans-array.c:268
Dear All, Happy New Year! I have committed the fix for the above as 'obvious' and entirely harmless - revision 232026. 2016-01-01 Paul Thomas PR fortran/68864 * trans-array.c (evaluate_bound): If deferred, test that 'desc' is an array descriptor before using gfc_conv_descriptor_xxx. 2016-01-01 Paul Thomas PR fortran/68864 * gfortran.dg/pr68864.f90: New test. Cheers Paul
Re: RFD: annotate iterator patterns with expanded forms
On Tue, 1 Dec 2015, Bernd Schmidt wrote: > On 12/01/2015 04:31 PM, Bernd Schmidt wrote: > > On 12/01/2015 04:23 PM, Jakub Jelinek wrote: > > > With the comments in the *.md file I'd worry about them getting out of > > > date, > > > or people feeling they have to edit them manually (rather than being > > > regenerated or whatever). > > > > I suppose we could have a Makefile rule that checks for out-of-date > > comments (by redoing the annotation and running diff). That would also > > alleviate the second worry. > > > > I'd much prefer the original source files to be searchable, because if I > > want to make modifications, I can't make them in tmp-mddump.md and going > > back and forth between two files is just inconvenient. > > The automatic Makefile approach might look something like this. The effect is > similar to what happens when you edit tm.texi.in, except the build would not > be interrupted every time, only when you modify the iterator expansion of a > pattern. There's a new rtx code which can be put into a machine description to > enable this feature. (No-one else chimed in, so:) I really like this! > This could be further tweaked to make (enable_auto_annotate) push/poppable; I > could imagine a world where we'd want it enabled for i386.md but not for > sse.md. Another tweak might be to have every line marked as "--GEN--" both for > clarity and for robustifying the part of the script that removes the previous > version of the annotations. > > Thoughts? Maybe a good idea. HNY, everyone. brgds, H-P
cilkplus fails without pthreads for me
cilkplus fails without pthreads for me:
xg++: error: unrecognized command line option '-pthread'
compiler exited with status 1
output is:
xg++: error: unrecognized command line option '-pthread'
FAIL: c-c++-common/attr-simd-3.c -std=gnu++14 PR68158 (test for errors, line 5)
I suspect pthreads is a fairly hard requirement. Either a test compile and
link needs to be done, or we need to be able to whack out the tests on
non-pthread systems.
Ok?
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 144e4e9..6d25666 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -1450,6 +1450,10 @@ proc check_effective_target_cilkplus { } {
return 0;
}
+if { ! [check_effective_target_pthread] } {
+ return 0;
+}
+
return 1
}
[PATCH] * doc/invoke.texi: fix typos of -finite-math-only
Hello,
I noticed tiny typos in the docs.
(CC me with replies, please, as I'm not reading the list.)
Vladimir
From 707de44fdb74ecfbc7120e2d6b5b9fdb4d281855 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vladim=C3=ADr=20=C4=8Cun=C3=A1t?=
Date: Fri, 1 Jan 2016 20:10:56 +0100
Subject: [PATCH] * doc/invoke.texi: fix typos of -finite-math-only
I believe there are no other s/-ff/-f/ typos in this file.
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b85f9b5..3f91d1a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -20374,7 +20374,7 @@ Newton-Raphson steps to increase precision
instead of doing a divide or
square root and divide for floating-point arguments. You should use
the @option{-ffast-math} option when using @option{-mrecip} (or at
least @option{-funsafe-math-optimizations},
-@option{-finite-math-only}, @option{-freciprocal-math} and
+@option{-ffinite-math-only}, @option{-freciprocal-math} and
@option{-fno-trapping-math}). Note that while the throughput of the
sequence is generally higher than the throughput of the non-reciprocal
instruction, the precision of the sequence can be decreased by up to 2
@@ -23366,7 +23366,7 @@ to increase precision instead of @code{DIVSS}
and @code{SQRTSS}
(and their vectorized
variants) for single-precision floating-point arguments. These
instructions
are generated only when @option{-funsafe-math-optimizations} is enabled
-together with @option{-finite-math-only} and @option{-fno-trapping-math}.
+together with @option{-ffinite-math-only} and @option{-fno-trapping-math}.
Note that while the throughput of the sequence is higher than the
throughput
of the non-reciprocal instruction, the precision of the sequence can be
decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994).
--
2.5.2
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH] Fix tilegx libgcc with multilib
Hi Walter,
while playing with the tilegx cross compiler I noticed another defect.
Currently building a tilegx cross compiler fails in libgcc multilib
configuration,
because of the following static assert in _FP_FROM_INT:
_FP_STATIC_ASSERT ((rsize) <= 2 * _FP_W_TYPE_SIZE,\
"rsize too large");\
previously that macro used to abort at run-time. This happens apparently in all
float to ti-int conversions in the 32-bit target configuration. So I assume
that
softfp_int_modes should only contain ti for 64-bit target configurations.
The following patch makes the multilib libgcc build succeed for me,
but I can not test if the result is actually usable.
Really AFAICT these machines must be pretty cool, but I don't own one...
Thanks
Bernd.2016-01-01 Bernd Edlinger
* config.host (tilegx*-*-linux*): Don't include
tilegx/t-softfp in 32-bit configurations.
Index: libgcc/config.host
===
--- libgcc/config.host (revision 231954)
+++ libgcc/config.host (working copy)
@@ -1268,7 +1268,11 @@ tic6x-*-elf)
unwind_header=config/c6x/unwind-c6x.h
;;
tilegx*-*-linux*)
- tmake_file="${tmake_file} tilegx/t-crtstuff t-softfp-sfdf tilegx/t-softfp t-softfp tilegx/t-tilegx"
+ tmake_file="${tmake_file} tilegx/t-crtstuff t-softfp-sfdf"
+ if test "${host_address}" = 64; then
+ tmake_file="${tmake_file} tilegx/t-softfp"
+ fi
+ tmake_file="${tmake_file} t-softfp tilegx/t-tilegx"
md_unwind_header=tilepro/linux-unwind.h
;;
tilepro*-*-linux*)
Re: [PATCH] * doc/invoke.texi: fix typos of -finite-math-only
On 01/01/2016 12:31 PM, Vladimír Čunát wrote: Hello, I noticed tiny typos in the docs. (CC me with replies, please, as I'm not reading the list.) This patch is fine with an appropriate ChangeLog entry. Generally, fixing typos in documentation or comments falls under the "obvious patch" rule, so it doesn't need explicit approval anyway. -Sandra
[doc, committed] tidy function attributes documentation
I was starting to work on PR1078 and noticed that some recent-ish
entries in the function attributes section were mis-alphabetized in the
table and in need of copy-editing. I've checked in this patch to fix
that, and the related bits in options.texi.
BTW, I also think that the -fstack-protector* options are miscategorized
as "Optimize Options" in the manual, but I did not fix that here. I've
had the idea for some time that there should be a separate section on
options that decorate code with run-time instrumentation and error
checking, including the options for profiling, bounds checking,
sanitizers, etc as well as stack checking and stack protection. But,
one thing at a time.
-Sandra
2016-01-01 Sandra Loosemore
gcc/
* doc/extend.texi (Common Function Attributes) : Move
to correct alphabetization of table. Copy-edit and correct
markup.
: Likewise.
: Likewise.
: Likewise.
* doc/invoke.texi (Optimize Options) <-fstack-protector-explicit>:
Correct punctuation.
(Code Gen Options) <-fno-plt>: Copy-edit.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 232029)
+++ gcc/doc/extend.texi (working copy)
@@ -2932,6 +2932,36 @@ my_memcpy (void *dest, const void *src,
__attribute__((nonnull));
@end smallexample
+@item noplt
+@cindex @code{noplt} function attribute
+The @code{noplt} attribute is the counterpart to option @option{-fno-plt}.
+Calls to functions marked with this attribute in position-independent code
+do not use the PLT.
+
+@smallexample
+@group
+/* Externally defined function foo. */
+int foo () __attribute__ ((noplt));
+
+int
+main (/* @r{@dots{}} */)
+@{
+ /* @r{@dots{}} */
+ foo ();
+ /* @r{@dots{}} */
+@}
+@end group
+@end smallexample
+
+The @code{noplt} attribute on function @code{foo}
+tells the compiler to assume that
+the function @code{foo} is externally defined and that the call to
+@code{foo} must avoid the PLT
+in position-independent code.
+
+In position-dependent code, a few targets also convert calls to
+functions that are marked to not use the PLT to use the GOT instead.
+
@item noreturn
@cindex @code{noreturn} function attribute
@cindex functions that never return
@@ -2977,35 +3007,6 @@ the standard C library can be guaranteed
with the notable exceptions of @code{qsort} and @code{bsearch} that
take function pointer arguments.
-@item noplt
-@cindex @code{noplt} function attribute
-The @code{noplt} attribute is the counterpart to option @option{-fno-plt} and
-does not use PLT for calls to functions marked with this attribute in position
-independent code.
-
-@smallexample
-@group
-/* Externally defined function foo. */
-int foo () __attribute__ ((noplt));
-
-int
-main (/* @r{@dots{}} */)
-@{
- /* @r{@dots{}} */
- foo ();
- /* @r{@dots{}} */
-@}
-@end group
-@end smallexample
-
-The @code{noplt} attribute on function foo tells the compiler to assume that
-the function foo is externally defined and the call to foo must avoid the PLT
-in position independent code.
-
-Additionally, a few targets also convert calls to those functions that are
-marked to not use the PLT to use the GOT instead for non-position independent
-code.
-
@item optimize
@cindex @code{optimize} function attribute
The @code{optimize} attribute is used to specify that a function is to
@@ -3120,44 +3121,35 @@ with a copy that redefines NULL appropri
The warnings for missing or incorrect sentinels are enabled with
@option{-Wformat}.
-@item stack_protect
-@cindex @code{stack_protect} function attribute
-This function attribute make a stack protection of the function if
-flags @option{fstack-protector} or @option{fstack-protector-strong}
-or @option{fstack-protector-explicit} are set.
-
-@item target_clones (@var{options})
-@cindex @code{target_clones} function attribute
-The @code{target_clones} attribute is used to specify that a function is to
-be cloned into multiple versions compiled with different target options
-than specified on the command line. The supported options and restrictions
-are the same as for @code{target} attribute.
-
-For instance on an x86, you could compile a function with
-@code{target_clones("sse4.1,avx")}. It will create 2 function clones,
-one compiled with @option{-msse4.1} and another with @option{-mavx}.
-At the function call it will create resolver @code{ifunc}, that will
-dynamically call a clone suitable for current architecture.
-
@item simd
@itemx simd("@var{mask}")
-@cindex @code{simd} function attribute.
+@cindex @code{simd} function attribute
This attribute enables creation of one or more function versions that
can process multiple arguments using SIMD instructions from a
single invocation. Specifying this attribute allows compiler to
assume that such versions are available at link time (provided
in the same or another translation unit). Generated versions are
-target dependent and described in corresponding Vector ABI document. For
Re: [PATCH] PR/68089: C++-11: Ingore "alignas(0)".
On 12/31/2015 04:50 AM, Dominik Vogt wrote:
The attached patch fixes C++-11 handling of "alignas(0)" which
should be ignored but currently generates an error message. A
test case is included; the patch has been tested on S390x. Since
it's a language issue it should be independent of the backend
used.
The patch doesn't handle value-dependent expressions(*). It
seems that the problem is in handle_aligned_attribute() calling
check_user_alignment() with the second argument (ALLOW_ZERO)
set to false. Calling it with true fixes the problem and handles
value-dependent expressions (I haven't done any more testing beyond
that).
Also, in the test, I noticed the definition of the first struct
is missing the terminating semicolon.
Martin
[*] Such as in the following:
template struct A { alignas (N) int i; };
A<0> a3;
[patch, c++] delete "com_interface" attribute
PR 1078 (yes, that is a very old issue) notes that there is no
documentation for the C++ "com_interface" attribute. In fact, this
attribute has done nothing but issue a warning saying it is obsolete for
almost 15 years (r42465, to be exact). It is hard to imagine that
anyone is using it any more, so I think we should just delete it
entirely instead of documenting it. OK to commit?
-Sandra
2016-01-01 Sandra Loosemore
PR 1078
gcc/cp/
* tree.c (cxx_attribute_table): Remove "com_interface" entry.
(handle_com_interface_attribute): Delete.
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c (revision 232029)
+++ gcc/cp/tree.c (working copy)
@@ -43,7 +43,6 @@ static tree verify_stmt_tree_r (tree *,
static tree build_local_temp (tree);
static tree handle_java_interface_attribute (tree *, tree, tree, int, bool *);
-static tree handle_com_interface_attribute (tree *, tree, tree, int, bool *);
static tree handle_init_priority_attribute (tree *, tree, tree, int, bool *);
static tree handle_abi_tag_attribute (tree *, tree, tree, int, bool *);
@@ -3480,8 +3479,6 @@ const struct attribute_spec cxx_attribut
affects_type_identity } */
{ "java_interface", 0, 0, false, false, false,
handle_java_interface_attribute, false },
- { "com_interface", 0, 0, false, false, false,
-handle_com_interface_attribute, false },
{ "init_priority", 1, 1, true, false, false,
handle_init_priority_attribute, false },
{ "abi_tag", 1, -1, false, false, false,
@@ -3514,35 +3511,6 @@ handle_java_interface_attribute (tree* n
return NULL_TREE;
}
-/* Handle a "com_interface" attribute; arguments as in
- struct attribute_spec.handler. */
-static tree
-handle_com_interface_attribute (tree* node,
-tree name,
-tree /*args*/,
-int /*flags*/,
-bool* no_add_attrs)
-{
- static int warned;
-
- *no_add_attrs = true;
-
- if (DECL_P (*node)
- || !CLASS_TYPE_P (*node)
- || *node != TYPE_MAIN_VARIANT (*node))
-{
- warning (OPT_Wattributes, "%qE attribute can only be applied "
- "to class definitions", name);
- return NULL_TREE;
-}
-
- if (!warned++)
-warning (0, "%qE is obsolete; g++ vtables are now COM-compatible by default",
- name);
-
- return NULL_TREE;
-}
-
/* Handle an "init_priority" attribute; arguments as in
struct attribute_spec.handler. */
static tree
[doc, committed] document no_stack_limit attribute
I've checked in this patch to address one of the long-standing
documentation bugs reported in PR 1078.
-Sandra
2016-01-01 Sandra Loosemore
PR 1078
gcc/
* extend.texi (Common Function Attributes) : New.
* invoke.texi (Code Gen Options) <-fno-stack-limit>: Add pointer
to corresponding attribute.
Index: extend.texi
===
--- extend.texi (revision 232030)
+++ extend.texi (working copy)
@@ -2877,6 +2877,12 @@ prologue which decides whether to split
@code{no_split_stack} attribute do not have that prologue, and thus
may run with only a small amount of stack space available.
+@item no_stack_limit
+@cindex @code{no_stack_limit} function attribute
+This attribute locally overrides the @option{-fstack-limit-register}
+and @option{-fstack-limit-symbol} command-line options; it has the effect
+of disabling stack limit checking in the function it applies to.
+
@item noclone
@cindex @code{noclone} function attribute
This function attribute prevents a function from being considered for
Index: invoke.texi
===
--- invoke.texi (revision 232030)
+++ invoke.texi (working copy)
@@ -24631,6 +24631,9 @@ and grows downwards, you can use the fla
@option{-Wl,--defsym,__stack_limit=0x7ffe} to enforce a stack limit
of 128KB@. Note that this may only work with the GNU linker.
+You can locally override stack limit checking by using the
+@code{no_stack_limit} function attribute (@pxref{Function Attributes}).
+
@item -fsplit-stack
@opindex fsplit-stack
Generate code to automatically split the stack before it overflows.
Re: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion
On 12/31/2015 08:40 AM, Patrick Palka wrote:
The Cilk Plus code may sometimes turn a COND_EXPR into an
error_mark_node for no good reason. This can be seen by compiling the
test case c-c++-common/cilk-plus/CK/pr60469.c with both gcc and g++ and
observing the differences of the -fdump-tree-original dumps:
With gcc, we get the following code in the GENERIC dump:
finally
{
_Cilk_sync;
D.1897.worker->current_stack_frame = D.1897.call_parent;
__cilkrts_pop_frame (&D.1897);
if (D.1897.flags != 16777216)
{
__cilkrts_leave_frame (&D.1897);
}
}
Whereas with g++ we get
finally
{
_Cilk_sync;
D.2387.worker->current_stack_frame = D.2387.call_parent;
__cilkrts_pop_frame (&D.2387);
<<< error >>>
}
Notice that the COND_EXPR is replaced with an << error >> in the g++
dump.
This patch fixes the COND_EXPR handling within Cilk Plus. I think the
cause is a simple typo/logic bug.
gcc/cp/ChangeLog:
* cp-array-notation.c (cp_expand_cond_array_notations): Return
error_mark_node only if find_rank failed, not if it was
successful.
Can you use -fdump-tree-original in the testcase and verify there's no
<<< error >>> expressions in the resulting dump file?
With that change, this is OK.
jeff
Re: RFA: PR 66655: Use COFF/PE weak symbols
On 12/22/2015 03:17 AM, Nick Clifton wrote: Hi Guys, The patch below is a proposed fix for PR 66655. The issue I believe is not that the ming32 definition of bind_local_p is wrong, but rather that G++ thinks that it cannot make the decl weak even though bind_local_p says that it should. The answer is to define MAKE_DECL_ONE_ONLY using the COFF/PE weak symbol support now available in gas and the linker. Doing this allows the test to pass. OK to apply ? Cheers Nick gcc/ChangeLog 2015-12-22 Nick Clifton PR target/66655 * config/i386/cygming.h (MAKE_DECL_ONE_ONLY): Use weak symbol support, if available. You probably know the capabilities of COFF/PE better than I, so the patch itself is fine. Is there any way that test can be shoved into our dejagnu testing harness? I think we've got support somewhere for tests which require multiple input files. Jeff
Re: RFA: PR 68770: Fix use of uninitialised value in secondary_reload
On 12/22/2015 03:04 AM, Nick Clifton wrote: Hi Guys, The patch below fixes PR 68770 - a warning from valgrind about an uninitialised value being used in the default_secondary_reload. The problem turns out to the in copy_costs which creates its own secondary reload information structure, but it does not initialise all of the fields. One field in particular - t_icode - is examined by default_secondary_reload, and it was this that was triggering the valgrind warning. Tested with no regressions on a x86_64-pc-linux-gnu and a powerpc64-le-linux-gnu toolchain. OK to apply ? Cheers Nick gcc/ChangeLog 2015-12-22 Nick Clifton PR target/68770 * ira-costs.c (copy_cost): Initialise the t_code field of the sri structure. Can you please reduce the testcase from the BZ so that it can be included in the testsuite? I realize it might take a long time with multidelta because of the need to run the compiler with valgrind. But once you've got the right script, you ought to be able to just let it run overnight or whatever. To speed things up, you might consider first trying to compile the case without valgrind and if that fails, then that particular reduction is "not interesting". That should dramatically cut down on the number of times you have to run the compiler under valgrind control. With a testcase, this is fine. jeff
Re: [PATCH] ia64: don't use dynamic relocations for local symbols
On 12/28/2015 02:54 PM, Sergei Trofimovich wrote:
From: Sergei Trofimovich
Tested on the following example:
void * a[77] __attribute((visibility("hidden")));
void f(long o, void * v) { a[0x6eff - o + 66] = v; }
Before the patch generated code uses .GOT entry:
addl r14 = @ltoffx(a#), r1
ld8.mov r14 = [r14], a#
After the patch generated code uses static gprel relocation:
movl r14 = @gprel(a#)
add r14 = r1, r14
That way gcc will be able to compile glibc's ld: PR/60465
Egad. PIC on ia64 is a mess. I can kind of see what Richard was trying
to do, but ewww. I don't think it's worth the effort to deep dive into
the PIC support and make ia64 handle things like most other ports --
it's a dead architecture so ISTM the easiest fix is the right fix.
A few, relatively minor things.
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
Signed-off-by: Sergei Trofimovich
---
gcc/config/ia64/ia64.c| 2 ++
gcc/config/ia64/predicates.md | 26 ++
2 files changed, 28 insertions(+)
diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c
index f48cebc..6ea5072 100644
--- a/gcc/config/ia64/ia64.c
+++ b/gcc/config/ia64/ia64.c
@@ -1105,6 +1105,8 @@ ia64_expand_load_address (rtx dest, rtx src)
emit_insn (gen_load_fptr (dest, src));
else if (sdata_symbolic_operand (src, VOIDmode))
emit_insn (gen_load_gprel (dest, src));
+ else if (local_symbolic_operand64 (src, VOIDmode))
+emit_insn (gen_load_gprel64 (dest, src));
Comment here. Something like
/* We want to use gprel rather than ltoff relocations for
local symbolic operands. */
+;; True if OP refers to a local symbol +any large offset).
;; True if OP refers to a local symbol [+ any offset ]
I haven't dug into the ia64 port (and I'm not planning to) to see if/how
it MINUS in symbolic expressions. It's been the source of problems in
various ports trough the years.
Can you take the testcase from your post as well as the one from BZ60465
comment #37 (from you) and add them to the testsuite?
You can dump them into testsuite/gcc.target/ia64.
I think you'll just want to scan the assembler output to verify you're
not getting ltoff relocations. Look for uses of scan-assembler-not in
other tests for examples.
Normally we'd require a bootstrap & regression test. We're more lenient
with patches to dead architectures. What I'd do is something like
Add new tests to /configure
make <-j whatever> all-gcc
cd gcc
make check-gcc RUNTESTFLAGS=ia64.exp
Save those results. Ideally everything will pass except your two new tests.
Apply your patch to ia64.c/predicates.md then just
make <-j whatever> all-gcc
cd gcc
make check-gcc RUNTESTFLAGS=ia64.exp
Note you're not running the full testsuite, just a few dozen ia64
specific tests, which will include your new tests. ANd you're not
rebuilding the whole compiler between those steps, just ia64.o and
relinking the compiler. So it ought to be reasonably fast.
So to summarize, I think your patch needs the two trivial comment fixes
noted above, 2 testcases and the before/after results of running just
the ia64.exp tests. Repost with that and I'll get it into the tree.
Jeff
Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation
On 12/25/2015 01:40 AM, Ajit Kumar Agarwal wrote: Hello Jeff: I am out on vacation till 3rd Jan 2016. Is it okay If I respond on the below once I am back in office. Yes. I'm on vacation until then as well. Jeff
Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed
On 12/22/2015 09:46 PM, Martin Sebor wrote:
The attached patch rejects invocations of atomic fetch_op intrinsics
on objects of _Bool type as discussed in the context of PR c/68908.
Tested on x86_64.
Martin
gcc-68966.patch
gcc/testsuite/ChangeLog:
2015-12-22 Martin Sebor
PR c/68966
* gcc.dg/atomic-fetch-bool.c: New test.
* gcc.dg/sync-fetch-bool.c: Same.
gcc/ChangeLog:
2015-12-22 Martin Sebor
PR c/68966
* doc/extend.texi (__atomic Builtins, __sync Builtins): Document
constraint on the type of arguments.
gcc/c-family/ChangeLog:
2015-12-22 Martin Sebor
PR c/68966
* c-common.c (sync_resolve_size): Reject first argument when it's
a pointer to _Bool.
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 231903)
+++ gcc/c-family/c-common.c (working copy)
@@ -7667,6 +7667,6 @@
if (error_operand_p (align))
return -1;
if (TREE_CODE (align) != INTEGER_CST
|| !INTEGRAL_TYPE_P (TREE_TYPE (align)))
{
No changes in this hunk. I assume you hand-edited the patch to remove
something that you really didn't intend to submit and left the above
useless hunk.
The patch itself is fine for the trunk.
Thanks,
Jeff
Re: [PATCH] Fix PR61441 introduced regression (PR tree-optimization/69070)
On 12/31/2015 02:29 AM, Jakub Jelinek wrote: Hi! The PR61441 change added REAL_VALUE_ISSIGNALING_NAN checks for both operands, but only arg1 is guaranteed to be a REAL_CST at this point. If arg0 is not a REAL_CST, I think we can allow all the opts the function does, as all transformations replace the pow with some other expression that uses the argument some way (sqrt, cbrt, cbrt of sqrt, multiplication by itself, ...), so sNaN exteptions should be preserved. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2015-12-31 Jakub Jelinek PR tree-optimization/69070 * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Only test REAL_VALUE_ISSIGNALING_NAN on arg0 if arg0 is a REAL_CST. * gcc.dg/pr69070.c: New test. OK. jeff
