Re: [patch] Add test for PR c++/53531
OK, thanks. Jason
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen 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
wrote:
>> From: Richard Sandiford
>> 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: __int256
On Fri, Jul 13, 2012 at 3:59 AM, 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. > > 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? 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. Richard. > >
Re: [patch] Add block debug info to phi_arg_d
On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher wrote: > On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen 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 wrote:
> On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
> wrote:
>>> From: Richard Sandiford
>>> 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 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.
Re: [PATCH 1/6] Thread pointer built-in functions, core parts
Richard Sandiford 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 >>>
Re: Fix PR53908
> From: Richard Guenther > Date: Fri, 13 Jul 2012 09:37:13 +0200 > On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher > wrote: > > On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson > > wrote: > >>> From: Richard Sandiford > >>> 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 wrote: >> From: Richard Guenther >> Date: Fri, 13 Jul 2012 09:37:13 +0200 > >> On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher >> wrote: >> > On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson >> > wrote: >> >>> From: Richard Sandiford >> >>> 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
* 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 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
> Date: Fri, 13 Jul 2012 10:08:05 +0200
> On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson
> 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
Steven Bosscher
Bernd Schmidt
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
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)
+{
+ int ret_val = -1;
+ char *authent;
+ authent = ha_get_string_value();
+ if (authent) {
+*user = g_strdup(auth
Re: __int256
On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump wrote: > On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote: >> On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump 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 wrote: > On Fri, Jul 13, 2012 at 9:36 AM, Richard Guenther > 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
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 @@
}
template::value>::type>
+ std::enable_if::value>::type>
std::pair
insert(_Pair&& __obj)
{
@@ -261,8 +261,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(const_iterator __hint, _Pair&& __obj)
{
@@ -663,8 +663,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(_Pair&& __obj)
{
@@ -675,8 +675,8 @@
}
template::value>::type>
+ std::enable_if::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__
template::value>::type>
+ std::enable_if::value>::type>
std::pair
insert(_Pair&& __x)
{
@@ -244,8 +244,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
template::value>::type>
+ std::enable_if::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__
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(_Pair&& __x)
{ return iterator(_Base::insert(std::forward<_Pair>(__x)), this); }
@@ -227,8 +227,8 @@
#ifdef __GXX_EXPERIMENTAL_CXX0X__
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(const_iterator __position, _Pair&& __x)
{
Index: include/profile/unordered_map
===
--- include/profile/unordered_map (revision 189440)
+++ include/profile/unordered_map (working copy)
@@ -1,6 +1,6 @@
// Profiling unordered_map/unordered_multimap implementation -*- C++ -*-
-// Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -214,8 +214,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
std::pair
insert(_Pair&& __obj)
{
@@ -227,8 +227,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(const_iterator __iter, _Pair&& __v)
{
@@ -503,8 +503,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(_Pair&& __obj)
{
@@ -515,8 +515,8 @@
}
template::value>::type>
+ std::enable_if::value>::type>
iterator
insert(const_iterator __iter, _Pair&& __v)
{
Index: include/profile/map.h
===
--- include/profile/map.h (revision 189440)
+++ include/profile/map.h (working copy)
@@ -1,6 +1,6 @@
// Profiling map implementation -*- C++ -*-
-// Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redist
[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
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 wrote: > > On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher > wrote: > > On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen 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 wrote: > On Fri, Jul 13, 2012 at 3:36 PM, Richard Guenther > wrote: >> >> On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher >> wrote: >> > On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen 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
Date: Mon, 18 Jun 2012 18:10:19 -0700
Subject: [PATCH] XLP scheduling.
2012-07-13 Chung-Lin Tang
Maxim Kuvyrkov
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.
(mfhi_,mthi_):
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 +283,7 @@
prefetch,prefetchx,condmove,mtc,mfc,mth
[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
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 d
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
[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 * 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 : > 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
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
+
+ __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
* 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
* 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
+i386_pe_seh_emit_exce
Re: [patch] Call free_after_parsing earlier
On Thu, Jul 12, 2012 at 9:21 AM, Richard Guenther
wrote:
> On Wed, Jul 11, 2012 at 9:39 PM, Steven Bosscher
> 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
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
, 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
, 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
, 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
, 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
, 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
, 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
(node=0x770d5750) at ../../trunk/gcc/cgraphunit.c:658
#22 0x00fc5c13 in cgraph_analyze_fun
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
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 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. -Nathan
Re: __int256
On Fri, Jul 13, 2012 at 8:21 PM, 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); > > 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 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
>
> 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 ta
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.
Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?
Ciao!
Steven
[1]
http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?limit_changes=0&r1=61136&r2=61135&pathrev=61136)
[2]
http://gcc.gnu.org/viewcvs/trunk/gcc/toplev.c?r1=82643&r2=82642&pathrev=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. W
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 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 > Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > > On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie 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: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
On Fri, Jul 13, 2012 at 12:47 PM, Eli Zaretskii wrote: >> Date: Fri, 13 Jul 2012 12:36:44 -0700 >> From: Doug Evans >> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org >> >> On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie 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? It's a "matched set" with filename_hash. The hashtab.c constructors take a hash_f function pointer and an eq_f function pointer.
Re: Fix PR53908
On Fri, Jul 13, 2012 at 10:56 AM, Hans-Peter Nilsson wrote: >> From: Richard Guenther >> Date: Fri, 13 Jul 2012 10:08:05 +0200 >> On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson >> 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
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
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 :-)
[Committed] fix testcase cleanup of octeon2-pipe-1.c and octeon-pipe-1.c
Hi,
The two testcases octeon2-pipe-1.c and octeon-pipe-1.c cleanup their
dump files using cleanup-tree-dump but the dump files where are
supposed to be cleaned up are rtl ones. This patch which I committed
as obvious fix that.
Committed after testing on mips64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
2012-07-13 Andrew Pinski
* gcc.target/mips/octeon2-pipe-1.c: Use cleanup-rtl-dump
rather than cleanup-tree-dump.
* gcc.target/mips/octeon-pipe-1.c: Likewise.
Index: gcc.target/mips/octeon2-pipe-1.c
===
--- gcc.target/mips/octeon2-pipe-1.c(revision 189401)
+++ gcc.target/mips/octeon2-pipe-1.c(working copy)
@@ -8,4 +8,4 @@ NOMIPS16 int f (int a, int b)
}
/* { dg-final { scan-rtl-dump "octeon_mult\\*17" "sched2" } } */
-/* { dg-final { cleanup-tree-dump "sched2" } } */
+/* { dg-final { cleanup-rtl-dump "sched2" } } */
Index: gcc.target/mips/octeon-pipe-1.c
===
--- gcc.target/mips/octeon-pipe-1.c (revision 189401)
+++ gcc.target/mips/octeon-pipe-1.c (working copy)
@@ -8,4 +8,4 @@ NOMIPS16 int f (int a, int b)
}
/* { dg-final { scan-rtl-dump "octeon_mult\\*71" "sched2" } } */
-/* { dg-final { cleanup-tree-dump "sched2" } } */
+/* { dg-final { cleanup-rtl-dump "sched2" } } */
Index: ChangeLog
===
--- ChangeLog (revision 189476)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-07-13 Andrew Pinski
+
+ * gcc.target/mips/octeon2-pipe-1.c: Use cleanup-rtl-dump
+ rather than cleanup-tree-dump.
+ * gcc.target/mips/octeon-pipe-1.c: Likewise.
+
2012-07-13 Richard Guenther
PR tree-optimization/53907
Re: [PATCH 1/6] Thread pointer built-in functions, core parts
On Jul 12, 2012, at 11:47 PM, Chung-Lin Tang 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 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 > > * 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 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?
Re: [RFA libiberty, gdb] Add hashtab support to filename_ncmp.c and use it in gdb.
> Date: Fri, 13 Jul 2012 14:26:15 -0700 > From: Doug Evans > Cc: d...@redhat.com, gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org > > > 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? > > It's a "matched set" with filename_hash. > The hashtab.c constructors take a hash_f function pointer and an eq_f > function pointer. I understand all that, but why would the eq_f function need to be an external function on its own? E.g., if we were to write a qsort replacement, would we have a suitable string comparison function declared extern, when it is a trivial wrapper around strcmp?
Re: [RFT] Remove -fno-tree-dominator-opts from libgcc/config/t-darwin
On 14 Jul 2012, at 00:21, Mike Stump wrote: > 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 :-) apologies, I missed a post.
