C++ (RFC) PATCH fix for PR55076 and PR53921
The problem here is that we end up with an INDIRECT_REF TREE_CODE with a
null TREE_TYPE in lvalue_kind. Is this possible at that point, or does
it point to a deeper underlying problem?
Bootstraped and tested on x86_64-pc-linux-gnu.
2012-10-27 Markus Trippelsdorf
PR c++/50089
PR c++/53921
PR c++/55076
* tree.c (lvalue_kind): Guard against null TREE_TYPE.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 8d555c2..0f1a75d 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -145,7 +145,7 @@ lvalue_kind (const_tree ref)
case ARRAY_REF:
case PARM_DECL:
case RESULT_DECL:
- if (TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE)
+ if (TREE_TYPE (ref) && TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE)
return clk_ordinary;
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C
new file mode 100644
index 000..76b6376
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template8.C
@@ -0,0 +1,12 @@
+// PR c++/50089 c++/53921 c++/55076
+// { dg-do compile { target c++11 } }
+void a (int);
+template
+struct A
+{
+int b;
+void c ()
+{
+[=] { a (b); }; //ICE without this->b
+};
+};
--
Markus
Re: [PATCH] PR c++/54955 - Fail to parse alignas expr at the beginning of a declaration
Jason Merrill writes:
> On 10/26/2012 01:37 PM, Dodji Seketeli wrote:
>> cp_next_tokens_can_be_std_attribute_p (cp_parser *parser)
>> {
>> - return cp_nth_tokens_can_be_std_attribute_p (parser, 1);
>> + cp_token *token = cp_lexer_peek_token (parser->lexer);
>> +
>> + return (cxx_dialect >= cxx0x
>> + (token->type == CPP_KEYWORD && token->keyword == RID_ALIGNAS)
>> + || cp_nth_tokens_can_be_std_attribute_p (parser, 1));
>
> Shouldn't this change be in cp_nth_tokens... rather than here?
Like this? (tested like the previous patch)
gcc/cp
PR c++/54955
* parser.c (cp_nth_tokens_can_be_std_attribute_p): Recognize the
'Alignas' keyword as the beginning of a c++11 attribute specifier.
Update the comment of the function.
(cp_next_tokens_can_be_gnu_attribute_p): Update the comment of the
function.
gcc/testsuite/
PR c++/54955
* g++.dg/cpp0x/gen-attrs-48-2.C: New test.
---
gcc/cp/parser.c | 11 ++-
gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C | 4
2 files changed, 10 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9403563..f2642ab 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -20324,7 +20324,7 @@ cp_next_tokens_can_be_gnu_attribute_p (cp_parser
*parser)
}
/* Return TRUE iff the next tokens in the stream are possibly the
- beginning of a standard C++-11 attribute. */
+ beginning of a standard C++-11 attribute specifier. */
static bool
cp_next_tokens_can_be_std_attribute_p (cp_parser *parser)
@@ -20333,7 +20333,7 @@ cp_next_tokens_can_be_std_attribute_p (cp_parser
*parser)
}
/* Return TRUE iff the next Nth tokens in the stream are possibly the
- beginning of a standard C++-11 attribute. */
+ beginning of a standard C++-11 attribute specifier. */
static bool
cp_nth_tokens_can_be_std_attribute_p (cp_parser *parser, size_t n)
@@ -20341,9 +20341,10 @@ cp_nth_tokens_can_be_std_attribute_p (cp_parser
*parser, size_t n)
cp_token *token = cp_lexer_peek_nth_token (parser->lexer, n);
return (cxx_dialect >= cxx0x
- && token->type == CPP_OPEN_SQUARE
- && (token = cp_lexer_peek_nth_token (parser->lexer, n + 1))
- && token->type == CPP_OPEN_SQUARE);
+ && ((token->type == CPP_KEYWORD && token->keyword == RID_ALIGNAS)
+ || (token->type == CPP_OPEN_SQUARE
+ && (token = cp_lexer_peek_nth_token (parser->lexer, n + 1))
+ && token->type == CPP_OPEN_SQUARE)));
}
/* Return TRUE iff the next Nth tokens in the stream are possibly the
diff --git a/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C
b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C
new file mode 100644
index 000..3cc5897
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/gen-attrs-48-2.C
@@ -0,0 +1,4 @@
+// Origin: PR c++/54955
+// { dg-do compile { target c++11 } }
+
+alignas(double) int f;
--
Dodji
[PATCH, testsuite]: Add a testcase for PR34283, RA problem fixed by LRA
Hello!
Attached patch adds a testcase for RA problem that was fixed by LRA.
2012-10-27 Uros Bizjak
PR target/34283
* gcc.target/i386/pr34283.c: New test.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: gcc.target/i386/pr34283.c
===
--- gcc.target/i386/pr34283.c (revision 0)
+++ gcc.target/i386/pr34283.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -msse4" } */
+
+typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
+typedef long long __v2di __attribute__ ((__vector_size__ (16)));
+
+__m128i _mm_set_epi64x (long long __q1, long long __q0)
+{
+ return __extension__ (__m128i)(__v2di){ __q0, __q1 };
+}
+
+/* { dg-final { scan-assembler-not "movdqa" } } */
[PATCH] PR c++/54466 - ICE with alias template which type-id is const qualified
Hello,
Consider this short example:
template
struct X { };
template
using Y = const X;
using Z = Y;
G++ crashes in lookup_class_template_1 while trying to build the alias
template instantiation Y.
I think this is indirectly due to the fact that lookup_class_template_1
can now yield a const qualified type like 'const X'.
As a consequence, the code in lookup_template_class_1 that was trying
to access the TYPE_STUB_DECL field of the result of
lookup_template_class_1 should now be adjusted to access the
TYPE_STUB_DECL of the main variant of the resulting type instead;
because qualified types (constructed with build_qualified_type)
have their TYPE_STUB_DECL set to NULL.
Fixed thus and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
PR c++/54466
* pt.c (lookup_template_class_1): TYPE_STUB_DECL should be
accessed on the main variant of the type.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-25.C: New test file.
In the example of this patch, g++ crashes when trying to build the
alias template Y
+ struct X { };
+
+template
+ using Y = const X;
+
+using Z = Y;
--
Dodji
Re: PR c/53066 Wshadow should not warn for shadowing an extern function
On 25 April 2012 13:54, Joseph S. Myers wrote: > On Wed, 25 Apr 2012, Manuel López-Ibáñez wrote: > >> On 25 April 2012 00:01, Joseph S. Myers wrote: >> > On Sun, 22 Apr 2012, Manuel López-Ibáñez wrote: >> > >> >> Wshadow warns whenever any declaration shadows a global function >> >> declaration. This is almost always noise, since most (always?) of the >> >> time one cannot mistakenly replace a function by another variable. The >> >> false positives are too common (Linus mentions using the name 'index' >> >> when including string.h). >> > >> > I think the correct rule would be: warn if a variable *with >> > pointer-to-function type* shadows a function, and warn if a nested >> > function shadows another function, but don't warn for variables shadowing >> > functions if the variable has any other type (because if the variable has >> > some type that isn't a pointer-to-function, no confusion is likely without >> > another error being given). >> >> Right. How does one check that a decl is a nested function? > > I think you should check if the decl has function type or pointer to > function type. (Nested functions are simply I think the only valid case > where you can end up with one function shadowing another; "has function > type" is the logical check rather than "is a nested function".) Like so? Bootstrapped and regression tested on x86_64-linux-gnu. OK? 2012-10-27 Manuel López-Ibáñez PR c/53066 gcc/ * c/c-decl.c (warn_if_shadowing): Do not warn if a variable shadows a function, unless the variable is a function or a pointer-to-function. * tree.h (FUNCTION_POINTER_TYPE_P): New. testsuite/ * gcc.dg/Wshadow-4.c: New. wshadow.diff Description: Binary data
Re: *ping* [patch, fortran] Handle -Wextra, -fcompare-reals is implied with -Wextra
Am 27.10.2012 01:41, schrieb Andreas Schwab: Thomas Koenig writes: Index: trans.c === --- trans.c (revision 192638) +++ trans.c (working copy) @@ -814,26 +814,23 @@ gfc_allocate_allocatable (stmtblock_t * block, tre What's this? Something that I accidentally committed, which is part of a patch pending review (see http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00613.html). Reverted as of revision 192875. Thomas
[RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes
Hello!
As suggested by Richard S. [1], after the patch that converts subreg:M
(op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can
remove several peephole2 patterns that handle subregs of PLUS, MINUS
and MULT operators. I have attached RFC prototype patch that will
trigger an ICE when to-be-removed pattern triggers, with the intention
that these patterns wil be removed entirely (An "invalid" pattern was
indeed generated elsewhere, see patch).
2012-10-18 Uros Bizjak
* config/i386/i386.md (ashift to lea splitter): Split to SImode mult.
(simple lea to add/shift peephole2s): Remove peephole2s that operate
on subregs of DImode operations.
(*mov_insv_1_rex64): Use gen_int_mode to truncate
const_int RTX to QImode value.
(*movsi_insv_1): Ditto.
The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to
test the patch on x32 before it is committed to mainline SVN.
[1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html
Uros.
Index: i386.md
===
--- i386.md (revision 192873)
+++ i386.md (working copy)
@@ -2704,7 +2704,8 @@
"TARGET_64BIT"
{
if (CONST_INT_P (operands[1]))
-operands[1] = simplify_gen_subreg (QImode, operands[1], mode, 0);
+operands[1] = gen_int_mode (INTVAL (operands[1]), QImode);
+
return "mov{b}\t{%b1, %h0|%h0, %b1}";
}
[(set_attr "type" "imov")
@@ -2718,7 +2719,8 @@
"!TARGET_64BIT"
{
if (CONST_INT_P (operands[1]))
-operands[1] = simplify_gen_subreg (QImode, operands[1], SImode, 0);
+operands[1] = gen_int_mode (INTVAL (operands[1]), QImode);
+
return "mov{b}\t{%b1, %h0|%h0, %b1}";
}
[(set_attr "type" "imov")
@@ -9600,10 +9602,10 @@
"TARGET_64BIT && reload_completed
&& true_regnum (operands[0]) != true_regnum (operands[1])"
[(set (match_dup 0)
- (zero_extend:DI (subreg:SI (mult:DI (match_dup 1) (match_dup 2)) 0)))]
+ (zero_extend:DI (mult:SI (match_dup 1) (match_dup 2]
{
- operands[1] = gen_lowpart (DImode, operands[1]);
- operands[2] = gen_int_mode (1 << INTVAL (operands[2]), DImode);
+ operands[1] = gen_lowpart (SImode, operands[1]);
+ operands[2] = gen_int_mode (1 << INTVAL (operands[2]), SImode);
})
;; This pattern can't accept a variable shift count, since shifts by
@@ -17366,7 +17368,7 @@
&& peep2_regno_dead_p (0, FLAGS_REG)"
[(parallel [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))
(clobber (reg:CC FLAGS_REG))])]
- "operands[2] = gen_lowpart (SImode, operands[2]);")
+ "gcc_unreachable ();")
(define_peephole2
[(set (match_operand:SI 0 "register_operand")
@@ -17377,7 +17379,7 @@
&& peep2_regno_dead_p (0, FLAGS_REG)"
[(parallel [(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))
(clobber (reg:CC FLAGS_REG))])]
- "operands[1] = gen_lowpart (SImode, operands[1]);")
+ "gcc_unreachable ();")
(define_peephole2
[(set (match_operand:DI 0 "register_operand")
@@ -17413,10 +17415,7 @@
[(parallel [(set (match_dup 0)
(zero_extend:DI (plus:SI (match_dup 2) (match_dup 1
(clobber (reg:CC FLAGS_REG))])]
-{
- operands[1] = gen_lowpart (SImode, operands[1]);
- operands[2] = gen_lowpart (SImode, operands[0]);
-})
+ "gcc_unreachable ();")
(define_peephole2
[(set (match_operand:DI 0 "register_operand")
@@ -17428,10 +17427,7 @@
[(parallel [(set (match_dup 0)
(zero_extend:DI (plus:SI (match_dup 2) (match_dup 1
(clobber (reg:CC FLAGS_REG))])]
-{
- operands[1] = gen_lowpart (SImode, operands[1]);
- operands[2] = gen_lowpart (SImode, operands[0]);
-})
+ "gcc_unreachable ();")
(define_peephole2
[(set (match_operand:SWI48 0 "register_operand")
@@ -17453,7 +17449,7 @@
&& peep2_regno_dead_p (0, FLAGS_REG)"
[(parallel [(set (match_dup 0) (ashift:SI (match_dup 0) (match_dup 2)))
(clobber (reg:CC FLAGS_REG))])]
- "operands[2] = GEN_INT (exact_log2 (INTVAL (operands[2])));")
+ "gcc_unreachable ();")
(define_peephole2
[(set (match_operand:DI 0 "register_operand")
@@ -17480,10 +17476,7 @@
[(parallel [(set (match_dup 0)
(zero_extend:DI (ashift:SI (match_dup 2) (match_dup 1
(clobber (reg:CC FLAGS_REG))])]
-{
- operands[1] = GEN_INT (exact_log2 (INTVAL (operands[1])));
- operands[2] = gen_lowpart (SImode, operands[0]);
-})
+ "gcc_unreachable ();")
;; The ESP adjustments can be done by the push and pop instructions. Resulting
;; code is shorter, since push is only 1 byte, while add imm, %esp is 3 bytes.
Re: unordered map design modification
On 10/26/2012 10:41 AM, Paolo Carlini wrote:
On 10/25/2012 10:15 PM, François Dumont wrote:
Here is the patch to apply the same modification applied to
unordered_set and unordered_multiset. It also use default
implementation for unordered_set/unordered_multiset copy/move
constructor/assignment operators.
Looks good to me, thanks! Before committing, please double check the
various comments vs the various observations Jon sent over the last time.
Thanks again,
Paolo.
Attached patch applied.
2012-10-27 François Dumont
* include/bits/unordered_map.h (unordered_map<>): Prefer
aggreagation to inheritance with _Hashtable.
(unordered_multimap<>): Likewise.
* include/bits/unordered_set.h
(unordered_set<>(const unordered_set&)): Use default
implementation.
(unordered_set<>(unordered_set&&)): Likewise.
(unordered_set<>::operator=(const unordered_set&)): Likewise.
(unordered_set<>::operator=(unordered_set&&)): Likewise.
(unordered_multiset<>(const unordered_multiset&)): Likewise.
(unordered_multiset<>(unordered_multiset&&)): Likewise.
(unordered_multiset<>::operator=(const unordered_multiset&)):
Likewise.
(unordered_multiset<>::operator=(unordered_multiset&&)): Likewise.
* include/debug/unordered_map (operator==): Adapt.
* include/profile/unordered_map (operator==): Adapt.
I think I did consider all Jonathan remarks which was mostly to use as
much as possible default implementations so benefit from noexcept
qualification.
François
Index: include/profile/unordered_map
===
--- include/profile/unordered_map (revision 192694)
+++ include/profile/unordered_map (working copy)
@@ -330,7 +330,7 @@
inline bool
operator==(const unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>& __x,
const unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>& __y)
-{ return __x._M_equal(__y); }
+{ return static_cast(__x) == __y; }
template
@@ -599,7 +599,7 @@
inline bool
operator==(const unordered_multimap<_Key, _Tp, _Hash, _Pred, _Alloc>& __x,
const unordered_multimap<_Key, _Tp, _Hash, _Pred, _Alloc>& __y)
-{ return __x._M_equal(__y); }
+{ return static_cast(__x) == __y; }
template
Index: include/debug/unordered_map
===
--- include/debug/unordered_map (revision 192694)
+++ include/debug/unordered_map (working copy)
@@ -482,7 +482,7 @@
inline bool
operator==(const unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>& __x,
const unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>& __y)
-{ return __x._M_equal(__y); }
+{ return __x._M_base() == __y._M_base(); }
template
@@ -929,7 +929,7 @@
inline bool
operator==(const unordered_multimap<_Key, _Tp, _Hash, _Pred, _Alloc>& __x,
const unordered_multimap<_Key, _Tp, _Hash, _Pred, _Alloc>& __y)
-{ return __x._M_equal(__y); }
+{ return __x._M_base() == __y._M_base(); }
template
Index: include/bits/unordered_map.h
===
--- include/bits/unordered_map.h (revision 192694)
+++ include/bits/unordered_map.h (working copy)
@@ -95,41 +95,654 @@
class _Pred = std::equal_to<_Key>,
class _Alloc = std::allocator > >
class unordered_map
-: public __umap_hashtable<_Key, _Tp, _Hash, _Pred, _Alloc>
{
- typedef __umap_hashtable<_Key, _Tp, _Hash, _Pred, _Alloc> _Base;
+ typedef __umap_hashtable<_Key, _Tp, _Hash, _Pred, _Alloc> _Hashtable;
+ _Hashtable _M_h;
public:
- typedef typename _Base::value_type value_type;
- typedef typename _Base::size_type size_type;
- typedef typename _Base::hasher hasher;
- typedef typename _Base::key_equal key_equal;
- typedef typename _Base::allocator_type allocator_type;
+ // typedefs:
+ //@{
+ /// Public typedefs.
+ typedef typename _Hashtable::key_type key_type;
+ typedef typename _Hashtable::value_type value_type;
+ typedef typename _Hashtable::mapped_type mapped_type;
+ typedef typename _Hashtable::hasher hasher;
+ typedef typename _Hashtable::key_equal key_equal;
+ typedef typename _Hashtable::allocator_type allocator_type;
+ //@}
+ //@{
+ /// Iterator-related typedefs.
+ typedef typename allocator_type::pointer pointer;
+ typedef typename allocator_type::const_pointer const_pointer;
+ typedef typename allocator_type::reference reference;
+ typedef typename allocator_type::const_reference const_reference;
+ typedef typename _Hashtable::iterator iterator;
+ typedef typename _Hashtable::const_iterator const_iterator;
+ typedef typename _Hashtable::local_iterator local_iterator;
+ typedef typename _Hashtable::const_local_iterator const_local_iterator;
+ typedef typename _Hashtable::size_type size_type;
+ ty
[SH, committed] PR 55042
Hello,
I've committed the obvious fix for PR 55042 as rev 192877.
Cheers,
Oleg
gcc/ChangeLog:
PR target/55042
* config/sh/sh.c (sh1_builtin_p): Comment out unused function.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 192482)
+++ gcc/config/sh/sh.c (working copy)
@@ -11587,11 +11587,14 @@
return TARGET_SHMEDIA;
}
+/* This function can be used if there are any built-ins that are not for
+ SHmedia. It's commented out to avoid the defined-but-unused warning.
static bool
sh1_builtin_p (void)
{
return TARGET_SH1;
}
+*/
/* describe number and signedness of arguments; arg[0] == result
(1: unsigned, 2: signed, 4: don't care, 8: pointer 0: no argument */
[Patch,AVR,applied]: Fix PR55034
http://gcc.gnu.org/viewcvs?view=revision&revision=192878 Applied as obvios. Johann PR target/55034 * config/avr/avr.c (avr_out_lpm): Remove unused regno_dest.
[wwwdocs,Java] Remove FAQ entry releated to 12 year old problem
I doubt this has been an FAQ in the last decade. :-) Applied. Gerald 2012-10-27 Gerald Pfeifer * faq.html (My program seems to hang): Remove. Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/faq.html,v retrieving revision 1.66 diff -u -3 -p -r1.66 faq.html --- faq.html21 Oct 2012 14:05:48 - 1.66 +++ faq.html27 Oct 2012 14:43:58 - @@ -66,7 +66,6 @@ How do I increase the runtime's initial and maximum heap sizes? How can I profile my application? -My program seems to hang and doesn't produce any output Programming Issues @@ -527,18 +526,6 @@ $ ../configure [...] - - 5.7 My program seems to hang and doesn't produce any output - - - Some versions had a bug in the iconv support. You can work around - it by setting LANG=en_US.UTF-8 at runtime, or give the - following option during compile time - -Dfile.encoding=UTF-8. This problem should no longer - occur as of November 1, 2000. - - - Programming Issues 6.1 Are there any examples of how to use CNI?
committed: Fix WORDS_BIG_ENDIAN use in lra-assign.c:find_hard_regno_for
Bootstrapped (c,c++) on i686-pc-linux-gnu.
Committed as obvious.
2012-10-27 Joern Rennecke
* lra-assigns.c (find_hard_regno_for): Fix use of WORDS_BIG_ENDIAN.
Index: lra-assigns.c
===
--- lra-assigns.c (revision 192878)
+++ lra-assigns.c (revision 192879)
@@ -571,15 +571,12 @@ find_hard_regno_for (int regno, int *cos
&& HARD_REGNO_MODE_OK (hard_regno, PSEUDO_REGNO_MODE (regno))
&& ! TEST_HARD_REG_BIT (impossible_start_hard_regs, hard_regno)
&& (nregs_diff == 0
-#ifdef WORDS_BIG_ENDIAN
- || (hard_regno - nregs_diff >= 0
- && TEST_HARD_REG_BIT (reg_class_contents[rclass],
- hard_regno - nregs_diff))
-#else
- || TEST_HARD_REG_BIT (reg_class_contents[rclass],
- hard_regno + nregs_diff)
-#endif
- ))
+ || (WORDS_BIG_ENDIAN
+ ? (hard_regno - nregs_diff >= 0
+&& TEST_HARD_REG_BIT (reg_class_contents[rclass],
+ hard_regno - nregs_diff))
+ : TEST_HARD_REG_BIT (reg_class_contents[rclass],
+ hard_regno + nregs_diff
{
if (hard_regno_costs_check[hard_regno]
!= curr_hard_regno_costs_check)
Re: [patch, fortran] PR 54833 Don't wrap calls to free(a) in if (a != NULL)
Thomas Koenig writes: > PR fortran/54833 > * trans.c (gfc_call_free): Do not wrap the > call to __builtin_free in check for NULL. > (gfc_deallocate_with_status): For automatic deallocation without > status for non-coarrays, don't wrap call to __builtin_free in > check for NULL. spawn /home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../gfortran -B/home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../ -B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/ /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90 -fno-diagnostics-show-caret -Os -pedantic-errors -B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -lm -o ./alloc_comp_assign_1.exe /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90: In function 'main': /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90:57:0: internal compiler error: in cselib_record_set, at cselib.c:2379 0x1029ac87 cselib_record_set ../../gcc/gcc/cselib.c:2379 0x1029ac87 cselib_record_sets ../../gcc/gcc/cselib.c:2596 0x1029b417 cselib_process_insn(rtx_def*) ../../gcc/gcc/cselib.c:2649 0x104ec9ab reload_cse_regs_1 ../../gcc/gcc/postreload.c:224 0x104ee1db reload_cse_regs ../../gcc/gcc/postreload.c:70 0x104ee1db rest_of_handle_postreload ../../gcc/gcc/postreload.c:2289 0x104ee1db rest_of_handle_postreload ../../gcc/gcc/postreload.c:2283 Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: PR c/53063 Handle Wformat with LangEnabledBy
On 19 October 2012 18:17, Joseph S. Myers wrote: > On Wed, 17 Oct 2012, Manuel López-Ibáñez wrote: > >> documentation but I can also implement -Wformat=0 being an alias for >> -Wno-format and -Wformat=1 an alias for -Wformat and simply reject >> -Wno-format=. > > I think that's what's wanted; -Wno-format= should be rejected, -Wformat= > should take an arbitrary integer level (of which at present all those > above 2 are equivalent to 2, just as -O for n > 3 is equivalent to > -O3). This patch implements exactly that. Bootstrapped and regression tested on x86_64-linux-gnu. OK? 2012-10-27 Manuel López-Ibáñez PR c/53063 gcc/ * doc/invoke.texi (Wformat): Update. c-family/ * c.opt (Wformat): Make it Alias Wformat=1. (Wformat-contains-nul,Wformat-extra-args,Wformat-nonliteral, Wformat-security,Wformat-y2k,Wformat-zero-length): Use LangEnabledBy. (Wformat=): RejectNegative. Use LangEnabledBy. (Wnonnull): Use LangEnabledBy. * c-opts.c (c_common_handle_option): Do not handle Wformat here. * c-format.c (decode_format_attr): Replace OPT_Wformat with OPT_Wformat_. (maybe_read_dollar_number): Likewise. (avoid_dollar_number): Likewise. (finish_dollar_format_checking): Likewise. (check_format_info): Likewise. (check_format_info_main): Likewise. (check_format_types): Likewise. (format_type_warning): Likewise. * c-common.c (int): Likewise. (check_function_sentinel): Likewise. * c-common.h (warn_format): Do not declare here. testsuite/ * gcc.dg/warn-nsstring.c: Use -Wformat explicitly. gcc/ * optc-gen.awk: Factor code out to... * opt-functions.awk (lang_enabled_by): ... this new function. wformat.diff Description: Binary data
PR c/53063 more LangEnabledBy conversions.
More mostly easy conversions to LangEnabledBy. Regtested on x86_64-linux-gnu. OK? 2012-10-27 Manuel López-Ibáñez PR c/53063 c-family/ * c.opt(Warray-bounds,Wdelete-non-virtual-dtor,Wenum-compare, Wmain,Woverlength-strings, Wunknown-pragmas,Wunused-macros): Use LangEnabledBy. (Wswitch,Wswitch-default,Wswitch-enum): Likewise. Move here from common.opt. (Wvariadic-macros): Init(1). * c-opts.c (c_common_handle_option): Do not handle them explicitly. (c_common_post_options): Likewise. (sanitize_cpp_opts): warn_unused_macros is now cpp_warn_unused_macros. (push_command_line_include): Likewise. * c-common.c (warn_unknown_pragmas): Do not define. * c-common.h (warn_unknown_pragmas): Do not declare. gcc/ * common.opt (Wswitch,Wswitch-default,Wswitch-enum): Move to c.opt. langenabledmore.diff Description: Binary data
Re: [patch, fortran] PR 54833 Don't wrap calls to free(a) in if (a != NULL)
Hi Andreas, Thomas Koenig writes: PR fortran/54833 * trans.c (gfc_call_free): Do not wrap the call to __builtin_free in check for NULL. (gfc_deallocate_with_status): For automatic deallocation without status for non-coarrays, don't wrap call to __builtin_free in check for NULL. spawn /home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../gfortran -B/home/andreas/src/gcc/m68k/gcc/testsuite/gfortran/../../ -B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/ /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90 -fno-diagnostics-show-caret -Os -pedantic-errors -B/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -L/home/andreas/src/gcc/m68k/m68k-linux/./libgfortran/.libs -lm -o ./alloc_comp_assign_1.exe /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90: In function 'main': /home/andreas/src/gcc/gcc/gcc/testsuite/gfortran.dg/alloc_comp_assign_1.f90:57:0: internal compiler error: in cselib_record_set, at cselib.c:2379 0x1029ac87 cselib_record_set ../../gcc/gcc/cselib.c:2379 Strange, this looks more like a bug that is exposed through the patch. I also don't see how such a change to the Fortran front end can result in something invalid in postreload. Does not happen on the architectures that I used, and I do not have access to that architecture. Does a (rougly) equivalent C case compile? Thomas
Re: [patch, fortran] PR 54833 Don't wrap calls to free(a) in if (a != NULL)
Thomas Koenig writes: > Does not happen on the architectures that I used, and I do not > have access to that architecture. A cross compiler is enough. > Does a (rougly) equivalent C case compile? How does a (rougly) equivalent C case look like? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [patch, fortran] PR 54833 Don't wrap calls to free(a) in if (a != NULL)
On Sat, Oct 27, 2012 at 7:41 PM, Andreas Schwab wrote: > How does a (rougly) equivalent C case look like? Usually something can be constructed from the -fdump-tree-gimple dump. Ciao! Steven
Re: [PATCH] Fix debug info for expr and jump stmt
On Sat, Oct 27, 2012 at 12:53 AM, Dehao Chen wrote:
> Hi,
>
> I've updated the patch:
>
> 1. abandon the changes in cfgexpand.c
> 2. set the block for trees when lowering gimple stmt.
> 3. add a unittest.
Index: gcc/gimple-low.c
===
--- gcc/gimple-low.c(revision 192809)
+++ gcc/gimple-low.c(working copy)
@@ -331,7 +331,18 @@ lower_omp_directive (gimple_stmt_iterator *gsi, st
gsi_next (gsi);
}
+/* Call back function to set the block for expr. */
+static tree
+tree_set_block_r (tree *tp, int *walk_subtrees ATTRIBUTE_UNUSED,
+ void *data)
+{
+ tree block = (tree) data;
+ if (CAN_HAVE_LOCATION_P (*tp))
+TREE_SET_BLOCK (*tp, block);
+ return NULL_TREE;
+}
+
/* Lower statement GSI. DATA is passed through the recursion. We try to
track the fallthruness of statements and get rid of unreachable return
statements in order to prevent the EH lowering pass from adding useless
@@ -343,8 +354,11 @@ static void
lower_stmt (gimple_stmt_iterator *gsi, struct lower_data *data)
{
gimple stmt = gsi_stmt (*gsi);
+ unsigned i;
gimple_set_block (stmt, data->block);
+ for (i = 0; i < gimple_num_ops (stmt); i++)
+walk_tree (gimple_op_ptr (stmt, i), tree_set_block_r, data->block, NULL);
switch (gimple_code (stmt))
{
why do you need this? The stmt location is taken from the operands and in fact
they may have more precise locations. So it seems completely pointless to me
(wasting location entries where a NULL block is just fine (take the block from
the stmt)).
So, what is the issue you try to fix? Yes, the stmt operands will
keep the BLOCK
live, but it is live if the frontend assigned it.
Richard.
> However, this patch will trigger two lto bug when asserting
> LTO_NO_PREVAIL for TREE_CHAIN. After debugging for a while, I found
> that the problem was also there even without the patch. This patch
> just reveal the problem by moving a decl into cache so that it will be
> checked. As I'm not familiar with LTO, not quite sure what the root
> problem is. Can anyone help take a look?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog:
> 2012-10-25 Dehao Chen
>
> * tree-eh.c (do_return_redirection): Set location for jump statement.
> (do_goto_redirection): Likewise.
> (frob_into_branch_around): Likewise.
> (lower_try_finally_nofallthru): Likewise.
> (lower_try_finally_copy): Likewise.
> (lower_try_finally_switch): Likewise.
> * gimple-low.c (tree_set_block_r): New callback function.
> (lower_stmt): Set block for tested expr.
>
> gcc/testsuite/ChangeLog:
> 2012-10-25 Dehao Chen
>
> * g++.dg/debug/dwarf2/block.C: New testcase.
Re: [PATCH] Fix debug info for expr and jump stmt
On Sat, Oct 27, 2012 at 11:07 AM, Richard Biener
wrote:
> On Sat, Oct 27, 2012 at 12:53 AM, Dehao Chen wrote:
>> Hi,
>>
>> I've updated the patch:
>>
>> 1. abandon the changes in cfgexpand.c
>> 2. set the block for trees when lowering gimple stmt.
>> 3. add a unittest.
>
> Index: gcc/gimple-low.c
> ===
> --- gcc/gimple-low.c(revision 192809)
> +++ gcc/gimple-low.c(working copy)
> @@ -331,7 +331,18 @@ lower_omp_directive (gimple_stmt_iterator *gsi, st
>gsi_next (gsi);
> }
>
> +/* Call back function to set the block for expr. */
>
> +static tree
> +tree_set_block_r (tree *tp, int *walk_subtrees ATTRIBUTE_UNUSED,
> + void *data)
> +{
> + tree block = (tree) data;
> + if (CAN_HAVE_LOCATION_P (*tp))
> +TREE_SET_BLOCK (*tp, block);
> + return NULL_TREE;
> +}
> +
> /* Lower statement GSI. DATA is passed through the recursion. We try to
> track the fallthruness of statements and get rid of unreachable return
> statements in order to prevent the EH lowering pass from adding useless
> @@ -343,8 +354,11 @@ static void
> lower_stmt (gimple_stmt_iterator *gsi, struct lower_data *data)
> {
>gimple stmt = gsi_stmt (*gsi);
> + unsigned i;
>
>gimple_set_block (stmt, data->block);
> + for (i = 0; i < gimple_num_ops (stmt); i++)
> +walk_tree (gimple_op_ptr (stmt, i), tree_set_block_r, data->block, NULL);
>
>switch (gimple_code (stmt))
> {
>
>
> why do you need this? The stmt location is taken from the operands and in
> fact
> they may have more precise locations. So it seems completely pointless to me
> (wasting location entries where a NULL block is just fine (take the block from
> the stmt)).
>
> So, what is the issue you try to fix? Yes, the stmt operands will
> keep the BLOCK
> live, but it is live if the frontend assigned it.
The issue I was trying to fix is that when expanding to rtl, the
operands's location is still gonna be used by set_curr_insn_location.
Thus we need to set the block info when we update the block info for
stmt. The unittest I added will have this problem.
Thanks,
Dehao
>
> Richard.
>
>> However, this patch will trigger two lto bug when asserting
>> LTO_NO_PREVAIL for TREE_CHAIN. After debugging for a while, I found
>> that the problem was also there even without the patch. This patch
>> just reveal the problem by moving a decl into cache so that it will be
>> checked. As I'm not familiar with LTO, not quite sure what the root
>> problem is. Can anyone help take a look?
>>
>> Thanks,
>> Dehao
>>
>> gcc/ChangeLog:
>> 2012-10-25 Dehao Chen
>>
>> * tree-eh.c (do_return_redirection): Set location for jump statement.
>> (do_goto_redirection): Likewise.
>> (frob_into_branch_around): Likewise.
>> (lower_try_finally_nofallthru): Likewise.
>> (lower_try_finally_copy): Likewise.
>> (lower_try_finally_switch): Likewise.
>> * gimple-low.c (tree_set_block_r): New callback function.
>> (lower_stmt): Set block for tested expr.
>>
>> gcc/testsuite/ChangeLog:
>> 2012-10-25 Dehao Chen
>>
>> * g++.dg/debug/dwarf2/block.C: New testcase.
Re: [patch, fortran] PR 54833 Don't wrap calls to free(a) in if (a != NULL)
Steven Bosscher writes: > On Sat, Oct 27, 2012 at 7:41 PM, Andreas Schwab wrote: >> How does a (rougly) equivalent C case look like? > > Usually something can be constructed from the -fdump-tree-gimple dump. Doesn't look like. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
[wwwdocs,Java] point java/done.html to sourceware.org
Applied, based an another reminder of these two no longer being synonymous. Gerald 2012-10-27 Gerald Pfeifer * done.html: Adjust URL for rhug. Index: done.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/done.html,v retrieving revision 1.50 diff -u -3 -p -r1.50 done.html --- done.html 29 Oct 2011 19:13:24 - 1.50 +++ done.html 27 Oct 2012 19:05:52 - @@ -162,7 +162,7 @@ -http://sources.redhat.com/rhug/";>rhug +http://sourceware.org/rhug/";>rhug Anthony Green and friends have set up rhug, a collection of free software Java packages set up to build with gcj. Both sources and RPMs are available.
Re: [wwwdocs,Java] point java/done.html to sourceware.org
On Sat, 27 Oct 2012, Gerald Pfeifer wrote: > 2012-10-27 Gerald Pfeifer > > * done.html: Adjust URL for rhug. And here is a fix for a long standing issue... Gerald Index: done.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/done.html,v retrieving revision 1.51 diff -u -3 -p -r1.51 done.html --- done.html 27 Oct 2012 19:07:04 - 1.51 +++ done.html 27 Oct 2012 19:33:06 - @@ -146,7 +146,7 @@ Fluid Dynamics - Alejandro Rodr?uez Gallego, at ICAI University (Spain) + Alejandro Rodríguez Gallego, at ICAI University (Spain) has spent two years developing a Java program to solve fluid dynamics. He says:
Re: [PR38711] Use DF_LIVE in IRA if it available (for -O2 and higher)
On Sat, Oct 13, 2012 at 11:12 PM, Vladimir Makarov wrote: > On 12-10-13 11:37 AM, Steven Bosscher wrote: >>> LIVE is not used on purpose. I added LIVE usage to the old RA about 10 >>> years ago (it was before DF-infrastructure). Everything was ok until, >>> somebody reported compiler crash on semantically wrong program (something >>> with usage of uninitialized variable). After that I removed this code. >> >> GCC was a completely different compiler 10 years ago. Handling of >> uninitialized variables is radically different since tree-ssa, and >> also the resource allocation side of the compiler has essentially been >> rewritten (by you :-). Whatever broke in the compiler 10 years ago may >> not be relevant anymore today. It looks like the problems still exist, the PRs keep coming in (PR55046, PR54961, PR54993, PR39607) with no obvious fixes. So I'm going to revert this patch. Ciao! Steven
Re: [PR38711] Use DF_LIVE in IRA if it available (for -O2 and higher)
On Sat, Oct 27, 2012 at 11:49 PM, Steven Bosscher wrote:
> So I'm going to revert this patch.
Or actually better, this lighter-weight patch. Will commit after the
usual testing.
* ira.c (ira): Remove DF_LIVE if the problem is in the stack.
(do_reload): Add it back at the end.
Index: ira.c
===
--- ira.c (revision 192878)
+++ ira.c (working copy)
@@ -4399,6 +4399,16 @@ ira (FILE *f)
setup_prohibited_mode_move_regs ();
df_note_add_problem ();
+
+ /* DF_LIVE can't be used in the register allocator, too many other
+ parts of the compiler depend on using the "classic" liveness
+ interpretation of the DF_LR problem. See PR38711.
+ Remove the problem, so that we don't spend time updating it in
+ any of the df_analyze() calls during IRA/LRA. */
+ if (optimize > 1)
+df_remove_problem (df_live);
+ gcc_checking_assert (df_live == NULL);
+
#ifdef ENABLE_CHECKING
df->changeable_flags |= DF_VERIFY_SCHEDULED;
#endif
@@ -4678,6 +4688,12 @@ do_reload (void)
df_scan_alloc (NULL);
df_scan_blocks ();
+ if (optimize > 1)
+{
+ df_live_add_problem ();
+ df_live_set_all_dirty ();
+}
+
if (optimize)
df_analyze ();
Re: [RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes
On Sat, Oct 27, 2012 at 5:12 AM, Uros Bizjak wrote:
> Hello!
>
> As suggested by Richard S. [1], after the patch that converts subreg:M
> (op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can
> remove several peephole2 patterns that handle subregs of PLUS, MINUS
> and MULT operators. I have attached RFC prototype patch that will
> trigger an ICE when to-be-removed pattern triggers, with the intention
> that these patterns wil be removed entirely (An "invalid" pattern was
> indeed generated elsewhere, see patch).
>
> 2012-10-18 Uros Bizjak
>
> * config/i386/i386.md (ashift to lea splitter): Split to SImode mult.
> (simple lea to add/shift peephole2s): Remove peephole2s that operate
> on subregs of DImode operations.
> (*mov_insv_1_rex64): Use gen_int_mode to truncate
> const_int RTX to QImode value.
> (*movsi_insv_1): Ditto.
>
> The patch was bootstrapped and regression tested on
> x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to
> test the patch on x32 before it is committed to mainline SVN.
>
> [1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html
>
> Uros.
I tested it on x32, ia32 and x86-64 with GCC testsuite and glibc.
There are no GCC regressions on x32. However, for glibc trunk,
on x32 and x86-64, I got
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ildoubl.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ldouble.out]
Error 1
On ia32, I got
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-fenv.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-ifloat.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-idouble.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-float.out]
Error 1
make[4]: ***
[/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-double.out]
Error 1
I am testing if they are caused by the change.
--
H.J.
Re: [RFC PATCH, i386]: Remove peephole2s for (subreg (operator (...)(...))) RTXes
On Sat, Oct 27, 2012 at 4:36 PM, H.J. Lu wrote:
> On Sat, Oct 27, 2012 at 5:12 AM, Uros Bizjak wrote:
>> Hello!
>>
>> As suggested by Richard S. [1], after the patch that converts subreg:M
>> (op:N (...)(...)) to op:M (subreg:M (...) subreg:M (...)), we can
>> remove several peephole2 patterns that handle subregs of PLUS, MINUS
>> and MULT operators. I have attached RFC prototype patch that will
>> trigger an ICE when to-be-removed pattern triggers, with the intention
>> that these patterns wil be removed entirely (An "invalid" pattern was
>> indeed generated elsewhere, see patch).
>>
>> 2012-10-18 Uros Bizjak
>>
>> * config/i386/i386.md (ashift to lea splitter): Split to SImode mult.
>> (simple lea to add/shift peephole2s): Remove peephole2s that operate
>> on subregs of DImode operations.
>> (*mov_insv_1_rex64): Use gen_int_mode to truncate
>> const_int RTX to QImode value.
>> (*movsi_insv_1): Ditto.
>>
>> The patch was bootstrapped and regression tested on
>> x86_64-pc-linux-gnu {,-m32} without problems, but I will ask H.J. to
>> test the patch on x32 before it is committed to mainline SVN.
>>
>> [1] http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01856.html
>>
>> Uros.
>
> I tested it on x32, ia32 and x86-64 with GCC testsuite and glibc.
> There are no GCC regressions on x32. However, for glibc trunk,
> on x32 and x86-64, I got
>
> make[4]: ***
> [/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ildoubl.out]
> Error 1
> make[4]: ***
> [/export/build/gnu/glibc-test/build-x86_64-linux/math/test-ldouble.out]
> Error 1
>
> On ia32, I got
>
> make[4]: ***
> [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-fenv.out]
> Error 1
> make[4]: ***
> [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-ifloat.out]
> Error 1
> make[4]: ***
> [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-idouble.out]
> Error 1
> make[4]: ***
> [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-float.out]
> Error 1
> make[4]: ***
> [/export/build/gnu/glibc-32bit-test/build-i686-linux/math/test-double.out]
> Error 1
>
> I am testing if they are caused by the change.
>
They are caused by this patch. I configure glibc with CFLAGS="-O3 -g"
--
H.J.
Ping / update: RFA: replace #ifdef with if/#if for HAVE_ATTR_*
With the lra branch merged, I had to update the patch, because of new uses of
HAVE_ATTTR_enabled. While looking at the conflicts, I also found that it
was often hard to tell if macros were used for performance reasons, or
just because there was no other interface available. lra itself is probably
one of the last files that we want to wean from tm.h, because it's use of
FIRST_PSEUDO_REGISTER, but some of the macros it uses in #ifdefs are used
in other files with much more tenous connections to tm.h. So, for these to
use, I added a few new piece-of-data members in the target structure.
bootstrapped in revision 192840 on i686-pc-linux-gnu.
tested iin revision 192840 with config.list.mk on i686-pc-linux-gnu.
2012-10-27 Joern Rennecke
* doc/md.texi (Defining Attributes): Document that we are defining
HAVE_ATTR_name macors as 1 for defined attributes, and as 0
for undefined special attributes.
* doc/tm.texi.in: Add @hook TARGET_HAVE_CC0.
* doc/tm.texi: Regenerate.
* final.c (asm_insn_count, align_fuzz): Always define.
(insn_current_reference_address): Likewise.
(init_insn_lengths): Use if (HAVE_ATTR_length) instead of
#ifdef HAVE_ATTR_length.
(get_attr_length_1, shorten_branches, final): Likewise.
(final_scan_insn, output_asm_name): Likewise.
* genattr.c (gen_attr): Define HAVE_ATTR_name macros for
defined attributes as 1.
Remove ancient get_attr_alternative compatibility code.
For special purpose attributes not provided, define HAVE_ATTR_name
as 0.
In case no length attribute is given, provide stub definitions
for insn_*_length* functions, and also include insn-addr.h.
In case no enabled attribute is given, provide stub definition.
* genattrtab.c (write_length_unit_log): Always write a definition.
* hooks.c (hook_int_rtx_1): New function.
* hooks.h (hook_int_rtx_1): Declare.
* lra-int.h (struct lra_insn_recog_data): Make member
alternative_enabled_p unconditional.
* lra.c (free_insn_recog_data): Use if (HAVE_ATTR_length) instead of
#ifdef HAVE_ATTR_length.
(lra_set_insn_recog_data): Likewise. Make initialization of
alternative_enabled_p unconditional.
(lra_update_insn_recog_data): Use #if instead of #ifdef for
HAVE_ATTR_enabled.
* recog.c [!HAVE_ATTR_enabled] (get_attr_enabled): Don't define.
(extract_insn): Check HAVE_ATTR_enabled.
(gate_handle_split_before_regstack): Use #if instead of
#if defined for HAVE_ATTR_length.
* gcc/target-def.h: Provide definitions for TARGET_HAVE_CC0,
TARGET_AUTO_INC_DEC, TARGET_STACK_REGS, TARGET_HAVE_ATTR_LENGTH
and TARGET_HAVE_ATTR_ENABLED.
* target.def (have_cc0, auto_inc_dec): New flags in target structure.
(stack_regs, have_attr_enabled, have_attr_length): Likewise.
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 192840)
+++ gcc/doc/md.texi (working copy)
@@ -7558,7 +7558,7 @@ (define_attr "type" "branch,fp,load,stor
the following lines will be written to the file @file{insn-attr.h}.
@smallexample
-#define HAVE_ATTR_type
+#define HAVE_ATTR_type 1
enum attr_type @{TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
TYPE_STORE, TYPE_ARITH@};
extern enum attr_type get_attr_type ();
@@ -7583,6 +7583,10 @@ extern enum attr_type get_attr_type ();
generation. @xref{Disable Insn Alternatives}.
@end table
+For each of these special attributes, the corresponding
+@samp{HAVE_ATTR_@var{name}} @samp{#define} is also written when the
+attribute is not defined; in that case, it is defined as @samp{0}.
+
@findex define_enum_attr
@anchor{define_enum_attr}
Another way of defining an attribute is to use:
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 192840)
+++ gcc/doc/tm.texi (working copy)
@@ -11333,3 +11333,11 @@ @deftypefn {Target Hook} {unsigned HOST_
@deftypevr {Target Hook} {unsigned char} TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
This value should be set if the result written by @code{atomic_test_and_set}
is not exactly 1, i.e. the @code{bool} @code{true}.
@end deftypevr
+
+@deftypevr {Target Hook} bool TARGET_HAVE_CC0
+@deftypevrx {Target Hook} {bool} TARGET_AUTO_INC_DEC
+@deftypevrx {Target Hook} {bool} TARGET_STACK_REGS
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_ENABLED
+@deftypevrx {Target Hook} {bool} TARGET_HAVE_ATTR_LENGTH
+These flags are automatically generated; you should not override them in tm.c:
+@end deftypevr
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in (revision 192840)
+++ gcc/doc/tm.texi.in (working copy)
@@ -11173,3 +11173,5 @@ @hook TARGET_MEMMODEL_CHECK
@end deftypefn
@hook TARGET_ATOMIC_TEST_AN
Re: [PATCH] Fix libbacktrace on 32-bit sparc
On Fri, Oct 26, 2012 at 9:27 PM, David Miller wrote:
>
> I'm getting a SIGBUS on every backtrace libbacktrace generates
> on 32-bit sparc builds. The crashes usually happen in
> add_function_range(), where 'p' is not 8-byte aligned.
>
> It seems that the vector code doesn't take care to align the pointers
> it returns. I cribbed the size alignment done in mmap.c's
> implementation of backtrace_alloc() to fix this.
Sorry about the problem, but I don't see how this can be the right
fix. A single vector will always be an array of the same struct, so I
don't see how any individual struct can be misaligned. It seems like
increasing the requested size is just going to consistently misalign
any struct that does not require 8 byte alignment, so later references
into the vector using an index will fail. Also backtrace_vector_grow
is based on top of backtrace_alloc, so again aligning the size
shouldn't matter.
The struct used by add_function_range is
struct function_addrs
{
uint64_t low;
uint64_t high;
struct function *function;
};
So on a 32-bit system, this should have a size of 20 if uint64_t
requires 4-byte alignment, but it should have a size of 24 if uint64_t
requires 8-byte alignment. It sounds like uint64_t requires 8-byte
alignment, so the size of this struct should be 24, so your patch
shouldn't change matters. Since your patch presumably works, it
sounds like sizeof (struct function_addrs) is returning 20, but that
does not make sense. It would mean that allocating an array of struct
function_addrs wouldn't work correctly.
So I don't know what is going on.
Ian
Re: [PATCH] Fix libbacktrace on 32-bit sparc
From: Ian Lance Taylor
Date: Sat, 27 Oct 2012 21:06:59 -0700
> The struct used by add_function_range is
>
> struct function_addrs
> {
> uint64_t low;
> uint64_t high;
> struct function *function;
> };
>
> So on a 32-bit system, this should have a size of 20 if uint64_t
> requires 4-byte alignment, but it should have a size of 24 if uint64_t
> requires 8-byte alignment. It sounds like uint64_t requires 8-byte
> alignment, so the size of this struct should be 24, so your patch
> shouldn't change matters. Since your patch presumably works, it
> sounds like sizeof (struct function_addrs) is returning 20, but that
> does not make sense. It would mean that allocating an array of struct
> function_addrs wouldn't work correctly.
>
> So I don't know what is going on.
The size is 24, and my patch definitely makes the crashes go away.
It seems like a vector is being used for a mixed set of objects.
I'll try to figure out how that is happening.
Re: [PATCH] Fix libbacktrace on 32-bit sparc
From: David Miller Date: Sun, 28 Oct 2012 00:31:27 -0400 (EDT) > The size is 24, and my patch definitely makes the crashes go away. > > It seems like a vector is being used for a mixed set of objects. > I'll try to figure out how that is happening. Ok, the problem seems to have to do with releases. The releases place vector memory chunks into a global pool. So a memory chunk from a vector used for one type of object, can be sucked into and used by another vector. But the alignment requirements are different, so we can obtain a chunk from the freelist that was being used for a vector of 4-byte aligned objects. The crash sequences are always of the form: vec_release(0xffb37ac8) base+size(0xf0199008) amount(312) ... vec_grow(0xffb37ac8:24) from 0x975168, ret=0xf01754cc [size(24):alc(360)] That size alignment done by backtrace_alloc() has no influence upon this issue. Since chunks are released from wherever the vector's allocation point was at the time of the release. In fact I bet that alignment in backtrace_alloc() never triggers when it is invoked from backtrace_vector_grow().
