Re: Ping: [PATCH] non-GNU C++ compilers
Committed. Thanks!
Re: PATCH RFA: New configure option --with-native-system-header-dir
+ yes|no) AC_MSG_ERROR([bad value ${withval} given for
--with-native-system-header-dir]) ;;
+ /*) ;;
+ *) AC_MSG_ERROR([--with-native-system-header-dir argument ${withval} must
be an absolute directory]) ;;
This doesn't handle DOS-style absolute paths (like c:/Users). Not
sure if we care about '\' separators but they probably should be
checked for too (if the user can figure out how to make those work
elsewhere, we shouldn't prevent it here).
Otherwise, I'm OK with the build-specific portions of the patch (and
the djgpp-specific ones).
Re: [ping 3] [patch] attribute to reverse bitfield allocations
Ping 3 ? I'd like to get this in before stage1 ends... There's RX-specific code that goes with it that can't go in until the core functionality is approved. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01800.html
Re: Include $(CFLAGS-$@) in ALL_CXXFLAGS
There are some gcc flags that are not legal g++ flags, though...
Re: Include $(CFLAGS-$@) in ALL_CXXFLAGS
Hmm... ok, I'm just a tad paranoid about using the name CFLAGS for g++, someone's bound to do the stupid thing eventually.
Re: RFC: [build, ada] Centralize PICFLAG configuration
Do I need to sync the config and libiberty parts to src manually or does this happen by some sort of magic? intl/; config.rhost; libiberty/; libiberty's part of include/ gcc: http://gcc.gnu.org Changes need to be done in tandem with the official GCC sources or submitted to the master file maintainer and brought in via a merge. Note: approved patches in gcc's libiberty or intl are automatically approved in this libiberty and intl also; feel free to merge them yourself if needed sooner than the next merge. Otherwise, changes are automatically merged, usually within a day.
[ping 2] [patch] attribute to reverse bitfield allocations
Ping 2 ? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
Re: [M32C] Hookize CLASS_MAX_NREGS
OK to install? * config/m32c/m32c.h (CLASS_MAX_NREGS): Remove macro. * config/m32c/m32c-protos.h (m32c_class_max_nregs): Remove. * config/m32c/m32c.c (m32c_class_max_nregs): Make static. Change regclass argument type to reg_class_t. Change 'max' and 'v' vars and return types to unsigned char. Use reg_class_contents instead of class_contents. (TARGET_CLASS_MAX_NREGS): Define. Ok.
Re: [M32C] Hookize PREFERRED_RELOAD_CLASS and PREFERRED_OUTPUT_RELOAD_CLASS
Ok.
Re: [backport] arm,rx: don't ICE on naked functions with local vars
Probably. Thanks for the leg-work. I'll approve the patch as-is. May I apply it to the 4.5 and 4.6 branches? The same patch applies as-is to both.
Re: [patch] attribute to reverse bitfield allocations
Seeing little opposition, I plod further... now with documentation and a test case. OK yet? Ping? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
Re: [patch] arm,rx: don't ICE on naked functions with local vars
Naked is related to TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS - ARM and RX set the latter based on the former, and nobody else uses that target hook. So, naked functions don't have stack slots for args. Without stack slots, args can't be assigned to memory locations - even if they're TREE_ADDRESSABLE.
Re: [patch] arm,rx: don't ICE on naked functions with local vars
Fails the same way with a parameter as with a local:
int result;
void __attribute__((naked)) ISRFunction(int x) {
result = subFunction(x);
}
but I'm certainly open to a better explanation of how a user program
can trigger an ICE that way.
Hmmm... the only use of targetm.calls.allocate_stack_slots_for_args()
is in use_register_for_decl() - which is used by expand_decl() for
automatic variables.
Maybe the hook should have been called allocate_stack_slots_for_decls() ?
Re: [patch] arm,rx: don't ICE on naked functions with local vars
Thanks! Committed.
Re: PR 45819 - possible fix?
So don't lie to GCC then? You specify
struct X { char c; int i; } __attribute__((packed)) x;
and expect that GCC knows x.i is aligned to 4 bytes!?
The actual header is much more complex than this trivial example.
It also fails with this example, where the port_status[] array *is*
obviously aligned, but the packed attribute *also* makes gcc think
the *structure* is misaligned, which is not the case:
struct ehci_regs {
char x;
short y;
char z;
unsigned int port_status[0];
} __attribute__ ((packed));
The line that fails is the next one:
return *(volatile unsigned int *)status_reg;
The user has explicitly told gcc that the pointer is a valid
pointer-to-int. How else can the user tell gcc it's wrong about
alignment? I mean, without changing zillions of released kernel
header files?
Or declare it a bug in volatile handling (which is, after all, not
very well defined)
I've been working on fixing volatile to mean do what I tell you
but historically, volatile has had lots of leeway in gcc.
and simply throw away any alignment information we have in that case
(which would make it an expander bug I guess, unless the arm target does
something special here).
Various targets choose to honor volatile over gcc's natural bitfield
access rules, and yes, we're doing it in the expander. Other volatile
access rules could be applied there too.
[patch] RX: don't renumber interrupt registers
If a function is both a leaf function and an interrupt function, leaf
register renumbering causes the wrong set of registers to be saved.
This patch disables renumbering for interrupt functions.
* config/rx/rx.c (rx_leaf_registers): New.
(rx_set_leaf_registers): New.
(rx_expand_prologue): Call it.
* config/rx/rx.h (LEAF_REGISTERS): Define.
(LEAF_REG_REMAP): Define.
Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c (revision 176766)
+++ gcc/config/rx/rx.c (working copy)
@@ -985,12 +985,24 @@ is_naked_func (const_tree decl)
{
return has_func_attr (decl, naked);
}
static bool use_fixed_regs = false;
+char rx_leaf_registers [FIRST_PSEUDO_REGISTER];
+
+static void
+rx_set_leaf_registers (int enable)
+{
+ int i;
+
+ if (rx_leaf_registers[0] != enable)
+for (i = 0; i FIRST_PSEUDO_REGISTER; i++)
+ rx_leaf_registers[i] = enable;
+}
+
static void
rx_conditional_register_usage (void)
{
static bool using_fixed_regs = false;
if (rx_small_data_limit 0)
@@ -1380,12 +1392,17 @@ rx_expand_prologue (void)
rtx insn;
/* Naked functions use their own, programmer provided prologues. */
if (is_naked_func (NULL_TREE))
return;
+ /* We must not allow register renaming in interrupt functions,
+ because that invalidates the correctness of the set of call-used
+ registers we're going to save/restore. */
+ rx_set_leaf_registers (is_interrupt_func (NULL_TREE) ? 0 : 1);
+
rx_get_stack_layout ( low, high, mask, frame_size, stack_size);
/* If we use any of the callee-saved registers, save them now. */
if (mask)
{
/* Push registers in reverse order. */
Index: gcc/config/rx/rx.h
===
--- gcc/config/rx/rx.h (revision 176766)
+++ gcc/config/rx/rx.h (working copy)
@@ -260,12 +260,17 @@ enum reg_class
/* Order of allocation of registers. */
#define REG_ALLOC_ORDER\
{ 7, 10, 11, 12, 13, 14, 4, 3, 2, 1, 9, 8, 6, 5, 15 \
}
+/* We must somehow disable register remapping for interrupt functions. */
+extern char rx_leaf_registers[];
+#define LEAF_REGISTERS rx_leaf_registers
+#define LEAF_REG_REMAP(REG) (REG)
+
#define REGNO_IN_RANGE(REGNO, MIN, MAX)\
(IN_RANGE ((REGNO), (MIN), (MAX))\
|| (reg_renumber != NULL\
reg_renumber[(REGNO)] = (MIN) \
reg_renumber[(REGNO)] = (MAX)))
[patch] arm,rx: don't ICE on naked functions with local vars
This patch tests for at least one user-caused reason for this
assertion failing - requiring a local frame in a naked function. For
this case at least, it would be better to trigger an error than to
ICE. OK?
static int bar;
void __attribute__((naked)) function(void) {
int foo, result;
result = subFunction(foo, bar); // ICE here
}
* expr.c (expand_expr_addr_expr_1): Detect a user request for
a local frame in a naked function, and produce a suitable
error for that specific case.
Index: expr.c
===
--- expr.c (revision 176766)
+++ expr.c (working copy)
@@ -6943,13 +6943,22 @@ expand_expr_addr_expr_1 (tree exp, rtx t
modifier == EXPAND_INITIALIZER
? EXPAND_INITIALIZER : EXPAND_CONST_ADDRESS);
/* If the DECL isn't in memory, then the DECL wasn't properly
marked TREE_ADDRESSABLE, which will be either a front-end
or a tree optimizer bug. */
- gcc_assert (MEM_P (result));
+
+ if (TREE_ADDRESSABLE (exp)
+ ! MEM_P (result)
+ ! targetm.calls.allocate_stack_slots_for_args())
+ {
+ error (local frame unavailable (naked function?));
+ return result;
+ }
+ else
+ gcc_assert (MEM_P (result));
result = XEXP (result, 0);
/* ??? Is this needed anymore? */
if (DECL_P (exp) !TREE_USED (exp) == 0)
{
assemble_external (exp);
Re: PR 45819 - possible fix?
Fact is that GCC knows that memory is not properly aligned. So in the impossibly rare case that gcc is *wrong*, how is the programmer supposed to tell gcc that? I mean, gcc 4.4 has been doing what the programmer wanted, and zillions of ARM devices have been happily working, and now you tell me they should have been segfaulting for the last N years. Surely there's a chance that the ARM developers know what they're talking about, and have been desperately trying to convince gcc to stop trying to second-guess them? I mean, what else should the user expect when they cast a random value to a volatile uint32_t * and derefence it? I would have expected gcc to preserve the load *exactly* as the user specified it, not convert that one load into FOUR loads.
Re: [M32C] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P
Ok.
Re: PR 45819 - possible fix?
I built an arm kernel with it, the USB stuff works. I take that back - booted the wrong kernel. Didn't work, but I'll confirm that I'm building with a patched gcc (too many kernels and compilers to keep track of ;)
Re: PR 45819 - possible fix?
Yeah, the testcase is invalid - that we lost the volatile was a bug, but you really have to fix the kernel. Sadly, that's not a helpful suggestion. How else should the kernel force a word-sized read? I thought volatile was the way to tell gcc do exactly what I tell you to do ? And the kernel does produce the right code at that particular spot now, but for some reason the usb module still doesn't work. We'll have to debug it some more. The same code works just fine with gcc 4.4.
Re: PR 45819 - possible fix?
I'm testing the following. Richard. 2011-07-22 Richard Guenther rguent...@suse.de PR tree-optimization/45819 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Properly preserve volatile and notrap flags. * gcc.dg/pr45819.c: New testcase. I built an arm kernel with it, the USB stuff works.
cp/cvt: don't assume pointer sizes
Some targets (m32c, tpf, mips) have more than one pointer size. It is
not correct to assume that a pointer is POINTER_SIZE.
Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c(revision 176554)
+++ gcc/cp/cvt.c(working copy)
@@ -217,15 +217,16 @@ cp_convert_to_pointer (tree type, tree e
error (invalid conversion from %qT to %qT, intype, type);
return error_mark_node;
}
if (INTEGRAL_CODE_P (form))
{
- if (TYPE_PRECISION (intype) == POINTER_SIZE)
+ int this_pointer_size = TYPE_PRECISION (type);
+ if (TYPE_PRECISION (intype) == this_pointer_size)
return build1 (CONVERT_EXPR, type, expr);
- expr = cp_convert (c_common_type_for_size (POINTER_SIZE, 0), expr);
+ expr = cp_convert (c_common_type_for_size (this_pointer_size, 0), expr);
/* Modes may be different but sizes should be the same. There
is supposed to be some integral type that is the same width
as a pointer. */
gcc_assert (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (expr)))
== GET_MODE_SIZE (TYPE_MODE (type)));
TPF tescase (default pointer and int are 64 bits):
typedef void * __attribute__ ((mode (SI))) __ptr32_t;
unsigned int foo;
__ptr32_t foo_addr;
int bar( )
{
foo_addr = (__ptr32_t)foo;
return 0;
}
[patch] attribute to reverse bitfield allocations
Seeing little opposition, I plod further... now with documentation
and a test case. OK yet?
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176586)
+++ doc/extend.texi (working copy)
@@ -5089,12 +5089,74 @@ Note that the type visibility is applied
associated with the class (vtable, typeinfo node, etc.). In
particular, if a class is thrown as an exception in one shared object
and caught in another, the class must have default visibility.
Otherwise the two shared objects will be unable to use the same
typeinfo node and exception handling will break.
+@item bit_order
+Normally, GCC allocates bitfields from either the least significant or
+most significant bit in the underlying type, such that bitfields
+happen to be allocated from lowest address to highest address.
+Specifically, big-endian targets allocate the MSB first, where
+little-endian targets allocate the LSB first. The @code{bit_order}
+attribute overrides this default, allowing you to force allocation to
+be MSB-first, LSB-first, or the opposite of whatever gcc defaults to. The
+@code{bit_order} attribute takes an optional argument:
+
+@table @code
+
+@item native
+This is the default, and also the mode when no argument is given. GCC
+allocates LSB-first on little endian targets, and MSB-first on big
+endian targets.
+
+@item swapped
+Bitfield allocation is the opposite of @code{native}.
+
+@item lsb
+Bits are allocated LSB-first.
+
+@item msb
+Bits are allocated MSB-first.
+
+@end table
+
+A short example demonstrates bitfield allocation:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ char a:3;
+ char b:3;
+@} foo = @{ 3, 5 @};
+@end example
+
+With LSB-first allocation, @code{foo.a} will be in the 3 least
+significant bits (mask 0x07) and @code{foo.b} will be in the next 3
+bits (mask 0x38). With MSB-first allocation, @code{foo.a} will be in
+the 3 most significant bits (mask 0xE0) and @code{foo.b} will be in
+the next 3 bits (mask 0x1C).
+
+Note that it is entirely up to the programmer to define bitfields that
+make sense when swapped. Consider:
+
+@example
+struct __attribute__((bit_order(msb))) @{
+ short a:7;
+ char b:6;
+@} foo = @{ 3, 5 @};
+@end example
+
+On some targets, or if the struct is @code{packed}, GCC may only use
+one byte of storage for A despite it being a @code{short} type.
+Swapping the bit order of A would cause it to overlap B. Worse, the
+bitfield for B may span bytes, so ``swapping'' would no longer be
+defined as there is no ``char'' to swap within. To avoid such
+problems, the programmer should either fully-define each underlying
+type, or ensure that their target's ABI allocates enough space for
+each underlying type regardless of how much of it is used.
+
@end table
@subsection ARM Type Attributes
On those ARM targets that support @code{dllimport} (such as Symbian
OS), you can use the @code{notshared} attribute to indicate that the
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 176586)
+++ c-family/c-common.c (working copy)
@@ -312,12 +312,13 @@ struct visibility_flags visibility_optio
static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
static tree check_case_value (tree);
static bool check_case_bounds (tree, tree, tree *, tree *);
static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
+static tree handle_bitorder_attribute (tree *, tree, tree, int, bool *);
static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
static tree handle_common_attribute (tree *, tree, tree, int, bool *);
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -589,12 +590,14 @@ const unsigned int num_c_common_reswords
const struct attribute_spec c_common_attribute_table[] =
{
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
affects_type_identity } */
{ packed, 0, 0, false, false, false,
handle_packed_attribute , false},
+ { bit_order, 0, 1, false, true, false,
+ handle_bitorder_attribute , false},
{ nocommon, 0, 0, true, false, false,
handle_nocommon_attribute, false},
{ common, 0, 0, true, false, false,
handle_common_attribute, false },
/* FIXME: logically, noreturn attributes should be listed as
false, true, true and apply to function types. But implementing this
@@ -5764,12 +5767,42 @@ handle_packed_attribute (tree *node, tre
*no_add_attrs = true;
}
return NULL_TREE;
}
+/* Handle a bit_order
PR 45819 - possible fix?
In this PR, a cast to a volatile type is lost during forwprop1, resulting in the wrong access semantics being used for a memory-mapped peripheral register. Checking for loss of volatile in this patch solves the problem, but I don't know if this is the right place to put such a test - it could go in tree-ssa-forwprop.c also, to be specific to this bug. Comments? Index: tree-ssa.c === --- tree-ssa.c (revision 176495) +++ tree-ssa.c (working copy) @@ -1274,12 +1274,18 @@ useless_type_conversion_p (tree outer_ty /* If the outer type is (void *), the conversion is not necessary. */ if (VOID_TYPE_P (TREE_TYPE (outer_type))) return true; } + /* Do not lose casts to volatile qualified types. */ + if ((TYPE_VOLATILE (outer_type) + != TYPE_VOLATILE (inner_type)) + TYPE_VOLATILE (outer_type)) +return false; + /* From now on qualifiers on value types do not matter. */ inner_type = TYPE_MAIN_VARIANT (inner_type); outer_type = TYPE_MAIN_VARIANT (outer_type); if (inner_type == outer_type) return true;
RFC: attribute to reverse bitfield allocations
Finally getting around to writing this one. The idea is to have an
attribute which determines how bitfields are allocated within words
(lsb-first vs msb-first), assuming the programmer doesn't ask us to do
something impossible. __attribute__((bitorder(FOO))) where FOO is:
native (or omitted, or no attribute): no swapping
lsb, msb: swap as needed to get the desired allocation order
swapped: always swap
First pass. Still missing: documentation, checks for overlapped
bitfields after swapping.
Is this approach acceptable? Note: the qsort is because the output
function requires fields to be in bit-index order, but you can't sort
them earlier or the constructors wouldn't match the fields.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 176083)
+++ c-family/c-common.c (working copy)
@@ -312,12 +312,13 @@ struct visibility_flags visibility_optio
static tree c_fully_fold_internal (tree expr, bool, bool *, bool *);
static tree check_case_value (tree);
static bool check_case_bounds (tree, tree, tree *, tree *);
static tree handle_packed_attribute (tree *, tree, tree, int, bool *);
+static tree handle_bitorder_attribute (tree *, tree, tree, int, bool *);
static tree handle_nocommon_attribute (tree *, tree, tree, int, bool *);
static tree handle_common_attribute (tree *, tree, tree, int, bool *);
static tree handle_noreturn_attribute (tree *, tree, tree, int, bool *);
static tree handle_hot_attribute (tree *, tree, tree, int, bool *);
static tree handle_cold_attribute (tree *, tree, tree, int, bool *);
static tree handle_noinline_attribute (tree *, tree, tree, int, bool *);
@@ -589,12 +590,14 @@ const unsigned int num_c_common_reswords
const struct attribute_spec c_common_attribute_table[] =
{
/* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
affects_type_identity } */
{ packed, 0, 0, false, false, false,
handle_packed_attribute , false},
+ { bitorder, 0, 1, false, true, false,
+ handle_bitorder_attribute , false},
{ nocommon, 0, 0, true, false, false,
handle_nocommon_attribute, false},
{ common, 0, 0, true, false, false,
handle_common_attribute, false },
/* FIXME: logically, noreturn attributes should be listed as
false, true, true and apply to function types. But implementing this
@@ -5764,12 +5767,42 @@ handle_packed_attribute (tree *node, tre
*no_add_attrs = true;
}
return NULL_TREE;
}
+/* Handle a bitorder attribute; arguments as in
+ struct attribute_spec.handler. */
+
+static tree
+handle_bitorder_attribute (tree *ARG_UNUSED (node), tree ARG_UNUSED (name),
+ tree ARG_UNUSED (args),
+ int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ tree bmode;
+ const char *bname;
+
+ /* Allow no arguments to mean native. */
+ if (args == NULL_TREE)
+return NULL_TREE;
+
+ bmode = TREE_VALUE (args);
+
+ bname = IDENTIFIER_POINTER (bmode);
+ if (strcmp (bname, msb)
+ strcmp (bname, lsb)
+ strcmp (bname, swapped)
+ strcmp (bname, native))
+{
+ error (%qE is not a valid bitorder - use lsb, msb, native, or swapped,
bmode);
+ *no_add_attrs = true;
+}
+
+ return NULL_TREE;
+}
+
/* Handle a nocommon attribute; arguments as in
struct attribute_spec.handler. */
static tree
handle_nocommon_attribute (tree *node, tree name,
tree ARG_UNUSED (args),
Index: stor-layout.c
===
--- stor-layout.c (revision 176083)
+++ stor-layout.c (working copy)
@@ -1716,24 +1716,82 @@ finalize_type_size (tree type)
TYPE_ALIGN (variant) = align;
TYPE_USER_ALIGN (variant) = user_align;
SET_TYPE_MODE (variant, mode);
}
}
}
+
+static void
+reverse_bitfield_layout (record_layout_info rli)
+{
+ tree field, oldtype;
+ for (field = TYPE_FIELDS (rli-t); field; field = TREE_CHAIN (field))
+{
+ tree type = TREE_TYPE (field);
+ if (TREE_CODE (field) != FIELD_DECL)
+ continue;
+ if (TREE_CODE (field) == ERROR_MARK || TREE_CODE (type) == ERROR_MARK)
+ return;
+ oldtype = TREE_TYPE (DECL_FIELD_BIT_OFFSET (field));
+ DECL_FIELD_BIT_OFFSET (field)
+ = size_binop (MINUS_EXPR,
+ size_binop (MINUS_EXPR, TYPE_SIZE (type),
+ DECL_SIZE (field)),
+ DECL_FIELD_BIT_OFFSET (field));
+ TREE_TYPE (DECL_FIELD_BIT_OFFSET (field)) = oldtype;
+}
+}
+
+static int
+reverse_bitfields_p (record_layout_info rli)
+{
+ tree st, arg;
+ const char *mode;
+
+ st = rli-t;
+
+ arg = lookup_attribute (bitorder, TYPE_ATTRIBUTES (st));
+
+ if (!arg)
+return
Re: Removing target-libiberty (was: Re: Libiberty: POSIXify psignal definition)
Ok for trunk? Ok with me. I'll let the branch maintainers decide if they want it for their branches.
Re: [RFA/libiberty] Darwin has case-insensitive filesystems
Looks OK to me.
Re: Libiberty: POSIXify psignal definition
Since you feel so strongly about it and nobody objects, go ahead. Backport to open branches? (And note PR48825.) I've already given my OK, it's up to the branch managers to apply as they see fit.
Re: Ping:Re: Skip building target libiberty for arm*-*-linux-androideabi
Ping. http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02208.html I don't have the bandwidth to work on the ideal patch. Thus I am wondering if we can skip target-libiberty for androideabi target before the ideal patch is out. Target-specific changes in the build are up to the target maintainers.
Re: [patch] testsuite: support board_info timeouts
I never got feedback from the testsuite maintainers on this one...
Date: Mon, 9 Aug 2010 23:48:31 -0400
From: DJ Delorie d...@redhat.com
Mailing-List: contact gcc-patches-h...@gcc.gnu.org; run by ezmlm
Is there any reason why we don't support board-level timeouts? It's
really hard to specify timeouts for sid-based embedded targets with
lots of multilibs (or just one, sometimes).
It's certainly better than really REALLY ugly which is the only
other option at that point.
* lib/timeout.exp (timeout): Add board_info support.
2010-08-09 Thomas Koenig tkoe...@gcc.gnu.org
Index: lib/timeout.exp
===
--- lib/timeout.exp (revision 163048)
+++ lib/timeout.exp (working copy)
@@ -43,12 +43,14 @@ proc timeout_value { args } {
if [info exists individual_timeout] {
set val $individual_timeout
} elseif [info exists tool_timeout] {
set val $tool_timeout
} elseif [target_info exists gcc,timeout] {
set val [target_info gcc,timeout]
+} elseif [board_info target exists gcc,timeout] {
+ set val [board_info target gcc,timeout]
} else {
# This is really, REALLY ugly, but this is the default from
# remote.exp deep within DejaGnu.
set val 300
}
Re: [patch] testsuite: support board_info timeouts
Thanks! Committed.
Re: [PATCH][RFC] Init sizetypes based on target defs
hmm, yes. Again practically for most targets size_t will be following its SIZE_TYPE advice, but surely not for all. OTOH while the above clearly doesn't look accidential, it certainly looks wrong. If not for sizetype then at least for size_type_node. The comment hints that the patch at most will no longer get better code, but if Pmode gets better code when used for sizetype(!) then we should do so unconditionally and could get rid of the size_t reverse-engineering in initialize_sizetypes completely (m32c might disagree here). On m32c, Pmode is a 24-bit type, and the chip just doesn't have enough math opcodes to to 24-bit pointer math with any degree of efficiency. So, you either do 32-bit math (performance is horrible, since it's all emulated) or 16-bit math on just the offset (sizeof size_t Pmode).
Re: [PATCH][RFC] Init sizetypes based on target defs
Which means that Ada must be seriously broken on m32c (well, I guess nobody tried it there ;)). I usually only build C and C++.
Re: Libiberty: POSIXify psignal definition
Yes please. I've been arguing for that for some time. Since you feel so strongly about it and nobody objects, go ahead. http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html http://gcc.gnu.org/ml/gcc/2010-03/msg2.html http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01231.html http://gcc.gnu.org/ml/gcc-bugs/2011-03/msg00206.html http://gcc.gnu.org/ml/gcc/2011-03/msg00465.html http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02304.html
Re: Unreviewed build patches
there's nothing that could affect them. Famous last words :-)
Re: Unreviewed build patches
[build] More --enable-threads cleanup http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00059.html This might well be obvious. Also, we usually leave those up to the target maintainers, since they're target specific. But if it's just a correlation between the script and a list of source file options, go for it. Besides, it would be helpful if a build maintainer could have a look at [build] Move Solaris 2 startup files to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00098.html either to state that I don't need approval or to make suggestings for improvements. This is not yet the final patch, but the remainder is tuning. We normally let target maintainers manage anything in the build that's target-specific. However, you've mixed in target patches with target-independent patches. I have no problem with you checking in your own target changes, but if you could split out the rest for review, it would make it easier on us. Also, mention if you tested it on any ix86 non-solaris platform (linux, bsd, etc).
Re: Libiberty: POSIXify psignal definition
And the problem is that libiberty is assuming that it *knows* what functions newlib provides, so that it doesn't need to check directly. This is just broken... Historically, cygwin was built using libiberty and newlib, so you did not have a runtime at the time you were building libiberty, because you hadn't built newlib yet. In a combined tree, target-libiberty is still built before target-newlib, so the problem exists there too. At this point, though, I'm tempted to say there's no such thing as a target libiberty and rip all the target-libiberty rules out, and let newlib-hosted targets autodetect the host-libiberty. That is, if Cygwin doesn't need a target-libiberty any more?
Re: Libiberty: POSIXify psignal definition
What about these?
dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
dependencies = { module=all-target-libobjc; on=all-target-libiberty; };
dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; };
Re: Libiberty: POSIXify psignal definition
* strsignal.c (psignal): Change second parameter to const char *. Fix comment accordingly. OK. I had argued against this patch: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html The newlib change broke ALL released versions of gcc, and the above patch does NOT fix the problem, but merely hides it until the next time we trip over it.
Re: Libiberty: POSIXify psignal definition
So regardless of whether the changes to newlib are a good idea or not, I think the fix to libiberty is still right. Irrelevent. I said I'd accept that change *after* the real problem is fixed. The real problem hasn't been fixed. The real problem is that libibery should NOT INCLUDE PSIGNAL AT ALL if newlib has it. What *should* have happened, is libiberty should have been fixed *first*, and newlib waited until a gcc/binutils release cycle happened, so that at least ONE version of those could build with newlib.
Re: Libiberty: POSIXify psignal definition
Thanks. I just have no check in rights to the gcc repository. I applied the change to the sourceware CVS repository but for gcc I need a proxy. Please, never apply libiberty patches only to src. They're likely to get deleted by the robomerge. The rule is: gcc only, or both at the same time.
Re: Libiberty: POSIXify psignal definition
What I don't understand is why the newlib change broke older compilers. Older compilers have the older libiberty. At the moment, libiberty cannot be built by *any* released gcc, because you cannot *build* any released gcc, because it cannot build its target libiberty. The function has been added to newlib and the definitions in newlib are correct. Correct is irrelevent. They don't match libiberty, so the build breaks. If this is refering to the fact that libiberty doesn't grok automatically if a symbol has been added to newlib, then that's a problem in libiberty, not in newlib. It's a problem in every released gcc at the moment, so no released gcc can be built for a newlib target, without hacking the sources. Otherwise, if you're building an older compiler, just use an older newlib as well. The only option here is to not release a newlib at all until a fixed gcc release happens, then, and require that fixed gcc for that version of newlib forward.
[4.6,trunk,rx] avoid LABEL_NUSES on barriers
Occasionally, gcc passes a barrier instead of a label. This
accomodates such an event. Applies to 4.6 and trunk, and needed on
both to build newlib. Ok?
* config/rx/rx.c (rx_align_for_label): Don't test for
LABEL_NUSES on a barrier.
Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c (revision 173669)
+++ gcc/config/rx/rx.c (working copy)
@@ -2755,13 +2755,13 @@ int
rx_align_for_label (rtx lab, int uses_threshold)
{
/* This is a simple heuristic to guess when an alignment would not be useful
because the delay due to the inserted NOPs would be greater than the delay
due to the misaligned branch. If uses_threshold is zero then the
alignment
is always useful. */
- if (LABEL_NUSES (lab) uses_threshold)
+ if (LABEL_P (lab) LABEL_NUSES (lab) uses_threshold)
return 0;
return optimize_size ? 1 : 3;
}
static int
[rx] simulated conditional exec
This adds a simulated conditional execution option to the RX backend.
The RX can do a short conditional forward branch faster than a regular
conditional branch (1 byte, 1 cycle!), as long as it's only branching
across one or two insns. This patch encourages this behavior via the
condexec support, and gives a 1% performance improvement. The patch
is against 4.6 but applies to trunk also. Ok?
* config/rx/rx.opt (mcondexec): New.
* config/rx/rx-protos.h (rx_condexec_prescan): Declare.
* config/rx/rx.md (predicable): New.
(define_cond_exec): New.
(define_asm_attributes): New.
(pop_and_return): Manually call rx_condexec_prescan()
(*movregister_modes:mode_internal): Likewise.
(extendsmall_int_modes:modesi2): Likewise.
(zero_extendsmall_int_modes:modesi2): Likewise.
(stack_pushm): Likewise.
(stack_popm): Likewise.
(*stcc): Likewise.
(*insv_imm): Likewise.
* config/rx/rx.c (TARGET_DEFAULT_TARGET_FLAGS): New.
(rx_print_operand): Add %b for a reversed conditional.
(rx_condexec_prescan): New.
(TARGET_ASM_FINAL_POSTSCAN_INSN): Define.
(rx_final_postscan): New.
Index: gcc/config/rx/rx-protos.h
===
--- gcc/config/rx/rx-protos.h (revision 173670)
+++ gcc/config/rx/rx-protos.h (working copy)
@@ -28,6 +28,7 @@
extern voidrx_expand_prologue (void);
extern int rx_initial_elimination_offset (int, int);
+extern voidrx_condexec_prescan (void);
#ifdef RTX_CODE
extern int rx_align_for_label (rtx, int);
Index: gcc/config/rx/rx.md
===
--- gcc/config/rx/rx.md (revision 173670)
+++ gcc/config/rx/rx.md (working copy)
@@ -135,6 +135,21 @@
;;
+(define_attr predicable no,yes (const_string yes))
+
+(define_cond_exec
+ [(match_operator 0 comparison_operator
+ [(reg CC_REG) (const_int 0)])]
+ TARGET_CONDEXEC
+ b%b0 1f !
+ )
+
+(define_asm_attributes
+ [(set_attr predicable no)]
+ )
+
+;;
+
;; Comparisons
;; Note - we do not specify the two instructions necessary to perform
@@ -364,6 +379,7 @@
(return)]
reload_completed
{
+rx_condexec_prescan ();
rx_emit_stack_popm (operands, false);
return ;
}
@@ -567,7 +583,9 @@
(match_operand:register_modes
1 general_operand
Int08,Sint16,Sint24,i,r,m,r,Int08,Sint16,Sint24,i))]
- { return rx_gen_move_template (operands, false); }
+ {
+rx_condexec_prescan ();
+return rx_gen_move_template (operands, false); }
[(set_attr length 3,4,5,6,2,4,6,5,6,7,8)
(set_attr timings 11,11,11,11,11,12,11,11,11,11,11)]
)
@@ -577,7 +595,8 @@
(sign_extend:SI (match_operand:small_int_modes
1 nonimmediate_operand r,m)))]
- { return rx_gen_move_template (operands, false); }
+ { rx_condexec_prescan ();
+return rx_gen_move_template (operands, false); }
[(set_attr length 2,6)
(set_attr timings 11,12)]
)
@@ -587,7 +606,8 @@
(zero_extend:SI (match_operand:small_int_modes
1 nonimmediate_operand r,m)))]
- { return rx_gen_move_template (operands, true); }
+ { rx_condexec_prescan ();
+return rx_gen_move_template (operands, true); }
[(set_attr length 2,4)
(set_attr timings 11,12)]
)
@@ -610,6 +630,7 @@
(match_operand:SI 0 const_int_operand n)))])]
reload_completed
{
+rx_condexec_prescan ();
rx_emit_stack_pushm (operands);
return ;
}
@@ -636,6 +657,7 @@
(match_operand:SI 0 const_int_operand n)))])]
reload_completed
{
+rx_condexec_prescan ();
rx_emit_stack_popm (operands, true);
return ;
}
@@ -770,6 +792,7 @@
(match_dup 0)))]
reload_completed
{
+ rx_condexec_prescan ();
if (GET_CODE (operands[2]) == EQ)
return stz\t%1, %0;
else
@@ -1833,6 +1856,7 @@
(match_operand:SI 2 const_int_operand ))]
{
+ rx_condexec_prescan ();
if (INTVAL (operands[2]) 1)
return bset\t%1, %0;
else
Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c (revision 173670)
+++ gcc/config/rx/rx.c (working copy)
@@ -385,6 +385,7 @@
%A Print an operand without a leading # character.
%B Print an integer comparison name.
+ %b Print an integer comparison name, reversed.
%C Print a control register name.
%F Print a condition code flag name.
%H Print high part of a DImode register, integer or address.
@@ -499,7 +500,85 @@
fputs (ret, file);
break;
}
+case 'b':
+ {
+ enum rtx_code code = GET_CODE (op);
+ enum
Re: [PING] config/mep/mep.c: don't translate syntax description.
OK to check in? Ok with me. Thanks! 2011-05-06 Philipp Thomas p...@suse.de * config/mep/mep.c (mep_validate_vliw): Syntax description should not be translated.
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
I don't know how to avoid this problem in configure, other than by adding AC_LIBOBJ([psignal]). Right, the correct solution is - libiberty shouldn't provide psignal if newlib does. Making it match newlib is the wrong solution.
Re: newlib vs. libiberty mismatch breaks build (Re: [PATCH] Export psignal on all platforms)
You don't mean the prototype, do you? IMHO the char * should still be changed to const char * to adhere to POSIX. So far, it's served as a good tool for detecting when libiberty's configure isn't doing its job :-) At this point, we should avoid fixing it until the newlib/configure issue is fixed, otherwise the problem will get hidden away again. If, after that, you want to posixify libiberty some more, we'll worry about it then.
Re: [PATCH] use build_function_type_list in the mep backend
* config/mep/mep.c (mep_init_builtins): Call build_function_type_list instead of build_function_type. Ok.
Re: Ping^2 Re: Target header etc. cleanup patch
The m32c one is OK
Re: mt-mep using EXTRA_TARGET_HOST_ALL_MODULES?
There's a top-level utils/ subdir in some trees. Yes, MeP has a tool there.
Re: RX: 4.5 branch: Fix alignment and addressing issues.
What is length used for in the rx port? We have a local patch that uses the length to decide if/when to align labels; it goes along with the label alignment change I made a while back. However, the patch works best in 4.5 (align patch not backported) and there are other optimization problems with 4.6 that make the alignment not work as well as it should. The RX incurs a one-cycle penalty if you branch to an insn that spans a fetch line. So, we want to align by adding no more than N-1 bytes for an N-byte insn. A 3-byte insn will only be aligned if doing so adds 1 or 2 bytes; if 3 bytes are needed, the insn does not span a fetch line.
Re: 4.5 backport request...
I don't think this is suitable for the branch. Any reason why you can't work on the trunk? The vendor's release is 4.5 based, and 4.6 has some performance regressions with this chip. We'd like to sync up the FSF sources with the minor patches the vendor is using, so that their customers can take advantage of other 4.5-based bug fixes in the FSF tree. Note that no target actually uses these macros at the moment.
Re: [4.7] Avoid global state in mep_handle_option
Tested building cc1 and xgcc for cross to mep-elf. Will commit to trunk for 4.7 in the absence of target maintainer objections. No objections from me.
Re: [PATCH] avoid memory overrun in a test leading to potential double-free
avoid memory overrun in a test leading to potential double-free * testsuite/test-expandargv.c (writeout_test): Fix off-by-one error: i.e., do copy the trailing NUL byte. Ok. Thanks!
Re: [patch libiberty include]: Add additional helper functions for directory-separator searching
I think we don't need filename_dirchr, only filename_dirrchr. I see no harm in having both, for completeness, though. One could argue they should be in separate files, but they're trivial functions on non-dos-fs systems. What bothers me about this patch is that we're adding yet another set of functions that don't discriminate between the host filesystem, the target filesystem, and the build filesystem.
Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun
I was just wondering whether now would be a good time to mention Probably not, gcc being in stage 4 and all...
Re: [4.7] Avoid global state in m32c_handle_option
Tested building cc1 and xgcc for cross to m32c-elf. Will commit to trunk for 4.7 in the absence of target maintainer objections. Go for it :-)
