Re: [PATCH 1/6] Thread pointer built-in functions, core parts
On 2012/7/13 09:28 AM, Mike Stump wrote: On Jul 11, 2012, at 11:52 PM, Chung-Lin Tang wrote: Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only implement one of them (thread pointer read). sorry seems a little overly dramatic. I would have thought that error would be enough, I'll change to use error() instead. and then for the return value, maybe a const0_rtx for Pmode. A little unsure what you mean. Are you referring to return const0_rtx for default_expand_builtin_thread_pointer() instead of NULL? Thanks, Chung-Lin
Re: Fix PR53908
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
if (RTL_CONST_OR_PURE_CALL_P (insn))
/* Pure functions can read from memory. Const functions can
read from arguments that the ABI has forced onto the stack.
Neither sort of read can be volatile. */
memrefs_in_across |= MEMREF_NORMAL;
else
{
memrefs_in_across |= MEMREF_VOLATILE;
mem_sets_in_across |= MEMREF_VOLATILE;
}
}
OK with that change if you agree.
(Steven or Bernd, please ACK/NAK, for quick resolution.)
I've tested this version for trunk; no regressions for revision
189439 on x86_64-unknown-linux-gnu (N.B. the test-case doesn't
trigger on trunk). I've also tested Steven's earlier version,
same results, if you change your mind. :)
It'll be another 6:21 hours(!) before results from the 4.7
branch.
brgds, H-P
Re: [PATCH 1/6] Thread pointer built-in functions, core parts
On 2012/7/13 02:37 AM, Richard Sandiford wrote:
+void
+default_expand_builtin_set_thread_pointer (rtx val ATTRIBUTE_UNUSED)
+{
+ sorry (__builtin_set_thread_pointer() not available for this target);
+}
Function names should be quoted by % %. But maybe we can save the
translators some work and use:
sorry (%qs is not available for this target,
__builtin_thread_pointer());
...
sorry (%qs is not available for this target,
__builtin_set_thread_pointer());
Seeing default_expand_builtin_saveregs() as a current example, using %qs
sort of diverges from the style, though I'm not sure if that should be
changed too...personally I think unquoted looks cleaner :)
Another small detail, should '()' be included with the function name in
the diagnostic message?
Thanks,
Chung-Lin
Re: [PATCH 6/6] Thread pointer built-in functions, mips
On 2012/7/13 02:45 AM, Richard Sandiford wrote:
/* Implement TARGET_EXPAND_BUILTIN_THREAD_POINTER. */
static rtx
mips_expand_builtin_thread_pointer (rtx tp)
{
rtx fn;
if (TARGET_MIPS16)
...
}
(i.e. always using the passed-in tp, which is safe with your 1/6 patch),
then change mips_get_tp as follows:
/* Return a pseudo register that contains the current thread pointer. */
static rtx
mips_get_tp (void)
{
return mips_expand_builtin_thread_pointer (gen_reg_rtx (Pmode));
}
OK with that change, thanks.
Richard
Thanks! This looks prettier :)
I'll change to this form before applying.
Chung-Lin
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote: I'd suggest: 1. Remove this unittest for now. And revert the patch for now. 2. Integrate locus with block, and store them as an index. (This will incur big operation to GCC) I'm not sure what you mean with integrate...? A lot of the code you'll need already exists in emit-rtl.c. That code should be split out to a new file and be shared between rtl and gimple. You'll probably want to make block_locators_locs, block_locators_blocks, and locations_locators_locs part of struct function. The biggest challenges will be avoiding bloat and managing the locators for inlining/cloning... Ciao! Steven
Re: Fix PR53908
On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
if (RTL_CONST_OR_PURE_CALL_P (insn))
/* Pure functions can read from memory. Const functions can
read from arguments that the ABI has forced onto the stack.
Neither sort of read can be volatile. */
memrefs_in_across |= MEMREF_NORMAL;
else
{
memrefs_in_across |= MEMREF_VOLATILE;
mem_sets_in_across |= MEMREF_VOLATILE;
}
}
OK with that change if you agree.
(Steven or Bernd, please ACK/NAK, for quick resolution.)
I can't ACK, but I think Richard S.'s fix is correct.
Ciao!
Steven
Re: [RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin
On 11 Jul 2012, at 00:01, Iain Sandoe wrote: Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed patch causes no regressions. ppc-darwin 8 tests are still running, but it bootstrapped (500M G4, 24hrs for c/c++ build test). FAOD, from a testing perspective this is fine - but it needs Mike's OK, cheers Iain
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote: I'd suggest: 1. Remove this unittest for now. And revert the patch for now. 2. Integrate locus with block, and store them as an index. (This will incur big operation to GCC) I'm not sure what you mean with integrate...? A lot of the code you'll need already exists in emit-rtl.c. That code should be split out to a new file and be shared between rtl and gimple. You'll probably want to make block_locators_locs, block_locators_blocks, and locations_locators_locs part of struct function. The biggest challenges will be avoiding bloat and managing the locators for inlining/cloning... Btw, we discussed this briefly on the summit with Dodji and libcpp virtual locations already provide a way to associate a location_t with something else resulting in a new location_t. For inlining we simply have to say that the location_t's we use would always refer to the original BLOCK (thus, the abstract origin). There is no point to update the BLOCKs to point to the copies as far as debug information is concerned (?). Richard. Ciao! Steven
Re: Fix PR53908
On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
if (RTL_CONST_OR_PURE_CALL_P (insn))
/* Pure functions can read from memory. Const functions can
read from arguments that the ABI has forced onto the stack.
Neither sort of read can be volatile. */
memrefs_in_across |= MEMREF_NORMAL;
else
{
memrefs_in_across |= MEMREF_VOLATILE;
mem_sets_in_across |= MEMREF_VOLATILE;
}
}
OK with that change if you agree.
(Steven or Bernd, please ACK/NAK, for quick resolution.)
I can't ACK, but I think Richard S.'s fix is correct.
I agree, so, ok for trunk if it passes bootstrap testing.
Thanks,
Richard.
Ciao!
Steven
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 9:36 AM, Richard Guenther richard.guent...@gmail.com wrote: Btw, we discussed this briefly on the summit with Dodji and libcpp virtual locations already provide a way to associate a location_t with something else resulting in a new location_t. For inlining we simply have to say that the location_t's we use would always refer to the original BLOCK (thus, the abstract origin). There is no point to update the BLOCKs to point to the copies as far as debug information is concerned (?). That may work for DWARF, but what about other debug formats? Ciao! Steven
Re: [Patch, Fortran] Add parsing support for assumed-rank array
Hi Mikael, dear all,
On 07/05/2012 03:51 PM, Mikael Morin wrote:
I think the assumed-rank = rank == -1 convention should be
documented in gfortran.h, at least for the gfc_array_spec::rank field.
Okay. (Done in my version, which is not yet attached.)
@@ -2990,6 +3008,15 @@ gfc_procedure_use (gfc_symbol *sym,
gfc_actual_arglist **ap, + /* TS 29113, C407b. */
+ if (a-expr a-expr-expr_type == EXPR_VARIABLE
+ symbol_rank (a-expr-symtree-n.sym) == -1)
+ gfc_error (Assumed-rank argument requires an explicit
interface
+ at %L, a-expr-where);
Doesn't this duplicates the other explicit interface diagnostic below...
@@ -2194,6 +2206,15 @@ resolve_global_procedure (gfc_symbol *sym,
locus *where,
+/* TS 29113, 6.2. */
+else if (arg-sym arg-sym-as
+ arg-sym-as-type == AS_ASSUMED_RANK)
+gfc_error (Procedure '%s' at %L with assumed-rank dummy
+ argument '%s' must have an explicit interface,
+ sym-name, sym-declared_at, arg-sym-name);
No, they are different. Example:
! resolve_global_procedure:
! From the global symbol information, one knows in foo
! that the dummy argument of bar is an assumed-rank array
!
! (the actual argument has no assumed rank)
!
! This check is weak as it only works if both procedures
! are in the same translation unit.
!--
subroutine foo
integer :: x
call bar(x) ! ERROR HERE
end subroutine foo
subroutine bar(y)
integer :: y(..)
end subroutine bar
! gfc_procedure_use:
! The actual argument is assumed rank. Then the dummy argument
! has to be assumed-rank, which requires that the interface must
! be explicit.
!
! Hence, that's a constraint check which has and can be diagnosed
! at compile time. (C407b)
!-
subroutine foobar(z)
integer :: z(..)
call sub(z) ! ERROR here
end subroutine foobar
!-
@@ -5067,13 +5097,26 @@ resolve_variable (gfc_expr *e)
/* TS 29113, 407b. */
- if (e-ts.type == BT_ASSUMED !assumed_type_expr_allowed)
+ if (e-ts.type == BT_ASSUMED !assumed_rank_type_expr_allowed)
{
gfc_error (Invalid expression with assumed-type variable %s
at %L,
sym-name, e-where);
return FAILURE;
}
I'm not sure I understand the logic with the mixed assumed rank/type
flag. According to C407c, shouldn't we check that e is assumed rank/shape?
No, that check is not for assumed-rank arrays but for (e.g. scalar)
assumed type, TYPE(*). The check handles cases like:
type(*) :: x
print *, ubound(array, dim=x)
where x is not allowed, contrary to, e.g.,
type(*) :: x(:)
print *, ubound(x)
Thus, one needs to keep track whether x is allowed or is not allowed
in an expression. As that's the same for assumed type and for assumed
rank, I am using the same tracking variable, called
assumed_rank_type_expr_allowed. A better name would be:
assumed_rank_or_assumed_type_expr_allowed (or s/or/and/), however, I
found my version clear enough and while it is already long, that variant
would be even longer.
+ /* TS 29113, C535b. */
+ if (((sym-ts.type == BT_CLASS sym-attr.class_ok
+ CLASS_DATA (sym)-as
+ CLASS_DATA (sym)-as-type == AS_ASSUMED_RANK)
+ || (sym-ts.type != BT_CLASS sym-as
+sym-as-type == AS_ASSUMED_RANK))
+ !assumed_rank_type_expr_allowed)
+{
+ gfc_error (Invalid expression with assumed-rank variable %s
at %L,
+ sym-name, e-where);
The error message could be made more helpful. ;-)
Suggestions welcome. Example use would be:
x = x +1
call foo(x+1)
call sin(x) ! Though that probably triggers elsewhere
I don't think the wording is that bad.
@@ -5084,6 +5127,22 @@ resolve_variable (gfc_expr *e)
return FAILURE;
}
+ /* TS 29113, C535b. */
+ if (((sym-ts.type == BT_CLASS sym-attr.class_ok
+ CLASS_DATA (sym)-as
+ CLASS_DATA (sym)-as-type == AS_ASSUMED_RANK)
+ || (sym-ts.type != BT_CLASS sym-as
+sym-as-type == AS_ASSUMED_RANK))
+ e-ref
+ !(e-ref-type == REF_ARRAY e-ref-u.ar.type == AR_FULL
+e-ref-next == NULL))
+{
+ gfc_error (Assumed-rank variable %s with designator at %L,
+ sym-name, e-ref-u.ar.where);
Ditto here. And I think that C535b is more about the context of the
expression rather than the expression itself.
Here, I am lost. The check is that
ubound(x(:))
call bar (x(1))
call bar2(x([1,3,5])
call bar3(x(1:5:2))
or similar does not occur if x is assumed rank. That (:) is an
(array) designator. Do you have a better suggestion? I could add the
word array before designator, but I would like to avoid to list all
possible combinations.
From TS29113:
C407b An assumed-type variable name shall not appear in a designator or
...
From Fortran 2008:
1.3.59 designator
name followed by zero or more component selectors, complex part
selectors, array section selectors, array element
Re: [PATCH 1/6] Thread pointer built-in functions, core parts
Richard Sandiford rsand...@nildram.co.uk writes: Function names should be quoted by % %. But maybe we can save the translators some work and use: sorry (%qs is not available for this target, __builtin_thread_pointer()); ... sorry (%qs is not available for this target, __builtin_set_thread_pointer()); instead. I'm no expert on the diagnostic stuff though. The function name should not be followed by parens. 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: new sign/zero extension elimination pass
On 12/07/12 14:04, Kenneth Zadeck wrote: you are on the right track with the example but combine will not get this unless everything is in the same bb. the whole point of having a separate pass for doing extension elimination is that it needs to be done over the entire function. There is a pass_ree, which does inter-bb combine targeted at extensions. However, that pass is currently limited to combining extensions with the definitions of the register it extends. The way your example sounds, you want the reverse, where extensions are combined with all their uses. I would say pass_ree is the natural place to add this and handle the example you describe. Thanks, - Tom my example is also a little more complex because, since we are talking about induction vars, you have an initial assignment outside of a loop, and increment inside the loop and the test you describe at the bottom of the loop. I would point out that with respect to speed optimizations, the case i am describing is in fact very important because getting code out of loops is were the important gains are. I believe that the ppc has a some significant performance issues because of this kind of thing. kenny On 07/12/2012 05:20 AM, Tom de Vries wrote: On 12/07/12 11:05, Tom de Vries wrote: On 12/07/12 03:39, Kenneth Zadeck wrote: Tom, I have a problem with the approach that you have taken here. I believe that this could be a very useful addition to gcc so I am in general very supportive, but i think you are missing an important case. My problem is that it the pass does not actually look at the target and make any decisions based on that target. for instance, we have a llp64 target. As with many targets, the target has a rich set of compare and branch instructions. In particular, it can do both 32 and 64 bit comparisons.We see that many of the upstream optimizations that take int (SI mode) index variables generate extension operations before doing 64 bit compare and branch instructions, even though there are 32 bit comparison and branches on the machine. There are a lot of machines that can do more than one size of comparison. This optimization pass, as it is currently written will not remove those extensions because it believes that the length of the destination is the final answer unless it is wrapped in an explicit truncation. Instead it needs to ask the port if there is a shorted compare and branch instruction that does not cost more. in that case, those instructions should be rewritten to use the shorted compare and branch. There are many operations other than compare and branch where the pass should be asking can i shorten the target for free and therefore get rid of the extension? Kenneth, I'm not sure I understand the optimization you're talking about, in particular I'm confused about whether the branch range of the 32-bit and 64-bit comparison is the same. Assuming it's the same, my understanding is that you're talking about an example like this: ... (insn (set (reg:DI 5) (zero_extend:DI (reg:SI 4 (jump_insn (set (pc) (if_then_else (eq (reg:DI 5) (const_int 0)) (label_ref:DI 62) (pc - (jump_insn (set (pc) (if_then_else (eq (reg:SI 4) (const_int 0)) (label_ref:DI 62) (pc ... I would expect combine to optimize this. In case I got the example all backwards or it is a too simple one, please provide an rtl example that illustrates the optimization. Thanks, - Tom right shifts, rotates, and stores are not in this class, but left shifts are as are all comparisons, compare and branches, conditional moves. There may even be machines that have this for divide, but i do not know of any off the top of my head. What i am suggesting moves this pass into the target specific set of optimizations rather than target independent set, but at where this pass is to be put this is completely appropriate.Any dest instruction where all of the operands have been extended should be checked to see if it was really necessary to use the longer form before doing the propagation pass. kenny On 07/11/2012 06:30 AM, Tom de Vries wrote: On 13/11/10 10:50, Eric Botcazou wrote: I profiled the pass on spec2000: -mabi=32 -mabi=64 ee-pass (usr time): 0.70 1.16 total (usr time): 919.30 879.26 ee-pass(%): 0.08 0.13 The pass takes 0.13% or less of the total usr runtime. For how many hits? What are the numbers with --param ee-max-propagate=0? Is it necessary to improve the runtime of this pass? I've already given my opinion about the implementation. The other passes in the
Re: Fix PR53908
From: Richard Guenther richard.guent...@gmail.com Date: Fri, 13 Jul 2012 09:37:13 +0200 On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: From: Richard Sandiford rsand...@nildram.co.uk Date: Thu, 12 Jul 2012 21:18:54 +0200 OK with that change if you agree. (Steven or Bernd, please ACK/NAK, for quick resolution.) I can't ACK, but I think Richard S.'s fix is correct. (There was a delegation from a maintainer so yes.) I agree, so, ok for trunk if it passes bootstrap testing. Ok for 4.7 too? brgds, H-P
Re: Fix PR53908
On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: From: Richard Guenther richard.guent...@gmail.com Date: Fri, 13 Jul 2012 09:37:13 +0200 On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: From: Richard Sandiford rsand...@nildram.co.uk Date: Thu, 12 Jul 2012 21:18:54 +0200 OK with that change if you agree. (Steven or Bernd, please ACK/NAK, for quick resolution.) I can't ACK, but I think Richard S.'s fix is correct. (There was a delegation from a maintainer so yes.) I agree, so, ok for trunk if it passes bootstrap testing. Ok for 4.7 too? Of course. Richard. brgds, H-P
[PATCH] Make LTO type merging cheaper
A patch that's in my local tree for quite some time. This removes
redundant tests.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
* gimple.c (gimple_types_compatible_p_1): Remove redundant
type attribute comparisons.
(gimple_canonical_types_compatible_p): Likewise.
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 189311)
+++ gcc/gimple.c(working copy)
@@ -3422,10 +3422,6 @@ gimple_types_compatible_p_1 (tree t1, tr
goto different_types;
}
- /* If their attributes are not the same they can't be the same type. */
- if (!attribute_list_equal (TYPE_ATTRIBUTES (t1), TYPE_ATTRIBUTES (t2)))
-goto different_types;
-
/* Do type-specific comparisons. */
switch (TREE_CODE (t1))
{
@@ -4449,10 +4445,6 @@ gimple_canonical_types_compatible_p (tre
return true;
}
- /* If their attributes are not the same they can't be the same type. */
- if (!attribute_list_equal (TYPE_ATTRIBUTES (t1), TYPE_ATTRIBUTES (t2)))
-return false;
-
/* Do type-specific comparisons. */
switch (TREE_CODE (t1))
{
@@ -4499,13 +4491,6 @@ gimple_canonical_types_compatible_p (tre
}
case METHOD_TYPE:
- /* Method types should belong to the same class. */
- if (!gimple_canonical_types_compatible_p
-(TYPE_METHOD_BASETYPE (t1), TYPE_METHOD_BASETYPE (t2)))
- return false;
-
- /* Fallthru */
-
case FUNCTION_TYPE:
/* Function types are the same if the return type and arguments types
are the same. */
Re: __int256
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote: On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote: This patch adds __int256 to the front-ends. We have another patch underway to do N-bit constant ints, where N is defined by the port. This patch is in the process of being reviewed now, and Kenny should be able to submit it shortly. How do you handle the fact that we cannot represent all constants of __int256 or larger with an INTEGER_CST? I think this introduces latent wrong-code bugs almost everywhere in the compiler. As I said, in Kenny's next patch, we add support for all constants of any size the port needs. I don't know if you've ever tried to use the compiler with OImode, but, what I can say is the bugs are not terribly latent at times and they are not hidden very well at all, today. The goal of course, is to improve that and make it work better. These issues that I know about existed, prior to my patch, and we are in the process of fixing them. Some have been fixed, others remain to be fixed. The issues I'm thinking about exist with or without my patch to the frontend to support __int256. Merely adding __int256 doesn't make any of the issues I'm aware of appear, and the issues I'm aware of don't appear with sizes less than 256. I have put the patch through the C test suite, and it doesn't show any failures. Do you have any examples of bugs that are _introduced_ by my patch? I'd be happy to fix any that arise.
Re: Fix PR53908
From: Richard Guenther richard.guent...@gmail.com
Date: Fri, 13 Jul 2012 10:08:05 +0200
On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
Ok for 4.7 too?
Of course.
Committed to trunk as follows, including the test-case which
doesn't fail on trunk but does on 4.6 and 4.7.
Will commit to 4.7 branch too. I'll leave 4.6 to those
interested enough to invest time to do the testing.
gcc:
2012-07-13 Richard Sandiford rdsandif...@googlemail.com
Steven Bosscher ste...@gcc.gnu.org
Bernd Schmidt ber...@codesourcery.com
PR rtl-optimization/53908
* df-problems.c (can_move_insns_across): When doing
memory-reference book-keeping, handle call insns.
gcc/testsuite:
2012-07-13 Hans-Peter Nilsson h...@axis.com
PR rtl-optimization/53908
* gcc.dg/torture/pr53908.c: New test.
Index: gcc/df-problems.c
===
--- gcc/df-problems.c (revision 189440)
+++ gcc/df-problems.c (working copy)
@@ -4068,6 +4068,19 @@ can_move_insns_across (rtx from, rtx to,
for (insn = across_to; ; insn = next)
{
+ if (CALL_P (insn))
+ {
+ if (RTL_CONST_OR_PURE_CALL_P (insn))
+ /* Pure functions can read from memory. Const functions can
+ read from arguments that the ABI has forced onto the stack.
+ Neither sort of read can be volatile. */
+ memrefs_in_across |= MEMREF_NORMAL;
+ else
+ {
+ memrefs_in_across |= MEMREF_VOLATILE;
+ mem_sets_in_across |= MEMREF_VOLATILE;
+ }
+ }
if (NONDEBUG_INSN_P (insn))
{
memrefs_in_across |= for_each_rtx (PATTERN (insn), find_memory,
--- /dev/null Tue Oct 29 15:57:07 2002
+++ gcc/testsuite/gcc.dg/torture/pr53908.c Thu Jul 12 19:22:59 2012
@@ -0,0 +1,288 @@
+/* { dg-do run } */
+/* SEGV at comment below. */
+typedef unsigned int size_t;
+typedef enum har {
+ he_fatal = (-199),
+ he_not_initialized,
+ he_bad_input,
+ he_memory_too_small,
+ he_bad_action,
+ he_duplicate,
+ he_bad_nonce,
+ he_stale_nonce,
+ he_bad_credentials,
+ he_bad_user,
+ he_no_such_user,
+ he_bad_passwd,
+ he_unknown_auth_scheme,
+ he_not_found,
+ he_failed_digest_file_check,
+ he_failed_digest_file_save,
+ he_process_not_privileged,
+ he_other,
+ he_end_of_range,
+ ha_no_error = 0,
+ ha_no_value = 1
+} har;
+typedef enum realm_type
+{
+ axis_realm = 0,
+ ws_realm
+} realm_type;
+
+__attribute__((__noclone__, __noinline__))
+har has_www_auth(char *, size_t, realm_type, har);
+
+__attribute__((__noclone__, __noinline__))
+har has_auth_user(const char *, const char *, realm_type, char *, size_t);
+
+__attribute__((__noclone__, __noinline__))
+char *ha_get_string_value(void);
+
+typedef struct
+{
+ unsigned int track_id;
+ char* user;
+ char* realm;
+ char* authent;
+ int internal_realm;
+} request;
+enum user_response {
+ file_not_found_user_response = -3,
+ access_denied_user_response = -2,
+ no_user_response = -1,
+ ok_user_response = 0
+};
+struct realm_group {
+ char *name;
+ int id;
+ struct realm_group *next;
+};
+struct realm {
+ char *name;
+ char *space;
+ struct realm_group *groups;
+ struct realm *next;
+};
+struct user_info {
+ char *name;
+ int no_groups;
+ int groups[128];
+ struct user_info *next;
+};
+static struct user_info *find_user(const char *user_name);
+static int is_member_of_groups(const struct user_info *user_item,
+const struct realm_group *groups);
+int authent_author(request *req);
+struct realm *realms = ((void *)0);
+struct user_info *users = ((void *)0);
+static struct user_info*
+find_user(const char *user_name)
+{
+ struct user_info *user_item;
+ user_item = users;
+ while (user_item != ((void *)0)) {
+/* SEGV due to NULL access here on user_name. See also comment below. */
+if ((__builtin_strcmp(user_item-name, user_name) == 0))
+ break;
+user_item = user_item-next;
+ }
+ return user_item;
+}
+static int
+is_member_of_groups(const struct user_info *user_item,
+const struct realm_group *groups)
+{
+ const struct realm_group *group_item;
+ int i;
+ group_item = groups;
+ while (group_item != ((void *)0)) {
+for (i = 0; i user_item-no_groups; i++)
+ if (user_item-groups[i] == group_item-id)
+ return 0;
+group_item = group_item-next;
+ }
+ return -1;
+}
+char *foo (void) __attribute__((__noclone__, __noinline__));
+char* g_strdup (const char *str) __attribute__((__malloc__, __noclone__,
__noinline__));
+int g_strcmp0 (const char *str1, const char *str2);
+static int
+is_basic(char **user)
+{
+ char *passwd_ptr;
+ char *authent = foo();
+ passwd_ptr = __builtin_strchr(authent, ':');
+ if (passwd_ptr != ((void *)0)) {
+*user = g_strdup(authent);
+return 0;
+ }
+ return -1;
+}
+static int
+is_digest(char **user)
+{
+
Re: __int256
On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump mikest...@comcast.net wrote: On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote: On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote: This patch adds __int256 to the front-ends. We have another patch underway to do N-bit constant ints, where N is defined by the port. This patch is in the process of being reviewed now, and Kenny should be able to submit it shortly. How do you handle the fact that we cannot represent all constants of __int256 or larger with an INTEGER_CST? I think this introduces latent wrong-code bugs almost everywhere in the compiler. As I said, in Kenny's next patch, we add support for all constants of any size the port needs. I don't know if you've ever tried to use the compiler with OImode, but, what I can say is the bugs are not terribly latent at times and they are not hidden very well at all, today. The goal of course, is to improve that and make it work better. These issues that I know about existed, prior to my patch, and we are in the process of fixing them. Some have been fixed, others remain to be fixed. The issues I'm thinking about exist with or without my patch to the frontend to support __int256. Merely adding __int256 doesn't make any of the issues I'm aware of appear, and the issues I'm aware of don't appear with sizes less than 256. I have put the patch through the C test suite, and it doesn't show any failures. Do you have any examples of bugs that are _introduced_ by my patch? I'd be happy to fix any that arise. No. Just you expose the users to those bugs by exposing __int256 ;) Docs should have a pretty big fat warning on it. Richard.
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 9:50 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 9:36 AM, Richard Guenther richard.guent...@gmail.com wrote: Btw, we discussed this briefly on the summit with Dodji and libcpp virtual locations already provide a way to associate a location_t with something else resulting in a new location_t. For inlining we simply have to say that the location_t's we use would always refer to the original BLOCK (thus, the abstract origin). There is no point to update the BLOCKs to point to the copies as far as debug information is concerned (?). That may work for DWARF, but what about other debug formats? We also discussed that ;) Dump all but DWARF and provide DWARF - STABS translation. Richard. Ciao! Steven
[v3] libstdc++/53657
Hi,
thanks to Jason's work on DR 1402, fixing in mainline and branch this
library/ABI issue is now trivial. Tested x86_64-linux.
Thanks,
Paolo.
/
2012-07-13 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/53657
* include/bits/stl_pair.h (pair::pair(pair)): Declare defaulted,
per C++11.
* include/bits/stl_map.h (map::insert(_Pair), map::insert
(const_iterator, _Pair)): Constrain with std::is_constructible,
per LWG2005.
* include/bits/stl_multimap.h (multimap::insert(_Pair),
multimap::insert(const_iterator, _Pair)): Likewise.
* include/bits/hashtable_policy.h (_Insert::insert(_Pair),
_Insert::insert(const_iterator, _Pair)): Likewise.
* include/debug/unordered_map: Adjust.
* include/debug/map.h: Likewise.
* include/debug/multimap.h: Likewise.
* include/profile/unordered_map: Likewise.
* include/profile/map.h: Likewise.
* include/profile/multimap.h: Likewise.
Index: include/debug/unordered_map
===
--- include/debug/unordered_map (revision 189442)
+++ include/debug/unordered_map (working copy)
@@ -248,8 +248,8 @@
}
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
std::pairiterator, bool
insert(_Pair __obj)
{
@@ -261,8 +261,8 @@
}
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
iterator
insert(const_iterator __hint, _Pair __obj)
{
@@ -663,8 +663,8 @@
}
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
iterator
insert(_Pair __obj)
{
@@ -675,8 +675,8 @@
}
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
iterator
insert(const_iterator __hint, _Pair __obj)
{
Index: include/debug/map.h
===
--- include/debug/map.h (revision 189442)
+++ include/debug/map.h (working copy)
@@ -213,8 +213,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
std::pairiterator, bool
insert(_Pair __x)
{
@@ -244,8 +244,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
iterator
insert(const_iterator __position, _Pair __x)
{
Index: include/debug/multimap.h
===
--- include/debug/multimap.h(revision 189442)
+++ include/debug/multimap.h(working copy)
@@ -201,8 +201,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+ _Pair::value::type
iterator
insert(_Pair __x)
{ return iterator(_Base::insert(std::forward_Pair(__x)), this); }
@@ -227,8 +227,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
templatetypename _Pair, typename = typename
- std::enable_ifstd::is_convertible_Pair,
- value_type::value::type
+ std::enable_ifstd::is_constructiblevalue_type,
+
[PATCH] Fix PR53937
We fail to handle constant addresses in get_pointer_alignment_1
so we use too pessimistic alignment when accessing a packed
structure via such a pointer.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
PR middle-end/53937
* builtins.c (get_pointer_alignment_1): Handle constant
pointers.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 189451)
+++ gcc/builtins.c (working copy)
@@ -536,6 +536,13 @@ get_pointer_alignment_1 (tree exp, unsig
return false;
}
}
+ else if (TREE_CODE (exp) == INTEGER_CST)
+{
+ *alignp = BIGGEST_ALIGNMENT;
+ *bitposp = ((TREE_INT_CST_LOW (exp) * BITS_PER_UNIT)
+ (BIGGEST_ALIGNMENT - 1));
+ return true;
+}
*bitposp = 0;
*alignp = BITS_PER_UNIT;
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 3:36 PM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote: I'd suggest: 1. Remove this unittest for now. And revert the patch for now. 2. Integrate locus with block, and store them as an index. (This will incur big operation to GCC) I'm not sure what you mean with integrate...? A lot of the code you'll need already exists in emit-rtl.c. That code should be split out to a new file and be shared between rtl and gimple. You'll probably want to make block_locators_locs, block_locators_blocks, and locations_locators_locs part of struct function. The biggest challenges will be avoiding bloat and managing the locators for inlining/cloning... Btw, we discussed this briefly on the summit with Dodji and libcpp virtual locations already provide a way to associate a location_t with something else resulting in a new location_t. For inlining we simply have to say that the location_t's we use would always refer to the original BLOCK (thus, the abstract origin). There is no point to update the BLOCKs to point to the copies as far as debug information is concerned (?). I'm not quite sure if I understand correctly: we will clone all blocks and update them during function inline/clone, and assign new location_t to the cloned gimple/phi_arg_t/expr etc. Otherwise, the inline stack cannot be maintained, right? Thanks, Dehao Richard. Ciao! Steven
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 11:41 AM, Dehao Chen de...@google.com wrote: On Fri, Jul 13, 2012 at 3:36 PM, Richard Guenther richard.guent...@gmail.com wrote: On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com wrote: On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote: I'd suggest: 1. Remove this unittest for now. And revert the patch for now. 2. Integrate locus with block, and store them as an index. (This will incur big operation to GCC) I'm not sure what you mean with integrate...? A lot of the code you'll need already exists in emit-rtl.c. That code should be split out to a new file and be shared between rtl and gimple. You'll probably want to make block_locators_locs, block_locators_blocks, and locations_locators_locs part of struct function. The biggest challenges will be avoiding bloat and managing the locators for inlining/cloning... Btw, we discussed this briefly on the summit with Dodji and libcpp virtual locations already provide a way to associate a location_t with something else resulting in a new location_t. For inlining we simply have to say that the location_t's we use would always refer to the original BLOCK (thus, the abstract origin). There is no point to update the BLOCKs to point to the copies as far as debug information is concerned (?). I'm not quite sure if I understand correctly: we will clone all blocks and update them during function inline/clone, and assign new location_t to the cloned gimple/phi_arg_t/expr etc. Otherwise, the inline stack cannot be maintained, right? That's true. Richard.
[PATCH][MIPS] NetLogic XLP scheduling
Hi Richard,
This patch adds scheduling support for the NetLogic XLP, including a new
pipeline description, and associated changes.
Asides from the new xlp.md description file, there are also some sync
primitive attribute modifications, for better scheduling of sync loops
(Maxim should be able to better explain this).
Other generic changes include a new hilo insn attribute, to mark which
of HI/LO does a m[ft]hilo insn access.
Can you see if this is okay for trunk?
Thanks,
Chung-Lin
From 014ff721a2e6cb96236dcf5e11d7f15c3b927386 Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov ma...@codesourcery.com
Date: Mon, 18 Jun 2012 18:10:19 -0700
Subject: [PATCH] XLP scheduling.
2012-07-13 Chung-Lin Tang clt...@codesourcery.com
Maxim Kuvyrkov ma...@codesourcery.com
NetLogic Microsystems Inc.
* config/mips/mips.md (define_attr type): New values atomic and
syncloop.
(hilo): New attribute for indicating which of hi/lo accessed.
(include xlp.md): New include.
(mfhiGPR:mode_HILO:mode,mthiGPR:mode_HILO:mode):
Set hilo attribute.
* config/mips/sync.md: Set type attribute for instructions.
* config/mips/generic.md (generic_atomic, generic_syncloop):
New reservations.
* config/mips/xlp.md: New file.
* config/mips/mips-proto.h (mips_hilo_use): Declare.
* config/mips/mips.c (mips_issue_rate): Handle XLP.
(mips_hilo_use): New function for computing hilo attribute.
---
gcc/config/mips/generic.md| 16 +++
gcc/config/mips/mips-protos.h |2 +
gcc/config/mips/mips.c| 28 ++
gcc/config/mips/mips.md | 18 +++-
gcc/config/mips/sync.md | 78 ++-
gcc/config/mips/xlp.md| 217 +
6 files changed, 332 insertions(+), 27 deletions(-)
create mode 100644 gcc/config/mips/xlp.md
diff --git a/gcc/config/mips/generic.md b/gcc/config/mips/generic.md
index d61511f..02b1d8b 100644
--- a/gcc/config/mips/generic.md
+++ b/gcc/config/mips/generic.md
@@ -103,3 +103,19 @@
(define_insn_reservation generic_frecip_fsqrt_step 5
(eq_attr type frdiv1,frdiv2,frsqrt1,frsqrt2)
alu)
+
+(define_insn_reservation generic_atomic 10
+ (eq_attr type atomic)
+ alu)
+
+;; Sync loop consists of (in order)
+;; (1) optional sync,
+;; (2) LL instruction,
+;; (3) branch and 1-2 ALU instructions,
+;; (4) SC instruction,
+;; (5) branch and ALU instruction.
+;; The net result of this reservation is a big delay with a flush of
+;; ALU pipeline.
+(define_insn_reservation generic_sync_loop 40
+ (eq_attr type syncloop)
+ alu*39)
diff --git a/gcc/config/mips/mips-protos.h b/gcc/config/mips/mips-protos.h
index d1fa160..1b1cbcb 100644
--- a/gcc/config/mips/mips-protos.h
+++ b/gcc/config/mips/mips-protos.h
@@ -334,6 +334,8 @@ extern void mips_final_prescan_insn (rtx, rtx *, int);
extern int mips_trampoline_code_size (void);
extern void mips_function_profiler (FILE *);
+extern int mips_hilo_use (rtx);
+
typedef rtx (*mulsidi3_gen_fn) (rtx, rtx, rtx);
#ifdef RTX_CODE
extern mulsidi3_gen_fn mips_mulsidi3_gen_fn (enum rtx_code);
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 7356ce5..f46eb49 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -12480,6 +12480,9 @@ mips_issue_rate (void)
case PROCESSOR_LOONGSON_3A:
return 4;
+case PROCESSOR_XLP:
+ return (reload_completed ? 4 : 3);
+
default:
return 1;
}
@@ -17407,6 +17410,31 @@ mips_expand_vec_minmax (rtx target, rtx op0, rtx op1,
x = gen_rtx_IOR (vmode, t0, t1);
emit_insn (gen_rtx_SET (VOIDmode, target, x));
}
+
+/* Determine HI/LO access on INSN, return 1 for HI, -1 for LO,
+ and 0 for no access. Used for determining hilo attribute. */
+
+int
+mips_hilo_use (rtx insn)
+{
+ rtx pat, dest, src;
+ enum attr_type insn_type;
+
+ if (! (pat = single_set (insn)))
+return 0;
+
+ insn_type = get_attr_type (insn);
+ dest = SET_DEST (pat);
+ src = SET_SRC (pat);
+
+ if ((insn_type == TYPE_MTHILO REGNO (dest) == HI_REGNUM)
+ || (insn_type == TYPE_MFHILO REGNO (src) == HI_REGNUM))
+return 1;
+ if ((insn_type == TYPE_MTHILO REGNO (dest) == LO_REGNUM)
+ || (insn_type == TYPE_MFHILO REGNO (src) == LO_REGNUM))
+return -1;
+ return 0;
+}
/* Initialize the GCC target structure. */
#undef TARGET_ASM_ALIGNED_HI_OP
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 5b1735f..d2a304e 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -274,6 +274,8 @@
;; frsqrt1 floating point reciprocal square root step1
;; frsqrt2 floating point reciprocal square root step2
;; multi multiword sequence (or user asm statements)
+;; atomic atomic memory update instruction
+;; sync_loop memory atomic operation implemented as a sync loop
;; nop no operation
;; ghost an instruction that produces no real code
(define_attr type
@@ -281,7
[PATCH] Fix PR53922
This fixes PR53922 - we failed to handle don't know return
from value_inside_range inside range_includes_zero_p. Fixed
and re-structured the code to not have the strage range/anti-range
issue.
Bootstrapped and tested on x86_64-unknown-linxu-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
PR tree-optimization/53922
* tree-vrp.c (value_inside_range): Change prototype to take
min/max instead of value-range.
(range_includes_zero_p): Likewise. Return the result from
value_inside_range.
(extract_range_from_binary_expr_1): Adjust to handle dont-know
return value from range_includes_zero_p.
(extract_range_from_unary_expr_1): Likewise.
(compare_range_with_value): Likewise.
(vrp_meet_1): Likewise.
* gcc.dg/torture/pr53922.c: New testcase.
Index: gcc/tree-vrp.c
===
*** gcc/tree-vrp.c (revision 189451)
--- gcc/tree-vrp.c (working copy)
*** compare_values (tree val1, tree val2)
*** 1339,1379
}
! /* Return 1 if VAL is inside value range VR (VR-MIN = VAL = VR-MAX),
! 0 if VAL is not inside VR,
-2 if we cannot tell either way.
-FIXME, the current semantics of this functions are a bit quirky
- when taken in the context of VRP. In here we do not care
- about VR's type. If VR is the anti-range ~[3, 5] the call
- value_inside_range (4, VR) will return 1.
-
- This is counter-intuitive in a strict sense, but the callers
- currently expect this. They are calling the function
- merely to determine whether VR-MIN = VAL = VR-MAX. The
- callers are applying the VR_RANGE/VR_ANTI_RANGE semantics
- themselves.
-
- This also applies to value_ranges_intersect_p and
- range_includes_zero_p. The semantics of VR_RANGE and
- VR_ANTI_RANGE should be encoded here, but that also means
- adapting the users of these functions to the new semantics.
-
Benchmark compile/20001226-1.c compilation time after changing this
function. */
static inline int
! value_inside_range (tree val, value_range_t * vr)
{
int cmp1, cmp2;
! cmp1 = operand_less_p (val, vr-min);
if (cmp1 == -2)
return -2;
if (cmp1 == 1)
return 0;
! cmp2 = operand_less_p (vr-max, val);
if (cmp2 == -2)
return -2;
--- 1339,1363
}
! /* Return 1 if VAL is inside value range MIN = VAL = MAX,
! 0 if VAL is not inside [MIN, MAX],
-2 if we cannot tell either way.
Benchmark compile/20001226-1.c compilation time after changing this
function. */
static inline int
! value_inside_range (tree val, tree min, tree max)
{
int cmp1, cmp2;
! cmp1 = operand_less_p (val, min);
if (cmp1 == -2)
return -2;
if (cmp1 == 1)
return 0;
! cmp2 = operand_less_p (max, val);
if (cmp2 == -2)
return -2;
*** value_ranges_intersect_p (value_range_t
*** 1402,1424
}
! /* Return true if VR includes the value zero, false otherwise. FIXME,
!currently this will return false for an anti-range like ~[-4, 3].
!This will be wrong when the semantics of value_inside_range are
!modified (currently the users of this function expect these
!semantics). */
! static inline bool
! range_includes_zero_p (value_range_t *vr)
{
! tree zero;
!
! gcc_assert (vr-type != VR_UNDEFINED
!vr-type != VR_VARYING
! !symbolic_range_p (vr));
!
! zero = build_int_cst (TREE_TYPE (vr-min), 0);
! return (value_inside_range (zero, vr) == 1);
}
/* Return true if *VR is know to only contain nonnegative values. */
--- 1386,1399
}
! /* Return 1 if [MIN, MAX] includes the value zero, 0 if it does not
!include the value zero, -2 if we cannot tell. */
! static inline int
! range_includes_zero_p (tree min, tree max)
{
! tree zero = build_int_cst (TREE_TYPE (min), 0);
! return value_inside_range (zero, min, max);
}
/* Return true if *VR is know to only contain nonnegative values. */
*** extract_range_from_binary_expr_1 (value_
*** 2641,2647
gives [min / 4, max / 4] range. */
if (vr1.type == VR_RANGE
!symbolic_range_p (vr1)
! !range_includes_zero_p (vr1))
{
vr0.type = type = VR_RANGE;
vr0.min = vrp_val_min (expr_type);
--- 2616,2622
gives [min / 4, max / 4] range. */
if (vr1.type == VR_RANGE
!symbolic_range_p (vr1)
! range_includes_zero_p (vr1.min, vr1.max) == 0)
{
vr0.type = type = VR_RANGE;
vr0.min = vrp_val_min (expr_type);
*** extract_range_from_binary_expr_1 (value_
*** 2658,2665
not eliminate a division by
Re: new sign/zero extension elimination pass
it really is not. the problem is that sign extension removal is just a more difficult problem than what you are considering. You have attacked a small part of the problem and have a good start but you really should consider the whole problem. kenny On 07/13/2012 03:53 AM, Tom de Vries wrote: On 12/07/12 14:04, Kenneth Zadeck wrote: you are on the right track with the example but combine will not get this unless everything is in the same bb. the whole point of having a separate pass for doing extension elimination is that it needs to be done over the entire function. There is a pass_ree, which does inter-bb combine targeted at extensions. However, that pass is currently limited to combining extensions with the definitions of the register it extends. The way your example sounds, you want the reverse, where extensions are combined with all their uses. I would say pass_ree is the natural place to add this and handle the example you describe. Thanks, - Tom my example is also a little more complex because, since we are talking about induction vars, you have an initial assignment outside of a loop, and increment inside the loop and the test you describe at the bottom of the loop. I would point out that with respect to speed optimizations, the case i am describing is in fact very important because getting code out of loops is were the important gains are. I believe that the ppc has a some significant performance issues because of this kind of thing. kenny On 07/12/2012 05:20 AM, Tom de Vries wrote: On 12/07/12 11:05, Tom de Vries wrote: On 12/07/12 03:39, Kenneth Zadeck wrote: Tom, I have a problem with the approach that you have taken here. I believe that this could be a very useful addition to gcc so I am in general very supportive, but i think you are missing an important case. My problem is that it the pass does not actually look at the target and make any decisions based on that target. for instance, we have a llp64 target. As with many targets, the target has a rich set of compare and branch instructions. In particular, it can do both 32 and 64 bit comparisons.We see that many of the upstream optimizations that take int (SI mode) index variables generate extension operations before doing 64 bit compare and branch instructions, even though there are 32 bit comparison and branches on the machine. There are a lot of machines that can do more than one size of comparison. This optimization pass, as it is currently written will not remove those extensions because it believes that the length of the destination is the final answer unless it is wrapped in an explicit truncation. Instead it needs to ask the port if there is a shorted compare and branch instruction that does not cost more. in that case, those instructions should be rewritten to use the shorted compare and branch. There are many operations other than compare and branch where the pass should be asking can i shorten the target for free and therefore get rid of the extension? Kenneth, I'm not sure I understand the optimization you're talking about, in particular I'm confused about whether the branch range of the 32-bit and 64-bit comparison is the same. Assuming it's the same, my understanding is that you're talking about an example like this: ... (insn (set (reg:DI 5) (zero_extend:DI (reg:SI 4 (jump_insn (set (pc) (if_then_else (eq (reg:DI 5) (const_int 0)) (label_ref:DI 62) (pc - (jump_insn (set (pc) (if_then_else (eq (reg:SI 4) (const_int 0)) (label_ref:DI 62) (pc ... I would expect combine to optimize this. In case I got the example all backwards or it is a too simple one, please provide an rtl example that illustrates the optimization. Thanks, - Tom right shifts, rotates, and stores are not in this class, but left shifts are as are all comparisons, compare and branches, conditional moves. There may even be machines that have this for divide, but i do not know of any off the top of my head. What i am suggesting moves this pass into the target specific set of optimizations rather than target independent set, but at where this pass is to be put this is completely appropriate.Any dest instruction where all of the operands have been extended should be checked to see if it was really necessary to use the longer form before doing the propagation pass. kenny On 07/11/2012 06:30 AM, Tom de Vries wrote: On 13/11/10 10:50, Eric Botcazou wrote: I profiled the pass on spec2000: -mabi=32 -mabi=64 ee-pass (usr time): 0.70 1.16 total (usr time): 919.30 879.26 ee-pass(%): 0.08 0.13 The pass takes 0.13% or less of the total usr
[PATCH] Fix comment in cgraphunit.c
I think the comment at the start of the file is wrong, since it speaks about varpool_finalize_variable, but there's no such function (not even mentioned in CLs). I'd say the author meant varpool_finalize_decl. 2012-07-13 Marek Polacek pola...@redhat.com * cgraphunit.c: Rename varpool_finalize_variable to varpool_finalize_decl in a comment. --- gcc/cgraphunit.c.mp 2012-07-13 13:49:41.071591575 +0200 +++ gcc/cgraphunit.c2012-07-13 13:49:50.715613502 +0200 @@ -34,7 +34,7 @@ along with GCC; see the file COPYING3. (There is one exception needed for implementing GCC extern inline function.) -- varpool_finalize_variable +- varpool_finalize_decl This function has same behavior as the above but is used for static variables. Marek
Re: [RFC, ARM] later split of symbol_refs
2012/6/30 Georg-Johann Lay g...@gcc.gnu.org: Is there a special reason to restrict it to SYMBOL_REF? Doesn't the same issue occur with, e.g. (const (plus (symbol_ref const_int))) or label_ref? Hi! We have added splits for symbol_ref plus const and label_ref. With this patch, assembly code and oprofile data look better, but on SPEC2K INT it's about 3% slower than with split for only symbol_refs. We will try to find later why this happens. For now, we commited the original patch. symbol_plus.patch Description: Binary data
[PATCH] Fix PR53907
If one writes p - ((intptr_t)p % align) to align a pointer we neither
produce optimal code for the aligning nor can we track the alignment
for the resulting pointer from within CCP. The following makes
sure we transform the above to p ~align instead.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
PR tree-optimization/53907
* tree-ssa-forwprop.c (associate_pointerplus): New function.
(ssa_forward_propagate_and_combine): Call it.
* gcc.target/i386/pr53907.c: New testcase.
Index: gcc/tree-ssa-forwprop.c
===
*** gcc/tree-ssa-forwprop.c (revision 189458)
--- gcc/tree-ssa-forwprop.c (working copy)
***
*** 2474,2479
--- 2465,2523
return false;
}
+ /* Associate operands of a POINTER_PLUS_EXPR assignmen at *GSI. Returns
+true if anything changed, false otherwise. */
+
+ static bool
+ associate_pointerplus (gimple_stmt_iterator *gsi)
+ {
+ gimple stmt = gsi_stmt (*gsi);
+ gimple def_stmt;
+ tree ptr, rhs, algn;
+
+ /* Pattern match
+tem = (sizetype) ptr;
+tem = tem algn;
+tem = -tem;
+... = ptr p+ tem;
+ and produce the simpler and easier to analyze with respect to alignment
+... = ptr ~algn; */
+ ptr = gimple_assign_rhs1 (stmt);
+ rhs = gimple_assign_rhs2 (stmt);
+ if (TREE_CODE (rhs) != SSA_NAME)
+ return false;
+ def_stmt = SSA_NAME_DEF_STMT (rhs);
+ if (!is_gimple_assign (def_stmt)
+ || gimple_assign_rhs_code (def_stmt) != NEGATE_EXPR)
+ return false;
+ rhs = gimple_assign_rhs1 (def_stmt);
+ if (TREE_CODE (rhs) != SSA_NAME)
+ return false;
+ def_stmt = SSA_NAME_DEF_STMT (rhs);
+ if (!is_gimple_assign (def_stmt)
+ || gimple_assign_rhs_code (def_stmt) != BIT_AND_EXPR)
+ return false;
+ rhs = gimple_assign_rhs1 (def_stmt);
+ algn = gimple_assign_rhs2 (def_stmt);
+ if (TREE_CODE (rhs) != SSA_NAME
+ || TREE_CODE (algn) != INTEGER_CST)
+ return false;
+ def_stmt = SSA_NAME_DEF_STMT (rhs);
+ if (!is_gimple_assign (def_stmt)
+ || !CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt)))
+ return false;
+ if (gimple_assign_rhs1 (def_stmt) != ptr)
+ return false;
+
+ algn = double_int_to_tree (TREE_TYPE (ptr),
+double_int_not (tree_to_double_int (algn)));
+ gimple_assign_set_rhs_with_ops (gsi, BIT_AND_EXPR, ptr, algn);
+ fold_stmt_inplace (gsi);
+ update_stmt (stmt);
+
+ return true;
+ }
+
/* Combine two conversions in a row for the second conversion at *GSI.
Returns 1 if there were any changes made, 2 if cfg-cleanup needs to
run. Else it returns 0. */
*** ssa_forward_propagate_and_combine (void)
*** 2815,2820
--- 2850,2857
else if (code == PLUS_EXPR
|| code == MINUS_EXPR)
changed = associate_plusminus (gsi);
+ else if (code == POINTER_PLUS_EXPR)
+ changed = associate_pointerplus (gsi);
else if (CONVERT_EXPR_CODE_P (code)
|| code == FLOAT_EXPR
|| code == FIX_TRUNC_EXPR)
Index: gcc/testsuite/gcc.target/i386/pr53907.c
===
*** gcc/testsuite/gcc.target/i386/pr53907.c (revision 0)
--- gcc/testsuite/gcc.target/i386/pr53907.c (working copy)
***
*** 0
--- 1,14
+ /* { dg-do compile } */
+ /* { dg-options -O -msse2 } */
+
+ #include emmintrin.h
+
+ __m128i x(char *s)
+ {
+ __m128i sz,z,mvec;
+ s-=((unsigned long) s)%16;
+ sz=_mm_load_si128((__m128i *)s);
+ return sz;
+ }
+
+ /* { dg-final { scan-assembler movdqa } } */
[PATCH] Fix libmudflap.c/fail1[12]-frag.c FAILs
Recognized as memset, fixed.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
* libmudflap.c/fail11-frag.c: Adjust to not look like memset.
* libmudflap.c/fail12-frag.c: Likewise.
Index: libmudflap/testsuite/libmudflap.c/fail11-frag.c
===
--- libmudflap/testsuite/libmudflap.c/fail11-frag.c (revision 189461)
+++ libmudflap/testsuite/libmudflap.c/fail11-frag.c (working copy)
@@ -10,7 +10,7 @@ y = x;
while (i--)
{
++x;
- *x = 0;
+ *x = i;
}
return 0;
}
Index: libmudflap/testsuite/libmudflap.c/fail12-frag.c
===
--- libmudflap/testsuite/libmudflap.c/fail12-frag.c (revision 189461)
+++ libmudflap/testsuite/libmudflap.c/fail12-frag.c (working copy)
@@ -10,7 +10,7 @@ y = x;
while (i--)
{
++x;
- *x = 0;
+ *x = i;
}
return 0;
}
[PATCH] Fix mudflap testsuite flags
It appears that mudflap tries to run its test without optimization
as well by doing
set MUDFLAP_FLAGS [list {} {-static} {-O2} {-O3}]
but it does not consider options pre-pended on each commandline
which includes -O2. So we happen to run the {-O2} test twice
and the {} test is useless.
Fixed by explicitely using {-O0} everywhere. I did not touch
-static as it is sufficiently different (even if it includes -O2 as well).
Committed as obvious.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
* testsuite/libmudflap.c++/ctors.exp: Explicitely specify -O0.
* testsuite/libmudflap.c++/c++frags.exp: Likewise.
* testsuite/libmudflap.cth/cthfrags.exp: Likewise.
* testsuite/libmudflap.c/cfrags.exp: Likewise.
* testsuite/libmudflap.c/externs.exp: Likewise.
Index: libmudflap/testsuite/libmudflap.c++/ctors.exp
===
--- libmudflap/testsuite/libmudflap.c++/ctors.exp (revision 189462)
+++ libmudflap/testsuite/libmudflap.c++/ctors.exp (working copy)
@@ -1,5 +1,5 @@
global MUDFLAP_FLAGS
-set MUDFLAP_FLAGS [list {} {-static} {-O2} {-O3}]
+set MUDFLAP_FLAGS [list {-O0} {-static} {-O2} {-O3}]
libmudflap-init c++
if {$cxx == g++} then {
Index: libmudflap/testsuite/libmudflap.c++/c++frags.exp
===
--- libmudflap/testsuite/libmudflap.c++/c++frags.exp(revision 189462)
+++ libmudflap/testsuite/libmudflap.c++/c++frags.exp(working copy)
@@ -1,5 +1,5 @@
global MUDFLAP_FLAGS
-set MUDFLAP_FLAGS [list {} {-static} { -O} {-O2} {-O3}]
+set MUDFLAP_FLAGS [list {-O0} {-static} { -O} {-O2} {-O3}]
libmudflap-init c++
if {$cxx == g++} then {
Index: libmudflap/testsuite/libmudflap.cth/cthfrags.exp
===
--- libmudflap/testsuite/libmudflap.cth/cthfrags.exp(revision 189462)
+++ libmudflap/testsuite/libmudflap.cth/cthfrags.exp(working copy)
@@ -1,5 +1,5 @@
global MUDFLAP_FLAGS
-set MUDFLAP_FLAGS [list {} {-static -DSTATIC} {-O2} {-O3}]
+set MUDFLAP_FLAGS [list {-O0} {-static -DSTATIC} {-O2} {-O3}]
libmudflap-init c
Index: libmudflap/testsuite/libmudflap.c/cfrags.exp
===
--- libmudflap/testsuite/libmudflap.c/cfrags.exp(revision 189462)
+++ libmudflap/testsuite/libmudflap.c/cfrags.exp(working copy)
@@ -1,5 +1,5 @@
global MUDFLAP_FLAGS
-set MUDFLAP_FLAGS [list {} {-static} {-O2} {-O3}]
+set MUDFLAP_FLAGS [list {-O0} {-static} {-O2} {-O3}]
libmudflap-init c
Index: libmudflap/testsuite/libmudflap.c/externs.exp
===
--- libmudflap/testsuite/libmudflap.c/externs.exp (revision 189462)
+++ libmudflap/testsuite/libmudflap.c/externs.exp (working copy)
@@ -1,5 +1,5 @@
global MUDFLAP_FLAGS
-set MUDFLAP_FLAGS [list {} {-static} {-O2} {-O3}]
+set MUDFLAP_FLAGS [list {-O0} {-static} {-O2} {-O3}]
libmudflap-init c
dg-init
Re: __int256
On Fri, 13 Jul 2012, Mike Stump wrote: As I said, in Kenny's next patch, we add support for all constants of any size the port needs. I don't know if you've ever tried to use the compiler with OImode, but, what I can say is the bugs are not terribly latent at times and they are not hidden very well at all, today. The goal of course, is to improve that and make it work better. These issues that I know about existed, prior to my patch, and we are in the process of fixing them. Some have been fixed, others remain to be fixed. The issues I'm thinking about exist with or without my patch to the frontend to support __int256. Merely adding __int256 doesn't make any of the issues I'm aware of appear, and the issues I'm aware of don't appear with sizes less than 256. I think the patches allowing constants of such a type to work should go in first, and the libgcc support, before we consider the support for the type from the front ends using keywords as opposed to mode attributes. You're using OImode in target-independent code. But I don't see a change to machmode.def to add it as a machine-independent mode. Nor do I think it *should* be a machine-independent mode; it's sufficiently specialised that it should be possible to do things without it needing to be one. See my comments (several messages on 1 July 2011) about 40-bit integer support; carefully designed target hooks to specify the keywords / modes for target-specific integer types are better than adding more and more cases to several difference places in the target-independent compiler. __int128_t and __uint128_t are legacy built-in typedef names and I don't think there should be any analogue for 256-bit integers; just __int256 and unsigned __int256. I have put the patch through the C test suite, and it doesn't show any failures. Certainly you should add analogues of gcc.dg/torture/fp-int-convert-*timode.c for the new type and verify that those tests all work for it. It would seem advisable to add tests covering pure integer operations for the new type (all the C integer operations), for both constants and runtime evaluation, as well. -- Joseph S. Myers jos...@codesourcery.com
[Patch/RFC] SEH exceptions for Win64
Hi,
this is a rebase of RTH's patch posted a few years ago. It is almost
unchanged, except that there is no SEH specific unwind.h header (there are 3
#if/#endif part in unwind-generic.h) and a minor cleanup in unwind-seh.c
(indentation, unused variables).
This patch allows to propagate GCC exceptions through any code (including code
produced by msvc), but to my knowledge propagation of msvc exceptions through
gcc code doesn't work (because we cancel the exception to run cleanups).
We have tested it heavily in our infrastructure and found no issues in that
part. We had to write a specific personality routine for Ada to handle stack
checking and access violation in user code; but as far as I know this is not
needed by c++.
I did a manual build and testing for x86_64-pc-mingw32 and I will run a full
bootstrap and regression run on GNU/Linux.
Tristan.
libstdc++-v3/
* libsupc++/eh_personality.cc (__gxx_personality_seh0): New function.
Adjust for SEH.
* config/abi/pre/gnu.ver: Add __gxx_personality_seh0.
libobjc/
* exception.c (__gnu_objc_personality_seh0): New function.
libjava/
* libgcj.ver: Add __gcj_personality_seh0.
* exception.cc (__gcj_personality_seh0): New function.
Adjust for SEH.
libgcc/
* unwind-seh.c: New file.
* unwind-generic.h: Include windows.h for SEH.
(_Unwind_Exception): Use 6 private fields for SEH.
(_GCC_specific_handler): Declare.
* unwind-c.c (__gcc_personality_seh0): New function.
Adjust for SEH.
* config/i386/libgcc-cygming.ver: New file.
* config/i386/t-seh-eh: New file.
* config.host (x86_64-*-mingw*): Default to seh.
gcc/
* opts.c (finish_options): Handle UI_SEH.
* expr.c (build_personality_function): Handle UI_SEH.
* dwarf2out.c (dwarf2out_begin_prologue): Handle UI_SEH.
* coretypes.h (unwind_info_type): Add UI_SEH.
* config/i386/winnt.c (i386_pe_seh_emit_except_personality):
New function.
(i386_pe_seh_init_sections): Likewise.
* config/i386/cygming.h (TARGET_ASM_EMIT_EXCEPT_PERSONALITY): Define.
(TARGET_ASM_INIT_SECTIONS): Define.
* common/config/i386/i386-common.c (TARGET_EXCEPT_UNWIND_INFO): Define.
(i386_except_unwind_info): New function.
diff --git a/gcc/common/config/i386/i386-common.c
b/gcc/common/config/i386/i386-common.c
index 70b7eb7..1fe04a6 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -667,6 +667,30 @@ ix86_supports_split_stack (bool report ATTRIBUTE_UNUSED,
return ret;
}
+/* Implement TARGET_EXCEPT_UNWIND_INFO. */
+
+static enum unwind_info_type
+i386_except_unwind_info (struct gcc_options *opts)
+{
+ /* Honor the --enable-sjlj-exceptions configure switch. */
+#ifdef CONFIG_SJLJ_EXCEPTIONS
+ if (CONFIG_SJLJ_EXCEPTIONS)
+return UI_SJLJ;
+#endif
+
+ /* On windows 64, prefer SEH exceptions over anything else. */
+ if (TARGET_64BIT DEFAULT_ABI == MS_ABI opts-x_flag_unwind_tables)
+return UI_SEH;
+
+ if (DWARF2_UNWIND_INFO)
+return UI_DWARF2;
+
+ return UI_SJLJ;
+}
+
+#undef TARGET_EXCEPT_UNWIND_INFO
+#define TARGET_EXCEPT_UNWIND_INFO i386_except_unwind_info
+
#undef TARGET_DEFAULT_TARGET_FLAGS
#define TARGET_DEFAULT_TARGET_FLAGS\
(TARGET_DEFAULT \
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index b5f89c4..8455a67 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -48,6 +48,10 @@ along with GCC; see the file COPYING3. If not see
#define TARGET_ASM_UNWIND_EMIT_BEFORE_INSN false
#undef TARGET_ASM_FUNCTION_END_PROLOGUE
#define TARGET_ASM_FUNCTION_END_PROLOGUE i386_pe_seh_end_prologue
+#undef TARGET_ASM_EMIT_EXCEPT_PERSONALITY
+#define TARGET_ASM_EMIT_EXCEPT_PERSONALITY i386_pe_seh_emit_except_personality
+#undef TARGET_ASM_INIT_SECTIONS
+#define TARGET_ASM_INIT_SECTIONS i386_pe_seh_init_sections
#define SUBTARGET_ASM_UNWIND_INIT i386_pe_seh_init
#undef DEFAULT_ABI
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index fe733b0..49e6bbd 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -258,6 +258,8 @@ extern tree i386_pe_mangle_assembler_name (const char *);
extern void i386_pe_seh_init (FILE *);
extern void i386_pe_seh_end_prologue (FILE *);
extern void i386_pe_seh_unwind_emit (FILE *, rtx);
+extern void i386_pe_seh_emit_except_personality (rtx);
+extern void i386_pe_seh_init_sections (void);
/* In winnt-cxx.c and winnt-stubs.c */
extern void i386_pe_adjust_class_at_definition (tree);
diff --git a/gcc/config/i386/winnt.c b/gcc/config/i386/winnt.c
index 5b71ccb..17ee137 100644
--- a/gcc/config/i386/winnt.c
+++ b/gcc/config/i386/winnt.c
@@ -1143,6 +1143,48 @@ i386_pe_seh_unwind_emit (FILE *asm_out_file, rtx insn)
found:
seh_frame_related_expr (asm_out_file, seh, pat);
}
+
+void
Re: [patch] Call free_after_parsing earlier
On Thu, Jul 12, 2012 at 9:21 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Jul 11, 2012 at 9:39 PM, Steven Bosscher stevenb@gmail.com
wrote:
Hello,
GCC calls free_after_parsing in rest_of_clean_state.
That's way too late, it can be done in free_lang_data_in_cgraph instead.
But that's only called with -flto ... I think it should be called in
cgraph_finalize_function instead (being optimistic here - heh).
Quite optimistic, indeed...
I choose for free_lang_data_in_cgraph (which, BTW, doesn't belong in
tree.c, but that aside) because I thought the C++ front end might need
its function-language after cgraph_finalize_function. And indeed
so...
Ciao!
Steven
$ cat t.C
#line 14971 configure
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
$ gdb --args ./cc1plus t.C
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu...
Breakpoint 1 at 0x38a80b5: file ../../trunk/gcc/diagnostic.c, line 1011.
Breakpoint 2 at 0x38a7ed6: file ../../trunk/gcc/diagnostic.c, line 955.
Function exit not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
Function abort not defined.
Make breakpoint pending on future shared library load? (y or [n])
[answered N; input not from terminal]
(gdb) run
Starting program: /home/stevenb/devel/build-test/gcc/cc1plus t.C
void foo()
Analyzing compilation unit
Program received signal SIGSEGV, Segmentation fault.
0x0096b93a in stmts_are_full_exprs_p () at
../../trunk/gcc/cp/semantics.c:370
370 return current_stmt_tree ()-stmts_are_full_exprs_p;
(gdb) bt
#0 0x0096b93a in stmts_are_full_exprs_p () at
../../trunk/gcc/cp/semantics.c:370
#1 0x00b1f294 in cp_gimplify_expr (expr_p=0x77232a20,
pre_p=0x7fff97a8, post_p=0x7fff8ba8) at
../../trunk/gcc/cp/cp-gimplify.c:530
#2 0x0156fb44 in gimplify_expr (expr_p=0x77232a20,
pre_p=0x7fff97a8, post_p=0x7fff8ba8, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7064
#3 0x01563bb7 in gimplify_stmt (stmt_p=0x77232a20,
seq_p=0x7fff97a8) at ../../trunk/gcc/gimplify.c:5678
#4 0x01562d43 in gimplify_cleanup_point_expr
(expr_p=0x77245ad8, pre_p=0x7fffb3b0) at
../../trunk/gcc/gimplify.c:5455
#5 0x01572c33 in gimplify_expr (expr_p=0x77245ad8,
pre_p=0x7fffb3b0, post_p=0x7fff9998, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7479
#6 0x01563bb7 in gimplify_stmt (stmt_p=0x77245ad8,
seq_p=0x7fffb3b0) at ../../trunk/gcc/gimplify.c:5678
#7 0x01543e69 in gimplify_statement_list
(expr_p=0x7fffb288, pre_p=0x7fffb3b0) at
../../trunk/gcc/gimplify.c:1527
#8 0x0157352f in gimplify_expr (expr_p=0x7fffb288,
pre_p=0x7fffb3b0, post_p=0x7fffa6e8, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7531
#9 0x01563bb7 in gimplify_stmt (stmt_p=0x7fffb288,
seq_p=0x7fffb3b0) at ../../trunk/gcc/gimplify.c:5678
#10 0x0153eb49 in gimplify_and_add (t=0x77247600,
seq_p=0x7fffb3b0) at ../../trunk/gcc/gimplify.c:358
#11 0x01572a22 in gimplify_expr (expr_p=0x77245ac0,
pre_p=0x7fffcd40, post_p=0x7fffb3f8, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7457
#12 0x01563bb7 in gimplify_stmt (stmt_p=0x77245ac0,
seq_p=0x7fffcd40) at ../../trunk/gcc/gimplify.c:5678
#13 0x01543e69 in gimplify_statement_list
(expr_p=0x7724c098, pre_p=0x7fffcd40) at
../../trunk/gcc/gimplify.c:1527
#14 0x0157352f in gimplify_expr (expr_p=0x7724c098,
pre_p=0x7fffcd40, post_p=0x7fffc148, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7531
#15 0x01563bb7 in gimplify_stmt (stmt_p=0x7724c098,
seq_p=0x7fffcd40) at ../../trunk/gcc/gimplify.c:5678
#16 0x01542106 in gimplify_bind_expr (expr_p=0x7723c898,
pre_p=0x7fffdc80) at ../../trunk/gcc/gimplify.c:1220
#17 0x01571446 in gimplify_expr (expr_p=0x7723c898,
pre_p=0x7fffdc80, post_p=0x7fffd068, gimple_test_f=0x155d16c
is_gimple_stmt, fallback=0)
at ../../trunk/gcc/gimplify.c:7316
#18 0x01563bb7 in gimplify_stmt (stmt_p=0x7723c898,
seq_p=0x7fffdc80) at ../../trunk/gcc/gimplify.c:5678
#19 0x01577766 in gimplify_body (fndecl=0x7723c800,
do_parms=1 '\001') at ../../trunk/gcc/gimplify.c:8177
#20 0x01578d36 in gimplify_function_tree
(fndecl=0x7723c800) at ../../trunk/gcc/gimplify.c:8311
#21 0x00fc490c in cgraph_analyze_function
Re: C++ PATCH for c++/53733 (DR 1402, deleting move ctor)
On 07/10/2012 02:04 AM, Jason Merrill wrote:
Apparently we need to implement DR 1402 in 4.7 in order to fix the
std::pair ABI breakage properly. So here it is: if overload resolution
chooses a non-trivial copy constructor, instead of causing the move
constructor to be deleted, we just don't implicitly declare it.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
PR 53953 points out a regression caused by this patch; I didn't notice
that the lambda code returns before I had initialized no_implicit_p.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit ceef07db024219e8a2694aceb59cd2ddc4ce9d6f
Author: Jason Merrill ja...@redhat.com
Date: Fri Jul 13 16:47:38 2012 +0200
PR c++/53953
* method.c (synthesized_method_walk): Initialize no_implicit_p sooner.
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index bd0792f..b0e9ece 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -1120,6 +1120,9 @@ synthesized_method_walk (tree ctype, special_function_kind sfk, bool const_p,
if (spec_p)
*spec_p = (cxx_dialect = cxx0x ? noexcept_true_spec : empty_except_spec);
+ if (no_implicit_p)
+*no_implicit_p = false;
+
if (deleted_p)
{
/* The closure type associated with a lambda-expression has a deleted
@@ -1195,9 +1198,6 @@ synthesized_method_walk (tree ctype, special_function_kind sfk, bool const_p,
if (trivial_p)
*trivial_p = expected_trivial;
- if (no_implicit_p)
-*no_implicit_p = false;
-
/* The TYPE_HAS_COMPLEX_* flags tell us about constraints from base
class versions and other properties of the type. But a subobject
class can be trivially copyable and yet have overload resolution
Re: __int256
Mike Stump wrote: This patch adds __int256 to the front-ends. We follow the __int128 code fairly closely... So, an outstanding question would be, how do I get the mangle codes allocated for the type? I just choose two unused codes, for now. All in all, the patch was pretty straight forward. We have another patch underway to do N-bit constant ints, where N is defined by the port. This patch is in the process of being reviewed now, and Kenny should be able to submit it shortly. The avr port defines __int24 and __uint24. Is that compatible with a generic __int24? Johann I tried hard to find all the __int128 bits, but, if there are any I missed, love to have a pointer to them. So, I think we have to resolve which mangle codes to use in some before this goes in, aside from that, Ok?
Re: __int256
On Jul 13, 2012, at 1:57 AM, Richard Guenther wrote:
I have put the patch through the C test suite, and it doesn't show any
failures.
Do you have any examples of bugs that are _introduced_ by my patch? I'd be
happy to fix any that arise.
No. Just you expose the users to those bugs by exposing __int256 ;) Docs
should have a pretty big fat warning on it.
Ah, ok, thanks. Now, the problem, OImode I believe is _already_ exposed to the
user:
int __attribute__((mode(SI))) a;
int __attribute__((mode(OI))) b;
This just changes the exposure slightly to be higher visibility and a prettier
interface in my opinion. Also, notice, that exposure I believe is limited to
ports that do this:
my_scalar_mode_supported_p (enum machine_mode mode)
{
switch (mode)
{
case OImode:
return true;
default:
return default_scalar_mode_supported_p (mode);
}
}
_exclusively_. As, in my code, it does this:
+if (targetm.scalar_mode_supported_p (OImode))
+ {
+int256_integer_type_node = make_signed_type (256);
+int256_unsigned_type_node = make_unsigned_type (256);
+ }
and this:
+ case RID_INT256:
+ if (int256_integer_type_node == NULL_TREE)
+ {
+ error_at (loc, %__int256% is not supported for this
target);
+ return specs;
+ }
and this:
+ if (explicit_int256)
+{
+ if (int256_integer_type_node == NULL_TREE)
+ {
+ error (%__int256% is not supported by this target);
+ explicit_int256 = false;
+ }
so, I'm having a really hard time with the notion that this actually creates
any new problems for anyone, even those that support OImode already. I just
checked all in tree gcc targets, and none claim OImode support. Do you have
any example of a testcase that shows a regression? Any that shows a regression
on any in tree port? I can easily test, as I have compilers that don't have
any OI support, compilers that have OI support, and compilers that have
__int256 support.
As for documenting bugs, generally we don't do that. Our intention is to
actually spend time to fix all bugs, so, documenting them I don't feel is
necessary.
Re: __int256
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote: On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote: I just checked all in tree gcc targets, and none claim OImode support. ./s390/s390-modes.def:23:INT_MODE (OI, 32); ./spu/spu-modes.def:29:INT_MODE (OI, 32); ./ia64/ia64-modes.def:68:INT_MODE (OI, 32); ./i386/i386-modes.def:88:INT_MODE (OI, 32); ./arm/arm-modes.def:82:INT_MODE (OI, 32); At least for ARM, OImode gets used for Neon intrinsics. Can't speak for the other ports, though. On x86_64-unknown-linux-gnu: $ cat t.c int __attribute__((__mode__(DI))) di; int __attribute__((__mode__(TI))) ti; int __attribute__((__mode__(OI))) oi; $ ./xgcc -B. t.c t.c:3:1: error: unable to emulate ‘OI’ int __attribute__((__mode__(OI))) oi; ^ This is trunk r189365. Ciao! Steven
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
Hi. ping [for the libiberty part]
[The gdb part needs to be updated due to recent changes there, but I'm
going to wait until the libiberty part is approved.]
On Mon, Jul 9, 2012 at 11:10 AM, Doug Evans d...@google.com wrote:
Hi.
filename_seen in gdb does a linear search, this patch changes it
to use a hash table.
Ok to check in?
I couldn't think of a good reason to put filename_hash,filename_eq in gdb,
and I like placing them close to where hashtab.c and filename_cmp are defined.
I also couldn't think of a sufficient reason to put them in a file by
themselves. Ergo adding them to filename_cmp.c, filenames.h.
[It's possible there's a program that uses filename_cmp and already
defines functions with the same names (thus this will introduce a build
failure), but that's always a risk. I couldn't find any in gdb,binutils,gcc.
Technically speaking, it's also possible that adding the #include hashtab.h
to filenames.h could introduce a build failure (e.g., some file has a static
symbol that collides with one used in hashtab.h). I'm hoping that's more of
a theoretical concern.]
2012-07-09 Doug Evans d...@google.com
include/
* filenames.h: #include hashtab.h.
(filename_hash, filename_eq): Declare.
libiberty/
* filename_cmp.c (filename_hash, filename_eq): New functions.
gdb/
* symtab.c (filename_seen): Rewrite to use a hash table.
Index: include/filenames.h
===
RCS file: /cvs/src/src/include/filenames.h,v
retrieving revision 1.10
diff -u -p -r1.10 filenames.h
--- include/filenames.h 1 Jul 2011 18:24:38 - 1.10
+++ include/filenames.h 9 Jul 2012 17:24:53 -
@@ -26,6 +26,8 @@ Foundation, Inc., 51 Franklin Street - F
#ifndef FILENAMES_H
#define FILENAMES_H
+#include hashtab.h /* for hashval_t */
+
#ifdef __cplusplus
extern C {
#endif
@@ -84,6 +86,10 @@ extern int filename_cmp (const char *s1,
extern int filename_ncmp (const char *s1, const char *s2,
size_t n);
+extern hashval_t filename_hash (const void *s);
+
+extern int filename_eq (const void *s1, const void *s2);
+
#ifdef __cplusplus
}
#endif
Index: libiberty/filename_cmp.c
===
RCS file: /cvs/src/src/libiberty/filename_cmp.c,v
retrieving revision 1.6
diff -u -p -r1.6 filename_cmp.c
--- libiberty/filename_cmp.c1 Jul 2011 18:24:39 - 1.6
+++ libiberty/filename_cmp.c9 Jul 2012 17:24:53 -
@@ -141,3 +141,52 @@ filename_ncmp (const char *s1, const cha
return 0;
#endif
}
+
+/*
+
+@deftypefn Extension hashval_t filename_hash (const void *@var{s})
+
+Return the hash value for file name @var{s} that will be compared
+using filename_cmp.
+This function is for use with hashtab.c hash tables.
+
+@end deftypefn
+
+*/
+
+hashval_t
+filename_hash (const void *s)
+{
+ /* The cast is for -Wc++-compat. */
+ const unsigned char *str = (const unsigned char *) s;
+ hashval_t r = 0;
+ unsigned char c;
+
+ while ((c = *str++) != 0)
+{
+ if (c == '\\')
+ c = '/';
+ c = TOLOWER (c);
+ r = r * 67 + c - 113;
+}
+
+ return r;
+}
+
+/*
+
+@deftypefn Extension int filename_eq (const void *@var{s1}, const void
*@var{s2})
+
+Return non-zero if file names @var{s1} and @var{s2} are equivalent.
+This function is for use with hashtab.c hash tables.
+
+@end deftypefn
+
+*/
+
+int
+filename_eq (const void *s1, const void *s2)
+{
+ /* The casts are for -Wc++-compat. */
+ return filename_cmp ((const char *) s1, (const char *) s2) == 0;
+}
Index: gdb/symtab.c
===
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.316
diff -u -p -r1.316 symtab.c
--- gdb/symtab.c29 Jun 2012 22:46:45 - 1.316
+++ gdb/symtab.c9 Jul 2012 17:24:54 -
@@ -3108,44 +3108,34 @@ operator_chars (char *p, char **end)
/* If FILE is not already in the table of files, return zero;
otherwise return non-zero. Optionally add FILE to the table if ADD
is non-zero. If *FIRST is non-zero, forget the old table
- contents. */
+ contents.
+
+ NOTE: We don't manage space for FILE, we assume FILE lives as long
+ as the caller needs. */
static int
filename_seen (const char *file, int add, int *first)
{
/* Table of files seen so far. */
- static const char **tab = NULL;
- /* Allocated size of tab in elements.
- Start with one 256-byte block (when using GNU malloc.c).
- 24 is the malloc overhead when range checking is in effect. */
- static int tab_alloc_size = (256 - 24) / sizeof (char *);
- /* Current size of tab in elements. */
- static int tab_cur_size;
- const char **p;
+ static htab_t files_seen;
+ void **slot;
if (*first)
{
- if (tab ==
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
I think it's confusing to have filename_cmp and filename_eq that do basically the same thing. Perhaps filename_eq should be filename_cmp_v or filename_cmp_hash or something, to indicate that it's *supposed* to be the same functionality as filename_cmp but with a different signature?
[patch] Make asm_out_file a text write-only file again
Hello, Geoff had to make asm_out_file read-write for PCH [1], because at the time it was necessary to read back anything written to asm_out_file and store it in the PCH. This didn't work on mingw32 so Danny Smith made the file binary [2] with the b modifier (but according to 'man fopen', only for non-POSIX). This is not necessary anymore. The attached patch changes things back to the pre-r61136 state of things. Bootstrappedtested on x86_64-unknown-linux-gnu. OK for trunk? Ciao! Steven [1] http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?limit_changes=0r1=61136r2=61135pathrev=61136) [2] http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=82643r2=82642pathrev=82643 gcc/ * toplev.c (init_asm_output): Open asm_out_file in 'w' mode. c-family/ * c-pch.c (CHECK_NO_ASM_OUT_DURING_PCH): Do not define. Remove code conditional on it. Index: toplev.c === --- toplev.c(revision 189469) +++ toplev.c(working copy) @@ -908,7 +908,7 @@ init_asm_output (const char *name) if (!strcmp (asm_file_name, -)) asm_out_file = stdout; else - asm_out_file = fopen (asm_file_name, w+b); + asm_out_file = fopen (asm_file_name, w); if (asm_out_file == 0) fatal_error (can%'t open %s for writing: %m, asm_file_name); } Index: c-family/c-pch.c === --- c-family/c-pch.c(revision 189469) +++ c-family/c-pch.c(working copy) @@ -35,24 +35,6 @@ along with GCC; see the file COPYING3. #include opts.h #include timevar.h -/* PCH was introduced before unit-at-a-time became the only supported - compilation mode. To exactly replay the content parsed at PCH generate - time, anything written to asm_out_file was read back in and stored in - the PCH, and written back out to asm_out_file while reading a PCH. - - Nowadays, ideally no action by a front end should never result in output - to asm_out_file, and front-end files should not include output.h. For - now assert that nothing is written to asm_out_file while a PCH is being - generated. Before GCC 4.8 is released, this code should be removed. - FIXME. */ -#define CHECK_NO_ASM_OUT_DURING_PCH -#ifdef CHECK_NO_ASM_OUT_DURING_PCH -extern FILE *asm_out_file; - -/* The position in the assembler output file when pch_init was called. */ -static long asm_file_startpos; -#endif - /* This is a list of flag variables that must match exactly, and their names for the error message. The possible values for *flag_var must fit in a 'signed char'. */ @@ -112,9 +94,7 @@ get_ident (void) } /* Prepare to write a PCH file, if one is being written. This is - called at the start of compilation. - - Also, print out the executable checksum if -fverbose-asm is in effect. */ + called at the start of compilation. */ void pch_init (void) @@ -153,10 +133,6 @@ pch_init (void) || fwrite (target_validity, v.target_data_length, 1, f) != 1) fatal_error (can%'t write to %s: %m, pch_file); -#ifdef CHECK_NO_ASM_OUT_DURING_PCH - asm_file_startpos = ftell (asm_out_file); -#endif - /* Let the debugging format deal with the PCHness. */ (*debug_hooks-handle_pch) (0); @@ -177,10 +153,6 @@ c_common_write_pch (void) cpp_write_pch_deps (parse_in, pch_outfile); -#ifdef CHECK_NO_ASM_OUT_DURING_PCH - gcc_assert (ftell (asm_out_file) - asm_file_startpos == 0); -#endif - gt_pch_save (pch_outfile); timevar_push (TV_PCH_CPP_SAVE);
Re: [PATCH 1/2] gcc symbol database
I'm sorry recent weeks I've got busy
No problem. I am sorry to reply this late to your message as well.
Later is the response from previous mail.
Please do not take this bad, but it will really ease communication (and
the review) if, when you reply to this message, you write your answers
*below* the parts of you are replying to, and remove the parts (of my
message) you are not replying to. I believe this is a good habit to
have at least when you are interacting with the GCC mailing lists.
Now here are my comments on your patches.
-
macro_end_expand can't be moved to _cpp_pop_context. My plugin shows later
results when `Gs callee _cpp_pop_context'.
GS multiple definition:
1)libcpp/directives.c 8130 skip_rest_of_line DEF_FUNC
2)libcpp/macro.c 67161 expand_arg DEF_FUNC
3)libcpp/macro.c 72900 cpp_get_token_1 DEF_FUNC
4)libcpp/traditional.c 10560 _cpp_scan_out_logical_line DEF_FUNC
I still think that the macro_end_expand can and should be moved to
_cpp_pop_context, even though that function is called from multiple
places. That is, in the 'if' block:
if (context-c.macro)
{
you just have to write something like:
if (in_macro_expansion_p)
/* We are at the end of the expansion of a macro. */
macro_end_expand (...);
This is what I was trying to tell you in my previous message, when I was
saying:
_cpp_pop_context is really the function that marks the end of a
given macro expansion, especially when the predicate
in_macro_expansion_p (introduced recently in trunk for gcc 4.8)
returns true.
Am I missing something?
So macro_start_expand can't be moved to enter_macro_context since the pair
should be matched in the same function cpp_get_token_1.
In the light of what I said above, I think macro_start_expand should
be moved to enter_macro_context, if you agree with my previous
statements.
1) macro_start_expand and macro_end_arg are used to tag all macro
tokens.
I think there are some concepts that need to be a bit more clearly
stated here, otherwise we'll be talking past each other.
You are basically making the pre-processor emit events at some useful
points of its operations. And then, your client code (the code of
your plugin) reacts whenever these useful events are emitted. It
reacts to these events to accomplish some useful tasks.
The tasks your wants to accomplish here, somehow, is to mark the tokens
that results from the expansion of a macro.
Right?
I think it will make the code more maintainable to have the events be
emitted at points that are well defined. And this is where I am
having issues with your patch.
So, it seems clear to me that macro_start_expand is an event that is
emitted at the beginning of the expansion of a macro.
But the meaning of the macro_end_arg event is really not clear to
me. From your code, it looks like it's a hack that lets you detect if
the macro_start_expand event really was emitted in cases where we are
sure that the macro is going to be expanded.
Let me explain a bit more.
When a macro M is encountered, enter_macro_context triggers its
expansion; but sometimes it does not. And what I understand is that, in
an ideal world, you want to call macro_start_expand only in cases where
enter_macro_context actually triggers the expansion. That way, your
plugin can use the tokens of the replacement-list of M (passed to
macro_start_expand) as it sees fit.
But in this patch, you are going a hackish route by unconditionally
calling macro_start_expand whenever M is encountered (right after
enter_macro_context is called), and if enter_macro_context does *not*
trigger the expansion of M, you tell your plugin to back out, by
calling macro_end_arg with its 'cancel' parameter set to a 'true'
boolean. Otherwise, if enter_macro_context happens to really have
expanded M, you are calling macro_end_arg with its 'cancel' parameter
set to a 'false' value, effectively telling your plugin OK, M was
really expanded.
And what I was saying in my previous email is that you could arrange
to emit the macro_start_expand event *only* when you are sure that
enter_macro_context is really going to expand M.
That is why I was saying in my previous message:
IMHO, it's more maintainable to put the call to
pfile-cb.macro_start_expand inside enter_macro_context, as that
is the function that really triggers the macro expansion.
And then, I told you where to put that call in enter_macro_context so
that you are sure to emit the event only when you are sure
enter_macro_context is going to expand M (and I am repeating it here
again):
Maybe if you put the call to macro_start_expand in this
enter_macro_context function only after we are sure we are going
to actually proceed with the expansion
return 0;
}
... here, then you wouldn't need the macro_end_arg at
all. Would that make sense?
2)
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie d...@redhat.com wrote: I think it's confusing to have filename_cmp and filename_eq that do basically the same thing. Perhaps filename_eq should be filename_cmp_v or filename_cmp_hash or something, to indicate that it's *supposed* to be the same functionality as filename_cmp but with a different signature? To be clear, filename_cmp is to strcmp as filename_eq is to streq. ref: STREQ in libiberty/regex.c: # define STREQ(s1, s2) ((strcmp (s1, s2) == 0)) Given that, I think the names are fine as is, but I'm happy to change them. I like eq, it's what hashtab uses (e.g. htab_eq_pointer). How about filename_eq_hash?
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
If there's precedent, I'm not worried about it. Ok to check in.
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
Date: Fri, 13 Jul 2012 12:36:44 -0700 From: Doug Evans d...@google.com Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie d...@redhat.com wrote: I think it's confusing to have filename_cmp and filename_eq that do basically the same thing. Perhaps filename_eq should be filename_cmp_v or filename_cmp_hash or something, to indicate that it's *supposed* to be the same functionality as filename_cmp but with a different signature? To be clear, filename_cmp is to strcmp as filename_eq is to streq. ref: STREQ in libiberty/regex.c: # define STREQ(s1, s2) ((strcmp (s1, s2) == 0)) Given that, I think the names are fine as is, but I'm happy to change them. Sorry if I'm missing something, but why do we need to advertise such a function at all? Given that libiberty already provides filename_cmp, isn't it trivial to write something like filename_eq whenever someone needs to use hashes of file names?
Re: __int256
On Fri, 13 Jul 2012, Georg-Johann Lay wrote: The avr port defines __int24 and __uint24. Is that compatible with a generic __int24? In my view, given suitable generic support ports like that should move to __intN keywords (usable with unsigned, so unsigned __intN would be the unsigned version of that type) and other type names such as __uint24 or __uint128_t should be considered deprecated backwards-compatibility typedefs (or if necessary macros) provided by the back ends. It would be good to have a reasonably thorough generic set of testcases for the various special-width integer types, used on whichever targets support those widths. If you have a 24-bit type now it might be good to extend the floating-point / integer conversion tests I mentioned to cover it -- Joseph S. Myers jos...@codesourcery.com
Re: Fix PR53908
On Fri, Jul 13, 2012 at 10:56 AM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: From: Richard Guenther richard.guent...@gmail.com Date: Fri, 13 Jul 2012 10:08:05 +0200 On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: Ok for 4.7 too? Of course. Committed to trunk as follows, including the test-case which doesn't fail on trunk but does on 4.6 and 4.7. Will commit to 4.7 branch too. I'll leave 4.6 to those interested enough to invest time to do the testing. I've bootstrapped and tested this on x86_64-unknown-linux-gnu. Without the patch, the test case fails, with the patch it passes. OK for 4.6 too? Ciao! Steven
[PATCH, committed] Fix PR53955
Configure with --disable-build-poststage1-with-cxx exposed functions
that should have been marked static. Bootstrapped on
powerpc-unknown-linux-gnu, committed as obvious.
Thanks,
Bill
2012-07-13 Bill Schmidt wschm...@linux.ibm.com
PR bootstrap/53955
* config/spu/spu.c (spu_init_cost): Mark static.
(spu_add_stmt_cost): Likewise.
(spu_finish_cost): Likewise.
(spu_destroy_cost_data): Likewise.
* config/i386/i386.c (ix86_init_cost): Mark static.
(ix86_add_stmt_cost): Likewise.
(ix86_finish_cost): Likewise.
(ix86_destroy_cost_data): Likewise.
* config/rs6000/rs6000.c (rs6000_init_cost): Mark static.
(rs6000_add_stmt_cost): Likewise.
(rs6000_finish_cost): Likewise.
(rs6000_destroy_cost_data): Likewise.
Index: gcc/config/spu/spu.c
===
--- gcc/config/spu/spu.c(revision 189460)
+++ gcc/config/spu/spu.c(working copy)
@@ -6919,7 +6919,7 @@ spu_builtin_vectorization_cost (enum vect_cost_for
/* Implement targetm.vectorize.init_cost. */
-void *
+static void *
spu_init_cost (struct loop *loop_info ATTRIBUTE_UNUSED)
{
unsigned *cost = XNEW (unsigned);
@@ -6929,7 +6929,7 @@ spu_init_cost (struct loop *loop_info ATTRIBUTE_UN
/* Implement targetm.vectorize.add_stmt_cost. */
-unsigned
+static unsigned
spu_add_stmt_cost (void *data, int count, enum vect_cost_for_stmt kind,
struct _stmt_vec_info *stmt_info, int misalign)
{
@@ -6956,7 +6956,7 @@ spu_add_stmt_cost (void *data, int count, enum vec
/* Implement targetm.vectorize.finish_cost. */
-unsigned
+static unsigned
spu_finish_cost (void *data)
{
return *((unsigned *) data);
@@ -6964,7 +6964,7 @@ spu_finish_cost (void *data)
/* Implement targetm.vectorize.destroy_cost_data. */
-void
+static void
spu_destroy_cost_data (void *data)
{
free (data);
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 189460)
+++ gcc/config/i386/i386.c (working copy)
@@ -40066,7 +40066,7 @@ ix86_autovectorize_vector_sizes (void)
/* Implement targetm.vectorize.init_cost. */
-void *
+static void *
ix86_init_cost (struct loop *loop_info ATTRIBUTE_UNUSED)
{
unsigned *cost = XNEW (unsigned);
@@ -40076,7 +40076,7 @@ ix86_init_cost (struct loop *loop_info ATTRIBUTE_U
/* Implement targetm.vectorize.add_stmt_cost. */
-unsigned
+static unsigned
ix86_add_stmt_cost (void *data, int count, enum vect_cost_for_stmt kind,
struct _stmt_vec_info *stmt_info, int misalign)
{
@@ -40103,7 +40103,7 @@ ix86_add_stmt_cost (void *data, int count, enum ve
/* Implement targetm.vectorize.finish_cost. */
-unsigned
+static unsigned
ix86_finish_cost (void *data)
{
return *((unsigned *) data);
@@ -40111,7 +40111,7 @@ ix86_finish_cost (void *data)
/* Implement targetm.vectorize.destroy_cost_data. */
-void
+static void
ix86_destroy_cost_data (void *data)
{
free (data);
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 189460)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -3522,7 +3522,7 @@ rs6000_preferred_simd_mode (enum machine_mode mode
/* Implement targetm.vectorize.init_cost. */
-void *
+static void *
rs6000_init_cost (struct loop *loop_info ATTRIBUTE_UNUSED)
{
unsigned *cost = XNEW (unsigned);
@@ -3532,7 +3532,7 @@ rs6000_init_cost (struct loop *loop_info ATTRIBUTE
/* Implement targetm.vectorize.add_stmt_cost. */
-unsigned
+static unsigned
rs6000_add_stmt_cost (void *data, int count, enum vect_cost_for_stmt kind,
struct _stmt_vec_info *stmt_info, int misalign)
{
@@ -3559,7 +3559,7 @@ rs6000_add_stmt_cost (void *data, int count, enum
/* Implement targetm.vectorize.finish_cost. */
-unsigned
+static unsigned
rs6000_finish_cost (void *data)
{
return *((unsigned *) data);
@@ -3567,7 +3567,7 @@ rs6000_finish_cost (void *data)
/* Implement targetm.vectorize.destroy_cost_data. */
-void
+static void
rs6000_destroy_cost_data (void *data)
{
free (data);
Re: __int256
On Jul 13, 2012, at 6:39 AM, Joseph S. Myers wrote: On Fri, 13 Jul 2012, Mike Stump wrote: As I said, in Kenny's next patch, we add support for all constants of any size the port needs. I don't know if you've ever tried to use the compiler with OImode, but, what I can say is the bugs are not terribly latent at times and they are not hidden very well at all, today. The goal of course, is to improve that and make it work better. These issues that I know about existed, prior to my patch, and we are in the process of fixing them. Some have been fixed, others remain to be fixed. The issues I'm thinking about exist with or without my patch to the frontend to support __int256. Merely adding __int256 doesn't make any of the issues I'm aware of appear, and the issues I'm aware of don't appear with sizes less than 256. I think the patches allowing constants of such a type to work should go in first, I understand the beauty of putting in the const wide int stuff first... I don't think it matters much to me... but I might ask why? I think we have added support for all in-tree gcc ports for all possible testcases. Do you know of a single testcase that fails on a single port? and the libgcc support, I wanted to separate the patches and keep them in small well focused review groups, as they hit wildly different reviewers. before we consider the support for the type from the front ends using keywords as opposed to mode attributes. I believe that libgcc support for all existing in-tree ports of gcc is already complete. We'd be happy to do any libgcc work necessary to make any testcase work on any existing in-tree gcc port. If you know of any work that remains to be done, please provide a testcase, and I can ensure the work is complete. You're using OImode in target-independent code. But I don't see a change to machmode.def to add it as a machine-independent mode. Ah, good catch. I've moved OImode up from the ports in the patch below. Nor do I think it *should* be a machine-independent mode; it's sufficiently specialised that it should be possible to do things without it needing to be one. Hum, how about this, if you fix __int128 to do it the way you want, then I will fix __int256 to copy the style that is set by __int128. I'd rather have them be exactly the same, so that testing for one will more likely help the other one. I don't have a good idea of a better way to do this. Longer term, I'd like __int256 to be universally available, just like long is and just like long long is. We can't do that yet, I think doing that is premature. See my comments (several messages on 1 July 2011) about 40-bit integer support; Ick, 40 / 8 is 5, and 5 isn't a power of 2, therefore, they are different cases to me.I appreciate that you'd like to see HImode go, wake me up when that is done. carefully designed target hooks to specify the keywords / modes for target-specific integer types are better than adding more and more cases to several difference places in the target-independent compiler. Agreed, on general principals. And, if I waned 60 bit support, or 250 bit support, I'm right there with you. However, 32 support, has, over time, proven to be the right answer. Likewise, merely shifted by some years later, 64 bit support. While 128 and 256 may seem to you to be as odd now as 64 bit support was back when 8 was all the rage... well, I'll stop there. Let me just say, these are special because they are powers of 2. If you can sketch out a better incantation for the 128 and 256 bit support, I can try my hand at improving it. I just don't know any better form for it. I'd argue that all powers of twos in use by any port, should be put into machmode.def. I can rip out all TImode handling, leaving the int128 handling, the TImode code I think is redundant with the int128 code. Would you like me to do that? I just don't want to be on the hook when it doesn't work out for someone. __int128_t and __uint128_t are legacy built-in typedef names and I don't think there should be any analogue for 256-bit integers; just __int256 and unsigned __int256. Ok, fixed. I have put the patch through the C test suite, and it doesn't show any failures. Certainly you should add analogues of gcc.dg/torture/fp-int-convert-*timode.c for the new type and verify that those tests all work for it. It would seem advisable to add tests covering pure integer operations for the new type (all the C integer operations), for both constants and runtime evaluation, as well. Ok, fixed. I put in the portable testcase, esoteric things like 80 bit floating point numbers can be added by people that like such things. diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def index d8e9e56..564e5c7 100644 --- a/gcc/builtin-types.def +++ b/gcc/builtin-types.def @@ -72,6 +72,8 @@ DEF_PRIMITIVE_TYPE (BT_LONG, long_integer_type_node)
Re: __int256
On Jul 13, 2012, at 9:20 AM, Georg-Johann Lay wrote: We have another patch underway to do N-bit constant ints, where N is defined by the port. This patch is in the process of being reviewed now, and Kenny should be able to submit it shortly. The avr port defines __int24 and __uint24. Is that compatible with a generic __int24? A 24-bit int is smaller than a HOST_WIDE_INT (right!), so the everything related to 24-bit constants is handled by existing CONST_INT code. Our patch doesn't change 24-bit constants. I've never seen a generic __int24, so I don't know what you mean, and I don't know what you mean by compatible. In the language standard, compatible is a very specific term, and it relates to the front-end code. I'm not altering or changing any front end semantics for any type, other than __int256, so the answer post my patch, is the same answer as previous to my patch. I hope that might answer your question, if not, expound on the question a little and I can try again.
Re: __int256
On Jul 13, 2012, at 11:21 AM, Nathan Froyd wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE (OI, 32);
./spu/spu-modes.def:29:INT_MODE (OI, 32);
./ia64/ia64-modes.def:68:INT_MODE (OI, 32);
./i386/i386-modes.def:88:INT_MODE (OI, 32);
./arm/arm-modes.def:82:INT_MODE (OI, 32);
Now, go back and check the target to see if they return true for:
@deftypefn {Target Hook} bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
@var{mode})
Define this to return nonzero if the port is prepared to handle
insns involving scalar mode @var{mode}. For a scalar mode to be
considered supported, all the basic arithmetic and comparisons
must work.
The default version of this hook returns true for any mode
required to handle the basic C types (as defined by the port).
Included here are the double-word arithmetic supported by the
code in @file{optabs.c}.
@end deftypefn
I'll wait. You'll notice that my patch uses that answer to determine if
support for __int256 is enabled.
Re: __int256
On Fri, 13 Jul 2012, Mike Stump wrote: I understand the beauty of putting in the const wide int stuff first... I don't think it matters much to me... but I might ask why? I think we have added support for all in-tree gcc ports for all possible testcases. Do you know of a single testcase that fails on a single port? We need to be careful about putting in changes that are only relevant for out-of-tree ports, because it's impossible for anyone using FSF GCC to validate whether the code in question works properly. Fixing issues that look like they would appear with a port with 256-bit integer support, and adding associated testcases, helps convince peopel that the code is sound. So does implementing it in a suitably generic way, so that the same code paths are used by narrower types for in-tree ports rather than there being code purely for 256-bit integers that is dead code for FSF GCC. I believe that libgcc support for all existing in-tree ports of gcc is already complete. We'd be happy to do any libgcc work necessary to make any testcase work on any existing in-tree gcc port. If you know of any work that remains to be done, please provide a testcase, and I can ensure the work is complete. The question is whether someone could just add their own 256-bit port and reasonably expect it to work. And when submitting patches, it's the job of the submitter to make it easy for the reviewer to give them an A - submit a patch series that makes it transparent to the reviewer that any questions they thought up have already been addressed (because they can see relevant testcases added to the testsuite, for example). Hum, how about this, if you fix __int128 to do it the way you want, then I will fix __int256 to copy the style that is set by __int128. I'd rather have them be exactly the same, so that testing for one will more likely help the other one. I don't have a good idea of a better way to do this. Longer term, I'd like __int256 to be universally available, just like long is and just like long long is. We can't do that yet, I think doing that is premature. Making a type universally available is dangerous because there are ABI implications - the function-calling ABI for a type should be worked out with the ABI maintainers for each relevant architecture rather than just blindly adding it and hoping that what the back end happens to do is a sensible ABI for all other compilers for that architecture to copy. The ABI for complex numbers on some architectures is an awful mess because of just blindly making them universally available without working out ABIs properly If you can sketch out a better incantation for the 128 and 256 bit support, I can try my hand at improving it. I just don't know any better form for it. I'd argue that all powers of twos in use by any port, should be put into machmode.def. I can rip out all TImode handling, leaving the int128 handling, the TImode code I think is redundant with the int128 code. Would you like me to do that? I just don't want to be on the hook when it doesn't work out for someone. I believe I sketched things in July 2011 - I'd guess sorting this out properly and incrementally is on the order of a ten-patch series (each patch being small and clearly safe for existing targets), not a hundred-patch series. For example, I said: * The c_common_type_for_size code using those nodes is suspicious. Front ends shouldn't care about modes like that. Check standard types, otherwise defer to something generic that loops over available types or modes or builds a type as needed. So in that case I'd do the following: * Check standard types, int, signed char, short, long, long long, as at present. * Check a list of __intN types. The list would be target-dependent. Targets supporting __int128 would define a relevant hook to produce the list containing just __int128. Your new target would define it to contain __int128 and __int256. * Check widest_integer_literal_type_node, as at present. * Check for modes, not through globals hardcoded for each mode as at present but through iterating through integer modes. Maybe getting rid of the globals such as intQI_type_node, replacing them by something sized to cover whatever integer modes on the target can be used for integer types and replacing code using those globals by something iterating over integer modes, would be a good first step. It shouldn't be that hard to move on to making the existence of TImode target-specific (I'd guess there would be a common .def file used by all targets that have TImode). -- Joseph S. Myers jos...@codesourcery.com
Re: [RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin
On Jul 13, 2012, at 12:28 AM, Iain Sandoe wrote: On 11 Jul 2012, at 00:01, Iain Sandoe wrote: Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed patch causes no regressions. ppc-darwin 8 tests are still running, but it bootstrapped (500M G4, 24hrs for c/c++ build test). FAOD, from a testing perspective this is fine - but it needs Mike's OK, Hum, no, it doesn't, it has already been approved by Paolo, and I don't disagree with that approval :-)
Re: [PATCH 1/6] Thread pointer built-in functions, core parts
On Jul 12, 2012, at 11:47 PM, Chung-Lin Tang clt...@codesourcery.com wrote: and then for the return value, maybe a const0_rtx for Pmode. A little unsure what you mean. Are you referring to return const0_rtx for default_expand_builtin_thread_pointer() instead of NULL? Yes. NULL has the habit of crashing things if they don't expect it.
Re: [PATCH] Make LTO type merging cheaper
On Fri, Jul 13, 2012 at 1:11 AM, Richard Guenther rguent...@suse.de wrote: A patch that's in my local tree for quite some time. This removes redundant tests. LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-07-13 Richard Guenther rguent...@suse.de * gimple.c (gimple_types_compatible_p_1): Remove redundant type attribute comparisons. (gimple_canonical_types_compatible_p): Likewise. This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53959 -- H.J.
Re: __int256
On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote: On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote: On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote: I just checked all in tree gcc targets, and none claim OImode support. ./s390/s390-modes.def:23:INT_MODE (OI, 32); ./spu/spu-modes.def:29:INT_MODE (OI, 32); ./ia64/ia64-modes.def:68:INT_MODE (OI, 32); ./i386/i386-modes.def:88:INT_MODE (OI, 32); ./arm/arm-modes.def:82:INT_MODE (OI, 32); At least for ARM, OImode gets used for Neon intrinsics. Can't speak for the other ports, though. On x86_64-unknown-linux-gnu: $ cat t.c int __attribute__((__mode__(DI))) di; int __attribute__((__mode__(TI))) ti; int __attribute__((__mode__(OI))) oi; $ ./xgcc -B. t.c t.c:3:1: error: unable to emulate ‘OI’ int __attribute__((__mode__(OI))) oi; ^ This is trunk r189365. Yup, exactly as I expected. The arm folks I suspect will discover the same.
Re: __int256
On Jul 13, 2012, at 4:21 PM, Joseph S. Myers wrote: On Fri, 13 Jul 2012, Mike Stump wrote: I understand the beauty of putting in the const wide int stuff first... I don't think it matters much to me... but I might ask why? I think we have added support for all in-tree gcc ports for all possible testcases. Do you know of a single testcase that fails on a single port? We need to be careful about putting in changes that are only relevant for out-of-tree ports, because it's impossible for anyone using FSF GCC to validate whether the code in question works properly. Anyone that wants to validate my work can trivially do so. They are free to grab any of the OI ports, and turn on scalar OImode, and then test. Because it is trivial to validate it, I have no clue what you mean by impossible. Does that mean that you have no access to an x86_64? I just can't begin to understand what you mean by impossible, can you elaborate? The question is whether someone could just add their own 256-bit port and reasonably expect it to work. No, they can not reasonable expect it to work. They are guaranteed that any expectations of goodness are misplaced, I will personally make that guarantee. What they can expect to work, are those things they have tested that work; that's all. The compiler has bugs, that those bugs prevent good code from working. This has always been the case, and will always be the case. I'm a realist, what I can say about the patch is that the compiler will work better with the patch, than without the patch. The patch lies in the direction of goodness, and that it is impossible to get to goodness without either applying the patch, or creating a virtually identical patch. And when submitting patches, it's the job of the submitter to make it easy for the reviewer to give them an A I don't see what you all see. For example, you see that it is impossible to validate my work, I only see that it is trivially possible to validate my work. I can't explain the difference in viewpoint. Richard says that the patch introduces wrong-code bugs almost everywhere in the compiler, I only see that it does not. I can't explain the difference. Richard says I expose users to bugs, I see that I do not. I can't explain the difference. I see that you worry that the patch is unsound, I only see that it is not. I can't explain the difference. I see that you want to pend this on libgcc work. I see that there is no benefit to doing that. I can't explain the difference. I see that Richard wants to pend the work on the cont_wide_int work, I see that there is no benefit to doing that. I can't explain the difference. The list is seemingly endless... I don't have a proof the work is sound, and cannot sign up to provide one at this time. I do not have the time at this point to fix all 256-bit bugs in the compiler. I don't have time to add support for all possible future ports of gcc. I don't have time to craft abis for all gcc ports. I don't have time to implement argument passing for all other ports. I don't have time to validate __int256 for you. I don't have time to re-implement __int128 support in the compiler for you. So, are there any other specific actionable things I can do for you to make the patch acceptable?
