Re: [libstdc++/65033] Give alignment info to libatomic
On 07/04/15 14:14 +0100, Jonathan Wakely wrote:
On 03/04/15 12:13 -0700, Richard Henderson wrote:
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
+++ b/libstdc++-v3/include/std/atomic
@@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align 1/2/4/8/16-byte types the same as integer types of that size.
+ // Align 1/2/4/8/16-byte types the natural alignment of that size.
// This matches the alignment effects of the C11 _Atomic qualifier.
- static constexpr int _S_min_alignment
+ static constexpr int _S_int_alignment
= sizeof(_Tp) == sizeof(char) ? alignof(char)
: sizeof(_Tp) == sizeof(short) ? alignof(short)
: sizeof(_Tp) == sizeof(int) ? alignof(int)
@@ -178,6 +178,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#endif
: 0;
+ static constexpr int _S_min_alignment
+ = _S_int_alignment sizeof(_Tp) ? _S_int_alignment : sizeof(_Tp);
+
This doesn't work for non-power-of-two sized _Tp.
Again, we don't have *any* target for which alignof(integer) sizeof(integer).
So if you care about forcing natural alignment, don't bother with the alignof
on the integrals, as you're doing with _S_int_alignment at the moment.
OK, the attached patch uses the simpler version you proposed, so
integral types and non-integral types with size 1/2/4/8/16 are aligned
to at least their size.
Committed to trunk.
What about the __atomic_base_PTp* partial specialization for
pointers, do we need to use alignas on its data member, or are
pointers always aligned appropriately on all targets?
And what about these lines:
void *__a = reinterpret_castvoid *(-__alignof(_M_i));
return __atomic_is_lock_free(sizeof(_M_i), __a);
Do we still need that if we use alignas on the data members?
If we do, do you agree with HP that it should use _S_alignment not
__alignof(_M_i)? That seems redundant to me once _M_i has been given a
fixed alignment with alignas.
commit 18fe6cb4dd74e5e5e4586ec10adba997e2e28c81
Author: Jonathan Wakely jwak...@redhat.com
Date: Fri Apr 3 15:14:40 2015 +0100
2015-04-07 Jonathan Wakely jwak...@redhat.com
Richard Henderson r...@redhat.com
PR libstdc++/65147
* include/bits/atomic_base.h (__atomic_base_ITp): Increase
alignment.
* include/std/atomic (atomic): For types with a power of two size set
alignment to at least the size.
* testsuite/29_atomics/atomic/65147.cc: New.
* testsuite/29_atomics/atomic_integral/65147.cc: New.
diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index 8104c98..79769cf 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -240,7 +240,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
private:
typedef _ITp __int_type;
- __int_type _M_i;
+ static constexpr int _S_alignment =
+ sizeof(_ITp) alignof(_ITp) ? sizeof(_ITp) : alignof(_ITp);
+
+ alignas(_S_alignment) __int_type _M_i;
public:
__atomic_base() noexcept = default;
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 88c8b17..125e37a 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -165,18 +165,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
struct atomic
{
private:
- // Align 1/2/4/8/16-byte types the same as integer types of that size.
- // This matches the alignment effects of the C11 _Atomic qualifier.
+ // Align 1/2/4/8/16-byte types to at least their size.
static constexpr int _S_min_alignment
- = sizeof(_Tp) == sizeof(char) ? alignof(char)
- : sizeof(_Tp) == sizeof(short) ? alignof(short)
- : sizeof(_Tp) == sizeof(int) ? alignof(int)
- : sizeof(_Tp) == sizeof(long) ? alignof(long)
- : sizeof(_Tp) == sizeof(long long) ? alignof(long long)
-#ifdef _GLIBCXX_USE_INT128
- : sizeof(_Tp) == sizeof(__int128) ? alignof(__int128)
-#endif
- : 0;
+ = (sizeof(_Tp) (sizeof(_Tp) - 1)) || sizeof(_Tp) 16
+ ? 0 : sizeof(_Tp);
static constexpr int _S_alignment
= _S_min_alignment alignof(_Tp) ? _S_min_alignment : alignof(_Tp);
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
new file mode 100644
index 000..e05ec17
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/65147.cc
@@ -0,0 +1,28 @@
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied
[PATCH] Fix PR65550, ICE on invalid PCH use
The following makes the checks whether the context allows a PCH file (only the first include may be one, and not nested) more robust thereby fixing PR65550. Bootstrapped and tested on x86_64-unknown-linux-gnu - ok? Thanks, Richard. 2015-04-09 Richard Biener rguent...@suse.de PR pch/65550 * files.c (pch_open_file): Allow main and pre-included files when trying to open a PCH. Index: libcpp/files.c === --- libcpp/files.c (revision 221942) +++ libcpp/files.c (working copy) @@ -291,11 +291,13 @@ pch_open_file (cpp_reader *pfile, _cpp_f /* If the file is not included as first include from either the toplevel file or the command-line it is not a valid use of PCH. */ - if (pfile-all_files - pfile-all_files-next_file - !(pfile-all_files-implicit_preinclude - || pfile-all_files-next_file-implicit_preinclude)) -return false; + for (_cpp_file *f = pfile-all_files; f; f = f-next_file) +if (f-implicit_preinclude) + continue; +else if (f-main_file) + break; +else + return false; flen = strlen (path); len = flen + sizeof (extension);
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote: It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( In this case it would be enough to replace the #ifndef/#ifdef HAVE_cc0 code with if (HAVE_cc0). That's the simplest way to avoid compile breakage. Likewise for so many other #ifdef code (HAVE_conditional_move, HAVE_trap, etc.). Perhaps something to work on in the next stage1... Ciao! Steven
Re: [PATCH] Be less conservative in process_{output,input}_constraints (PR target/65689)
On Thu, Apr 09, 2015 at 12:20:40AM +0200, Jakub Jelinek wrote:
On Wed, Apr 08, 2015 at 05:16:08PM -0500, Segher Boessenkool wrote:
On Wed, Apr 08, 2015 at 05:12:07PM -0500, Segher Boessenkool wrote:
On Wed, Apr 08, 2015 at 11:00:59PM +0200, Jakub Jelinek wrote:
+case MATCH_CODE:
+ if (*XSTR (exp, 1) == '\0')
+ {
+ const char *code, *codes = XSTR (exp, 0);
+ int ret = 0;
+ while ((code = scan_comma_elt (codes)) != 0)
+ if (strncmp (code, reg, 3) == 0
+(code[3] == ',' || code[3] == '\0' || code[3] == '
'))
This doesn't allow other whitespace. Maybe it's cleaner written as e.g.
codes - code == 3
... and that doesn't handle trailing whitespace. Ugh.
Yeah. Guess I should use
(code[3] == ',' || code[3] == '\0' || ISSPACE (code[3]))
instead then.
Or another option is just to follow what genpreds.c uses earlier:
|| (!strstr (XSTR (exp, 0), const_int)
!strstr (XSTR (exp, 0), const_double)))
if (strstr (XSTR (exp, 0), reg))
ret |= 1;
if (strstr (XSTR (exp, 0), mem))
ret |= 2;
would match besides reg/subreg or mem also define_register_constraint
or define_memory_constraint, but those surely won't appear in sane
constraints.md (and even if they would, all we need is conservative test).
Jakub
[libmpx, committed] Add zero length check for memmove wrapper
Hi,
This patch adds a zero length check into memmove wrapper (also affecting memcpy
and mempcpy) to avoid unnecessary bounds checks. Tested on on
x86_64-unknown-linux-gnu. Applied to trunk.
Thanks,
Ilya
--
libmpx/
2015-04-09 Ilya Enkovich ilya.enkov...@intel.com
* mpxwrap/mpx_wrappers.c (__mpx_wrapper_memmove): Add
zero length check.
gcc/testsuite/
2015-04-09 Ilya Enkovich ilya.enkov...@intel.com
* gcc.target/i386/mpx/memmove-zero-length.c: New.
diff --git a/gcc/testsuite/gcc.target/i386/mpx/memmove-zero-length.c
b/gcc/testsuite/gcc.target/i386/mpx/memmove-zero-length.c
new file mode 100644
index 000..78bfdeb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/mpx/memmove-zero-length.c
@@ -0,0 +1,18 @@
+/* { dg-do run } */
+/* { dg-options -fcheck-pointer-bounds -mmpx } */
+
+
+#include mpx-check.h
+#include string.h
+
+int mpx_test (int argc, const char **argv)
+{
+ int *buf = (int *)malloc (100 * sizeof(int));
+
+ memmove (buf, NULL, 0);
+ memmove (NULL, buf, 0);
+
+ free (buf);
+
+ return 0;
+}
diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
index ef4be8d..58670aa 100644
--- a/libmpx/mpxwrap/mpx_wrappers.c
+++ b/libmpx/mpxwrap/mpx_wrappers.c
@@ -97,6 +97,9 @@ __mpx_wrapper_memmove (void *dst, const void *src, size_t n)
size_t offset_src = ((size_t) s) (sizeof (void *) - 1);
size_t offset_dst = ((size_t) d) (sizeof (void *) - 1);
+ if (n == 0)
+return ret;
+
__bnd_chk_ptr_bounds (dst, n);
__bnd_chk_ptr_bounds (src, n);
[PATCH, i386] Fix PR target/65671. Generate 32x4 extract even for DF in absence of AVX-512DQ.
Hello,
Patch in the bottom fixes PR target/65671.
It simply generates vextract32x4 (float form) for double extract.
Bootstrap regtesting in progress.
I'll check it in if pass and back port to 4.9.x.
Feel free comment.
gcc/
* config/i386/sse.md: Generate vextract32x4 if AVX-512DQ
is disabled.
gcc/testsuite/
* gcc.target/i386/pr65671.c: New.
--
Thanks, K
commit cb8d5b1c3156d81ae81600217d0861be1aade0ec
Author: Kirill Yukhin kirill.yuk...@intel.com
Date: Thu Apr 9 13:05:54 2015 +0300
Fix PR target/65671. Generate 32x4 extract even for DF in absence of
AVX-512DQ.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 490fd6b..6d3b54a 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -7015,10 +7015,15 @@
(vec_select:ssehalfvecmode
(match_operand:VI8F_256 1 register_operand v,v)
(parallel [(const_int 2) (const_int 3)])))]
- TARGET_AVX
+ TARGET_AVX mask_avx512vl_condition mask_avx512dq_condition
{
- if (TARGET_AVX512DQ TARGET_AVX512VL)
-return vextractshuffletype64x2\t{$0x1, %1,
%0mask_operand2|%0mask_operand2, %1, 0x1};
+ if (TARGET_AVX512VL)
+ {
+if (TARGET_AVX512DQ)
+ return vextractshuffletype64x2\t{$0x1, %1,
%0mask_operand2|%0mask_operand2, %1, 0x1};
+else
+ return vextractshuffletype32x4\t{$0x1, %1, %0|%0, %1, 0x1};
+ }
else
return vextracti128\t{$0x1, %1, %0|%0, %1, 0x1};
}
diff --git a/gcc/testsuite/gcc.target/i386/pr65671.c
b/gcc/testsuite/gcc.target/i386/pr65671.c
new file mode 100644
index 000..8e5d00d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr65671.c
@@ -0,0 +1,15 @@
+/* PR target/65671 */
+/* { dg-do assemble } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options -O2 -mavx512vl -ffixed-ymm16 } */
+
+#include x86intrin.h
+
+register __m256d a asm (ymm16);
+__m128d b;
+
+void
+foo ()
+{
+ b = _mm256_extractf128_pd (a, 1);
+}
Re: [C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65690)
On 04/09/2015 05:38 AM, Jakub Jelinek wrote: Or supposedly no change at all, as the attributes would be either in TYPE_ATTRIBUTES, or on TYPE_DECL, but then it would be covered by the TYPE_NAME comparison. Interesting point. So maybe all we need to do here is copy TYPE_ALIGN/TYPE_USER_ALIGN, not change any of the tests. Jason
Re: [PATCH, i386] Fix PR target/65671. Generate 32x4 extract even for DF in absence of AVX-512DQ.
On Thu, Apr 09, 2015 at 06:37:01PM +0400, Kirill Yukhin wrote: gcc/ * config/i386/sse.md: Generate vextract32x4 if AVX-512DQ Please use PR target/65671 * config/i386/sse.md (vec_extract_hi_modemask_name): ... (both PR line and name of pattern missing). Jakub
[C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65715)
On Thu, Apr 09, 2015 at 10:51:12AM -0400, Jason Merrill wrote:
On 04/09/2015 05:38 AM, Jakub Jelinek wrote:
Or supposedly no change at all, as the attributes would be either in
TYPE_ATTRIBUTES, or on TYPE_DECL, but then it would be covered by
the TYPE_NAME comparison.
Interesting point. So maybe all we need to do here is copy
TYPE_ALIGN/TYPE_USER_ALIGN, not change any of the tests.
The following is actually enough to fix this.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-04-09 Jakub Jelinek ja...@redhat.com
PR c++/65715
* tree.c (cp_build_qualified_type_real): Also copy
TYPE_ALIGN and TYPE_USER_ALIGN.
* c-c++-common/attr-aligned-2.c: New test.
--- gcc/cp/tree.c.jj2015-04-09 17:05:02.331837692 +0200
+++ gcc/cp/tree.c 2015-04-09 17:15:25.216896052 +0200
@@ -1079,6 +1079,8 @@ cp_build_qualified_type_real (tree type,
{
t = build_variant_type_copy (t);
TYPE_NAME (t) = TYPE_NAME (type);
+ TYPE_ALIGN (t) = TYPE_ALIGN (type);
+ TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (type);
}
}
--- gcc/testsuite/c-c++-common/attr-aligned-2.c.jj 2015-04-09
17:13:26.327792252 +0200
+++ gcc/testsuite/c-c++-common/attr-aligned-2.c 2015-04-09 17:13:57.054300285
+0200
@@ -0,0 +1,18 @@
+/* PR c++/65715 */
+/* { dg-do run } */
+
+typedef double T[4][4] __attribute__((aligned (2 * __alignof__ (double;
+void foo (const T);
+struct S { T s; };
+
+int
+main ()
+{
+ if (__alignof__ (const T) != 2 * __alignof__ (double))
+__builtin_abort ();
+ return 0;
+}
+
+#if defined(__cplusplus) __cplusplus = 201103L
+static_assert (alignof (const T) == 2 * alignof (double), alignment of const
T);
+#endif
Jakub
Re: [PATCH, stage1] Better error recovery for merge-conflict markers
Hi David, Various tools that operate on source code files will inject markers into them when an unfixable conflict occurs in a merger. There appears to be no blessed standard for these conflict markers, but an ad-hoc convention is for 7 '' , '=', or '' characters at the start of a line, followed optionally by a space and optional text e.g.: HEAD extern int some_var; === extern short some_var; Some other branch This convention is followed by GNU patch: http://git.savannah.gnu.org/cgit/patch.git/tree/src/merge.c by git: http://git.kernel.org/cgit/git/git.git/tree/Documentation/merge-config.txt and by various other tools. if you read both of these tools carefully, you will notice an alternative conflict style (named 'diff3' in both of them), that includes a third section, the common pre-image. Here is an example: HEAD extern int some_var; ||| merge base extern int var; === extern short var; Some other branch Additionally, git supports a custom conflict-marker-size to change the default of 7 on a per file name (the conflict-marker-size attribute). So it may be worthwhile to support other sizes than 7 in this patch too. Bert
[PATCH] Fix ctor reference folding (PR middle-end/65554)
This test was failing at -O due to non-trivial conversion at assignment.
The reason is that gimple_fold_builtin_memory_op created invalid GIMPLE,
because fold_ctor_reference called via fold_const_aggregate_ref was
discarding a cast, so it returned a different type than it got. Fixed by
dropping useless type conversions only.
It also fixes a stale comment that I noticed.
Bootstrapped/regtested on x86_64-linux. Preapproved by Jakub on IRC,
applying to trunk.
2015-04-09 Marek Polacek pola...@redhat.com
Jakub Jelinek ja...@redhat.com
PR middle-end/65554
* gimple-fold.c (gimple_fold_builtin_memory_op): Update comment.
(fold_ctor_reference): Use STRIP_USELESS_TYPE_CONVERSION instead
of STRIP_NOPS.
* g++.dg/opt/pr65554.C: New test.
diff --git gcc/gimple-fold.c gcc/gimple-fold.c
index f89220c..9458f96 100644
--- gcc/gimple-fold.c
+++ gcc/gimple-fold.c
@@ -769,7 +769,7 @@ var_decl_component_p (tree var)
}
/* Fold function call to builtin mem{{,p}cpy,move}. Return
- NULL_TREE if no simplification can be made.
+ false if no simplification can be made.
If ENDP is 0, return DEST (like memcpy).
If ENDP is 1, return DEST+LEN (like mempcpy).
If ENDP is 2, return DEST+LEN-1 (like stpcpy).
@@ -5472,7 +5472,7 @@ fold_ctor_reference (tree type, tree ctor, unsigned
HOST_WIDE_INT offset,
ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
if (ret)
- STRIP_NOPS (ret);
+ STRIP_USELESS_TYPE_CONVERSION (ret);
return ret;
}
/* For constants and byte-aligned/sized reads try to go through
diff --git gcc/testsuite/g++.dg/opt/pr65554.C gcc/testsuite/g++.dg/opt/pr65554.C
index e69de29..70e43a4 100644
--- gcc/testsuite/g++.dg/opt/pr65554.C
+++ gcc/testsuite/g++.dg/opt/pr65554.C
@@ -0,0 +1,124 @@
+// PR middle-end/65554
+// { dg-do compile { target c++11 } }
+// { dg-options -O }
+
+namespace std
+{
+ struct B { enum { __value }; };
+ template typename _Iterator struct C
+ {
+static _Iterator _S_base (_Iterator p1) { return p1; }
+ };
+ template typename using _RequireInputIter = int;
+ template typename _Iterator _Iterator __niter_base (_Iterator p1)
+ {
+return std::C _Iterator::_S_base (p1);
+ }
+ template typename _Iterator _Iterator __miter_base (_Iterator p1)
+ {
+return std::C _Iterator::_S_base (p1);
+ }
+ struct D
+ {
+template typename _Tp static _Tp *__copy_m (_Tp * p1, _Tp * p2, _Tp *)
+{
+ int _Num = p2 - p1;
+ __builtin_memmove (0, p1, sizeof (_Tp) * _Num);
+}
+ };
+ template int, typename _II, typename _OI void __copy_move_a (_II p1, _II
p2, _OI p3)
+ {
+D::__copy_m (p1, p2, p3);
+ }
+ template int, typename _II, typename _OI void __copy_move_a2 (_II p1, _II
p2, _OI p3)
+ {
+__copy_move_a 0 (std::__niter_base (p1), std::__niter_base (p2),
std::__niter_base (p3));
+ }
+ template typename _II, typename _OI void copy (_II p1, _II p2, _OI p3)
+ {
+__copy_move_a2 B::__value (std::__miter_base (p1), std::__miter_base
(p2), p3);
+ }
+}
+template typename _Tp struct F { typedef _Tp *pointer; };
+namespace std
+{
+ template typename _Tp using __allocator_base = F _Tp;
+ template typename _Tp struct allocator:__allocator_base _Tp {};
+ template class _E struct initializer_list
+ {
+typedef _E *const_iterator;
+_E *_M_array;
+unsigned long _M_len;
+const_iterator begin () { return _M_array; }
+const_iterator end () { return begin () + 1; }
+ };
+ template typename _Alloc struct allocator_traits
+ {
+template typename _Tp static typename _Tp::pointer _S_pointer_helper
(_Tp *);
+typedef decltype (_S_pointer_helper ((_Alloc *) 0)) __pointer;
+typedef __pointer pointer;
+ };
+}
+template typename struct __alloc_traits:
+std::allocator_traits std::allocator const char * {};
+namespace std
+{
+ struct G
+ {
+template typename _InputIterator, typename _ForwardIterator static
_ForwardIterator __uninit_copy (_InputIterator p1, _InputIterator p2,
_ForwardIterator p3)
+{
+ copy (p1, p2, p3);
+}
+ };
+ template typename _InputIterator, typename _ForwardIterator void
+ uninitialized_copy (_InputIterator p1, _InputIterator p2, _ForwardIterator
p3)
+ {
+G::__uninit_copy (p1, p2, p3);
+ }
+ template typename _InputIterator, typename _ForwardIterator, typename _Tp
void __uninitialized_copy_a (_InputIterator p1, _InputIterator p2,
_ForwardIterator p3, allocator _Tp )
+ {
+uninitialized_copy (p1, p2, p3);
+ }
+ struct H
+ {
+typedef std::allocator int * _Tp_alloc_type;
+typedef __alloc_traits _Tp_alloc_type::pointer pointer;
+_Tp_alloc_type _M_get_Tp_allocator ();
+ };
+ template typename _Tp, typename = std::allocator _Tp struct J: H
+ {
+void operator= (initializer_list _Tp p1)
+{
+ this-assign (p1.begin (), p1.end ());
+}
+template typename _InputIterator, typename
Re: [PATCH] Fix PR65550, ICE on invalid PCH use
On Thu, Apr 09, 2015 at 03:03:38PM +0200, Richard Biener wrote: The following makes the checks whether the context allows a PCH file (only the first include may be one, and not nested) more robust thereby fixing PR65550. Bootstrapped and tested on x86_64-unknown-linux-gnu - ok? Thanks, Richard. 2015-04-09 Richard Biener rguent...@suse.de PR pch/65550 * files.c (pch_open_file): Allow main and pre-included files when trying to open a PCH. Ok. If it wouldn't be too hard to add a testcase, it would be appreciated, but if it isn't that easy, just commit it as is (or add testcase later). Jakub
Re: [PATCH] PR target/55143: undefined reference to `c_default_pointer_mode'
On Thu, Apr 09, 2015 at 09:57:29PM +0200, Bernhard Reutner-Fischer wrote: On 9 April 2015 at 21:41, Jakub Jelinek ja...@redhat.com wrote: On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote: gcc/ChangeLog: 2015-04-08 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c/c-tree.h (c_default_pointer_mode): Move declaration ... * c-family/c-common.h (c_default_pointer_mode): ... here. * c/c-decl.c (c_default_pointer_mode): Move definition ... * c-family/c-common.c (c_default_pointer_mode): ... here. The ChangeLog is certainly wrong, as both c and c-family have their own ChangeLog files, so you really can't write it using ... on both sides. So.. modulo leading tabs: gcc/c/ChangeLog: 2015-04-09 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c-decl.c (c_default_pointer_mode): Remove definition. * c-tree.h (c_default_pointer_mode): Remove declaration. gcc/c-family/ChangeLog: 2015-04-09 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c-common.c (c_default_pointer_mode): Add definition. * c-common.h (c_default_pointer_mode): Add declaration. Ok for trunk? The c_default_pointer_mode is very ugly hack, but guess at least for now it is ok for trunk. Jakub
patch to fix PR65710
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65710
The patch was bootstrapped and tested on x86/x86-64, ppc64, and aarch64.
The patch does not contain the test as it is too big. If it is reduced,
the test can be committed.
Committed as rev. 221956.
I am also submitting analogous patch to gcc-4.9 branch.
2015-04-09 Vladimir Makarov vmaka...@redhat.com
PR target/65710
* lra-int.h (lra_bad_spill_regno_start): New.
* lra.c (lra_bad_spill_regno_start): New.
(lra): Set up lra_bad_spill_regno_start. Set up
lra_constraint_new_regno_start unconditionally.
* lra-assigns.c (spill_for): Use lra_bad_spill_regno_start for
spill preferences.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 221949)
+++ lra-assigns.c (working copy)
@@ -910,6 +910,7 @@ spill_for (int regno, bitmap spilled_pse
enum reg_class rclass;
unsigned int spill_regno, reload_regno, uid;
int insn_pseudos_num, best_insn_pseudos_num;
+ int bad_spills_num, smallest_bad_spills_num;
lra_live_range_t r;
bitmap_iterator bi;
@@ -928,6 +929,7 @@ spill_for (int regno, bitmap spilled_pse
best_hard_regno = -1;
best_cost = INT_MAX;
best_insn_pseudos_num = INT_MAX;
+ smallest_bad_spills_num = INT_MAX;
rclass_size = ira_class_hard_regs_num[rclass];
mode = PSEUDO_REGNO_MODE (regno);
/* Invalidate try_hard_reg_pseudos elements. */
@@ -958,6 +960,7 @@ spill_for (int regno, bitmap spilled_pse
! bitmap_bit_p (lra_optional_reload_pseudos, spill_regno)))
goto fail;
insn_pseudos_num = 0;
+ bad_spills_num = 0;
if (lra_dump_file != NULL)
fprintf (lra_dump_file, Trying %d:, hard_regno);
sparseset_clear (live_range_reload_inheritance_pseudos);
@@ -965,6 +968,8 @@ spill_for (int regno, bitmap spilled_pse
{
if (bitmap_bit_p (insn_conflict_pseudos, spill_regno))
insn_pseudos_num++;
+ if (spill_regno = (unsigned int) lra_bad_spill_regno_start)
+ bad_spills_num++;
for (r = lra_reg_info[spill_regno].live_ranges;
r != NULL;
r = r-next)
@@ -1035,7 +1040,9 @@ spill_for (int regno, bitmap spilled_pse
}
if (best_insn_pseudos_num insn_pseudos_num
|| (best_insn_pseudos_num == insn_pseudos_num
- best_cost cost))
+ (bad_spills_num smallest_bad_spills_num
+ || (bad_spills_num == smallest_bad_spills_num
+ best_cost cost
{
best_insn_pseudos_num = insn_pseudos_num;
best_cost = cost;
Index: lra.c
===
--- lra.c (revision 221949)
+++ lra.c (working copy)
@@ -2180,6 +2180,10 @@ int lra_new_regno_start;
/* Start of reload pseudo regnos before the new spill pass. */
int lra_constraint_new_regno_start;
+/* Avoid spilling pseudos with regno more than the following value if
+ it is possible. */
+int lra_bad_spill_regno_start;
+
/* Inheritance pseudo regnos before the new spill pass. */
bitmap_head lra_inheritance_pseudos;
@@ -2269,6 +2273,7 @@ lra (FILE *f)
permit changing reg classes for pseudos created by this
simplification. */
lra_constraint_new_regno_start = lra_new_regno_start = max_reg_num ();
+ lra_bad_spill_regno_start = INT_MAX;
remove_scratches ();
scratch_p = lra_constraint_new_regno_start != max_reg_num ();
@@ -2406,12 +2411,14 @@ lra (FILE *f)
/* Assignment of stack slots changes elimination offsets for
some eliminations. So update the offsets here. */
lra_eliminate (false, false);
- /* After switching off inheritance and rematerialization passes,
- don't forget reload pseudos after spilling sub-pass to avoid
- LRA cycling in some complicated cases. */
- if (lra_inheritance_iter = LRA_MAX_INHERITANCE_PASSES
- || lra_rematerialization_iter = LRA_MAX_REMATERIALIZATION_PASSES)
- lra_constraint_new_regno_start = max_reg_num ();
+ lra_constraint_new_regno_start = max_reg_num ();
+ if (lra_bad_spill_regno_start == INT_MAX
+ lra_inheritance_iter LRA_MAX_INHERITANCE_PASSES
+ lra_rematerialization_iter LRA_MAX_REMATERIALIZATION_PASSES)
+ /* After switching off inheritance and rematerialization
+ passes, avoid spilling reload pseudos will be created to
+ prevent LRA cycling in some complicated cases. */
+ lra_bad_spill_regno_start = lra_constraint_new_regno_start;
lra_assignment_iter_after_spill = 0;
}
restore_scratches ();
Index: lra-int.h
===
--- lra-int.h (revision 221949)
+++ lra-int.h (working copy)
@@ -333,6 +333,7 @@ extern void lra_register_new_scratch_op
extern int lra_new_regno_start;
extern int lra_constraint_new_regno_start;
+extern int lra_bad_spill_regno_start;
extern bitmap_head lra_inheritance_pseudos;
extern bitmap_head lra_split_regs;
extern bitmap_head lra_subreg_reload_pseudos;
Re: [PATCH] Revised fix for PR65351
On Thu, Apr 09, 2015 at 12:29:06PM +0100, Iain Sandoe wrote: It turns out that existing versions of clang (used as bootstrap on later Darwin editions) support -mdynamic-no-pic, but not the inverse. The patch below revises mh-darwin so that it only adds -mdynamic-no-pic when the inverse is supported (for stage1 and boot cflags). For later stages, built with GCC, it is known to be supported and can be added unconditionally. When generating the PICFLAG, -mno-dynamic-no-pic is added only when -mdynamic-no-pic is present in CFLAGS. OK for trunk? Ok, thanks. Jakub
Re: [C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65690)
On Thu, Apr 09, 2015 at 10:48:29AM -0400, Jason Merrill wrote:
So the first hunk of the first patch is OK.
Ok, I've committed this to fix the regression.
2015-04-09 Jakub Jelinek ja...@redhat.com
PR c++/65690
* tree.c (build_cplus_array_type): Layout type before variants are
set, but copy over TYPE_SIZE and TYPE_SIZE_UNIT from the main
variant.
* c-c++-common/attr-aligned-1.c: New test.
--- gcc/cp/tree.c.jj2015-04-01 15:29:33.0 +0200
+++ gcc/cp/tree.c 2015-04-08 09:09:45.326939354 +0200
@@ -880,12 +880,19 @@ build_cplus_array_type (tree elt_type, t
{
t = build_min_array_type (elt_type, index_type);
set_array_type_canon (t, elt_type, index_type);
+ if (!dependent)
+ {
+ layout_type (t);
+ /* Make sure sizes are shared with the main variant.
+layout_type can't be called after setting TYPE_NEXT_VARIANT,
+as it will overwrite alignment etc. of all variants. */
+ TYPE_SIZE (t) = TYPE_SIZE (m);
+ TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
+ }
TYPE_MAIN_VARIANT (t) = m;
TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
TYPE_NEXT_VARIANT (m) = t;
- if (!dependent)
- layout_type (t);
}
}
--- gcc/testsuite/c-c++-common/attr-aligned-1.c.jj 2015-04-08
09:22:46.181427189 +0200
+++ gcc/testsuite/c-c++-common/attr-aligned-1.c 2015-04-08 09:26:41.315627195
+0200
@@ -0,0 +1,22 @@
+/* PR c++/65690 */
+/* { dg-do run } */
+
+typedef double T[4][4] __attribute__((aligned (2 * __alignof__ (double;
+void foo (const T);
+struct S { T s; };
+
+int
+main ()
+{
+ if (__alignof__ (struct S) != 2 * __alignof__ (double)
+ || __alignof__ (T) != 2 * __alignof__ (double)
+ || __alignof__ (const struct S) != 2 * __alignof__ (double))
+__builtin_abort ();
+ return 0;
+}
+
+#if defined(__cplusplus) __cplusplus = 201103L
+static_assert (alignof (S) == 2 * alignof (double), alignment of S);
+static_assert (alignof (T) == 2 * alignof (double), alignment of T);
+static_assert (alignof (const S) == 2 * alignof (double), alignment of const
S);
+#endif
Jakub
RE: [patch,avr]: Part2: Fix various problems with specs and specs file generation.
-Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Thursday, April 09, 2015 4:54 PM To: Sivanupandi, Pitchumani; Denis Chertykov Cc: GCC Patches; Joerg Wunsch; Selvaraj, Senthil_Kumar Subject: Re: [patch,avr]: Part2: Fix various problems with specs and specs file generation. Am 04/09/2015 um 12:59 PM schrieb Sivanupandi, Pitchumani: And what about the spaces problem as mentioned in http://savannah.nongnu.org/bugs/?44574 http://lists.gnu.org/archive/html/avr-libc-dev/2015-03/msg00010.html Art there plans to fix that? Yes. Will submit patch to avr-libc by next week. Thanks. Regards, Pitchumani If the device libs are moved, all the ~200 .dev/device directories will contain just 1 file each: crt1.o. Is it much work to tidy that up? (For example by renaming to, say, crtdevice.o and moving them to a common place or to their natural multilib location.) No, It is possible to do with the same patch. I'll rename crt1.o to crtdevice.o and move it to multilib location. Regards, Pitchumani
Re: [PATCH] add self-tuning to x86 hardware fast path in libitm
On Wed, Apr 8, 2015 at 6:54 PM, Andi Kleen a...@firstfloor.org wrote:
On the STAMP suite of benchmarks for transactional memory (described here
[1]).
I have ran an unmodified GCC 5.0.0 against the patched GCC with these
modifications and obtain the following speedups in STAMP with 4
threads (on a Haswell with 4 cores, average 10 runs):
I expect you'll need different tunings on larger systems.
I did not quite understand the extent of your comment: what
specifically would need different tuning? The idea is exactly that
this proposal does not have any attachment to the workload/deployment;
there are some parameters (aka, the magic numbers we discussed) but
they are quite reasonable, i.e., each one of them has a sensible value
with some meaning we understand.
That is a good point. While I haven't ever used fixed point
arithmetic, a cursory inspection reveals that it does make sense and
seems applicable to this case.
Are you aware of some place where this is being done already within
GCC that I could use as inspiration, or should I craft some macros
from scratch for this?
I believe the inliner uses fixed point. Own macros should be fine too.
Thanks, will try this out.
+ int32_t last_attempts = optimizer.last_attempts;
+ int32_t current_attempts = optimizer.optimized_attempts;
+ int32_t new_attempts = current_attempts;
+ if (unlikely(change_for_worse 1.40))
+{
+ optimizer.optimized_attempts = optimizer.best_ever_attempts;
+ optimizer.last_throughput = current_throughput;
+ optimizer.last_attempts = current_attempts;
+ return;
+}
+
+ if (unlikely(random() % 100 1))
+{
So where is the seed for that random stored? Could you corrupt some
user's random state? Is the state per thread or global?
If it's per thread how do you initialize so that they threads do
start with different seeds.
If it's global what synchronizes it?
As I do not specify any seed, I was under the impression that there
would be a default initialization. Furthermore, the posix
documentation specifies random() to be MT-safe, so I assumed its
internal state to be per-thread.
Did I mis-interpret this?
Yes, that's right. But it's very nasty to change the users RNG state.
A common pattern for repeatable benchmarks is to start with srand(1)
and then use the random numbers to run the benchmark, so it always does
the same thing. If you non deterministically (transaction aborts are not
deterministic) change the random state it will make the benchmark not
repeatable anymore. You'll need to use an own RNG state that it independent.
I understand your concern, thanks for raising it.
One general question on how to proceed:
given that I make some further changes, should I post the whole patch again?
Best regards,
-- Nuno Diegues
It would be good to see if any parts of the algorithm can be
simplified. In general in production software the goal is to have
the simplest algorithm that does the job.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH, i386] Fix PR target/65671. Generate 32x4 extract even for DF in absence of AVX-512DQ.
On 09 Apr 16:41, Jakub Jelinek wrote: Please use PR target/65671 * config/i386/sse.md (vec_extract_hi_modemask_name): ... (both PR line and name of pattern missing). Sure, thanks! -- K
Re: [C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65690)
On 04/08/2015 11:07 AM, Jakub Jelinek wrote:
But that is how handle_aligned_attribute works, since forever (checked it
back to 3.2). In = 3.4.x, it used to create it using build_type_copy,
since 4.0.0 using build_variant_type_copy, but both those routines behave
the same - build a type variant which is linked in the TYPE_NEXT_VARIANT
chain, and differs from the other type in there possibly just by
TYPE_ALIGN/TYPE_USER_ALIGN. Perhaps it should check TYPE_ALIGN only if
at least one of the two types has TYPE_USER_ALIGN set?
As for why TYPE_ATTRIBUTES are NULL, the reason for that is that
these are attributes on a typedef, so the attributes go into DECL_ATTRIBUTES
of the TYPE_DECL instead.
I see. So yes, I think we want to look at TYPE_USER_ALIGN as well.
Anyway, the P1 regression is just about the first hunk, so if you have
issues just with the second hunk and not the first hunk (from either of the
patches), I can just comment out the tests for alignof (const T), and open
a separate PR for that for later.
The second patch seems to cause a regression on c-c++-common/pr60226.c
because we avoid calling layout_type, so we lose the over-alignment
error. So the first hunk of the first patch is OK.
Incidentally, for template testcases it seems we also need to fix
layout_type and fixup_type_sizes to respect already-set TYPE_USER_ALIGN:
template class T struct A
{
T t;
};
typedef Aint T[4] alignas (2 * alignof (int));
Aint a[4];
typedef Achar T2[4] alignas (2 * alignof (int));
#define SA(X) static_assert((X),#X)
SA(alignof (T) == 2 * alignof(int));
SA(alignof (T2) == 2 * alignof(int));
Jason
Re: [PATCH] Be less conservative in process_{output,input}_constraints (PR target/65689)
On Wed, Apr 08, 2015 at 11:00:59PM +0200, Jakub Jelinek wrote: On x86_64/i686 this only detects constraint G as not allowing reg nor mem (it is match_code const_double), and V (plus and , but those are hardcoded in stmt.c already) that it allows mem but not reg. On aarch64, in the first category it detects several constraints. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? FYI, Alan Lawrence has successfully bootstrapped/regtested it also on aarch64-linux and arm hf. Jakub
[PATCH] PR target/55143: undefined reference to `c_default_pointer_mode'
gcc/ChangeLog: 2015-04-08 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c/c-tree.h (c_default_pointer_mode): Move declaration ... * c-family/c-common.h (c_default_pointer_mode): ... here. * c/c-decl.c (c_default_pointer_mode): Move definition ... * c-family/c-common.c (c_default_pointer_mode): ... here. --- Ok for trunk? Fixes all-gcc for ia64-hp-vms which previously failed with: g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti \ -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings \ -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic \ -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror \ -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 \ c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o \ c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o \ c/c-array-notation.o c-family/c-common.o c-family/c-cppbuiltin.o \ c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o \ c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o \ c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o \ c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o \ c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o \ vms-c.o default-c.o \ cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a \ libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a \ ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a \ ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a \ -L/obj.x86_64/gcc.config-list/ia64-hp-vms/./isl/.libs \ -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti \ -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings \ -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic \ -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror \ -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o \ cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o \ cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o \ cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o \ cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o \ cp/cxx-pretty-print.o cp/cp-cilkplus.o cp/cp-gimplify.o \ cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o \ cp/constexpr.o cp/cp-ubsan.o attribs.o incpath.o c-family/c-common.o \ c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o \ c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o \ c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o \ c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o \ c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o \ c-family/c-ubsan.o vms-c.o default-c.o cc1plus-checksum.o libbackend.a \ main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a \ ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a \ ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a \ ../libdecnumber/libdecnumber.a \ -L/obj.x86_64/gcc.config-list/ia64-hp-vms/./isl/.libs \ -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz vms-c.o: In function `handle_pragma_pointer_size(char const*)': vms-c.c:(.text+0x5ad): undefined reference to `c_default_pointer_mode' vms-c.c:(.text+0x5c2): undefined reference to `c_default_pointer_mode' vms-c.c:(.text+0x5da): undefined reference to `c_default_pointer_mode' vms-c.c:(.text+0x5f8): undefined reference to `c_default_pointer_mode' vms-c.o: In function `vms_c_common_override_options()': vms-c.c:(.text+0x9ec): undefined reference to `c_default_pointer_mode' vms-c.o:vms-c.c:(.text+0xa02): more undefined references to `c_default_pointer_mode' follow collect2: error: ld returned 1 exit status make[2]: *** [cc1plus] Error 1 --- gcc/c-family/c-common.c |4 gcc/c-family/c-common.h |4 gcc/c/c-decl.c |4 gcc/c/c-tree.h |4 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c index 456c619..7fe7fa6 100644 --- a/gcc/c-family/c-common.c +++ b/gcc/c-family/c-common.c @@ -67,6 +67,10 @@ along with GCC; see the file COPYING3. If not see cpp_reader *parse_in; /* Declared in c-pragma.h. */ +/* Mode used to build pointers (VOIDmode means ptr_mode). */ + +machine_mode c_default_pointer_mode = VOIDmode; + /* The following symbols are subsumed in the c_global_trees array, and listed here individually for documentation purposes. diff --git a/gcc/c-family/c-common.h
[doc] Add John Marino to doc/contrib.texi (was: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly)
On Wed, 21 May 2014, Jonathan Wakely wrote: Bootstrapped on x86_64-unknown-dragonfly3.6 and x86_64-unknown-linux-gnu, committed to trunk as http://gcc.gnu.org/r210694 John, thanks for contributing the target support and for persevering with the review process :-) And here is the corresponding entry to doc/contrib.texi. Committed. Better late than never, I guess, and still in time for 5.0. :-) Gerald 2015-04-09 Gerald Pfeifer ger...@pfeifer.com * doc/contrib.texi (Contributors): Add John Marino. Index: doc/contrib.texi === --- doc/contrib.texi(revision 221959) +++ doc/contrib.texi(working copy) @@ -590,6 +590,9 @@ Bob Manson for his behind the scenes work on dejagnu. @item +John Marino for contributing the DragonFly BSD port. + +@item Philip Martin for lots of libstdc++ string and vector iterator fixes and improvements, and string clean up and testsuites.
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On Thu, Apr 09, 2015 at 07:41:17AM -0500, Segher Boessenkool wrote: It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( Okay if testing has finished successfully? Segher 2015-04-09 Segher Boessenkool seg...@kernel.crashing.org PR rtl-optimization/65693 * combine.c (is_parallel_of_n_reg_sets): Move outside of #ifndef HAVE_cc0. This is obviously ok. Jakub
[PATCH] gfortran.dg/pr32627.f03 prints nul byte
We've been debugging a problem where nul (and other control) characters have been randomly appearing in powerpc parallel build logs. In the process, I noticed that some of the nuls are readily reproducible. One such case is due to the pr32627.f03 test which verifies that Fortran programs can initialize character arrays from C strings. The test declares an array as big as the C string (including the terminating nul) and prints its value to stdout. This then causes the nul to appear in the log files. The attached patch changes the declaration of the Fortran array to match the number of non-nul characters. Tested on powerpc64. Martin 2015-04-09 Martin Sebor mse...@redhat.com * gfortran.dg/pr32627.f03 (strptr): Change size to match the number of non-nul characters. diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03 index f8695e0..d9e2b13 100644 --- a/gcc/testsuite/gfortran.dg/pr32627.f03 +++ b/gcc/testsuite/gfortran.dg/pr32627.f03 @@ -18,7 +18,7 @@ program main type( c_ptr ) :: x type( A ), pointer :: fptr type( A ), target :: my_a_type - character( len=9 ), pointer :: strptr + character( len=8 ), pointer :: strptr fptr = my_a_type
Re: [wwwdocs] Update changes.html with Intel MPX and Pointer Bounds Checker
On 09 Apr 12:32, Gerald Pfeifer wrote:
On Thu, 9 Apr 2015, Ilya Enkovich wrote:
This adds Pointer Bounds Checker and MPX support to GCC 5 changes.
Is it OK?
Nice, thank you!
Can you just replace runtime checks by run-time checks and
IA-32/x86-64 GNU/Linux target by x86/x86-64 GNU/Linux targets
(x86, as we had agreed upon recently, and targets, Plural) and
add the to See Pointer Bounds Checker?
Similarly, can you please add This and the to New extension
is available via code-mmpx/code compiler switch in the second
hunk and also use run-time there?
Go ahead and commit with those changes.
Thanks,G
Gerald
Thank you for comments! Here is an updated version to be committed.
Ilya
--
--- changes.html2015-04-09 12:18:47.67230 +0300
+++ changes.html2015-04-09 14:00:43.880487000 +0300
@@ -158,20 +158,29 @@
licode-fsanitize=alignment/code: enable alignment checking, detect
various misaligned objects;/li
licode-fsanitize=object-size/code: enable object size checking,
detect
various out-of-bounds accesses./li
licode-fsanitize=vptr/code: enable checking of C++ member function
calls, member accesses and some conversions between pointers to base
and derived classes, detect if the referenced object does not have
the correct dynamic type./li
/ul
/li
+liPointer Bounds Checker, a bounds violation detector, has been added and
+ can be enabled via code-fcheck-pointer-bounds/code. Memory accesses
are
+ instrumented with run-time checks of used pointers against their bounds
to
+ detect pointer bounds violations (overflows). The Pointer Bounds Checker
+ is available on x86/x86-64 GNU/Linux targets with a new ISA extension
+ Intel MPX support. See the Pointer Bounds Checker
+ a
href=https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler;
+ Wiki page/a for more details.
+/li
/ul
h2 id=languagesNew Languages and Language specific improvements/h2
ul
li id=offloada
href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf;
OpenMP 4.0 specification/a offloading features are now supported by
the C, C++,
and Fortran compilers. Generic changes:
ul
liInfrastructure (suitable for any vendor)./li
liTestsuite which covers offloading from the
@@ -676,20 +685,28 @@
AVX-512{BW,DQ,VL,IFMA,VBMI}/a of Intel's CPU
codenamed Skylake Server was added to GCC. That includes inline
assembly support, new intrinsics, and basic autovectorization. These
new AVX-512 extensions are available via
the following GCC switches: AVX-512 Vector Length EVEX feature:
code-mavx512vl/code, AVX-512 Byte and Word instructions:
code-mavx512bw/code, AVX-512 Dword and Qword instructions:
code-mavx512dq/code, AVX-512 FMA-52 instructions:
code-mavx512ifma/code and for AVX-512 Vector Bit Manipulation
Instructions: code-mavx512vbmi/code./li
+ liNew ISA extensions support
+ a
href=https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf;
+ Intel MPX/a was added to GCC. This new extension is available via the
+ code-mmpx/code compiler switch. Intel MPX is a set of processor
features which,
+ with compiler, run-time library and OS support, brings increased
robustness to
+ software by run-time checking pointer references against their bounds.
+ In GCC Intel MPX is supported by Pointer Bounds Checker and libmpx
run-time
+ libraries./li
liThe new code-mrecord-mcount/code option for code-pg/code
generates a Linux kernel style table of pointers to mcount or
__fentry__ calls at the beginning of functions. The new
code-mnop-mcount/code option in addition also generates nops in
place of the __fentry__ or mcount call, so that a call per function
can be later patched in. This can be used for low overhead tracing or
hot code patching./li
liThe new code-malign-data/code option controls how
GCC aligns variables. code-malign-data=compat/code uses
increased alignment compatible with GCC 4.8 and earlier,
[PATCH] Makefile.tpl: Remove surplus whitespace
essentially s/[[:space:]]*[[:space:]];/;/g
ChangeLog (attn: to src, IIRC no write-access, ask someone to commit)
Ok for trunk now?
2015-04-01 Bernhard Reutner-Fischer al...@gcc.gnu.org
* Makefile.tpl: Remove surplus whitespace throughout.
* Makefile.in: Regenerate.
Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
---
Makefile.in | 4858 +-
Makefile.tpl | 110 +-
2 files changed, 2484 insertions(+), 2484 deletions(-)
diff --git a/Makefile.tpl b/Makefile.tpl
index 1ea1954..9972909 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -225,8 +225,8 @@ HOST_EXPORTS = \
GMPINC=$(HOST_GMPINC); export GMPINC; \
ISLLIBS=$(HOST_ISLLIBS); export ISLLIBS; \
ISLINC=$(HOST_ISLINC); export ISLINC; \
- LIBELFLIBS=$(HOST_LIBELFLIBS) ; export LIBELFLIBS; \
- LIBELFINC=$(HOST_LIBELFINC) ; export LIBELFINC; \
+ LIBELFLIBS=$(HOST_LIBELFLIBS); export LIBELFLIBS; \
+ LIBELFINC=$(HOST_LIBELFINC); export LIBELFINC; \
@if gcc-bootstrap
$(RPATH_ENVVAR)=`echo $(TARGET_LIB_PATH)$$$(RPATH_ENVVAR) | sed
's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@endif gcc-bootstrap
@@ -785,9 +785,9 @@ do-info: maybe-all-texinfo
install-info: do-install-info dir.info
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
- if [ -f dir.info ] ; then \
- $(INSTALL_DATA) dir.info $(DESTDIR)$(infodir)/dir.info ; \
- else true ; fi
+ if [ -f dir.info ]; then \
+ $(INSTALL_DATA) dir.info $(DESTDIR)$(infodir)/dir.info; \
+ else true; fi
install-pdf: do-install-pdf
@@ -913,14 +913,14 @@ uninstall:
.PHONY: install.all
install.all: install-no-fixedincludes
- @if [ -f ./gcc/Makefile ] ; then \
- r=`${PWD_COMMAND}` ; export r ; \
+ @if [ -f ./gcc/Makefile ]; then \
+ r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
(cd ./gcc \
- $(MAKE) $(FLAGS_TO_PASS) install-headers) ; \
+ $(MAKE) $(FLAGS_TO_PASS) install-headers); \
else \
- true ; \
+ true; \
fi
# install-no-fixedincludes is used to allow the elaboration of binary packages
@@ -960,15 +960,15 @@ installdirs: mkinstalldirs
$(SHELL) $(srcdir)/mkinstalldirs $(MAKEDIRS)
dir.info: do-install-info
- if [ -f $(srcdir)/texinfo/gen-info-dir ] ; then \
- $(srcdir)/texinfo/gen-info-dir $(DESTDIR)$(infodir)
$(srcdir)/texinfo/dir.info-template dir.info.new ; \
- mv -f dir.info.new dir.info ; \
- else true ; \
+ if [ -f $(srcdir)/texinfo/gen-info-dir ]; then \
+ $(srcdir)/texinfo/gen-info-dir $(DESTDIR)$(infodir)
$(srcdir)/texinfo/dir.info-template dir.info.new; \
+ mv -f dir.info.new dir.info; \
+ else true; \
fi
dist:
@echo Building a full distribution of this tree isn't done
- @echo via 'make dist'. Check out the etc/ subdirectory
+ @echo via 'make dist'. Check out the etc/ subdirectory
etags tags: TAGS
@@ -998,8 +998,8 @@ configure-[+prefix+][+module+]: [+ IF bootstrap +][+ ELSE +]
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
[+ IF check_multilibs
+]echo Checking multilib configuration for [+module+]...; \
- $(SHELL) $(srcdir)/mkinstalldirs [+subdir+]/[+module+] ; \
- $(CC_FOR_TARGET) --print-multi-lib [+subdir+]/[+module+]/multilib.tmp
2 /dev/null ; \
+ $(SHELL) $(srcdir)/mkinstalldirs [+subdir+]/[+module+]; \
+ $(CC_FOR_TARGET) --print-multi-lib [+subdir+]/[+module+]/multilib.tmp
2 /dev/null; \
if test -r [+subdir+]/[+module+]/multilib.out; then \
if cmp -s [+subdir+]/[+module+]/multilib.tmp
[+subdir+]/[+module+]/multilib.out; then \
rm -f [+subdir+]/[+module+]/multilib.tmp; \
@@ -1011,7 +1011,7 @@ configure-[+prefix+][+module+]: [+ IF bootstrap +][+ ELSE
+]
mv [+subdir+]/[+module+]/multilib.tmp
[+subdir+]/[+module+]/multilib.out; \
fi; \
[+ ENDIF check_multilibs +]test ! -f [+subdir+]/[+module+]/Makefile ||
exit 0; \
- $(SHELL) $(srcdir)/mkinstalldirs [+subdir+]/[+module+] ; \
+ $(SHELL) $(srcdir)/mkinstalldirs [+subdir+]/[+module+]; \
[+exports+] [+extra_exports+] \
echo Configuring in [+subdir+]/[+module+]; \
cd [+subdir+]/[+module+] || exit 1; \
@@ -1044,7 +1044,7 @@ configure-stage[+id+]-[+prefix+][+module+]:
TFLAGS=$(STAGE[+id+]_TFLAGS); \
[+ IF check_multilibs
+]echo Checking multilib configuration for [+module+]...; \
- $(CC_FOR_TARGET) --print-multi-lib [+subdir+]/[+module+]/multilib.tmp
2 /dev/null ; \
+ $(CC_FOR_TARGET) --print-multi-lib [+subdir+]/[+module+]/multilib.tmp
2 /dev/null; \
if test -r [+subdir+]/[+module+]/multilib.out; then \
if cmp -s
RE: [patch,avr]: Part2: Fix various problems with specs and specs file generation.
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Wednesday, April 08, 2015 4:56 PM
To: Denis Chertykov
Cc: Sivanupandi, Pitchumani; GCC Patches; Joerg Wunsch; Selvaraj,
Senthil_Kumar
Subject: Re: [patch,avr]: Part2: Fix various problems with specs and specs
file generation.
Am 04/08/2015 um 10:28 AM schrieb Denis Chertykov:
2015-04-07 15:34 GMT+03:00 Georg-Johann Lay a...@gjlay.de:
Am 04/06/2015 um 11:54 AM schrieb Sivanupandi, Pitchumani:
Hi Johann,
Did you try running g++ tests?
It seems xgcc is invoked to get multilibs (from
gcc/testsuite/lib/g++.exp) which failed to find specs file.
This is because libgloss.exp:get_multilibs (used from g++_init) runs
xgcc
($compiler) without -B, i.e. without any prefix. Without prefix
there is no way to determine where the specs files are located.
Patching driver_self_specs to read a specs file by means of -specs=
is, well, not very common. I don't know any other target which does
that.
As a work-around you can run the tests against the installed compiler.
Denis, what do you think? I could add yet another fixme to avr
backend like the following; that way there's no need to change
dejagnu:
Johann
Index: config/avr/driver-avr.c
===
--- config/avr/driver-avr.c (revision 221602)
+++ config/avr/driver-avr.c (working copy)
@@ -80,6 +80,20 @@ avr_devicespecs_file (int argc, const ch
return X_NODEVLIB;
case 1:
+ if (0 == strcmp (device-specs, argv[0]))
+{
+ /* FIXME: This means device-specs%s from
avr.h:DRIVER_SELF_SPECS
+ has not been resolved to a path. That case can occur when
the
+ c++ testsuite is run from the build directory. DejaGNU's
+ libgloss.exp:get_multilibs runs $compiler without -B,
i.e.runs
+ xgcc without specifying a prefix. Without any prefix,
+ there
is
+ no means to find out where the specs files might be located.
+ get_multilibs runs xgcc --print-multi-lib, hence we don't
+ actually need information form a specs file and may skip it
+ altogether. */
+ return X_NODEVLIB;
+}
+
mmcu = AVR_MMCU_DEFAULT;
break;
I'm weak in dejagnu internals and c++ testsuite.
It looks like an acceptable solution.
Denis.
Pitchumani, does that patch work for you? If so I'd go ahead and apply
it.
Yes. It works for me.
Thanks.
And what about the spaces problem as mentioned in
http://savannah.nongnu.org/bugs/?44574
http://lists.gnu.org/archive/html/avr-libc-dev/2015-03/msg00010.html
Art there plans to fix that?
Yes. Will submit patch to avr-libc by next week.
Regards,
Pitchumani
[Patch, fortran] PR56852 - [4.8/4.9/5 Regression] ICE on invalid: Bad array reference for an undeclared loop variable
Dear All,
I intend to commit this patch tonight, unless there are objections. It
is safe, since it skips an ICE if the conditions in the ChangeLog are
met.
Bootstraps and regtests on x86_64/FC21.
Paul
2013-04-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/56852
* primary.c (gfc_variable_attr): Avoid ICE on AR_UNKNOWN if any
of the index variables are untyped and errors are present.
2013-04-09 Paul Thomas pa...@gcc.gnu.org
PR fortran/56852
* gfortran.dg/pr56852.f90 : New test
Index: gcc/fortran/primary.c
===
*** gcc/fortran/primary.c (revision 221941)
--- gcc/fortran/primary.c (working copy)
*** check_substring:
*** 2138,2144
symbol_attribute
gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
{
! int dimension, codimension, pointer, allocatable, target;
symbol_attribute attr;
gfc_ref *ref;
gfc_symbol *sym;
--- 2138,2144
symbol_attribute
gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
{
! int dimension, codimension, pointer, allocatable, target, n;
symbol_attribute attr;
gfc_ref *ref;
gfc_symbol *sym;
*** gfc_variable_attr (gfc_expr *expr, gfc_t
*** 2195,2201
break;
case AR_UNKNOWN:
! gfc_internal_error (gfc_variable_attr(): Bad array reference);
}
break;
--- 2195,2219
break;
case AR_UNKNOWN:
! /* If any of start, end or stride is not integer, there will
! already have been an error issued. */
! for (n = 0; n ref-u.ar.as-rank; n++)
! {
! int errors;
! gfc_get_errors (NULL, errors);
! if (((ref-u.ar.start[n]
! ref-u.ar.start[n]-ts.type == BT_UNKNOWN)
!||
!(ref-u.ar.end[n]
! ref-u.ar.end[n]-ts.type == BT_UNKNOWN)
!||
!(ref-u.ar.stride[n]
! ref-u.ar.stride[n]-ts.type == BT_UNKNOWN))
!errors 0)
! break;
! }
! if (n == ref-u.ar.as-rank)
! gfc_internal_error (gfc_variable_attr(): Bad array reference);
}
break;
Index: gcc/testsuite/gfortran.dg/pr56852.f90
===
*** gcc/testsuite/gfortran.dg/pr56852.f90 (revision 0)
--- gcc/testsuite/gfortran.dg/pr56852.f90 (working copy)
***
*** 0
--- 1,11
+ ! { dg-do compile }
+ ! Test the fix for pr56852, where an ICE would occur after the error.
+ !
+ ! Contributed by Lorenz Huedepohl b...@stellardeath.org
+ !
+ program test
+ implicit none
+ real :: a(4)
+ ! integer :: i
+ read(0) (a(i),i=1,4) ! { dg-error has no IMPLICIT type }
+ end program
Re: [wwwdocs] Update changes.html with Intel MPX and Pointer Bounds Checker
On Thu, 9 Apr 2015, Ilya Enkovich wrote: This adds Pointer Bounds Checker and MPX support to GCC 5 changes. Is it OK? Nice, thank you! Can you just replace runtime checks by run-time checks and IA-32/x86-64 GNU/Linux target by x86/x86-64 GNU/Linux targets (x86, as we had agreed upon recently, and targets, Plural) and add the to See Pointer Bounds Checker? Similarly, can you please add This and the to New extension is available via code-mmpx/code compiler switch in the second hunk and also use run-time there? Go ahead and commit with those changes. Thanks,G Gerald
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On 04/09/2015 07:21 AM, Steven Bosscher wrote: On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote: It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( In this case it would be enough to replace the #ifndef/#ifdef HAVE_cc0 code with if (HAVE_cc0). That's the simplest way to avoid compile breakage. Likewise for so many other #ifdef code (HAVE_conditional_move, HAVE_trap, etc.). Perhaps something to work on in the next stage1... Most definitely a direction I want to see us moving. The glibc project recently went through the pain of the transition, but I believe it'll be worth it long term for them and even more so for us (we have a lot more conditionally compiled code than glibc). jeff
[wwwdocs] Update changes.html with Intel MPX and Pointer Bounds Checker
Hi,
This adds Pointer Bounds Checker and MPX support to GCC 5 changes. Is it OK?
Thanks,
Ilya
--
--- changes.html2015-04-09 12:18:47.67230 +0300
+++ changes.html2015-04-09 12:58:23.677983000 +0300
@@ -158,20 +158,29 @@
licode-fsanitize=alignment/code: enable alignment checking, detect
various misaligned objects;/li
licode-fsanitize=object-size/code: enable object size checking,
detect
various out-of-bounds accesses./li
licode-fsanitize=vptr/code: enable checking of C++ member function
calls, member accesses and some conversions between pointers to base
and derived classes, detect if the referenced object does not have
the correct dynamic type./li
/ul
/li
+liPointer Bounds Checker, a bounds violation detector, has been added and
+ can be enabled via code-fcheck-pointer-bounds/code. Memory accesses
are
+ instrumented with runtime checks of used pointers against their bounds to
+ detect pointer bounds violations (overflows). The Pointer Bounds Checker
+ is available on IA-32/x86-64 GNU/Linux target with a new ISA extension
+ Intel MPX support. See Pointer Bounds Checker
+ a
href=https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler;
+ Wiki page/a for more details.
+/li
/ul
h2 id=languagesNew Languages and Language specific improvements/h2
ul
li id=offloada
href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf;
OpenMP 4.0 specification/a offloading features are now supported by
the C, C++,
and Fortran compilers. Generic changes:
ul
liInfrastructure (suitable for any vendor)./li
liTestsuite which covers offloading from the
@@ -676,20 +685,28 @@
AVX-512{BW,DQ,VL,IFMA,VBMI}/a of Intel's CPU
codenamed Skylake Server was added to GCC. That includes inline
assembly support, new intrinsics, and basic autovectorization. These
new AVX-512 extensions are available via
the following GCC switches: AVX-512 Vector Length EVEX feature:
code-mavx512vl/code, AVX-512 Byte and Word instructions:
code-mavx512bw/code, AVX-512 Dword and Qword instructions:
code-mavx512dq/code, AVX-512 FMA-52 instructions:
code-mavx512ifma/code and for AVX-512 Vector Bit Manipulation
Instructions: code-mavx512vbmi/code./li
+ liNew ISA extensions support
+ a
href=https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf;
+ Intel MPX/a was added to GCC. New extension is available via
code-mmpx/code
+ compiler switch. Intel MPX is a set of processor features which,
+ with compiler, runtime library and OS support, brings increased
robustness to
+ software by runtime checking pointer references against their bounds.
+ In GCC Intel MPX is supported by Pointer Bounds Checker and libmpx
runtime
+ libraries./li
liThe new code-mrecord-mcount/code option for code-pg/code
generates a Linux kernel style table of pointers to mcount or
__fentry__ calls at the beginning of functions. The new
code-mnop-mcount/code option in addition also generates nops in
place of the __fentry__ or mcount call, so that a call per function
can be later patched in. This can be used for low overhead tracing or
hot code patching./li
liThe new code-malign-data/code option controls how
GCC aligns variables. code-malign-data=compat/code uses
increased alignment compatible with GCC 4.8 and earlier,
Re: [PATCH] gfortran.dg/pr32627.f03 prints nul byte
Attached is an updated patch that fixes the substr_6.f90 test that also prints a nul character to stdout. I don't think there are any others. Besides interfering with the debugging of the log corruption I mentioned, printing nuls or control characters in tests is also problematic for tools designed to post-process log files (e.g., grep) that are intended to work with text files (i.e., files not containing nuls). Control characters can cause the tools to fail in non-C locales (such as UTF-8). On 04/09/2015 12:54 PM, Martin Sebor wrote: We've been debugging a problem where nul (and other control) characters have been randomly appearing in powerpc parallel build logs. In the process, I noticed that some of the nuls are readily reproducible. One such case is due to the pr32627.f03 test which verifies that Fortran programs can initialize character arrays from C strings. The test declares an array as big as the C string (including the terminating nul) and prints its value to stdout. This then causes the nul to appear in the log files. The attached patch changes the declaration of the Fortran array to match the number of non-nul characters. Tested on powerpc64. Martin 2015-04-09 Martin Sebor mse...@redhat.com * gfortran.dg/pr32627.f03 (strptr): Change size to match the number of non-nul characters. * gfortran.dg/substr_6.f90: Make the NUL character visible on stdout and avoid corrupting text output. diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03 index f8695e0..d9e2b13 100644 --- a/gcc/testsuite/gfortran.dg/pr32627.f03 +++ b/gcc/testsuite/gfortran.dg/pr32627.f03 @@ -18,7 +18,7 @@ program main type( c_ptr ) :: x type( A ), pointer :: fptr type( A ), target :: my_a_type - character( len=9 ), pointer :: strptr + character( len=8 ), pointer :: strptr fptr = my_a_type diff --git a/gcc/testsuite/gfortran.dg/substr_6.f90 b/gcc/testsuite/gfortran.dg/substr_6.f90 index 813a025..a7cdc10 100644 --- a/gcc/testsuite/gfortran.dg/substr_6.f90 +++ b/gcc/testsuite/gfortran.dg/substr_6.f90 @@ -11,6 +11,15 @@ if (c(1) /= ) call abort() c = (/ c0(1)(1:5) /) do i=1,5 if (c(1)(i:i) /= c1(i)) call abort() + + ! Make NULs visible (and avoid corrupting text output). + if (c(1)(i:i) == ACHAR(0)) then +print (a,$), NUL + else +print (a,$), c(1)(i:i) + end if end do -print *, c(1) + +print *, + end
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On Thu, 9 Apr 2015, Segher Boessenkool wrote: I tested a cross to cris-linux and built a Linux kernel with the trivial patch (attached); doing that for all other cross configs is in progress. Thanks. Using contrib/config-list.mk comes to mind, but might be a bit excessive in this particular case. It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( Canned reply: use simulator targets, http://gcc.gnu.org/simtest-howto.html. brgds, H-P
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On Thu, Apr 09, 2015 at 03:21:44PM +0200, Steven Bosscher wrote: On Thu, Apr 9, 2015 at 2:41 PM, Segher Boessenkool wrote: It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( In this case it would be enough to replace the #ifndef/#ifdef HAVE_cc0 code with if (HAVE_cc0). That's the simplest way to avoid compile breakage. Likewise for so many other #ifdef code (HAVE_conditional_move, HAVE_trap, etc.). If the code inside the #ifdef can actually compile for the opposite condition, yeah. The bad effect of not breaking compilation for cc0 targets is we are even less likely to consider whether something would break on cc0 ;-) Perhaps something to work on in the next stage1... Thanks for volunteering! Segher
Re: [PATCH] PR target/55143: undefined reference to `c_default_pointer_mode'
On 9 April 2015 at 21:41, Jakub Jelinek ja...@redhat.com wrote: On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote: gcc/ChangeLog: 2015-04-08 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c/c-tree.h (c_default_pointer_mode): Move declaration ... * c-family/c-common.h (c_default_pointer_mode): ... here. * c/c-decl.c (c_default_pointer_mode): Move definition ... * c-family/c-common.c (c_default_pointer_mode): ... here. The ChangeLog is certainly wrong, as both c and c-family have their own ChangeLog files, so you really can't write it using ... on both sides. So.. modulo leading tabs: gcc/c/ChangeLog: 2015-04-09 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c-decl.c (c_default_pointer_mode): Remove definition. * c-tree.h (c_default_pointer_mode): Remove declaration. gcc/c-family/ChangeLog: 2015-04-09 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c-common.c (c_default_pointer_mode): Add definition. * c-common.h (c_default_pointer_mode): Add declaration. Ok for trunk? thanks,
[PATCH] Fix ubsan type reporting (PR tree-optimization/65709)
Hi!
As can be seen on the following testcase, instrument_mem_ref (for
both -fsanitize=alignment and -fsanitize=null) has been using wrong type
to find out what is the access type - instead of the type of MEM_REF
which is the access type it was using the TREE_TYPE of MEM_REF's argument
type, which can be some arbitrary other type, either due to type punning,
or if it is a SSA_NAME it can be random other type because most pointer
types are considered type compatible in GIMPLE.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2015-04-09 Jakub Jelinek ja...@redhat.com
PR tree-optimization/65709
* ubsan.c (instrument_mem_ref): Use TREE_TYPE (base) instead of
TREE_TYPE (TREE_TYPE (t)).
* c-c++-common/ubsan/align-9.c: New test.
--- gcc/ubsan.c.jj 2015-03-27 10:48:33.0 +0100
+++ gcc/ubsan.c 2015-04-09 10:05:48.841221438 +0200
@@ -1232,9 +1232,9 @@ instrument_mem_ref (tree mem, tree base,
tree t = TREE_OPERAND (base, 0);
if (!POINTER_TYPE_P (TREE_TYPE (t)))
return;
- if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_TYPE (t))) mem != base)
+ if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (base)) mem != base)
ikind = UBSAN_MEMBER_ACCESS;
- tree kind = build_int_cst (TREE_TYPE (t), ikind);
+ tree kind = build_int_cst (build_pointer_type (TREE_TYPE (base)), ikind);
tree alignt = build_int_cst (pointer_sized_int_node, align);
gcall *g = gimple_build_call_internal (IFN_UBSAN_NULL, 3, t, kind, alignt);
gimple_set_location (g, gimple_location (gsi_stmt (*iter)));
--- gcc/testsuite/c-c++-common/ubsan/align-9.c.jj 2015-04-09
10:11:15.227973011 +0200
+++ gcc/testsuite/c-c++-common/ubsan/align-9.c 2015-04-09 10:13:16.857017169
+0200
@@ -0,0 +1,21 @@
+/* Limit this to known non-strict alignment targets. */
+/* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
+/* { dg-options -O2 -fsanitize=alignment -fsanitize-recover=alignment } */
+
+__attribute__((noinline, noclone)) void
+foo (void *p, const void *q)
+{
+ *(long int *) p = *(const long int *) q;
+}
+
+int
+main ()
+{
+ struct S { long c; char f[64]; char d; char e[2 * sizeof (long)]; char
g[64]; } s;
+ __builtin_memset (s, '\0', sizeof s);
+ foo (s.e[0], s.e[sizeof (long)]);
+ return 0;
+}
+
+/* { dg-output \.c:8:\[0-9]*: \[^\n\r]*load of misaligned address
0x\[0-9a-fA-F]* for type 'const long int', which requires \[48] byte
alignment.* } */
+/* { dg-output \.c:8:\[0-9]*: \[^\n\r]*store to misaligned address
0x\[0-9a-fA-F]* for type 'long int', which requires \[48] byte alignment } */
Jakub
Re: patch to fix PR65648
Hi
On 7 April 2015 at 22:02, Yvan Roux yvan.r...@linaro.org wrote:
On 7 April 2015 at 21:33, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
validation is ongoing, but here is my attempt to add this testcase,
does it look correct (it's the first time I use that kind of include
in testsuite)
The intent is that we have a testcase for all targets at various
optimization levels, plus one with specific options for the particular
target.
If you get at least one FAIL with this patch with Vlad's patch reverted and
no FAILs with that patch, the patch is ok for trunk with the obvious
ChangeLog entry.
As this testcase needs to be executed, we can have some conflict at
link time, depending on how the libs were compiled. Here is what I've
for the moment, let me know if it's ok and/or if you have suggestion
on how to improve it.
- armv6 doesn't support the hard-float ABI in Thumb mode, I disable
the testcase with this directive, but not sure it's the best way:
{ dg-skip-if avoid conflicting multilib options { *-*-*eabihf } {
* } { } }ot
- The original problem was reported on armv6-m arch. but is not
related to the M profile, if we stick to armv6-m the link will fail on
compiler which default to the -A profile. As my guess is that -A
profile is more widely tested, I changed the -march flag to armv6. Do
you think it's ok ?
With the attached patch there is only 1 FAIL before Vlad's patch on
the execution of the test and they all PASS when testing
arm-linux-gnueabi, and the target test is UNSUPPORTED when test
arm-linux-gnueabihf.
Cheers,
Yvan
2105-04-09 Yvan Roux yvan.r...@linaro.org
PR target/65648
* gcc.c-torture/execute/pr65648.c: New test.
* gcc.target/arm/pr65648.c: New test.
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr65648.c
b/gcc/testsuite/gcc.c-torture/execute/pr65648.c
new file mode 100644
index 000..88a2fc9
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr65648.c
@@ -0,0 +1,34 @@
+/* PR target/65648 */
+
+int a = 0, *b = 0, c = 0;
+static int d = 0;
+short e = 1;
+static long long f = 0;
+long long *i = f;
+unsigned char j = 0;
+
+__attribute__((noinline, noclone)) void
+foo (int x, int *y)
+{
+ asm volatile ( : : r (x), r (y) : memory);
+}
+
+__attribute__((noinline, noclone)) void
+bar (const char *x, long long y)
+{
+ asm volatile ( : : r (x), r (y) : memory);
+ if (y != 0)
+__builtin_abort ();
+}
+
+int
+main ()
+{
+ int k = 0;
+ b = k;
+ j = (!a) - (c = e);
+ *i = j;
+ foo (a, k);
+ bar (, f);
+ return 0;
+}
diff --git a/gcc/testsuite/gcc.target/arm/pr65648.c
b/gcc/testsuite/gcc.target/arm/pr65648.c
new file mode 100644
index 000..e075546
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr65648.c
@@ -0,0 +1,9 @@
+/* { dg-do run } */
+/* { dg-skip-if avoid conflicting multilib options { *-*-* } { -march=* }
{ -march=armv6 } } */
+/* { dg-skip-if avoid conflicting multilib options { *-*-* } { -marm } {
} } */
+/* { dg-skip-if avoid conflicting multilib options { *-*-*eabihf } { * } {
} } */
+/* { dg-options -mthumb -Os -mfloat-abi=soft } */
+/* { dg-add-options arm_arch_v6 } */
+
+#include ../../gcc.c-torture/execute/pr65648.c
+
Re: [C++ PATCH] Fix alignment handling in build_cplus_array_type/cp_build_qualified_type_real (PR c++/65690)
On Wed, Apr 08, 2015 at 12:02:39PM +0200, Jakub Jelinek wrote:
The included (first) patch has been successfully bootstrapped/regtested on
x86_64-linux and i686-linux, the attached patch not, but I can
bootstrap/regtest it if you prefer it.
The attached version unfortunately regresses pr60226.c
typedef int __attribute__ ((aligned (1 28))) int28;
int28 foo[4] = {}; /* { dg-error alignment of array elements is greater than
element size } */
error is not reported then. But the first version with the layout_type call
in there works.
@@ -1057,21 +1064,23 @@ cp_build_qualified_type_real (tree type,
should be equivalent to those in check_qualified_type. */
for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
if (TREE_TYPE (t) == element_type
- TYPE_NAME (t) == TYPE_NAME (type)
- TYPE_CONTEXT (t) == TYPE_CONTEXT (type)
- attribute_list_equal (TYPE_ATTRIBUTES (t),
- TYPE_ATTRIBUTES (type)))
+ check_base_type (t, type))
So, would instead of this change adding
TYPE_USER_ALIGN (t) == TYPE_USER_ALIGN (type)
(!TYPE_USER_ALIGN (t) || TYPE_ALIGN (t) == TYPE_ALIGN (type))
to the conditional work for you?
Or supposedly no change at all, as the attributes would be either in
TYPE_ATTRIBUTES, or on TYPE_DECL, but then it would be covered by
the TYPE_NAME comparison.
break;
if (!t)
{
t = build_cplus_array_type (element_type, TYPE_DOMAIN (type));
- /* Keep the typedef name. */
- if (TYPE_NAME (t) != TYPE_NAME (type))
+ /* Keep the typedef name, context and alignment. */
+ if (TYPE_NAME (t) != TYPE_NAME (type)
+ || TYPE_CONTEXT (t) != TYPE_CONTEXT (type)
+ || TYPE_ALIGN (t) != TYPE_ALIGN (type))
Then supposedly similar change to the above one (the TYPE_USER_ALIGN stuff).
Jakub
Re: [PATCH, i386] Fix PR target/65671. Generate 32x4 extract even for DF in absence of AVX-512DQ.
On Thu, Apr 9, 2015 at 4:37 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Patch in the bottom fixes PR target/65671.
It simply generates vextract32x4 (float form) for double extract.
Bootstrap regtesting in progress.
I'll check it in if pass and back port to 4.9.x.
Feel free comment.
gcc/
* config/i386/sse.md: Generate vextract32x4 if AVX-512DQ
is disabled.
gcc/testsuite/
* gcc.target/i386/pr65671.c: New.
OK with fixed ChangeLogs. (Please add PR target/65671 to both ChangeLogs).
Thanks,
Uros.
commit cb8d5b1c3156d81ae81600217d0861be1aade0ec
Author: Kirill Yukhin kirill.yuk...@intel.com
Date: Thu Apr 9 13:05:54 2015 +0300
Fix PR target/65671. Generate 32x4 extract even for DF in absence of
AVX-512DQ.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 490fd6b..6d3b54a 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -7015,10 +7015,15 @@
(vec_select:ssehalfvecmode
(match_operand:VI8F_256 1 register_operand v,v)
(parallel [(const_int 2) (const_int 3)])))]
- TARGET_AVX
+ TARGET_AVX mask_avx512vl_condition mask_avx512dq_condition
{
- if (TARGET_AVX512DQ TARGET_AVX512VL)
-return vextractshuffletype64x2\t{$0x1, %1,
%0mask_operand2|%0mask_operand2, %1, 0x1};
+ if (TARGET_AVX512VL)
+ {
+if (TARGET_AVX512DQ)
+ return vextractshuffletype64x2\t{$0x1, %1,
%0mask_operand2|%0mask_operand2, %1, 0x1};
+else
+ return vextractshuffletype32x4\t{$0x1, %1, %0|%0, %1, 0x1};
+ }
else
return vextracti128\t{$0x1, %1, %0|%0, %1, 0x1};
}
diff --git a/gcc/testsuite/gcc.target/i386/pr65671.c
b/gcc/testsuite/gcc.target/i386/pr65671.c
new file mode 100644
index 000..8e5d00d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr65671.c
@@ -0,0 +1,15 @@
+/* PR target/65671 */
+/* { dg-do assemble } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options -O2 -mavx512vl -ffixed-ymm16 } */
+
+#include x86intrin.h
+
+register __m256d a asm (ymm16);
+__m128d b;
+
+void
+foo ()
+{
+ b = _mm256_extractf128_pd (a, 1);
+}
Re: [PATCH] Update {x86_64,i[34]86,aarch64,s390{,x},powerpc64}-linux baseline_symbols.txt
On Wed, Apr 8, 2015 at 11:28 AM, Jonathan Wakely jwak...@redhat.com wrote: On 08/04/15 19:40 +0200, Jakub Jelinek wrote: Hi! Attached patch updates baseline_symbols.txt for a couple of architectures. Don't have 32-bit powerpc-linux around though this time. Ok for trunk? OK, thanks very much for doing this. I checked in this patch to update x32 baseline_symbols.txt:. -- H.J. x32.patch.xz Description: application/xz
Re: [PATCH] Update {x86_64,i[34]86,aarch64,s390{,x},powerpc64}-linux baseline_symbols.txt
On 09/04/15 08:44 -0700, H.J. Lu wrote: I checked in this patch to update x32 baseline_symbols.txt:. Great, thanks.
Re: [Patch, Fortran, pr60322] was: [Patch 1/2, Fortran, pr60322] [OOP] Incorrect bounds on polymorphic dummy array
Hi Paul, hi all,
Paul, thanks for the review. Answers to your questions are inline below:
On Sun, 5 Apr 2015 11:13:05 +0200
Paul Richard Thomas paul.richard.tho...@gmail.com wrote:
snip
+ /* The dummy is returned for pointer, allocatable or assumed rank arrays.
+ The check for pointerness needs to be repeated here (it is done in
+ IS_CLASS_ARRAY (), too), because for class arrays that are pointers, as
+ is the one of the sym, which is incorrect here. */
What does this mean, please?
The first sentence is about regular arrays and should be unchanged from the
original source. Then I have to check for class (arrays) that are pointers,
i.e., independent of whether the sym is a class array or a regular pointer to a
class object. (The latter shouldn't make it into the routine anyway.)
IS_CLASS_ARRAY () returns false for too many reasons to be of use here. I have
to apologize and confess that the comment was a mere note to myself to not
return to use is_classarray in the if below. Let me rephrase the comment to be:
/* The dummy is returned for pointer, allocatable or assumed rank arrays.
For class arrays the information if sym is an allocatable or pointer
object needs to be checked explicitly (IS_CLASS_ARRAY can be false for
too many reasons to be of use here). */
+ /* Returning the descriptor for dummy class arrays is hazardous,
because
+ some caller is expecting an expression to apply the component refs to.
+ Therefore the descriptor is only created and stored in
+ sym-backend_decl's GFC_DECL_SAVED_DESCRIPTOR. The caller is then
+ responsible to extract it from there, when the descriptor is
+ desired. */
+ if (IS_CLASS_ARRAY (sym)
+ (!DECL_LANG_SPECIFIC (sym-backend_decl)
+ || !GFC_DECL_SAVED_DESCRIPTOR (sym-backend_decl)))
+{
+ decl = gfc_build_dummy_array_decl (sym, sym-backend_decl);
+ /* Prevent the dummy from being detected as unused if it is copied. */
+ if (sym-backend_decl != NULL decl != sym-backend_decl)
+DECL_ARTIFICIAL (sym-backend_decl) = 1;
+ sym-backend_decl = decl;
+}
The comments, such as the above are often going well beyond column 72,
into the 80's. I know that much of the existing code violates this
style requirement but there is no need to do so if clarity is not
reduced thereby.
Er, the document at
https://gcc.gnu.org/codingconventions.html#C_Formatting
says that line length is 80, or is there another convention, that I am not
aware of?
In trans-stmt.c s/standart/standard/
Fixed.
Don't forget to put the PR numbers in the ChangeLogs.
I won't anymore, already got told off :-)
For this submission, I would have appreciated some a description of
what each chunk in the patch is doing, just because there is so much
of it. I suppose that it was good for my imortal soul to sort it out
for myself but it took a little while :-)
I initially tried to split the submission in two parts to make it more
manageable. One part with the brain-dead substitutions of as and array_attr and
one with the new code. Albeit I failed to get the brain-dead part right and
made some mistakes there already, which Mikael pointed out. I therefore went
for the big submission.
Now doing a description of what each chunk does is quite tedious. I really
would like to spend my time more productive. Would you be satisfied, when I
write a story about the patch, referring to some parts more explicitly, like
Chunk 4 of file trans-stmt.c is the heart of the patch and does this and that.
The remaining chunks are more or less putting the data together.
(This is not correct for this patch of course. Just an example.) More elaborate
of course, but just to give an idea.
Thanks again. I will commit as soon as 5.2/6.0 commit window is open.
Regards,
Andre
Cheers and many thanks for the patch.
Paul
On 27 March 2015 at 13:48, Paul Richard Thomas
paul.richard.tho...@gmail.com wrote:
Dear Andre,
I am in the UK as of last night. Before leaving, I bootstrapped and
regtested your patch and all was well. I must drive to Cambridge this
afternoon to see my mother and will try to get to it either this
evening or tomorrow morning. There is so much of it and it touches
many places; so I must give it a very careful looking over before
giving the green light. Bear with me please.
Great work though!
Paul
On 24 March 2015 at 18:06, Andre Vehreschild ve...@gmx.de wrote:
Hi all,
I have worked on the comments Mikael gave me. I am now checking for
class_pointer in the way he pointed out.
Furthermore did I *join the two parts* of the patch into this one, because
keeping both in sync was no benefit but only tedious and did not prove to
be reviewed faster.
Paul, Dominique: I have addressed the LOC issue that came up lately. Or
rather the patch addressed it already. I feel like this is not tested very
well, not the loc() call nor the
Re: breakage with [PATCH] combine: Disregard clobbers in another test for two SETs (PR65693)
On Wed, Apr 08, 2015 at 10:29:03PM -0400, Hans-Peter Nilsson wrote: On Wed, 8 Apr 2015, Segher Boessenkool wrote: 2015-04-08 Segher Boessenkool seg...@kernel.crashing.org * combine.c (is_parallel_of_n_reg_sets): Change first argument from an rtx_insn * to an rtx. (try_combine): Adjust both callers. Use it once more. Hi, That once more is outside of #ifndef HAVE_cc0 and is_parallel_of_n_reg_sets is only defined inside of one. Boom. Oops. So sorry. Full test on a cc0 target (such as cris-elf) is advised, and at least make all-gcc would be a minimum after fixing. I tested a cross to cris-linux and built a Linux kernel with the trivial patch (attached); doing that for all other cross configs is in progress. It would be nice if there would be some cc0 target in the compile farm, since cc0 isn't going away any time soon :-( Okay if testing has finished successfully? Segher 2015-04-09 Segher Boessenkool seg...@kernel.crashing.org PR rtl-optimization/65693 * combine.c (is_parallel_of_n_reg_sets): Move outside of #ifndef HAVE_cc0. --- gcc/combine.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/combine.c b/gcc/combine.c index 32950383..0836f74 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -2492,7 +2492,6 @@ update_cfg_for_uncondjump (rtx_insn *insn) } } -#ifndef HAVE_cc0 /* Return whether PAT is a PARALLEL of exactly N register SETs followed by an arbitrary number of CLOBBERs. */ static bool @@ -2517,6 +2516,7 @@ is_parallel_of_n_reg_sets (rtx pat, int n) return true; } +#ifndef HAVE_cc0 /* Return whether INSN, a PARALLEL of N register SETs (and maybe some CLOBBERs), can be split into individual SETs in that order, without changing semantics. */ -- 1.8.1.4
Re: [PATCH] Fix ubsan type reporting (PR tree-optimization/65709)
On April 9, 2015 8:11:22 PM GMT+02:00, Jakub Jelinek ja...@redhat.com wrote:
Hi!
As can be seen on the following testcase, instrument_mem_ref (for
both -fsanitize=alignment and -fsanitize=null) has been using wrong
type
to find out what is the access type - instead of the type of MEM_REF
which is the access type it was using the TREE_TYPE of MEM_REF's
argument
type, which can be some arbitrary other type, either due to type
punning,
or if it is a SSA_NAME it can be random other type because most pointer
types are considered type compatible in GIMPLE.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for
trunk?
OK.
Thanks,
Richard.
2015-04-09 Jakub Jelinek ja...@redhat.com
PR tree-optimization/65709
* ubsan.c (instrument_mem_ref): Use TREE_TYPE (base) instead of
TREE_TYPE (TREE_TYPE (t)).
* c-c++-common/ubsan/align-9.c: New test.
--- gcc/ubsan.c.jj 2015-03-27 10:48:33.0 +0100
+++ gcc/ubsan.c2015-04-09 10:05:48.841221438 +0200
@@ -1232,9 +1232,9 @@ instrument_mem_ref (tree mem, tree base,
tree t = TREE_OPERAND (base, 0);
if (!POINTER_TYPE_P (TREE_TYPE (t)))
return;
- if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (TREE_TYPE (t))) mem !=
base)
+ if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (base)) mem != base)
ikind = UBSAN_MEMBER_ACCESS;
- tree kind = build_int_cst (TREE_TYPE (t), ikind);
+ tree kind = build_int_cst (build_pointer_type (TREE_TYPE (base)),
ikind);
tree alignt = build_int_cst (pointer_sized_int_node, align);
gcall *g = gimple_build_call_internal (IFN_UBSAN_NULL, 3, t, kind,
alignt);
gimple_set_location (g, gimple_location (gsi_stmt (*iter)));
--- gcc/testsuite/c-c++-common/ubsan/align-9.c.jj 2015-04-09
10:11:15.227973011 +0200
+++ gcc/testsuite/c-c++-common/ubsan/align-9.c 2015-04-09
10:13:16.857017169 +0200
@@ -0,0 +1,21 @@
+/* Limit this to known non-strict alignment targets. */
+/* { dg-do run { target { i?86-*-linux* x86_64-*-linux* } } } */
+/* { dg-options -O2 -fsanitize=alignment
-fsanitize-recover=alignment } */
+
+__attribute__((noinline, noclone)) void
+foo (void *p, const void *q)
+{
+ *(long int *) p = *(const long int *) q;
+}
+
+int
+main ()
+{
+ struct S { long c; char f[64]; char d; char e[2 * sizeof (long)];
char g[64]; } s;
+ __builtin_memset (s, '\0', sizeof s);
+ foo (s.e[0], s.e[sizeof (long)]);
+ return 0;
+}
+
+/* { dg-output \.c:8:\[0-9]*: \[^\n\r]*load of misaligned address
0x\[0-9a-fA-F]* for type 'const long int', which requires \[48] byte
alignment.* } */
+/* { dg-output \.c:8:\[0-9]*: \[^\n\r]*store to misaligned address
0x\[0-9a-fA-F]* for type 'long int', which requires \[48] byte
alignment } */
Jakub
Re: [PATCH] Fix ICE with x86_64 alloca (PR target/65693)
On Wed, Apr 8, 2015 at 10:52 PM, Jakub Jelinek ja...@redhat.com wrote:
This patch extends the PR65220 patch:
1) there is really no reason to limit the divisor to 32 or 64,
we can divide/modulo by pow2 constants up to 2G (0x7fff is
then still representable in 32-bit signed immediate)
2) on the testcase RTL cprop unfortunately isn't performed, because
the function contains only a single basic block, and the combiner
when the constant is propagated into it simplifies it to the
shift and and; so the patch adds another pattern similar to the previous
one to handle this case
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-04-08 Jakub Jelinek ja...@redhat.com
PR target/65693
* config/i386/i386.md (*udivmodmode4_pow2): Allow
any pow2 integer in between 2 and 0x8000U inclusive.
(*udivmodmode4_pow2_1): New define_insn_and_split.
* gcc.target/i386/pr65693.c: New test.
Part 1) is OK and is IMO a good improvement. The combiner part 2) has
just been fixed in a generic way [1], so it looks that the new pattern
is not needed.
There still remains the issue with asm(%rdx) that effectively
blocks usage of rdx register in the function. Does RA declares the
register as fixed in this case?
[1] https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00359.html
Thanks,
Uros.
--- gcc/config/i386/i386.md.jj 2015-04-03 15:32:30.0 +0200
+++ gcc/config/i386/i386.md 2015-04-08 17:30:10.615369134 +0200
@@ -7340,7 +7340,7 @@ (define_insn_and_split *udivmodmode4_
(set (match_operand:SWI48 1 register_operand =r)
(umod:SWI48 (match_dup 2) (match_dup 3)))
(clobber (reg:CC FLAGS_REG))]
- UINTVAL (operands[3]) - 2 MODE_SIZE * BITS_PER_UNIT
+ IN_RANGE (INTVAL (operands[3]), 2, HOST_WIDE_INT_UC (0x8000))
(UINTVAL (operands[3]) (UINTVAL (operands[3]) - 1)) == 0
#
1
@@ -7357,6 +7357,27 @@ (define_insn_and_split *udivmodmode4_
[(set_attr type multi)
(set_attr mode MODE)])
+;; Similarly, but for the case when the combiner simplifies it.
+(define_insn_and_split *udivmodmode4_pow2_1
+ [(set (match_operand:SWI48 0 register_operand =r)
+ (lshiftrt:SWI48 (match_operand:SWI48 2 register_operand 0)
+ (match_operand:SWI48 3 const_int_operand n)))
+ (set (match_operand:SWI48 1 register_operand =r)
+ (and:SWI48 (match_dup 2) (match_operand:SWI48 4 const_int_operand
n)))
+ (clobber (reg:CC FLAGS_REG))]
+ IN_RANGE (INTVAL (operands[3]), 1, 31)
+UINTVAL (operands[4]) == (HOST_WIDE_INT_1U INTVAL (operands[3])) -
1
+ #
+ 1
+ [(set (match_dup 1) (match_dup 2))
+ (parallel [(set (match_dup 0) (lshiftrt:MODE (match_dup 2) (match_dup
3)))
+ (clobber (reg:CC FLAGS_REG))])
+ (parallel [(set (match_dup 1) (and:MODE (match_dup 1) (match_dup 4)))
+ (clobber (reg:CC FLAGS_REG))])]
+
+ [(set_attr type multi)
+ (set_attr mode MODE)])
+
(define_insn *udivmodmode4_noext
[(set (match_operand:SWIM248 0 register_operand =a)
(udiv:SWIM248 (match_operand:SWIM248 2 register_operand 0)
--- gcc/testsuite/gcc.target/i386/pr65693.c.jj 2015-04-08 17:42:14.146727788
+0200
+++ gcc/testsuite/gcc.target/i386/pr65693.c 2015-04-08 17:41:22.0
+0200
@@ -0,0 +1,13 @@
+/* PR target/65693 */
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+int a;
+
+void
+foo (int (*fn) (int, int, int), unsigned int b)
+{
+ unsigned long *c = (unsigned long *) __builtin_alloca (b);
+ a = *c;
+ register int d asm (edx) = fn (0, 0, d);
+}
Jakub
[PATCH, committed] PR jit/65691: Fix copypaste error in jit docs
I've committed the following trivial patch to trunk (as r221959). gcc/jit/ChangeLog: PR jit/65691 * docs/cp/topics/expressions.rst (Simple expressions): Fix copy and paste error in description of gccjit::context::one. * docs/topics/expressions.rst (Simple expressions): Likewise in description of gcc_jit_context_one. * docs/_build/texinfo/libgccjit.texi: Regenerate. --- gcc/jit/docs/cp/topics/expressions.rst | 2 +- gcc/jit/docs/topics/expressions.rst| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/jit/docs/cp/topics/expressions.rst b/gcc/jit/docs/cp/topics/expressions.rst index bacfde1..4ea2622 100644 --- a/gcc/jit/docs/cp/topics/expressions.rst +++ b/gcc/jit/docs/cp/topics/expressions.rst @@ -80,7 +80,7 @@ Simple expressions gccjit::context::one (gccjit::type numeric_type) const Given a numeric type (integer or floating point), get the rvalue for - zero. Essentially this is just a shortcut for: + one. Essentially this is just a shortcut for: .. code-block:: c++ diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 49317b9..621991f 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -84,7 +84,7 @@ Simple expressions gcc_jit_type *numeric_type) Given a numeric type (integer or floating point), get the rvalue for - zero. Essentially this is just a shortcut for: + one. Essentially this is just a shortcut for: .. code-block:: c -- 1.8.5.3
Re: [patch,avr]: Part2: Fix various problems with specs and specs file generation.
Am 04/09/2015 um 12:59 PM schrieb Sivanupandi, Pitchumani: And what about the spaces problem as mentioned in http://savannah.nongnu.org/bugs/?44574 http://lists.gnu.org/archive/html/avr-libc-dev/2015-03/msg00010.html Art there plans to fix that? Yes. Will submit patch to avr-libc by next week. Thanks. Regards, Pitchumani If the device libs are moved, all the ~200 .dev/device directories will contain just 1 file each: crt1.o. Is it much work to tidy that up? (For example by renaming to, say, crtdevice.o and moving them to a common place or to their natural multilib location.) Johann
Re: [PATCH] PR target/55143: undefined reference to `c_default_pointer_mode'
On Thu, Apr 09, 2015 at 09:27:34PM +0200, Bernhard Reutner-Fischer wrote: gcc/ChangeLog: 2015-04-08 Bernhard Reutner-Fischer al...@gcc.gnu.org PR target/55143 * c/c-tree.h (c_default_pointer_mode): Move declaration ... * c-family/c-common.h (c_default_pointer_mode): ... here. * c/c-decl.c (c_default_pointer_mode): Move definition ... * c-family/c-common.c (c_default_pointer_mode): ... here. The ChangeLog is certainly wrong, as both c and c-family have their own ChangeLog files, so you really can't write it using ... on both sides. Jakub
Re: patch to fix PR65648
On Thu, Apr 09, 2015 at 01:10:41PM +0200, Yvan Roux wrote: 2105-04-09 Yvan Roux yvan.r...@linaro.org PR target/65648 * gcc.c-torture/execute/pr65648.c: New test. This part is definitely ok for trunk. * gcc.target/arm/pr65648.c: New test. This part should better be reviewed by some ARM maintainer, I'm really lost in all the incompatible ARM options. Jakub
[patch,avr,committed]: ad PR65296: work around device-specs file + dejagnu for c++.
Applied this patch:
http://gcc.gnu.org/r221947
Johann
* config/avr/driver-avr.c (avr_devicespecs_file): Don't specify a
device specs file if device-specs%s didn't resolve to a path.
Index: config/avr/driver-avr.c
===
--- config/avr/driver-avr.c (revision 221946)
+++ config/avr/driver-avr.c (working copy)
@@ -80,6 +80,19 @@ avr_devicespecs_file (int argc, const ch
return X_NODEVLIB;
case 1:
+ if (0 == strcmp (device-specs, argv[0]))
+{
+ /* FIXME: This means device-specs%s from avr.h:DRIVER_SELF_SPECS
+ has not been resolved to a path. That case can occur when the
+ c++ testsuite is run from the build directory. DejaGNU's
+ libgloss.exp:get_multilibs runs $compiler without -B, i.e.runs
+ xgcc without specifying a prefix. Without any prefix, there is
+ no means to find out where the specs files might be located.
+ get_multilibs runs xgcc --print-multi-lib, hence we don't actually
+ need information form a specs file and may skip it here. */
+ return X_NODEVLIB;
+}
+
mmcu = AVR_MMCU_DEFAULT;
break;
[PATCH] Revised fix for PR65351
Hi,
It turns out that existing versions of clang (used as bootstrap on later Darwin
editions) support -mdynamic-no-pic, but not the inverse. The patch below
revises mh-darwin so that it only adds -mdynamic-no-pic when the inverse is
supported (for stage1 and boot cflags). For later stages, built with GCC, it
is known to be supported and can be added unconditionally.
When generating the PICFLAG, -mno-dynamic-no-pic is added only when
-mdynamic-no-pic is present in CFLAGS.
OK for trunk?
Iain
2015-04-09 Jakub Jelinek ja...@redhat.com
Iain Sandoe i...@codesourcery.com
PR target/65351
config/
* mh-darwin: Only apply -mdynamic-no-pic for m32 Darwin when the
compiler in
use supports -mno-dynamic-no-pic.
* picflag.m4: Only append -mno-dynamic-no-pic for Darwin when
-mdynamic-no-pic
is present in CFLAGS.
libiberty/
* configure: Regenerate.
libada/
* configure: Regenerate.
libgcc/
* configure: Regenerate.
gcc/
* configure: Regenerate.
diff --git a/config/mh-darwin b/config/mh-darwin
index a039f20..148b730 100644
--- a/config/mh-darwin
+++ b/config/mh-darwin
@@ -1,18 +1,29 @@
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin. This fix speeds
-# compiles by 3-5%.
-BOOT_CFLAGS += \
+# compiles by 3-5%. Don't add it if the compiler doesn't also support
+# -mno-dynamic-no-pic to undo it.
+DARWIN_MDYNAMIC_NO_PIC := \
`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
- echo -mdynamic-no-pic ;; esac;`
+ $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2/dev/null \
+echo -mdynamic-no-pic ;; esac`
+DARWIN_GCC_MDYNAMIC_NO_PIC := \
+`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
+ $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2/dev/null \
+ || echo -mdynamic-no-pic ;; esac`
# ld on Darwin versions = 10.7 defaults to PIE executables. Disable this for
# gcc components, since it is incompatible with our pch implementation.
-BOOT_LDFLAGS += \
-`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
+DARWIN_NO_PIE := `case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;;
esac;`
+
+BOOT_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
+BOOT_LDFLAGS += $(DARWIN_NO_PIE)
# Similarly, for cross-compilation.
-STAGE1_CFLAGS += \
-`case ${host} in i?86-*-darwin* | powerpc-*-darwin*)\
- echo -mdynamic-no-pic ;; esac;`
-STAGE1_LDFLAGS += \
-`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
+STAGE1_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
+STAGE1_LDFLAGS += $(DARWIN_NO_PIE)
+
+# Without -mno-dynamic-no-pic support, add -mdynamic-no-pic just to later
+# stages when we know it is built with gcc.
+STAGE2_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
+STAGE3_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
+STAGE4_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
diff --git a/config/picflag.m4 b/config/picflag.m4
index 836523d..2f5b972 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -7,11 +7,15 @@ AC_DEFUN([_GCC_PICFLAG], [
case ${$2} in
# PIC is the default on some targets or must not be used.
*-*-darwin*)
- # PIC is the default on this platform
- # Common symbols not allowed in MH_DYLIB files
- # Cancel any earlier -mdynamic-no-pic, as that makes
- # the code not suitable for shared libraries.
- $1='-fno-common -mno-dynamic-no-pic'
+ # For darwin, common symbols are not allowed in MH_DYLIB files
+ case ${CFLAGS} in
+ # If we are using a compiler supporting mdynamic-no-pic
+ # and the option has been tested as safe to add, then cancel
+ # it here, since the code generated is incompatible with shared
+ # libs.
+ *-mdynamic-no-pic*) $1='-fno-common -mno-dynamic-no-pic' ;;
+ *) $1=-fno-common ;;
+ esac
;;
alpha*-dec-osf5*)
# PIC is the default.
