[patch gimplify]: Fix for PR/48984

[Kai Tietz]

Hello,

this patch fixes the issue reported in PR/48984.  Issue is that
fortran has multiple BOOLEAN_TYPE'ed types with different modes. So
the check for BOOLEAN_TYPE in gimplification is wrong and instead we
need to check for identify to boolean_type_node.

ChangeLog

2011-05-13  Kai Tietz

* gimplify.c (gimplify_expr): Check for boolean_type_node instead
for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
(gimple_boolify): Check for cast for boolean_type_node instead for
BOOLEAN_TYPE.

Bootstrap passed and now doing fortran testsuite run to verify.

Regards,
Kai

Index: gimplify.c
===
--- gimplify.c  (revision 173711)
+++ gimplify.c  (working copy)
@@ -2848,7 +2848,7 @@
 default:
   /* Other expressions that get here must have boolean values, but
 might need to be converted to the appropriate mode.  */
-  if (TREE_CODE (type) == BOOLEAN_TYPE)
+  if (type == boolean_type_node)
return expr;
   return fold_convert_loc (loc, boolean_type_node, expr);
 }
@@ -6754,7 +6754,7 @@
  }

case TRUTH_NOT_EXPR:
- if (TREE_CODE (TREE_TYPE (*expr_p)) != BOOLEAN_TYPE)
+ if (TREE_TYPE (*expr_p) != boolean_type_node)
{
  tree type = TREE_TYPE (*expr_p);
  *expr_p = fold_convert (type, gimple_boolify (*expr_p));
@@ -7199,7 +7199,7 @@
   fold_truth_not_expr) happily uses operand type and doesn't
   automatically uses boolean_type as result, we need to keep
   orignal type.  */
-   if (TREE_CODE (org_type) != BOOLEAN_TYPE)
+   if (org_type != boolean_type_node)
  {
*expr_p = fold_convert (org_type, *expr_p);
ret = GS_OK;

Re: [patch gimplify]: Fix for PR/48984

[Eric Botcazou]

> 2011-05-13  Kai Tietz
>
> * gimplify.c (gimplify_expr): Check for boolean_type_node instead
> for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
> (gimple_boolify): Check for cast for boolean_type_node instead for
> BOOLEAN_TYPE.

Missing PR middle-end/48984 at the top.

-- 
Eric Botcazou

Re: PATCH: Change maybe_eh_return to bool

[Uros Bizjak]

On Thu, May 12, 2011 at 11:58 PM, H.J. Lu  wrote:

>> FWIW, the return type of ix86_save_reg (and ix86_hard_regno_mode_ok
>> and perhaps many others...) can also be changed to bool.
>
> This patch changes the return type of ix86_save_reg to bool and return
> value of ix86_hard_regno_mode_ok to bool.
>
> OK for trunk?

> 2011-05-12  H.J. Lu  
>
>        * config/i386/i386.c (ix86_save_reg): Change return type to
>        bool.
>        (ix86_hard_regno_mode_ok): Change return value to bool.
>

OK, but please update the function comments to say "Return TRUE ..."
instead of "Return 1 ..."

Also:

> -  return reload_in_progress || reload_completed;
> + return true;
> +  return reload_in_progress != 0 || reload_completed != 0;

return !can_create_pseudo_p ();

Thanks,
Uros.

Re: [Patch,AVR]: Fix PR27663

[Denis Chertykov]

2011/5/11 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/5/2 Georg-Johann Lay :
>>
>>> This is a fix for an optimization flaw when a long value is composed
>>> from byte values.
>>>
>>> For -fsplit-wide-types (which is still default for avr) the code is
>>> worse than with -fno-split-wide-types. The code for the test case is
>>> better in either situations, i.e. compared to code without the patch,
>>> but it is still not optimal.
>>>
>>> Fixing this by some combine patterns is the only thing the BE can do.
>>> I did not write more complex patterns because things get too complex
>>> with little performance gain.
>>>
>>> Tested without regressions.
>>>
>>> Johann
>>>
>>> 2011-05-02  Georg-Johann Lay  
>>>
>>>      PR target/27663
>>>      * config/avr/predicates.md (const_8_16_24_operand): New predicate.
>>>      * config/avr/avr.md ("*iorqi.byte0",
>>>      "*iorqi.byte1-3"): New define_insn_and_split patterns.
>>>
>> I'm sorry, but I dot'n like to have a both combiner related patches in
>> port because code improvement isn't much and your patterns are
>> difficult to understand and maintain.
>>
>> May be somebody else have a different oppinion ?
>> I'm open to discussion.
>>
>> Denis.
>
> Let me add that the patch is generic enough to also improve ORing HI against
> QI like described in
>
> http://gcc.gnu.org/PR41076
>
> which is not uncommon on avr.

You right here.
Please, apply the patch.

Denis.

Re: [PATCH] use AS_HELP_STRING throughout gcc/configure.ac

[Andreas Schwab]

"Ralf Wildenhues"  writes:

> Yes, if you visually compared the diff of configure and of './configure
> --help' before and after the change, to only contain intended changes.

Yes, I did.  The help texts are now nicely aligned and folded, except
for a few which come from outside (more to follow).

Thanks, Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

[PATCH] Optimize fix for PR48172

[Richard Guenther]

The following avoids the multiplication by niters when the step
is equal.

Boostrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2011-05-13  Richard Guenther  

PR tree-optimization/48172
* tree-vect-loop-manip.c (vect_vfa_segment_size): Avoid
multiplying by number of iterations for equal step.
(vect_create_cond_for_alias_checks): Likewise.

Index: gcc/tree-vect-loop-manip.c
===
*** gcc/tree-vect-loop-manip.c  (revision 173704)
--- gcc/tree-vect-loop-manip.c  (working copy)
*** vect_create_cond_for_align_checks (loop_
*** 2353,2375 
  
 Input:
   DR: The data reference.
!  VECT_FACTOR: vectorization factor.
!  SCALAR_LOOP_NITERS: number of iterations.
  
 Return an expression whose value is the size of segment which will be
 accessed by DR.  */
  
  static tree
! vect_vfa_segment_size (struct data_reference *dr, int vect_factor,
!  tree scalar_loop_niters)
  {
tree segment_length;
segment_length = size_binop (MULT_EXPR,
   fold_convert (sizetype, DR_STEP (dr)),
!  size_int (vect_factor));
!   segment_length = size_binop (MULT_EXPR,
!  segment_length,
!  fold_convert (sizetype, scalar_loop_niters));
if (vect_supportable_dr_alignment (dr, false)
  == dr_explicit_realign_optimized)
  {
--- 2353,2370 
  
 Input:
   DR: The data reference.
!  LENGTH_FACTOR: segment length to consider.
  
 Return an expression whose value is the size of segment which will be
 accessed by DR.  */
  
  static tree
! vect_vfa_segment_size (struct data_reference *dr, tree length_factor)
  {
tree segment_length;
segment_length = size_binop (MULT_EXPR,
   fold_convert (sizetype, DR_STEP (dr)),
!  fold_convert (sizetype, length_factor));
if (vect_supportable_dr_alignment (dr, false)
  == dr_explicit_realign_optimized)
  {
*** vect_create_cond_for_alias_checks (loop_
*** 2417,2423 
  
ddr_p ddr;
unsigned int i;
!   tree part_cond_expr;
  
/* Create expression
   ((store_ptr_0 + store_segment_length_0) < load_ptr_0)
--- 2412,2418 
  
ddr_p ddr;
unsigned int i;
!   tree part_cond_expr, length_factor;
  
/* Create expression
   ((store_ptr_0 + store_segment_length_0) < load_ptr_0)
*** vect_create_cond_for_alias_checks (loop_
*** 2465,2474 
  vect_create_addr_base_for_vector_ref (stmt_b, cond_expr_stmt_list,
  NULL_TREE, loop);
  
!   segment_length_a = vect_vfa_segment_size (dr_a, vect_factor,
!   scalar_loop_iters);
!   segment_length_b = vect_vfa_segment_size (dr_b, vect_factor,
!   scalar_loop_iters);
  
if (vect_print_dump_info (REPORT_DR_DETAILS))
{
--- 2460,2471 
  vect_create_addr_base_for_vector_ref (stmt_b, cond_expr_stmt_list,
  NULL_TREE, loop);
  
!   if (!operand_equal_p (DR_STEP (dr_a), DR_STEP (dr_b), 0))
!   length_factor = scalar_loop_iters;
!   else
!   length_factor = size_int (vect_factor);
!   segment_length_a = vect_vfa_segment_size (dr_a, length_factor);
!   segment_length_b = vect_vfa_segment_size (dr_b, length_factor);
  
if (vect_print_dump_info (REPORT_DR_DETAILS))
{

Re: [patch gimplifier]: Boolify more strict conditional expressions and transform simple form to binary

[Richard Guenther]

On Thu, May 12, 2011 at 9:59 PM, H.J. Lu  wrote:
> On Thu, May 12, 2011 at 11:19 AM, Kai Tietz  wrote:
>> 2011/5/12 Richard Guenther :
>>> On Thu, May 12, 2011 at 3:29 PM, Kai Tietz  wrote:
 While testing some other issues with C++'s __java_boolean type
 occurred. So I adjusted check in test-cfg.c as you suggested.
 Additionally due the fact that we are now boolifying conditions for
 even BOOLEAN_TYPE'ed cases (for making sure inner arms are boolified,
 too), we possibly would alter here truth-type provided by FE. To
 restore original type (for types != boolean-type), we do type
 conversion always back to FE's used type for truth-AND/OR/XOR/etc as
 result.
>>>
>>> boolean_type_node is the only BOOLEAN_TYPE node we have,
>>> so please remove the !=/== boolean_type_node checks again, or,
>>> if you want more visual consistency with the adjustment gimple_boolify
>>> makes replace them with !=/== boolean_type_node comparisons
>>> completely.
>>>
>>> Ok with either change.
>>>
>>> Thanks,
>>> Richard.
>>>
 Patch bootstrapped with all languages on x86_64-pc-linux-gnu
 (multilib). Ok for apply?

 Regards,
 Kai

 Index: gcc/gcc/gimplify.c
 ===
 --- gcc.orig/gcc/gimplify.c     2011-05-12 09:02:58.946243000 +0200
 +++ gcc/gcc/gimplify.c  2011-05-12 15:13:59.534550700 +0200
 @@ -2824,9 +2824,6 @@ gimple_boolify (tree expr)
        }
     }

 -  if (TREE_CODE (type) == BOOLEAN_TYPE)
 -    return expr;
 -
   switch (TREE_CODE (expr))
     {
     case TRUTH_AND_EXPR:
 @@ -2851,6 +2848,9 @@ gimple_boolify (tree expr)
     default:
       /* Other expressions that get here must have boolean values, but
         might need to be converted to the appropriate mode.  */
 +      if (TREE_CODE (type) == BOOLEAN_TYPE
 +          && type == boolean_type_node)
 +       return expr;
       return fold_convert_loc (loc, boolean_type_node, expr);
     }
  }
 @@ -4695,31 +4695,6 @@ gimplify_scalar_mode_aggregate_compare (
   return GS_OK;
  }

 -/* Gimplify TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR expressions.  EXPR_P
 -   points to the expression to gimplify.
 -
 -   Expressions of the form 'a && b' are gimplified to:
 -
 -       a && b ? true : false
 -
 -   LOCUS is the source location to be put on the generated COND_EXPR.
 -   gimplify_cond_expr will do the rest.  */
 -
 -static enum gimplify_status
 -gimplify_boolean_expr (tree *expr_p, location_t locus)
 -{
 -  /* Preserve the original type of the expression.  */
 -  tree type = TREE_TYPE (*expr_p);
 -
 -  *expr_p = build3 (COND_EXPR, type, *expr_p,
 -                   fold_convert_loc (locus, type, boolean_true_node),
 -                   fold_convert_loc (locus, type, boolean_false_node));
 -
 -  SET_EXPR_LOCATION (*expr_p, locus);
 -
 -  return GS_OK;
 -}
 -
  /* Gimplify an expression sequence.  This function gimplifies each
    expression and rewrites the original expression with the last
    expression of the sequence in GIMPLE form.
 @@ -6762,12 +6737,26 @@ gimplify_expr (tree *expr_p, gimple_seq

        case TRUTH_ANDIF_EXPR:
        case TRUTH_ORIF_EXPR:
 -         /* Pass the source location of the outer expression.  */
 -         ret = gimplify_boolean_expr (expr_p, saved_location);
 -         break;
 +         {
 +           /* Preserve the original type of the expression and the
 +              source location of the outer expression.  */
 +           tree org_type = TREE_TYPE (*expr_p);
 +           *expr_p = gimple_boolify (*expr_p);
 +           *expr_p = build3_loc (saved_location, COND_EXPR,
 +                                 org_type, *expr_p,
 +                                 fold_convert_loc
 +                                   (saved_location,
 +                                    org_type, boolean_true_node),
 +                                 fold_convert_loc
 +                                   (saved_location,
 +                                    org_type, boolean_false_node));
 +           ret = GS_OK;
 +           break;
 +         }

        case TRUTH_NOT_EXPR:
 -         if (TREE_CODE (TREE_TYPE (*expr_p)) != BOOLEAN_TYPE)
 +         if (TREE_CODE (TREE_TYPE (*expr_p)) != BOOLEAN_TYPE
 +             || TREE_CODE (TREE_TYPE (*expr_p)) != boolean_type_node)
            {
              tree type = TREE_TYPE (*expr_p);
              *expr_p = fold_convert (type, gimple_boolify (*expr_p));
 @@ -7203,6 +7192,24 @@ gimplify_expr (tree *expr_p, gimple_seq
        case TRUTH_AND_EXPR:
        case TRUTH_OR_EXPR:
        case TRUTH_XOR_EXPR:
 +         {
 +           tree org

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Richard Guenther]

On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li  wrote:
> Ok for google/main.

Seems to be very special and not appropriate for GCC trunk.  Instead
an adjusted copy providing the interface GCC needs should belong to
the kernel tree.

Richard.

Re: [patch gimplify]: Fix for PR/48984

[Richard Guenther]

On Fri, May 13, 2011 at 8:56 AM, Eric Botcazou  wrote:
>> 2011-05-13  Kai Tietz
>>
>>         * gimplify.c (gimplify_expr): Check for boolean_type_node instead
>>         for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
>>         (gimple_boolify): Check for cast for boolean_type_node instead for
>>         BOOLEAN_TYPE.
>
> Missing PR middle-end/48984 at the top.

Ok with that change.

Richard.

> --
> Eric Botcazou
>

Re: [patch gimplify]: Fix for PR/48984

[Kai Tietz]

2011/5/13 Richard Guenther :
> On Fri, May 13, 2011 at 8:56 AM, Eric Botcazou  wrote:
>>> 2011-05-13  Kai Tietz
>>>
>>>         * gimplify.c (gimplify_expr): Check for boolean_type_node instead
>>>         for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
>>>         (gimple_boolify): Check for cast for boolean_type_node instead for
>>>         BOOLEAN_TYPE.
>>
>> Missing PR middle-end/48984 at the top.
>
> Ok with that change.
>
> Richard.
>
>> --
>> Eric Botcazou
>>

After testsuite run for fortran passed. Applied fix at revision 173726.

Regards,
Kai

Re: [Patch, libfortran] PR 48915 Fix incorrect return code with -fdump-core, error handling changes

[Janne Blomqvist]

PING.

On Sat, May 7, 2011 at 22:52, Janne Blomqvist  wrote:
> Hi,
>
> this simple bug led me to rethink normal and error termination and
> thus the patch changes some other related stuff as well. So the
> original problem was that when -fdump-core was enabled, STOP with a
> numeric stop code made the program terminate with an incorrect return
> code, since the core dump generation is done by the program killing
> itself.
>
> The real problem is that previously, we were mixing up normal
> termination with a non-zero exit status (e.g. file not found) with
> aborting the program (e.g. some serious error detected). The attached
> patch reworks this so that normal termination (with a zero or non-zero
> exit code) is done with exit(), and no backtrace or core dump is
> generated in any circumstance. For serious errors, a backtrace and
> core dump are generated.
>
> Since OS'es contain widely used ways to control core dump generation
> (e.g. ulimit -c), and we no longer "frivolously" try to generate a
> core dump just because we're exiting with non-zero status, there is
> IMHO no longer any need for a gfortran-specific option; if we hit a
> serious error, we call abort() and a core dump is always generated if
> the user environment is so configured (and the system supports core
> dumps).
>
> Also, since backtraces and core dumps are now only generated for
> serious errors (not e.g. file not found). -fbacktrace is enabled by
> default.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> frontend ChangeLog:
>
> 2011-05-07  Janne Blomqvist  
>
>        PR libfortran/48915
>        * gfortran.h (gfc_option_t): Remove flag_dump_core.
>        * gfortran.texi (GFORTRAN_ERROR_DUMPCORE): Remove section.
>        (GFORTRAN_ERROR_BACKTRACE): Document that it's enabled by default.
>        * intrinsic.texi (ABORT): Remove explanation of -fdump-core.
>        * invoke.texi: Remove -fdump-core, document that -fbacktrace is
>        enabled by default.
>        * lang.opt: Remove -fdump-core.
>        * options.c (gfc_init_options): Make backtrace default to enabled,
>        remove dump_core.
>        (gfc_handle_option): Remove OPT_fdump-core.
>        * trans-decl.c: Pass a 0 to preserve ABI.
>
> library ChangeLog:
>
> 2011-05-07  Janne Blomqvist  
>
>        PR libfortran/48915
>        * intrinsics/abort.c (abort): Call sys_abort().
>        * io/unix.c (st_vprintf): Call sys_abort().
>        * libgfortran.h (options_t): Remove dump_core member.
>        (handler): Rename to backtrace_handler.
>        (compile_options_t): Remove dump_core member.
>        (sys_exit): Remove.
>        (sys_abort): New function.
>        * runtime/backtrace.c (show_backtrace): Print a message if
>        backtrace is not available on target.
>        * runtime/compile_options.c (backtrace_handler): New
>        implementation based on example in Glibc manual.
>        (set_options): Remove dump_core handling, make signal handler
>        handle more signals.
>        (init_compile_options): Remove dump_core.
>        * runtime/environ.c (variable_table[]): Remove
>        GFORTRAN_ERROR_DUMPCORE element.
>        (show_variables): Update name, call exit().
>        * runtime/error.c (sys_exit): Remove.
>        (sys_abort): New function.
>        (recursion_check): Call sys_abort().
>        (os_error): Call exit().
>        (runtime_error): Likewise.
>        (runtime_error_at): Likewise.
>        (internal_error): Likewise.
>        (generate_error): Likewise.
>        (notify_std): Likewise.
>        * runtime/stop.c (stop_numeric): Call exit().
>        (stop_numeric_f08): Likewise.
>        (stop_string): Likewise.
>        (error_stop_string): Call sys_abort().
>        (error_stop_numeric): Print backtrace, exit with provided code.
>
>
> --
> Janne Blomqvist
>



-- 
Janne Blomqvist

Re: [Patch, libfortran] Thread safety and simplification of error printing

[Janne Blomqvist]

PING

On Sun, May 8, 2011 at 19:53, Janne Blomqvist  wrote:
> On Sun, May 8, 2011 at 14:40, Janne Blomqvist  
> wrote:
>> On Sat, May 7, 2011 at 19:35, Janne Blomqvist  
>> wrote:
>>> Hi,
>>>
>>> the error printing functionality (in io/unix.c) st_printf and
>>> st_vprintf are not thread-safe as they use a static buffer. However,
>>> since these routines are used when something has gone wrong, we
>>> shouldn't use malloc() to allocate thread-specific buffers or anything
>>> fancy like that. The way the buffer is used is that it is filled with
>>> vs(n)printf() and then the buffer is written using write(); the
>>> simplest way to fix this is to just print directly using vfprintf(),
>>> which is what this patch does. Also, the patch uses
>>> flockfile/funlockfile in a few places to increase the likelihood of
>>> multiple related messages to end up together on the output.
>>>
>>> As stderr is unbuffered and stdout is buffered, this patch also gets
>>> rid of the functionality to choose where to send the error output, as
>>> we don't want to deal with buffering in the error handling path. IMHO
>>> this is no loss, as all targets/shells/batch schedulers/ etc. where
>>> this might be relevant, offer functionality to redirect stderr to
>>> wherever stdout goes. So there is no need for a gfortran-specific
>>> mechanism for this.
>>
>> While this patch makes error printing thread-safe, it's no longer
>> async-signal-safe as the stderr lock might lead to a deadlock. So I'm
>> retracting this patch and thinking some more about this problem.
>
> So here is an updated patch. Compared to the status quo the main
> differences are that it uses a stack allocated buffer to do the
> formatting instead of a static one. This prevents conflicts from
> multiple threads and in contrast to the approach in the previous patch
> should also be async-signal-safe (or at least, less likely to go
> belly-up when called from within a signal handler than using
> vfprintf() directly). It also introduces a new function to write a
> string to standard error without any formatting (estr_write), which is
> simpler and less likely to cause problems than the general purpose
> vs(n)printf() used before. This can be used in lieu of st_printf in
> the majority of cases where no formatting is done.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> frontend ChangeLog:
>
> 2011-05-08  Janne Blomqvist  
>
>        * gfortran.texi: Remove GFORTRAN_USE_STDERR documentation.
>
>
> library ChangeLog:
>
> 2011-05-08  Janne Blomqvist  
>
>        * io/unix.c (st_vprintf,st_printf): Move to runtime/error.c.
>        * libgfortran.h (struct options_t): Remove use_stderr field.
>        (st_vprintf,st_printf): Move prototypes.
>        (estr_write): New prototype.
>        * runtime/error.c (sys_exit): Use estr_write instead of st_printf.
>        (estr_write): New function.
>        (st_vprintf): Move from io/unix.c, use stack allocated buffer,
>        always output to stderr.
>        (st_printf): Move from io/unix.c.
>        (show_locus): Use a local variable instead of static.
>        (os_error): Use estr_write instead of st_printf.
>        (runtime_error): Likewise.
>        (runtime_error_at): Likewise.
>        (runtime_warning_at): Likewise.
>        (internal_error): Likewise.
>        (generate_error): Likewise.
>        (generate_warning): Likewise.
>        (notify_std): Likewise.
>        * runtime/pause.c (do_pause): Likewise.
>        (pause_string): Likewise.
>        * runtime/stop.c (stop_string): Likewise.
>        (error_stop_string): Likewise.
>        * config/fpu_aix.h (set_fpu): Likewise.
>        * config/fpu_generic.h (set_fpu): Likewise.
>        * config/fpu_glibc.h (set_fpu): Likewise.
>        * config/fpu-sysv.h (set_fpu): Likewise.
>        * runtime/backtrace.c (dump_glibc_backtrace): Likewise.
>        (show_backtrace): Likewise.
>        * runtime/environ.c (print_spaces): Likewise.
>        (show_string): Likewise.
>        (show_variables): Likewise.
>        (variable_table[]): Remove GFORTRAN_USE_STDERR entry.
>
>
> --
> Janne Blomqvist
>



-- 
Janne Blomqvist

Re: [Patch, Fortran] Reject non-default-kind characters as flags to I/O statements

[Janne Blomqvist]

On Fri, May 13, 2011 at 00:56, Tobias Burnus  wrote:
> The patch is a correctness issue as the Fortran standard has those as
> constraints - and the results of passing kind=4 strings is also odd ...
>
> I used also the chance to resolve INQUIRE's decimal ...
>
> Build and partially regtested on x86-64-linux.
> OK for the trunk?

Ok, thanks for the patch. And especially thanks for the exhaustive
test cases! However, can you combine the test cases, I don't really
see any special reason to have them separate as they test more or less
the same thing?




-- 
Janne Blomqvist

RX: Fix thinkos in previous tidy up

[Nick Clifton]

Hi Guys,

  When I applied my RX tidy up patch yesterday I forgot to rebuild the
  toolchain and thus missed a couple of thinkos with my rename of the
  rx_legitimate_constant_p function.  I therefore applying the patch
  below to fix this problem.

Cheers
  Nick

gcc/ChangeLog
2011-05-13  Nick Clifton  

* config/rx/rx.md (mov expander): Fix use of
rx_legitimate_constant_p.
* config/rx/rx-protos.h (rx_legitimate_constant_p): Rename
prototype.

Index: gcc/config/rx/rx-protos.h
===
--- gcc/config/rx/rx-protos.h   (revision 173723)
+++ gcc/config/rx/rx-protos.h   (working copy)
@@ -31,7 +31,7 @@
 extern void rx_emit_stack_pushm (rtx *);
 extern voidrx_expand_epilogue (bool);
 extern char *  rx_gen_move_template (rtx *, bool);
-extern boolrx_legitimate_constant_p (enum machine_mode, rtx);
+extern boolrx_is_legitimate_constant (enum machine_mode, rtx);
 extern boolrx_is_restricted_memory_address (rtx,
 enum machine_mode);
 extern boolrx_match_ccmode (rtx, enum machine_mode);
Index: gcc/config/rx/rx.md
===
--- gcc/config/rx/rx.md (revision 173723)
+++ gcc/config/rx/rx.md (working copy)
@@ -556,7 +556,7 @@
 if (MEM_P (operand0) && MEM_P (operand1))
   operands[1] = copy_to_mode_reg (mode, operand1);
 if (CONST_INT_P (operand1)
-&& ! rx_legitimate_constant_p (mode, operand1))
+&& ! rx_is_legitimate_constant (mode, operand1))
   FAIL;
   }
 )

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Jan Hubicka]

> On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li  wrote:
> > Ok for google/main.
> 
> Seems to be very special and not appropriate for GCC trunk.  Instead
> an adjusted copy providing the interface GCC needs should belong to
> the kernel tree.
Andi Kleen also did work in this direction. We probably should synchronize the
efforts.

It seems that there is quite a bit of FDO stuff that should get in some form
to mainline for 4.7.  Perhaps some overview would be helpful.

Honza
> 
> Richard.

Re: x86 option handling cleanup, use more .opt features

[Jan Hubicka]

> 
> Various options with enumerated string arguments are changed to use
> Enum.  Some checking of those arguments was still needed, because the
> valid values depend on e.g. the -m64 setting, but that checking now
> works with the enumerated values not strings.  I didn't change the
> existing logic that -mcmodel=32 isn't allowed with PIC even though the
> 32-bit default is -mcmodel=32 and the implicit option is allowed with
> PIC, though that logic doesn't make sense to me.

The cmodels on 32bit compilation are not really defined, since ABI does not
really speaks on code models there.  "32" code model is more or less a
placeholder for the code model section. But indeed, allowing it with -fPIC
makes sense.
> 
> 2011-05-12  Joseph Myers  
> 
>   * config/i386/i386-opts.h: New.
>   * gcc/config/i386/i386.c (stringop_alg, ix86_cmodel,
>   ix86_asm_dialect, ix86_regparm, ix86_abi, ix86_branch_cost,
>   ix86_section_threshold): Remove.
>   (ix86_handle_option): Move MAX_CODE_ALIGN define here.  Handle
>   OPT_malign_loops_, OPT_malign_jumps_, OPT_malign_functions_ and
>   OPT_mbranch_cost_.
>   (ix86_option_override_internal): Don't decode strings for options
>   other than -march=, -mtune= and -mfpmath=.  Don't allow for
>   __attribute__ uses in remaining diagnostics for options with
>   string arguments.  Don't check for integer arguments being
>   negative.
>   * gcc/config/i386/i386.h (enum stringop_alg, enum calling_abi,
>   enum tls_dialect, enum cmodel, enum asm_dialect): Move to
>   i386-opts.h.
>   (ix86_abi, ix86_tls_dialect, ix86_cmodel, ix86_asm_dialect,
>   ix86_branch_cost, ix86_section_threshold): Remove.
>   * gcc/config/i386/i386.opt (config/i386/i386-opts.h): New
>   HeaderInclude.
>   (malign-functions=, malign-jumps=, malign-loops=): Use UInteger
>   but not Var.
>   (masm=): Use Enum and Init.
>   (asm_dialect): New Enum and EnumValue entries.
>   (mbranch-cost=): Use UInteger.
>   (mlarge-data-threshold=): Use UInteger and Init.
>   (mcmodel=): Use Enum and Init.
>   (cmodel): New Enum and EnumValue entries.
>   (mpc): Replace with separate mpc32, mpc64 and mpc80 entries.
>   (mpreferred-stack-boundary=, mincoming-stack-boundary=,
>   mregparm=): Use UInteger.
>   (mstringop-strategy=): Use Enum and Init.
>   (stringop_alg): New Enum and EnumValue entries.
>   (mtls-dialect=): Use Enum and Init.
>   (tls_dialect): New Enum and EnumValue entries.
>   (mabi=): Use Enum and Init.
>   (calling_abi): New Enum and EnumValue entries.
>   (mveclibabi=): Use Enum and Init.
>   (ix86_veclibabi): New Enum and EnumValue entries.
OK
Thanks for the hard work!
Honza

[wwwdocs,Java] Simplify design and markup of gcc-3.1/gcj-status.html

[Gerald Pfeifer]

Consistently use white (default) background for successfull tests, 
avoiding bgcolor attributes.

Applied.

Gerald

Index: gcc-3.1/gcj-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.1/gcj-status.html,v
retrieving revision 1.2
diff -u -r1.2 gcj-status.html
--- gcc-3.1/gcj-status.html 23 May 2003 09:59:09 -  1.2
+++ gcc-3.1/gcj-status.html 13 May 2011 10:03:17 -
@@ -19,63 +19,63 @@
 
  Platform   Status   Who  
 
- i686-pc-linux-gnu
+ i686-pc-linux-gnu
   Ok 
   Tom 
 
 
- i386-*-freebsd*
+ i386-*-freebsd*
   Ok 
   Loren James Rittle 
 
 
- alphaev67-unknown-linux-gnu
+ alphaev67-unknown-linux-gnu
   Ok 
   Tom 
 
 
- ia64-*-linux-gnu
+ ia64-*-linux-gnu
   Ok 
   Hans, Andrew, et al 
 
 
-  PPC Linux
+  PPC Linux
   Ok 
   Bryce 
 
 
-  sparc-sun-solaris2.5.1 
+  sparc-sun-solaris2.5.1 
   Ok 
   Rainer 
 
 
-  sparc-sun-solaris2.8 
+  sparc-sun-solaris2.8 
   Ok 
   Rainer 
 
 
-  sparc-sun-solaris2.7 
+  sparc-sun-solaris2.7 
   Ok (PR 6092 still in question) 
   Rainer 
 
 
-  sparc-sun-solaris2.6 
+  sparc-sun-solaris2.6 
   Ok 
   Andreas 
 
 
-  i386-pc-solaris2.8 
+  i386-pc-solaris2.8 
   Ok 
   Rainer 
 
 
-  mips-sgi-irix6.5 
+  mips-sgi-irix6.5 
   Ok; libgcj will not be enabled by default due to the tricks
  required to get it to build
   Rainer 
 
 
- i686-pc-mingw32
+ i686-pc-mingw32
  Ok.  Only works as a target, not a host.
  Is still incomplete (at least Process does not work yet)
  
@@ -87,17 +87,17 @@
   Andreas, Alexandre, others 
 
 
- alpha-dec-osf4.0f
+ alpha-dec-osf4.0f
   Ok 
   Rainer 
 
 
- alpha-dec-osf5.1
+ alpha-dec-osf5.1
   Ok 
   Rainer 
 
 
- linux -x- xscale-elf 
+ linux -x- xscale-elf 
   Ok 
   AG 
 

Re: [Patch, Fortran] Reject non-default-kind characters as flags to I/O statements

[Tobias Burnus]

Thanks for the review, Janne!

Janne Blomqvist wrote:
> Ok, thanks for the patch. And especially thanks for the exhaustive
> test cases!

They turned out to be quite useful to find other bugs ;-)
(INQUIRE with stream= is not implemented, INQUIRE with decimal=
 was not resolved.)

> However, can you combine the test cases, I don't really
> see any special reason to have them separate as they test more or less
> the same thing?

Me neither - thus, I had them initially in the same file. But
after the format errors, the compiler stops. I think it is because
the format errors are printed during matching, the others during
resolution. But I have not investigated and simply created an
additional file.

Tobias

[PATCH, i386]: Trivial, use can_create_pseudo_p () some more

[Uros Bizjak]

Hello!

Use can_create_pseudo_p () for things that happen strictly before reload.

2011-05-13  Uros Bizjak  

* config/i386/i386.md (*movxf_internal): Use !can_create_pseudo ().
(*movxf_internal_nointeger): Ditto.
(*movdf_internal_rex64): Ditto.
(*movdf_internal): Ditto.
(*movdf_internal_nointeger): Ditto.
(*movsf_internal): Ditto.
(sincos splitters): Use can_create_pseudo ().

Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 173723)
+++ config/i386/i386.md (working copy)
@@ -2866,7 +2866,7 @@
(match_operand:XF 1 "general_operand" "fm,f,G,roF,Fr"))]
   "optimize_function_for_speed_p (cfun)
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| GET_CODE (operands[1]) != CONST_DOUBLE
|| memory_operand (operands[0], XFmode))"
 {
@@ -2895,7 +2895,7 @@
(match_operand:XF 1 "general_operand" "fm,f,G,*roF,F*r"))]
   "optimize_function_for_size_p (cfun)
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| standard_80387_constant_p (operands[1])
|| GET_CODE (operands[1]) != CONST_DOUBLE
|| memory_operand (operands[0], XFmode))"
@@ -2938,7 +2938,7 @@
(match_operand:DF 1 "general_operand"
"fm,f,G,rm,r,F ,F ,C   ,Y2*x,m   ,Y2*x,r ,Yi"))]
   "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| (ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_LARGE)
|| (!(TARGET_SSE2 && TARGET_SSE_MATH)
&& optimize_function_for_size_p (cfun)
@@ -3102,7 +3102,7 @@
   "!TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))
&& optimize_function_for_speed_p (cfun)
&& TARGET_INTEGER_DFMODE_MOVES
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| (ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_LARGE)
|| (!(TARGET_SSE2 && TARGET_SSE_MATH)
&& optimize_function_for_size_p (cfun)
@@ -3255,7 +3255,7 @@
   "!TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))
&& (optimize_function_for_size_p (cfun)
|| !TARGET_INTEGER_DFMODE_MOVES)
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| (ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_LARGE)
|| (!(TARGET_SSE2 && TARGET_SSE_MATH)
&& optimize_function_for_size_p (cfun)
@@ -3263,8 +3263,7 @@
   && standard_80387_constant_p (operands[1]))
|| GET_CODE (operands[1]) != CONST_DOUBLE
|| ((optimize_function_for_size_p (cfun)
-|| !TARGET_MEMORY_MISMATCH_STALL
-   || reload_in_progress || reload_completed)
+|| !TARGET_MEMORY_MISMATCH_STALL)
   && memory_operand (operands[0], DFmode)))"
 {
   switch (which_alternative)
@@ -3420,7 +3419,7 @@
(match_operand:SF 1 "general_operand"
  "fm,f,G,rmF,Fr,C,x,xm,x,m  ,*y,*y ,r  ,Yi,r   ,*Ym"))]
   "!(MEM_P (operands[0]) && MEM_P (operands[1]))
-   && (reload_in_progress || reload_completed
+   && (!can_create_pseudo_p ()
|| (ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_LARGE)
|| (!TARGET_SSE_MATH && optimize_function_for_size_p (cfun)
   && standard_80387_constant_p (operands[1]))
@@ -13525,7 +13524,7 @@
(set (match_operand:XF 1 "register_operand" "")
(unspec:XF [(match_dup 2)] UNSPEC_SINCOS_SIN))]
   "find_regno_note (insn, REG_UNUSED, REGNO (operands[0]))
-   && !(reload_completed || reload_in_progress)"
+   && can_create_pseudo_p ()"
   [(set (match_dup 1) (unspec:XF [(match_dup 2)] UNSPEC_SIN))])
 
 (define_split
@@ -13535,7 +13534,7 @@
(set (match_operand:XF 1 "register_operand" "")
(unspec:XF [(match_dup 2)] UNSPEC_SINCOS_SIN))]
   "find_regno_note (insn, REG_UNUSED, REGNO (operands[1]))
-   && !(reload_completed || reload_in_progress)"
+   && can_create_pseudo_p ()"
   [(set (match_dup 0) (unspec:XF [(match_dup 2)] UNSPEC_COS))])
 
 (define_insn "sincos_extendxf3_i387"
@@ -13561,7 +13560,7 @@
(set (match_operand:XF 1 "register_operand" "")
(unspec:XF [(float_extend:XF (match_dup 2))] UNSPEC_SINCOS_SIN))]
   "find_regno_note (insn, REG_UNUSED, REGNO (operands[0]))
-   && !(reload_completed || reload_in_progress)"
+   && can_create_pseudo_p ()"
   [(set (match_dup 1)
(unspec:XF [(float_extend:XF (match_dup 2))] UNSPEC_SIN))])
 
@@ -13573,7 +13572,7 @@
(set (match_operand:XF 1 "register_operand" "")
(unspec:XF [(float_extend:XF (match_dup 2))] UNSPEC_SINCOS_SIN))]
   "find_regno_note (insn, REG_UNUSED, REGNO (operands[1]))
-   && !(reload_completed || reload_in_progress)"
+   && can_create_pseudo_p ()"
   [(

[wwwdocs,java] Simplify gcc-3.3/gcj-status.html

[Gerald Pfeifer]

Remove incomplete table entries and adjust a link description from 
gcj to GCJ.

Applied.

Gerald
Index: gcc-3.3/gcj-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/gcj-status.html,v
retrieving revision 1.4
diff -u -r1.4 gcj-status.html
--- gcc-3.3/gcj-status.html 19 Nov 2006 15:45:55 -  1.4
+++ gcc-3.3/gcj-status.html 13 May 2011 10:00:58 -
@@ -15,110 +15,6 @@
 
href="http://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=allwordssubst&component=java&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_severity=critical&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&bugidtype=include&cmdtype=doit&order=Bug+Number";>see
 list).
 
-
-Platforms
-
-
-
-Platform Status Who 
-
-
-
- i686-pc-linux-gnu
-  Ok 
-  Tom Tromey 
-
-
- i386-*-freebsd*
-    
-    
-
-
- alphaev67-unknown-linux-gnu
-    
-  Jeff Sturm 
-
-
- ia64-*-linux-gnu
-    
-    
-
-
- gnu-linux-unknown-powerpc
-    
-  Mark Wielaard 
-
-
-  sparc-sun-solaris2.5.1 
-    
-    
-
-
-  sparc-sun-solaris2.8 
-    
-  Jeff Sturm 
-
-
-  sparc-sun-solaris2.7 
-    
-    
-
-
-  sparc-sun-solaris2.6 
-    
-    
-
-
-  i386-pc-solaris2.8 
-    
-    
-
-
-  mips-sgi-irix6.5 
-   
-    
-
-
- i686-pc-mingw32
-    
-    
-
-
-  PPC Darwin
-    
-  Andreas Tobler 
-
-
- alpha-dec-osf4.0f
-    
-    
-
-
- alpha-dec-osf5.1
-    
-    
-
-
- s390-*-linux
-    
-  Ulrich Weigand 
-
-
- s390x-*-linux
-    
-  Ulrich Weigand 
-
-
- cross-building for xscale-elf
-    
-  Anthony Green 
-
-
-
-
  Packages 
 
 
@@ -161,7 +57,7 @@
 See Also
 
  It is also worth looking at the old gcj 3.1 status page for comparison.  In
+href="../gcc-3.1/gcj-status.html">GCJ 3.1 status page for comparison.  In
 particular known problems with 3.1 aren't required to be fixed for
 3.3.  
 

Re: [wwwdocs] Use regular markup for java/projects.html

[Gerald Pfeifer]

On Mon, 9 May 2011, Gerald Pfeifer wrote:
> I was hoping my patch made it easier for someone with more background
> to update this page in terms of contents, but seeing that nobody took
> action on your analysis I cooked up the patch below which I plan on 
> committing in a couple of days.
> 
> Gerald
> 
> 2011-05-09  Gerald Pfeifer  
> 
>   * projects.html: Update name of java mailing list.
>   (Plugin for Mozilla): Remove section.
>   (Compiler Improvements): Remove tree inlining item.
>   (Benchmark infrastructure): Remove reference to jMocha.

Done.  Thanks again for the suggestions, Steven.

Gerald

[PATCH] Fix PR48978

[Richard Guenther]

The change to pointer and function type hashing has made hashing
a lot weaker (contrary to what I expected) because if either type
resides in a SCC then we do _not_ take the hash of the visited
target types into account (I'm currently trying to think about
a way around that), so we are effectively weakening the hashes
by not hasing the target aggregate name.

Committed to trunk.

Richard.

2011-05-13  Richard Guenther  

PR lto/48978
* gimple.c (iterative_hash_gimple_type): Revert change in
pointer target and function result and argument hashing.

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 173725)
+++ gcc/gimple.c(working copy)
@@ -4110,10 +4110,20 @@ iterative_hash_gimple_type (tree type, h
 }
 
   /* For pointer and reference types, fold in information about the type
- pointed to.  */
+ pointed to but do not recurse into possibly incomplete types to
+ avoid hash differences for complete vs. incomplete types.  */
   if (POINTER_TYPE_P (type))
-v = visit (TREE_TYPE (type), state, v,
-  sccstack, sccstate, sccstate_obstack);
+{
+  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (type)))
+   {
+ v = iterative_hash_hashval_t (TREE_CODE (TREE_TYPE (type)), v);
+ v = iterative_hash_name
+   (TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (type))), v);
+   }
+  else
+   v = visit (TREE_TYPE (type), state, v,
+  sccstack, sccstate, sccstate_obstack);
+}
 
   /* For integer types hash the types min/max values and the string flag.  */
   if (TREE_CODE (type) == INTEGER_TYPE)
@@ -4154,13 +4164,29 @@ iterative_hash_gimple_type (tree type, h
v = visit (TYPE_METHOD_BASETYPE (type), state, v,
   sccstack, sccstate, sccstate_obstack);
 
-  /* Check result and argument types.  */
-  v = visit (TREE_TYPE (type), state, v,
-sccstack, sccstate, sccstate_obstack);
+  /* For result types allow mismatch in completeness.  */
+  if (RECORD_OR_UNION_TYPE_P (TREE_TYPE (type)))
+   {
+ v = iterative_hash_hashval_t (TREE_CODE (TREE_TYPE (type)), v);
+ v = iterative_hash_name
+   (TYPE_NAME (TYPE_MAIN_VARIANT (TREE_TYPE (type))), v);
+   }
+  else
+   v = visit (TREE_TYPE (type), state, v,
+  sccstack, sccstate, sccstate_obstack);
+
   for (p = TYPE_ARG_TYPES (type), na = 0; p; p = TREE_CHAIN (p))
{
- v = visit (TREE_VALUE (p), state, v,
-sccstack, sccstate, sccstate_obstack);
+ /* For argument types allow mismatch in completeness.  */
+ if (RECORD_OR_UNION_TYPE_P (TREE_VALUE (p)))
+   {
+ v = iterative_hash_hashval_t (TREE_CODE (TREE_VALUE (p)), v);
+ v = iterative_hash_name
+   (TYPE_NAME (TYPE_MAIN_VARIANT (TREE_VALUE (p))), v);
+   }
+ else
+   v = visit (TREE_VALUE (p), state, v,
+  sccstack, sccstate, sccstate_obstack);
  na++;
}
 

Re: [PATCH, ARM] ISO/IEC TR 18037 fixed-point support

[Julian Brown]

On Wed, 11 May 2011 15:45:52 +0100
Richard Sandiford  wrote:

> Julian Brown  writes:
> > Tested with cross to ARM Linux. OK to apply?
> 
> Just out of interest, are you able to test the patch on MIPS as well?
> I was wondering whether the fixed-point results there change after the
> target-independent parts of the patch.  (I think MIPS is still the
> only port with in-tree fixed-point support.)

I ran tests for 32-bit big-endian MIPS (since that was what came out by
default with our build infrastructure...) and I don't see any change in
test results.

Cheers,

Julian

[patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Kai Tietz]

Hello,

this patch adds a check to

ChangeLog

2011-05-13  Kai Tietz

  * gimplify.c (gimplify_expr): Make sure operand is boolified.
  * tree-cfg.c (verify_gimple_assign_unary): Check for boolean
compatible type
  for TRUTH_NOT_EXPR.

Bootstrapped for x86_64-pc-linux-gnu (multilib). Ok for apply?

Index: tree-cfg.c
===
--- tree-cfg.c  (revision 173725)
+++ tree-cfg.c  (working copy)
@@ -3342,6 +3342,14 @@
   return false;

 case TRUTH_NOT_EXPR:
+  if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
+  || !useless_type_conversion_p (boolean_type_node,  lhs_type))
+{
+   error ("invalid types in truth not");
+   debug_generic_expr (lhs_type);
+   debug_generic_expr (rhs1_type);
+   return true;
+}
 case NEGATE_EXPR:
 case ABS_EXPR:
 case BIT_NOT_EXPR:

Index: gimplify.c
===
--- gimplify.c  (revision 173726)
+++ gimplify.c  (working copy)
@@ -6754,14 +6754,18 @@
  }

case TRUTH_NOT_EXPR:
- if (TREE_TYPE (*expr_p) != boolean_type_node)
-   {
- tree type = TREE_TYPE (*expr_p);
- *expr_p = fold_convert (type, gimple_boolify (*expr_p));
- ret = GS_OK;
- break;
-   }
+ {
+   tree org_type = TREE_TYPE (*expr_p);

+   *expr_p = gimple_boolify (*expr_p);
+   if (org_type != boolean_type_node)
+ {
+   *expr_p = fold_convert (org_type, *expr_p);
+   ret = GS_OK;
+   break;
+ }
+ }
+
  ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
   is_gimple_val, fb_rvalue);
  recalculate_side_effects (*expr_p);

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Richard Guenther]

On Fri, May 13, 2011 at 1:31 PM, Kai Tietz  wrote:
> Hello,
>
> this patch adds a check to
>
> ChangeLog
>
> 2011-05-13  Kai Tietz
>
>          * gimplify.c (gimplify_expr): Make sure operand is boolified.
>          * tree-cfg.c (verify_gimple_assign_unary): Check for boolean
> compatible type
>          for TRUTH_NOT_EXPR.
>
> Bootstrapped for x86_64-pc-linux-gnu (multilib). Ok for apply?

Ok with 

> Index: tree-cfg.c
> ===
> --- tree-cfg.c  (revision 173725)
> +++ tree-cfg.c  (working copy)
> @@ -3342,6 +3342,14 @@
>       return false;
>
>     case TRUTH_NOT_EXPR:
> +      if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
> +          || !useless_type_conversion_p (boolean_type_node,  lhs_type))

the 2nd check removed, it's redundant with the common check below

  /* For the remaining codes assert there is no conversion involved.  */
  if (!useless_type_conversion_p (lhs_type, rhs1_type))
{
  error ("non-trivial conversion in unary operation");
  debug_generic_expr (lhs_type);
  debug_generic_expr (rhs1_type);
  return true;
}

and ...

> +        {
> +           error ("invalid types in truth not");
> +           debug_generic_expr (lhs_type);
> +           debug_generic_expr (rhs1_type);
> +           return true;
> +        }

please do not fall through here but add a break.

Richard.

>     case NEGATE_EXPR:
>     case ABS_EXPR:
>     case BIT_NOT_EXPR:
>
> Index: gimplify.c
> ===
> --- gimplify.c  (revision 173726)
> +++ gimplify.c  (working copy)
> @@ -6754,14 +6754,18 @@
>          }
>
>        case TRUTH_NOT_EXPR:
> -         if (TREE_TYPE (*expr_p) != boolean_type_node)
> -           {
> -             tree type = TREE_TYPE (*expr_p);
> -             *expr_p = fold_convert (type, gimple_boolify (*expr_p));
> -             ret = GS_OK;
> -             break;
> -           }
> +         {
> +           tree org_type = TREE_TYPE (*expr_p);
>
> +           *expr_p = gimple_boolify (*expr_p);
> +           if (org_type != boolean_type_node)
> +             {
> +               *expr_p = fold_convert (org_type, *expr_p);
> +               ret = GS_OK;
> +               break;
> +             }
> +         }
> +
>          ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
>                               is_gimple_val, fb_rvalue);
>          recalculate_side_effects (*expr_p);
>

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Paolo Bonzini]

On 05/13/2011 03:03 AM, Rong Xu wrote:

* gcc/coverage.c(revision 173717): set a flag if building for 
Linux kernel.
* gcc/tree-profile.c(revision 173717): don't emit TLS declarations 
for Linux kernel builds.


I think this should be done without touching at all the profiling 
machinery in GCC.


1) add a new TLS model -ftls-model=none and make the kernel uses it. 
The model would simply force targetm.have_tls to false.


2) as Richi mentioned, gcov-io and libgcov changes then can move to the 
kernel, and GCC needs no change at all here.


BTW, these parts of LIPO:


+  if (!is_kernel_build)
+DECL_TLS_MODEL (dc_gcov_type_ptr_var) =
+ decl_default_tls_model (dc_gcov_type_ptr_var);

   dc_void_ptr_var =
build_decl (UNKNOWN_LOCATION, VAR_DECL,
@@ -1488,8 +1493,9 @@
ptr_void);
   DECL_ARTIFICIAL (dc_void_ptr_var) = 1;
   DECL_EXTERNAL (dc_void_ptr_var) = 1;
-  DECL_TLS_MODEL (dc_void_ptr_var) =
-   decl_default_tls_model (dc_void_ptr_var);
+  if (!is_kernel_build)
+DECL_TLS_MODEL (dc_void_ptr_var) =
+ decl_default_tls_model (dc_void_ptr_var);


Probably are missing a !targetm.have_tls.

Paolo

Re: [patch gimplify]: Fix for PR/48984

[H.J. Lu]

On Thu, May 12, 2011 at 11:59 PM, Kai Tietz  wrote:
> Hello,
>
> this patch fixes the issue reported in PR/48984.  Issue is that
> fortran has multiple BOOLEAN_TYPE'ed types with different modes. So
> the check for BOOLEAN_TYPE in gimplification is wrong and instead we
> need to check for identify to boolean_type_node.
>
> ChangeLog
>
> 2011-05-13  Kai Tietz
>
>        * gimplify.c (gimplify_expr): Check for boolean_type_node instead
>        for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
>        (gimple_boolify): Check for cast for boolean_type_node instead for
>        BOOLEAN_TYPE.
>
> Bootstrap passed and now doing fortran testsuite run to verify.

It isn't completed fixed. I still got

FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1

with revision 173729.

-- 
H.J.

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Kai Tietz]

2011/5/13 Richard Guenther :
> On Fri, May 13, 2011 at 1:31 PM, Kai Tietz  wrote:
>> Hello,
>>
>> this patch adds a check to
>>
>> ChangeLog
>>
>> 2011-05-13  Kai Tietz
>>
>>          * gimplify.c (gimplify_expr): Make sure operand is boolified.
>>          * tree-cfg.c (verify_gimple_assign_unary): Check for boolean
>> compatible type
>>          for TRUTH_NOT_EXPR.
>>
>> Bootstrapped for x86_64-pc-linux-gnu (multilib). Ok for apply?
>
> Ok with 
>
>> Index: tree-cfg.c
>> ===
>> --- tree-cfg.c  (revision 173725)
>> +++ tree-cfg.c  (working copy)
>> @@ -3342,6 +3342,14 @@
>>       return false;
>>
>>     case TRUTH_NOT_EXPR:
>> +      if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
>> +          || !useless_type_conversion_p (boolean_type_node,  lhs_type))
>
> the 2nd check removed, it's redundant with the common check below
>
>  /* For the remaining codes assert there is no conversion involved.  */
>  if (!useless_type_conversion_p (lhs_type, rhs1_type))
>    {
>      error ("non-trivial conversion in unary operation");
>      debug_generic_expr (lhs_type);
>      debug_generic_expr (rhs1_type);
>      return true;
>    }
>
> and ...
>
>> +        {
>> +           error ("invalid types in truth not");
>> +           debug_generic_expr (lhs_type);
>> +           debug_generic_expr (rhs1_type);
>> +           return true;
>> +        }
>
> please do not fall through here but add a break.
>
> Richard.
>
>>     case NEGATE_EXPR:
>>     case ABS_EXPR:
>>     case BIT_NOT_EXPR:
>>
>> Index: gimplify.c
>> ===
>> --- gimplify.c  (revision 173726)
>> +++ gimplify.c  (working copy)
>> @@ -6754,14 +6754,18 @@
>>          }
>>
>>        case TRUTH_NOT_EXPR:
>> -         if (TREE_TYPE (*expr_p) != boolean_type_node)
>> -           {
>> -             tree type = TREE_TYPE (*expr_p);
>> -             *expr_p = fold_convert (type, gimple_boolify (*expr_p));
>> -             ret = GS_OK;
>> -             break;
>> -           }
>> +         {
>> +           tree org_type = TREE_TYPE (*expr_p);
>>
>> +           *expr_p = gimple_boolify (*expr_p);
>> +           if (org_type != boolean_type_node)
>> +             {
>> +               *expr_p = fold_convert (org_type, *expr_p);
>> +               ret = GS_OK;
>> +               break;
>> +             }
>> +         }
>> +
>>          ret = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p, post_p,
>>                               is_gimple_val, fb_rvalue);
>>          recalculate_side_effects (*expr_p);
>>
>

Committed at revision 173732 with your suggested adjustments.

Thanks,
Kai

Re: [patch gimplify]: Fix for PR/48984

[Richard Guenther]

On Fri, May 13, 2011 at 3:17 PM, H.J. Lu  wrote:
> On Thu, May 12, 2011 at 11:59 PM, Kai Tietz  wrote:
>> Hello,
>>
>> this patch fixes the issue reported in PR/48984.  Issue is that
>> fortran has multiple BOOLEAN_TYPE'ed types with different modes. So
>> the check for BOOLEAN_TYPE in gimplification is wrong and instead we
>> need to check for identify to boolean_type_node.
>>
>> ChangeLog
>>
>> 2011-05-13  Kai Tietz
>>
>>        * gimplify.c (gimplify_expr): Check for boolean_type_node instead
>>        for BOOLEAN_TYPE for TRUTH-NOT/AND/OR/XOR.
>>        (gimple_boolify): Check for cast for boolean_type_node instead for
>>        BOOLEAN_TYPE.
>>
>> Bootstrap passed and now doing fortran testsuite run to verify.
>
> It isn't completed fixed. I still got
>
> FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1
>
> with revision 173729.

That's now

  D.2716_9 = (_Bool) x_2(D);
  D.2717_10 = (_Bool) y_5(D);
  D.2718_11 = D.2716_9 & D.2717_10;
  D.2715_12 = (int) D.2718_11;

instead of

  x_9 = x_2(D);
  y_10 = y_5(D);
  D.2715_11 = x_2(D) & y_5(D);

before.  VRP does not optimize the above to the latter even if it would
know that x_2 and y_5 are both [0,1] (for some reason it thinks they
are varying).  Before VRP we had

  D.2716_9 = x_13 != 0;
  D.2717_10 = y_14 != 0;
  D.2715_11 = D.2716_9 && D.2717_10;

which helped VRP see that for _9 and _10 and thus it folded the
truth and to a bitwise and test.

This kind of fallout is expected but we should find a way to address
it.

Richard.

> --
> H.J.
>

Re: Cgraph thunk reorg

[Jan Hubicka]

Hi,
I built a cros with --enable-languages=c,c++ --disable-bootstrap 
--target=powerpc-ibm-aix5.3.0.0
and tried to compile covariant2.C and some of the other testcases you mention, 
but I don't
get the ICE.
Anything that could help me to reproduce this?

Honza
> Honza,
> 
> This patch seems to have introduced approximately 150 new G++
> testsuite failures on AIX.  The errors all are verify_cgraph_node ICEs
> related to thunks.
> 
> The all have a similar pattern:
> 
> /src/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: error:
> non-DECL_ONE_ONLY node in a same_comdat_group list
> c3* c7::_ZTch0_v0_n12_N2c72f6Ev()/3 @70097790 (asm:
> _ZTch0_v0_n12_N2c72f6Ev) (same comdat group as virtual c3* c7::f6()/1)
> availability:available analyzed address_taken externally_visible
> finalized asm_written
>   thunk of c3* *LTHUNK..0() (asm: *LTHUNK..0) fixed offset 0 virtual
> value -12 has virtual offset 1)
>   called by:
>   calls: virtual c3* c7::f6()/1 (1.00 per call)
>   References:
>   Refering this function:  var:int (* c24::_ZTC3c244_2c7 [5])(...) (addr)
> /src/gcc/testsuite/g++.dg/abi/covariant2.C:31:20: internal compiler
> error: verify_cgraph_node failed
> 
> /src/gcc/testsuite/g++.old-deja/g++.robertl/eb30.C:16:1: error:
> non-DECL_ONE_ONLY node in a same_comdat_group list
> void bifstream::_ZTv0_n12_N9bifstreamD0Ev()/172 @709d1420 (asm:
> _ZTv0_n12_N9bifstreamD0Ev) (same comdat group as virtual
> bifstream::~bifstream()/170) availability:available analyzed
> address_taken externally_visible finalized asm_written
>   thunk of void *LTHUNK..1() (asm: *LTHUNK..1) fixed offset 0 virtual
> value -12 has virtual offset 1)
>   called by:
>   calls: virtual bifstream::~bifstream()/170 (1.00 per call)
>   References:
>   Refering this function:  var:int (* bifstream::_ZTV9bifstream
> [10])(...) (addr)
> /src/gcc/testsuite/g++.old-deja/g++.robertl/eb30.C:16:1: internal
> compiler error: verify_cgraph_node failed
> 
> /src/gcc/testsuite/g++.old-deja/g++.jason/mi.C:17:1: error:
> non-DECL_ONE_ONLY node in a same_comdat_group list
> void E::_ZThn4_N1E3fooEv()/4 @700976e0 (asm: _ZThn4_N1E3fooEv) (same
> comdat group as virtual void E::foo()/2) availability:available
> analyzed address_taken externally_visible finalized asm_written
>   thunk of void *LTHUNK..0() (asm: *LTHUNK..0) fixed offset -4 virtual
> value 0 has virtual offset 0)
>   called by:
>   calls: virtual void E::foo()/2 (1.00 per call)
>   References:
>   Refering this function:  var:int (* E::_ZTV1E [7])(...) (addr)
> /src/gcc/testsuite/g++.old-deja/g++.jason/mi.C:17:1: internal compiler
> error: verify_cgraph_node failed
> 
> Thanks, David

C6X port 12/11: htdocs

[Bernd Schmidt]

As requested by Joseph, here are wwwdocs changes for the C6X port.


Bernd

Index: htdocs/backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.39
diff -c -p -r1.39 backends.html
*** htdocs/backends.html3 Jan 2011 15:57:04 -   1.39
--- htdocs/backends.html12 May 2011 13:29:53 -
*** arm  |  da  s
*** 72,77 
--- 72,78 
  avr  |L  FIl  c f m
  bfin |   F p g  da
  c4x  |  ??  N I BD   g  d  e 
+ c6x  |   S CB  p g bda 
  cris |   F  B cp g b a  s
  fr30 | ??FI Bgm s
  frv  | ??   B  pda  s
Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.801
diff -c -p -r1.801 index.html
*** htdocs/index.html   9 May 2011 00:31:43 -   1.801
--- htdocs/index.html   12 May 2011 13:29:53 -
*** mission statement.
*** 53,58 
--- 53,62 
  
  
  
+ May 13, 2011
+ A port for the TI C6X family of processors has been contributed by
+ CodeSourcery.
+ 
  April 28, 2011
  GCC 4.5.3 has been released.
  
Index: htdocs/readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.214
diff -c -p -r1.214 readings.html
*** htdocs/readings.html24 Apr 2011 09:02:00 -  1.214
--- htdocs/readings.html12 May 2011 13:29:53 -
*** names.
*** 99,105 
 Exact chip name: TMS320C4X
 http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
   
!  
   CRIS
 Manufacturer: Axis Communications
 Acronym stands for: Code Reduced Instruction Set
--- 99,112 
 Exact chip name: TMS320C4X
 http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
   
! 
!  C6X
!Manufacturer: Texas Instruments
!Exact chip name: TMS320C6X
!http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
!http://linux-c6x.org/";>Site for the Linux on C6X project
!  
! 
   CRIS
 Manufacturer: Axis Communications
 Acronym stands for: Code Reduced Instruction Set

[PATCH] ARM fixed-point support [1/6]: comparison optab biasing

[Julian Brown]

As per Joseph's suggestion here:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00846.html

I am re-posting machine-independent parts of my ARM fixed-point support
patches, with explanations as to why each part is necessary.

This is the first: on ARM, TARGET_LIB_INT_CMP_BIASED is false for
TARGET_BPABI targets (i.e. most currently-interesting cases --
EABI comparison helper functions return -1/0/1 for lt/eq/gt rather than
0/1/2). However the fixed-point helper library uses biased comparisons
unconditionally. So, this patch just makes comparisons between
fixed-point quantities use the biasing rather than not. (Grepping
config/, in practice, this will only affect ARM.)

Tested in a series with other fixed-point patches. OK to apply?

Julian

ChangeLog

gcc/
* optabs.c (prepare_cmp_insn): Use correct biasing for fixed-point
comparison helpers.
commit 12efebd5f56358c2d194659570ad05e089bbaaf3
Author: Julian Brown 
Date:   Fri May 13 05:42:15 2011 -0700

Correct biasing for fixed-point optabs.

diff --git a/gcc/optabs.c b/gcc/optabs.c
index 62e123b..a1b85b8 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -3930,11 +3930,13 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx_code comparison, rtx size,
 	 result against 1 in the biased case, and zero in the unbiased
 	 case. For unsigned comparisons always compare against 1 after
 	 biasing the unbiased result by adding 1. This gives us a way to
-	 represent LTU. */
+	 represent LTU.
+	 The comparisons in the fixed-point helper library are always
+	 biased.  */
   x = result;
   y = const1_rtx;
 
-  if (!TARGET_LIB_INT_CMP_BIASED)
+  if (!TARGET_LIB_INT_CMP_BIASED && !ALL_FIXED_POINT_MODE_P (mode))
 	{
 	  if (unsignedp)
 	x = plus_constant (result, 1);

[PATCH] ARM fixed-point support [2/6]: assembler format for fixed-point constants

[Julian Brown]

This patch changes the format used to print fixed-point constants from
hex to decimal. For instance a negative "short fract" fixed-point
constant may be represented as a signed HOST_WIDE_INT from -1 to -128,
which would currently be printed as e.g. 0xfffffxx, resulting in a
"bignum truncated to fit" warning from the assembler. This trouble is
avoided if we just print using integers instead, similarly to the way
signed character-constants are emitted elsewhere in the compiler.

Tested along with the rest of the patch series. OK to apply?

Julian

ChangeLog

* final.c (output_addr_const): Print fixed-point constants as
decimal not hex (avoiding an assembler overflow warning for
negative byte constants).
commit 7c169485b6e5b153af02c83e8b858b8613ed7664
Author: Julian Brown 
Date:   Fri May 13 05:44:19 2011 -0700

Tweak fixed-point constant format.

diff --git a/gcc/final.c b/gcc/final.c
index 7e1ae90..b147ddf 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -3633,8 +3633,7 @@ output_addr_const (FILE *file, rtx x)
   break;
 
 case CONST_FIXED:
-  fprintf (file, HOST_WIDE_INT_PRINT_HEX,
-	   (unsigned HOST_WIDE_INT) CONST_FIXED_VALUE_LOW (x));
+  fprintf (file, HOST_WIDE_INT_PRINT_DEC, CONST_FIXED_VALUE_LOW (x));
   break;
 
 case PLUS:

[PATCH] ARM fixed-point support [3/6]: missing FIXED_CST in tree-ssa-sccvn.c:copy_reference_ops_from_ref

[Julian Brown]

This patch adds FIXED_CST to copy_reference_ops_from_ref in
tree-ssa-sccvn.c. Some test code (using fixed-point constants) failed
for me without it. This looks obvious to me, unless there's some
particular reason fixed-point constants need to be handled differently
(or not at all) in that function.

Tested alongside other patches in the series. OK to apply?

Julian

ChangeLog

gcc/
* tree-ssa-sccvn.c (copy_reference_ops_from_ref): Support FIXED_CST.
commit 33446ea85573a6bd9ab000b2d8a6966e0e63c03e
Author: Julian Brown 
Date:   Fri May 13 05:46:15 2011 -0700

Add missing FIXED_CST to copy_reference_ops_from_ref.

diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 8f96d6c..55c1f53 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -681,6 +681,7 @@ copy_reference_ops_from_ref (tree ref, VEC(vn_reference_op_s, heap) **result)
 	case COMPLEX_CST:
 	case VECTOR_CST:
 	case REAL_CST:
+	case FIXED_CST:
 	case CONSTRUCTOR:
 	case VAR_DECL:
 	case PARM_DECL:

[PATCH] ARM fixed-point support [4/6]: allow overriding of fixed-point helper function names

[Julian Brown]

This patch allows the decoration of helper function names for
fixed-point support to be changed from the default "__foo" to a
different scheme, as required by the ARM EABI (these are
"vendor-specific" helpers, so should go in a particular namespace).
These are only the machine-independent changes: the ARM-specific bits
come later.

Tested alongside other patches in the series. OK to apply?

Julian

ChangeLog

gcc/
* config/fixed-bit.h (fixed-bit-machine.h): Include.
(DECORATE_FIXED_NAME): Conditionally define if undefined. Use
throughout file to decorate function names.
* config/fixed-bit-mach-generic.h: New.

libgcc/
* Makefile.in (FIXED_BIT_MACHINE): New rule. Include
target-specific or generic fixed_bit_machine_header to decorate the
names of fixed-point helper functions.
* fixed-obj.mk ($(o)_s$(objext)): Depend on $(FIXED_BIT_MACHINE).
commit 3a3866071a8525ef21ffd66119419a4239797f8a
Author: Julian Brown 
Date:   Fri May 13 05:51:54 2011 -0700

Machine-independent configuration changes for ARM fixed-point support

diff --git a/gcc/config/fixed-bit-mach-generic.h b/gcc/config/fixed-bit-mach-generic.h
new file mode 100644
index 000..8bfbf53
--- /dev/null
+++ b/gcc/config/fixed-bit-mach-generic.h
@@ -0,0 +1,23 @@
+/* Null machine-specific override for fixed-point support routine names.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published
+   by the Free Software Foundation; either version 3, or (at your
+   option) any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
diff --git a/gcc/config/fixed-bit.h b/gcc/config/fixed-bit.h
index 562772d..1cce4ef 100644
--- a/gcc/config/fixed-bit.h
+++ b/gcc/config/fixed-bit.h
@@ -25,6 +25,13 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #ifndef _FIXED_BIT_H
 #define _FIXED_BIT_H
 
+#include "fixed-bit-machine.h"
+
+/* This macro may be overridden for a given target in fixed-bit-machine.h.  */
+#ifndef DECORATE_FIXED_NAME
+#define DECORATE_FIXED_NAME(X) __ ## X
+#endif
+
 /* To use this file we need to define one of the following:
QQ_MODE, UQQ_MODE, HQ_MODE, UHQ_MODE, SQ_MODE, USQ_MODE, DQ_MODE, UDQ_MODE,
TQ_MODE, UTQ_MODE, HA_MODE, UHA_MODE, SA_MODE, USA_MODE, DA_MODE, UDA_MODE,
@@ -445,35 +452,37 @@ typedef union
 #define IBITS		IBITS2(MODE_NAME)
 #define I_F_BITS	(FBITS + IBITS)
 
-#define FIXED_OP(OP,MODE,NUM)	OP ## MODE ## NUM
-
-#define FIXED_SATURATE1_TEMP(NAME)	FIXED_OP(__saturate1,NAME,)
-#define FIXED_SATURATE2_TEMP(NAME)	FIXED_OP(__saturate2,NAME,)
-#define FIXED_MULHELPER_TEMP(NAME)	FIXED_OP(__mulhelper,NAME,)
-#define FIXED_DIVHELPER_TEMP(NAME)	FIXED_OP(__divhelper,NAME,)
-#define FIXED_ASHLHELPER_TEMP(NAME)	FIXED_OP(__ashlhelper,NAME,)
-#define FIXED_ADD_TEMP(NAME)	FIXED_OP(__add,NAME,3)
-#define FIXED_SSADD_TEMP(NAME)	FIXED_OP(__ssadd,NAME,3)
-#define FIXED_USADD_TEMP(NAME)	FIXED_OP(__usadd,NAME,3)
-#define FIXED_SUB_TEMP(NAME)	FIXED_OP(__sub,NAME,3)
-#define FIXED_SSSUB_TEMP(NAME)	FIXED_OP(__sssub,NAME,3)
-#define FIXED_USSUB_TEMP(NAME)	FIXED_OP(__ussub,NAME,3)
-#define FIXED_MUL_TEMP(NAME)	FIXED_OP(__mul,NAME,3)
-#define FIXED_SSMUL_TEMP(NAME)	FIXED_OP(__ssmul,NAME,3)
-#define FIXED_USMUL_TEMP(NAME)	FIXED_OP(__usmul,NAME,3)
-#define FIXED_DIV_TEMP(NAME)	FIXED_OP(__div,NAME,3)
-#define FIXED_UDIV_TEMP(NAME)	FIXED_OP(__udiv,NAME,3)
-#define FIXED_SSDIV_TEMP(NAME)	FIXED_OP(__ssdiv,NAME,3)
-#define FIXED_USDIV_TEMP(NAME)	FIXED_OP(__usdiv,NAME,3)
-#define FIXED_NEG_TEMP(NAME)	FIXED_OP(__neg,NAME,2)
-#define FIXED_SSNEG_TEMP(NAME)	FIXED_OP(__ssneg,NAME,2)
-#define FIXED_USNEG_TEMP(NAME)	FIXED_OP(__usneg,NAME,2)
-#define FIXED_ASHL_TEMP(NAME)	FIXED_OP(__ashl,NAME,3)
-#define FIXED_ASHR_TEMP(NAME)	FIXED_OP(__ashr,NAME,3)
-#define FIXED_LSHR_TEMP(NAME)	FIXED_OP(__lshr,NAME,3)
-#define FIXED_SSASHL_TEMP(NAME)	FIXED_OP(__ssashl,NAME,3)
-#define FIXED_USASHL_TEMP(NAME)	FIXED_OP(__usashl,NAME,3)
-#define FIXED_CMP_TEMP(NAME)	FIXED_OP(__cmp,NAME,2)
+#define FIXED_OP3(OP,MODE,NUM)	OP ## MODE ## NUM
+#define FIXED_OP2(OP,MODE,NUM)	FIXED_OP3 (OP, MODE, NUM)
+#define FIXED_OP(OP,MODE,NUM)	FIXED_OP2 (DECORATE_FIXED_NAME (OP), MODE, NUM)
+
+#define FIXED_SATURATE1_TEMP(NA

[PATCH] ARM fixed-point support [6/6]: target-specific parts

[Julian Brown]

This is the last patch to add fixed-point support to the ARM backend,
the actual ARM-specific backend parts. It's functionally unchanged from
the earlier patch:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00837.html

although Joseph's comments have (hopefully) all been addressed. One
must now configure with "--enable-fixed-point" to enable the
fixed-point support.

Tested alongside other patches in the series. OK to apply?

Julian

ChangeLog

gcc/
* configure.ac (fixed-point): Add ARM support.
* config/arm/arm.c (arm_fixed_mode_set): New struct.
(arm_set_fixed_optab_libfunc): New.
(arm_set_fixed_conv_libfunc): New.
(arm_init_libfuncs): Initialise fixed-point helper libfuncs with
ARM-specific names.
(arm_scalar_mode_supported_p): Support fixed-point modes.
(arm_vector_mode_supported_p): Support vector fixed-point modes.
* config/arm/arm-modes.def (FRACT, UFRACT, ACCUM, UACCUM): Declare
vector modes.
* config/arm/predicates.md (sat_shift_operator): New predicate.
* config/arm/arm-fixed.md: New.
* config/arm/arm.md: Include arm-fixed.md.
* config/arm/t-arm (MD_INCLUDES): Add arm-fixed.md.
* config/arm/fixed-bit-machine.h: New.
 
libgcc/
* config.host (arm*-*-linux*, arm*-*-uclinux*, arm*-*-eabi*)
(arm*-*-symbianelf*): Add arm/t-fixed-point makefile fragment.
target-specific or generic fixed_bit_machine_header to decorate the
names of fixed-point helper functions.
* config/arm/t-fixed-point: New.

gcc/testsuite/
* gcc.target/arm/fixed-point-exec.c: New test.

commit a93c41f6d4a4d4f434be897e5a3e8a16a4d4e9ad
Author: Julian Brown 
Date:   Wed May 11 04:42:46 2011 -0700

Fixed-point extension support for ARM.

diff --git a/gcc/config/arm/arm-fixed.md b/gcc/config/arm/arm-fixed.md
new file mode 100644
index 000..b19745e
--- /dev/null
+++ b/gcc/config/arm/arm-fixed.md
@@ -0,0 +1,402 @@
+;; Copyright 2011 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published
+;; by the Free Software Foundation; either version 3, or (at your
+;; option) any later version.
+;;
+;; GCC is distributed in the hope that it will be useful, but WITHOUT
+;; ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+;; or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+;; License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+;;
+;; This file contains ARM instructions that support fixed-point operations.
+
+(define_mode_iterator FIXED [QQ HQ SQ UQQ UHQ USQ HA SA UHA USA])
+
+(define_mode_iterator ADDSUB [V4QQ V2HQ V2HA])
+
+(define_mode_iterator UQADDSUB [V4UQQ V2UHQ UQQ UHQ V2UHA UHA])
+
+(define_mode_iterator QADDSUB [V4QQ V2HQ QQ HQ V2HA HA SQ SA])
+
+(define_mode_iterator QMUL [HQ HA])
+
+(define_mode_attr qaddsub_suf [(V4UQQ "8") (V2UHQ "16") (UQQ "8") (UHQ "16")
+			   (V2UHA "16") (UHA "16")
+			   (V4QQ "8") (V2HQ "16") (QQ "8") (HQ "16")
+			   (V2HA "16") (HA "16") (SQ "") (SA "")])
+
+(define_insn "add3"
+  [(set (match_operand:FIXED 0 "s_register_operand" "=r")
+	(plus:FIXED (match_operand:FIXED 1 "s_register_operand" "r")
+		(match_operand:FIXED 2 "s_register_operand" "r")))]
+  "TARGET_32BIT"
+  "add%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn "add3"
+  [(set (match_operand:ADDSUB 0 "s_register_operand" "=r")
+	(plus:ADDSUB (match_operand:ADDSUB 1 "s_register_operand" "r")
+		 (match_operand:ADDSUB 2 "s_register_operand" "r")))]
+  "TARGET_INT_SIMD"
+  "sadd%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn "usadd3"
+  [(set (match_operand:UQADDSUB 0 "s_register_operand" "=r")
+	(us_plus:UQADDSUB (match_operand:UQADDSUB 1 "s_register_operand" "r")
+			  (match_operand:UQADDSUB 2 "s_register_operand" "r")))]
+  "TARGET_INT_SIMD"
+  "uqadd%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn "ssadd3"
+  [(set (match_operand:QADDSUB 0 "s_register_operand" "=r")
+	(ss_plus:QADDSUB (match_operand:QADDSUB 1 "s_register_operand" "r")
+			 (match_operand:QADDSUB 2 "s_register_operand" "r")))]
+  "TARGET_INT_SIMD"
+  "qadd%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn "sub3"
+  [(set (match_operand:FIXED 0 "s_register_operand" "=r")
+	(minus:FIXED (match_operand:FIXED 1 "s_register_operand" "r")
+		 (match_operand:FIXED 2 "s_register_operand" "r")))]
+  "TARGET_32BIT"
+  "sub%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn "sub3"
+  [(set (match_operand:ADDSUB 0 "s_register_operand" "=r")
+	(minus:ADDSUB (match_operand:ADDSUB 1 "s_register_operand" "r")
+		  (match_operand:ADDSUB 2 "s_register_operand" "r")))]
+  "TARGET_INT_SIMD"
+  "ssub%?\\t%0, %1, %2"
+  [(set_attr "predicable" "yes")])
+
+(define_insn

C6X port 13/11: MAINTAINERS

[Bernd Schmidt]

On 05/10/2011 06:51 PM, Joseph S. Myers wrote:

> * If you are volunteering to be maintainer of the port, make that explicit 
> (and probably post to gcc@ for the attention of the SC; maintainership 
> needs approving by the SC, separately from the technical review of the 
> patches).

Patch appended.


Bernd
* MAINTAINERS (c6x port): New entry.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 173563)
+++ MAINTAINERS (working copy)
@@ -50,6 +50,7 @@ avr port  Anatoly Sokolov ae...@post.ru
 avr port   Eric Weddington eric.wedding...@atmel.com
 bfin port  Bernd Schmidt   ber...@codesourcery.com
 bfin port  Jie Zhang   jzhang...@gmail.com
+c6x port   Bernd Schmidt   ber...@codesourcery.com
 cris port  Hans-Peter Nilsson  h...@axis.com
 fr30 port  Nick Cliftonni...@redhat.com
 frv port   Nick Cliftonni...@redhat.com

[PATCH][?/n] Cleanup LTO type merging

[Richard Guenther]

This gets rid of type pair caching in the canonical type comparison.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2011-05-13  Richard Guenther  

* gimple.c (gimple_canonical_types_compatible_p): Do not use
type-pair caching, do not compare hashes.

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 173730)
+++ gcc/gimple.c(working copy)
@@ -4569,8 +4569,6 @@ gimple_register_type (tree t)
 static bool
 gimple_canonical_types_compatible_p (tree t1, tree t2)
 {
-  type_pair_t p = NULL;
-
   /* Before starting to set up the SCC machinery handle simple cases.  */
 
   /* Check first for the obvious case of pointer identity.  */
@@ -4656,27 +4654,9 @@ gimple_canonical_types_compatible_p (tre
   return true;
 }
 
-  /* If the hash values of t1 and t2 are different the types can't
- possibly be the same.  This helps keeping the type-pair hashtable
- small, only tracking comparisons for hash collisions.  */
-  if (gimple_canonical_type_hash (t1) != gimple_canonical_type_hash (t2))
-return false;
-
-  /* If we've visited this type pair before (in the case of aggregates
- with self-referential types), and we made a decision, return it.  */
-  p = lookup_type_pair (t1, t2, >c_visited, >c_ob);
-  if (p->same_p[GTC_DIAG] == 0 || p->same_p[GTC_DIAG] == 1)
-{
-  /* We have already decided whether T1 and T2 are the
-same, return the cached result.  */
-  return p->same_p[GTC_DIAG] == 1;
-}
-
-  gcc_assert (p->same_p[GTC_DIAG] == -2);
-
   /* 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;
+return false;
 
   /* Do type-specific comparisons.  */
   switch (TREE_CODE (t1))
@@ -4687,7 +4667,7 @@ gimple_canonical_types_compatible_p (tre
   if (!gimple_canonical_types_compatible_p (TREE_TYPE (t1), TREE_TYPE (t2))
  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
  || TYPE_NONALIASED_COMPONENT (t1) != TYPE_NONALIASED_COMPONENT (t2))
-   goto different_types;
+   return false;
   else
{
  tree i1 = TYPE_DOMAIN (t1);
@@ -4696,16 +4676,16 @@ gimple_canonical_types_compatible_p (tre
  /* For an incomplete external array, the type domain can be
 NULL_TREE.  Check this condition also.  */
  if (i1 == NULL_TREE && i2 == NULL_TREE)
-   goto same_types;
+   return true;
  else if (i1 == NULL_TREE || i2 == NULL_TREE)
-   goto different_types;
+   return false;
  /* If for a complete array type the possibly gimplified sizes
 are different the types are different.  */
  else if (((TYPE_SIZE (i1) != NULL) ^ (TYPE_SIZE (i2) != NULL))
   || (TYPE_SIZE (i1)
   && TYPE_SIZE (i2)
   && !operand_equal_p (TYPE_SIZE (i1), TYPE_SIZE (i2), 0)))
-   goto different_types;
+   return false;
  else
{
  tree min1 = TYPE_MIN_VALUE (i1);
@@ -4724,9 +4704,9 @@ gimple_canonical_types_compatible_p (tre
  && ((TREE_CODE (max1) == PLACEHOLDER_EXPR
   && TREE_CODE (max2) == PLACEHOLDER_EXPR)
  || operand_equal_p (max1, max2, 0)
-   goto same_types;
+   return true;
  else
-   goto different_types;
+   return false;
}
}
 
@@ -4734,7 +4714,7 @@ gimple_canonical_types_compatible_p (tre
   /* Method types should belong to the same class.  */
   if (!gimple_canonical_types_compatible_p
 (TYPE_METHOD_BASETYPE (t1), TYPE_METHOD_BASETYPE (t2)))
-   goto different_types;
+   return false;
 
   /* Fallthru  */
 
@@ -4745,13 +4725,13 @@ gimple_canonical_types_compatible_p (tre
 (TREE_TYPE (t1), TREE_TYPE (t2))
  && !gimple_canonical_types_compatible_p
(TREE_TYPE (t1), TREE_TYPE (t2)))
-   goto different_types;
+   return false;
 
   if (!comp_type_attributes (t1, t2))
-   goto different_types;
+   return false;
 
   if (TYPE_ARG_TYPES (t1) == TYPE_ARG_TYPES (t2))
-   goto same_types;
+   return true;
   else
{
  tree parms1, parms2;
@@ -4764,13 +4744,13 @@ gimple_canonical_types_compatible_p (tre
 (TREE_VALUE (parms1), TREE_VALUE (parms2))
  && !gimple_canonical_types_compatible_p
(TREE_VALUE (parms1), TREE_VALUE (parms2)))
-   goto different_types;
+   return false;
}
 
  if (parms1 || parms2)
-   goto different_types;
+   return false;
 
- goto same_types;
+ return true;
}
 
 case RECORD_TYPE:
@@ -4789,3

Re: [PATCH, ARM] ISO/IEC TR 18037 fixed-point support

[Julian Brown]

On Wed, 11 May 2011 15:27:37 + (UTC)
"Joseph S. Myers"  wrote:

> On Wed, 11 May 2011, Julian Brown wrote:
> 
> > There's currently no support for "long long" fixed-point types,
> > since those imply support for TImode arithmetic, which isn't
> > sensible on ARM. I've modified tests to make optional the
> > requirement for long long support.
> 
> I wonder how those tests work, or don't work, on 32-bit MIPS, which
> ought to have the same issue

Well they do seem to work, though I haven't investigated why.

> Is there a reason for having a separate function, rather than just
> using hook_bool_void_true (with this comment going on the definition
> of TARGET_FIXED_POINT_SUPPORTED_P)?
> 
> I don't see any change to the code in gcc/configure.ac that handles 
> --enable-fixed-point to know that ARM targets now support it.  Since
> the default hook returns ENABLE_FIXED_POINT, maybe if you fixed the
> configure test you wouldn't need to define the hook for ARM at all

I've done the latter: note you'll now need to configure with
"--enable-fixed-point" to turn fixed-point on for ARM.

> It might make sense to send the machine-independent parts separately, 
> under a separate subject heading, with an explanation for why each
> bit is needed.

I've done this (and the other bits you pointed out). See:

http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00964.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00965.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00966.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00967.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00969.html
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00968.html

Cheers,

Julian

Re: Prefixes for libgcc symbols (C6X 9.5/11)

[Joseph S. Myers]

On Fri, 13 May 2011, Bernd Schmidt wrote:

> The following patch adds a target hook and a corresponding LIBGCC2_
> macro which control the generation of library function names. It also
> makes libgcc-std.ver a generated file, built from libgcc-std.ver.in by
> replacing some placeholders with the correct prefixes. While I was
> there, I also added functionality to generate a version of this file
> with an extra underscore for the Blackfin port.

But the linker was changed to use C symbol names in linker scripts and I 
was told that this script in GCC would be removed in consequence.

http://sourceware.org/ml/binutils/2010-12/msg00375.html

Any new target macro for use only in target libraries should, in my view, 
be poisoned in the host system.h from the start to ensure that no-one 
accidentally adds definitions to the host tm.h.  This would be alongside 
the existing

/* Target macros only used for code built for the target, that have
   moved to libgcc-tm.h.  */
 #pragma GCC poison DECLARE_LIBRARY_RENAMES

or just change the comment on that pragma so it doesn't imply that the 
macro was once defined in tm.h.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [patch, ARM] Fix PR42017, LR not used in leaf functions

[Richard Sandiford]

Richard Sandiford  writes:
> Chung-Lin Tang  writes:
>> My fix here simply adds 'reload_completed' as an additional condition
>> for EPILOGUE_USES to return true for LR_REGNUM. I think this should be
>> valid, as correct LR save/restoring is handled by the epilogue/prologue
>> code; it should be safe for IRA to treat it as a normal call-used register.
>
> FWIW, epilogue_completed might be a more accurate choice.

I still stand by this, although I realise no other target does it.

> It seems a lot of other ports suffer from the same problem though.
> I wonder which targets really do want to make a register live throughout
> the function?  If none do, perhaps we should say that this macro is
> only meaningful once the epilogue has been generated.

To answer my own question, I suppose VRSAVE is one.  So I was wrong
about the target-independent "fix".

Richard

Re: C6X port 10/11: The port

[Joseph S. Myers]

On Fri, 13 May 2011, Bernd Schmidt wrote:

> On 05/10/2011 09:53 PM, Joseph S. Myers wrote:
> > General comment: there are lots of new files here that are built for the 
> > target, and if possible it's preferable for such sources to be under 
> > libgcc/config/ with associated build rules also located there not in the 
> > gcc/ directory.
> 
> I've made an attempt to move over the floating-point library functions,
> but this doesn't work since the include paths aren't set up properly -
> sfp-machine.h isn't found regardless of where it is placed. So I've left
> things in place for now.

I had thought there were some soft-fp files in libgcc/, but actually it 
appears there are just wrappers (see config/i386/64) including files from 
libgcc/config/.  Moving non-soft-fp files to libgcc/config/ should work, 
however.

> I'm also unsure what to do about t-c6x-softfp. I've noticed that e.g.
> moxie has two copies of the corresponding file, but I don't know why.

The main soft-fp configuration will only work in the gcc/ directory at 
present.

> >> +/* Make __c6xabi_AEABI_NAME an alias for __GCC_NAME.  */
> 
> > All this code now needs to go in a header in libgcc/config/, listed in 
> > libgcc_tm_file.
> 
> Changed. However, there's no libgcc_tm_file as far as I can see and
> other ports add the header to tm_file.

See r173619.

> > It's desirable for --target-help to show the list of valid values, either 
> > in the help for the individual option (as for various Enum options in 
> > common.opt, using the TAB-separated form of help text) or by adding a help 
> > text to the Enum definition.
> 
> I've done the latter. Text added to the EnumValues appears to be
> ignored, is that correct?

Yes, EnumValue entries don't have their own help text.

> > * Add the two new targets to contrib/config-list.mk (and confirm they do 
> > pass --enable-werror-always builds with current trunk GCC).
> 
> Added. I've tried to change my builds to use that option, but there are
> lots of errors that appear unrelated to the C6X port. c6x.o compiles
> without warnings.

There shouldn't be lots of errors; Joern does such builds frequently.  
Note that you need to start with a *current native trunk compiler* and use 
that when building the cross compiler; GCC is only expected to build 
cleanly with -Werror when the build uses the same version of GCC, not when 
it uses an older release.

>  - gcc.dg/march.c fails due to extra help text

It looks like this needs a similar fix (target-independent) to r172056 
(which fixed mtune.c).

> +#define PREFERRED_RELOAD_CLASS(x, class) (class)

This macro is being phased out and replaced by a target hook.  In general 
any target macro whose only use is in targhooks.c to provide a default 
transitional version of a hook should not be defined by a new port; new 
ports should define the hooks directly for all macros that are at that 
stage in transition to being hooks.

> +GCC_4.5.0 {

4.7.0 seems more appropriate for a new configuration.

> +  __c6xabi_divi
> +  __c6xabi_divu
> +  __c6xabi_remu
> +  __c6xabi_remi
> +  __c6xabi_divremu
> +  __c6xabi_divremi

> +  __c6xabi_strasgi_64plus
> +  __c6xabi_push_rts
> +  __c6xabi_pop_rts

These are all marked hidden in lib1funcs.asm, presumably because of their 
special register use conventions, so it doesn't make sense to give them 
symbol versions.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C6X port 12/11: htdocs

[Joseph S. Myers]

I forgot about it in my previous message, but there should be a release 
note in gcc-4.7/changes.html as well.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] ARM fixed-point support [6/6]: target-specific parts

[Joseph S. Myers]

On Fri, 13 May 2011, Julian Brown wrote:

> although Joseph's comments have (hopefully) all been addressed. One
> must now configure with "--enable-fixed-point" to enable the
> fixed-point support.

No, that's not how this configure logic works; it enables fixed point by 
default for the given targets.  The bit that enables it by default for 
MIPS (and that you're changing to cover ARM as well) is the code that is 
called if the user *doesn't* pass --enable-fixed-point or 
--disable-fixed-point.

That is, for ARM and non-IRIX MIPS it's enabled by default; for other 
targets it's disabled by default.  In any case, an explicit configure 
option overrides this default.  Which is the logic we want.  The only 
problem is the calls to AC_MSG_WARN, which produce

configure: WARNING: fixed-point is not supported for this target, ignored

when you didn't pass any fixed-point configure option.  And that's a 
pre-existing problem, that could be fixed simply by removing two 
AC_MSG_WARN calls.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C6X port 10/11: The port

[Bernd Schmidt]

On 05/13/2011 04:46 PM, Joseph S. Myers wrote:
> There shouldn't be lots of errors; Joern does such builds frequently.  
> Note that you need to start with a *current native trunk compiler* and use 
> that when building the cross compiler; GCC is only expected to build 
> cleanly with -Werror when the build uses the same version of GCC, not when 
> it uses an older release.

Ah ok.

>> +#define PREFERRED_RELOAD_CLASS(x, class) (class)
> 
> This macro is being phased out and replaced by a target hook.  In general 
> any target macro whose only use is in targhooks.c to provide a default 
> transitional version of a hook should not be defined by a new port; new 
> ports should define the hooks directly for all macros that are at that 
> stage in transition to being hooks.

Any others you spotted? I took care of a few of them earlier
(PRINT_OPERAND etc.). Maybe we need a poison_warn pragma?

>> +GCC_4.5.0 {
> 
> 4.7.0 seems more appropriate for a new configuration.

Even if we also add this to our 4.5 based tree?


Bernd

Re: [PATCH, ARM] ISO/IEC TR 18037 fixed-point support

[Joseph S. Myers]

On Fri, 13 May 2011, Julian Brown wrote:

> On Wed, 11 May 2011 15:27:37 + (UTC)
> "Joseph S. Myers"  wrote:
> 
> > On Wed, 11 May 2011, Julian Brown wrote:
> > 
> > > There's currently no support for "long long" fixed-point types,
> > > since those imply support for TImode arithmetic, which isn't
> > > sensible on ARM. I've modified tests to make optional the
> > > requirement for long long support.
> > 
> > I wonder how those tests work, or don't work, on 32-bit MIPS, which
> > ought to have the same issue
> 
> Well they do seem to work, though I haven't investigated why.

I think that does need further investigation, since it means that at least 
the claimed reason for needing patch 5/6 has something wrong with it.  
Maybe there's a reason it's appropriate to disable those types and tests 
on some targets, but it's not "those imply support for TImode arithmetic".

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: C6X port 10/11: The port

[Joseph S. Myers]

On Fri, 13 May 2011, Bernd Schmidt wrote:

> >> +#define PREFERRED_RELOAD_CLASS(x, class) (class)
> > 
> > This macro is being phased out and replaced by a target hook.  In general 
> > any target macro whose only use is in targhooks.c to provide a default 
> > transitional version of a hook should not be defined by a new port; new 
> > ports should define the hooks directly for all macros that are at that 
> > stage in transition to being hooks.
> 
> Any others you spotted? I took care of a few of them earlier
> (PRINT_OPERAND etc.). Maybe we need a poison_warn pragma?

I didn't spot any others.

> >> +GCC_4.5.0 {
> > 
> > 4.7.0 seems more appropriate for a new configuration.
> 
> Even if we also add this to our 4.5 based tree?

Yes.  Backporting

%inherit GCC_4.6.0 GCC_4.5.0
GCC_4.6.0 {
}
%inherit GCC_4.7.0 GCC_4.6.0
GCC_4.7.0 {
}

in libgcc-std.ver is easy.  (The latter isn't yet in trunk, it's added by 
; whatever the 
first patch to go in trunk with GCC_4.7.0 symbol versions is needs to add 
it to libgcc-std.ver.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Fix PR46728 (move pow/powi folds to tree phases)

[Nathan Froyd]

On 05/13/2011 10:52 AM, William J. Schmidt wrote:
> This patch addresses PR46728, which notes that pow and powi need to be
> lowered in tree phases to restore lost FMA opportunities and expose
> vectorization opportunities.
>
> +struct gimple_opt_pass pass_lower_pow =
> +{
> + {
> +  GIMPLE_PASS,
> +  "lower_pow",   /* name */
> +  NULL,  /* gate */

Please make this controlled by an option; this pass doesn't need to be run all
the time.

IMHO, the pass shouldn't run at anything less than -O3, but that's for other
people to decide.

-Nathan

Re: C6X port 12/11: htdocs

[Bernd Schmidt]

On 05/13/2011 04:47 PM, Joseph S. Myers wrote:
> I forgot about it in my previous message, but there should be a release 
> note in gcc-4.7/changes.html as well.

New version below.


Bernd
Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.39
diff -c -p -r1.39 backends.html
*** backends.html   3 Jan 2011 15:57:04 -   1.39
--- backends.html   13 May 2011 15:11:29 -
*** arm  |  da  s
*** 72,77 
--- 72,78 
  avr  |L  FIl  c f m
  bfin |   F p g  da
  c4x  |  ??  N I BD   g  d  e 
+ c6x  |   S CB  p g bda 
  cris |   F  B cp g b a  s
  fr30 | ??FI Bgm s
  frv  | ??   B  pda  s
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.801
diff -c -p -r1.801 index.html
*** index.html  9 May 2011 00:31:43 -   1.801
--- index.html  13 May 2011 15:11:29 -
*** mission statement.
*** 53,58 
--- 53,62 
  
  
  
+ May 13, 2011
+ A port for the TI C6X family of processors has been contributed by
+ CodeSourcery.
+ 
  April 28, 2011
  GCC 4.5.3 has been released.
  
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.214
diff -c -p -r1.214 readings.html
*** readings.html   24 Apr 2011 09:02:00 -  1.214
--- readings.html   13 May 2011 15:11:29 -
*** names.
*** 99,105 
 Exact chip name: TMS320C4X
 http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
   
!  
   CRIS
 Manufacturer: Axis Communications
 Acronym stands for: Code Reduced Instruction Set
--- 99,112 
 Exact chip name: TMS320C4X
 http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
   
! 
!  C6X
!Manufacturer: Texas Instruments
!Exact chip name: TMS320C6X
!http://www.ti.com/sc/docs/psheets/man_dsp.htm";>DSP 
Manuals
!http://linux-c6x.org/";>Site for the Linux on C6X project
!  
! 
   CRIS
 Manufacturer: Axis Communications
 Acronym stands for: Code Reduced Instruction Set
Index: gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.12
diff -c -p -r1.12 changes.html
*** gcc-4.7/changes.html11 May 2011 16:38:39 -  1.12
--- gcc-4.7/changes.html13 May 2011 15:11:29 -
***
*** 88,93 
--- 88,99 
  
  New Targets and Target Specific Improvements
  
+ C6X
+   
+ Support has been added for the Texas Instruments C6X family of
+   processors.
+   
+ 
  IA-32/x86-64

  ...

Re: [PATCH] Fix PR46728 (move pow/powi folds to tree phases)

[Richard Guenther]

On Fri, May 13, 2011 at 5:01 PM, Nathan Froyd  wrote:
> On 05/13/2011 10:52 AM, William J. Schmidt wrote:
>> This patch addresses PR46728, which notes that pow and powi need to be
>> lowered in tree phases to restore lost FMA opportunities and expose
>> vectorization opportunities.
>>
>> +struct gimple_opt_pass pass_lower_pow =
>> +{
>> + {
>> +  GIMPLE_PASS,
>> +  "lower_pow",                               /* name */
>> +  NULL,                                      /* gate */
>
> Please make this controlled by an option; this pass doesn't need to be run all
> the time.
>
> IMHO, the pass shouldn't run at anything less than -O3, but that's for other
> people to decide.

It was run unconditionally before, so unless we preserve the code at
expansion time we have to do it here.

I will have a closer look at the patch early next week.  Btw, I thought
of adding a POW_EXPR tree code that can take mixed-mode operands
to make foldings (eventually) simpler, but I'm not sure it's worth the
trouble.

The position of the pass is odd - why did you place it there?  I would
have placed it alongside pass_cse_sincos and pass_optimize_bswap.
The foldings should probably be done via fold-stmt only (where they
should already apply), and you won't catch things like pow(sqrt(...))
there because you only see the outer call.  That said, I'd be happier
if the patch just did the powi expansion and left the rest to somebody
else.

Richard.

Re: [PATCH] Fix PR46728 (move pow/powi folds to tree phases)

[William J. Schmidt]

On Fri, 2011-05-13 at 17:26 +0200, Richard Guenther wrote:
> On Fri, May 13, 2011 at 5:01 PM, Nathan Froyd  
> wrote:
> > On 05/13/2011 10:52 AM, William J. Schmidt wrote:
> >> This patch addresses PR46728, which notes that pow and powi need to be
> >> lowered in tree phases to restore lost FMA opportunities and expose
> >> vectorization opportunities.
> >>
> >> +struct gimple_opt_pass pass_lower_pow =
> >> +{
> >> + {
> >> +  GIMPLE_PASS,
> >> +  "lower_pow",   /* name */
> >> +  NULL,  /* gate */
> >
> > Please make this controlled by an option; this pass doesn't need to be run 
> > all
> > the time.
> >
> > IMHO, the pass shouldn't run at anything less than -O3, but that's for other
> > people to decide.
> 
> It was run unconditionally before, so unless we preserve the code at
> expansion time we have to do it here.

Right.  A number of tests fail at -O0 if it's not done unconditionally.
This seemed better than having duplicate code remain in expand.

> 
> I will have a closer look at the patch early next week.  

Much obliged!

> Btw, I thought
> of adding a POW_EXPR tree code that can take mixed-mode operands
> to make foldings (eventually) simpler, but I'm not sure it's worth the
> trouble.
> 
> The position of the pass is odd - why did you place it there?  I would
> have placed it alongside pass_cse_sincos and pass_optimize_bswap.

That was where I wanted it initially also, but this seems necessary for
the pass to run unconditionally.  If I recall correctly,
gate_all_optimizations() was kicking in at -O0, so I had to move it
earlier.

> The foldings should probably be done via fold-stmt only (where they
> should already apply), and you won't catch things like pow(sqrt(...))
> there because you only see the outer call.  That said, I'd be happier
> if the patch just did the powi expansion and left the rest to somebody
> else.

I'm not sure I understand this last part.  The original concern of
PR46728 regarded __builtin_pow(x, 0.75) being lowered too late for the
FMA optimization to kick in, so I needed to address that.  I'm probably
misunderstanding you.

> 
> Richard.

RFA: patch to fix PR48971

[Vladimir Makarov]

The following patch solves the problem described on 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48971


The patch was successfully bootstrapped on x86-64 and checked for ppc64, 
ia64, i686-linux, i686-apple-darwin, mips, arm, s390x, and sparc with 
and without -msoft-float.


Is it ok to submit to the trunk?

2011-05-13  Vladimir Makarov 

PR rtl-optimization/48971
* ira.c (setup_pressure_classes): Don't check register move cost
for classes with one registers.  Don't add pressure class if there
is a pressure class with the same available hard registers.
Check contains_reg_of_mode.  Fix a typo in collecting
temp_hard_regset.  Ignore hard registers not belonging to a class.


Index: ira.c
===
--- ira.c   (revision 173706)
+++ ira.c   (working copy)
@@ -799,27 +799,30 @@ setup_pressure_classes (void)
 {
   if (ira_available_class_regs[cl] == 0)
continue;
-  /* Check that the moves between any hard registers of the
-current class are not more expensive for a legal mode than
-load/store of the hard registers of the current class.  Such
-class is a potential candidate to be a register pressure
-class.  */
-  for (m = 0; m < NUM_MACHINE_MODES; m++)
+  if (ira_available_class_regs[cl] != 1)
{
- COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
- AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs);
- AND_COMPL_HARD_REG_SET (temp_hard_regset,
- ira_prohibited_class_mode_regs[cl][m]);
- if (hard_reg_set_empty_p (temp_hard_regset))
+ /* Check that the moves between any hard registers of the
+current class are not more expensive for a legal mode
+than load/store of the hard registers of the current
+class.  Such class is a potential candidate to be a
+register pressure class.  */
+ for (m = 0; m < NUM_MACHINE_MODES; m++)
+   {
+ COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
+ AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs);
+ AND_COMPL_HARD_REG_SET (temp_hard_regset,
+ ira_prohibited_class_mode_regs[cl][m]);
+ if (hard_reg_set_empty_p (temp_hard_regset))
+   continue;
+ ira_init_register_move_cost_if_necessary ((enum machine_mode) m);
+ cost = ira_register_move_cost[m][cl][cl];
+ if (cost <= ira_max_memory_move_cost[m][cl][1]
+ || cost <= ira_max_memory_move_cost[m][cl][0])
+   break;
+   }
+ if (m >= NUM_MACHINE_MODES)
continue;
- ira_init_register_move_cost_if_necessary ((enum machine_mode) m);
- cost = ira_register_move_cost[m][cl][cl];
- if (cost <= ira_max_memory_move_cost[m][cl][1]
- || cost <= ira_max_memory_move_cost[m][cl][0])
-   break;
}
-  if (m >= NUM_MACHINE_MODES)
-   continue;
   curr = 0;
   insert_p = true;
   COPY_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
@@ -848,6 +851,8 @@ setup_pressure_classes (void)
  && (! hard_reg_set_equal_p (temp_hard_regset2, temp_hard_regset)
  || cl == (int) GENERAL_REGS))
continue;
+ if (hard_reg_set_equal_p (temp_hard_regset2, temp_hard_regset))
+   insert_p = false;
  pressure_classes[curr++] = (enum reg_class) cl2;
}
   /* If the current candidate is a subset of a so far added
@@ -858,23 +863,44 @@ setup_pressure_classes (void)
   n = curr;
 }
 #ifdef ENABLE_IRA_CHECKING
-  /* Check pressure classes correctness: here we check that hard
- registers from all register pressure classes contains all hard
- registers available for the allocation.  */
-  CLEAR_HARD_REG_SET (temp_hard_regset);
-  CLEAR_HARD_REG_SET (temp_hard_regset2);
-  for (cl = 0; cl < LIM_REG_CLASSES; cl++)
-{
-  for (i = 0; i < n; i++)
-   if ((int) pressure_classes[i] == cl)
- break;
-  IOR_HARD_REG_SET (temp_hard_regset2, reg_class_contents[cl]);
-  if (i >= n)
-   IOR_HARD_REG_SET (temp_hard_regset, reg_class_contents[cl]);
-}
-  AND_COMPL_HARD_REG_SET (temp_hard_regset, no_unit_alloc_regs);
-  AND_COMPL_HARD_REG_SET (temp_hard_regset2, no_unit_alloc_regs);
-  ira_assert (hard_reg_set_subset_p (temp_hard_regset2, temp_hard_regset));
+  {
+HARD_REG_SET ignore_hard_regs;
+
+/* Check pressure classes correctness: here we check that hard
+   registers from all register pressure classes contains all hard
+   registers available for the allocation.  */
+CLEAR_HARD_REG_SET (temp_hard_regset);
+CLEAR_HARD_REG_SET (temp_hard_regset2);
+COPY_HARD_REG_SET (ignore_hard_regs, no_unit_alloc_regs);
+for (cl = 0; cl < L

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Andi Kleen]

On Fri, May 13, 2011 at 11:43:42AM +0200, Jan Hubicka wrote:
> > On Fri, May 13, 2011 at 6:53 AM, Xinliang David Li  
> > wrote:
> > > Ok for google/main.
> > 
> > Seems to be very special and not appropriate for GCC trunk.  Instead
> > an adjusted copy providing the interface GCC needs should belong to
> > the kernel tree.
> Andi Kleen also did work in this direction. We probably should synchronize the
> efforts.

Yes, the in kernel gcov code -- which already has large parts of
the gcov interface, but unfortunately for gcc 3 needs to be updated.
This needs to be done inside the kernel tree though.

I did some work on this to update, but my efforts fell a bit short. The 
resulting kernel was actually larger because I was missing some information.

My variant didn't need the TLS changes because I just used atomic
counters.

I also ran into some problems with gcc when the information was not
missing some TUs due to the way the information is collected.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Fix PR46728 (move pow/powi folds to tree phases)

[Nathan Froyd]

On 05/13/2011 11:26 AM, Richard Guenther wrote:
> On Fri, May 13, 2011 at 5:01 PM, Nathan Froyd  
> wrote:
>> On 05/13/2011 10:52 AM, William J. Schmidt wrote:
>>> This patch addresses PR46728, which notes that pow and powi need to be
>>> lowered in tree phases to restore lost FMA opportunities and expose
>>> vectorization opportunities.
>>>
>>> +struct gimple_opt_pass pass_lower_pow =
>>> +{
>>> + {
>>> +  GIMPLE_PASS,
>>> +  "lower_pow",   /* name */
>>> +  NULL,  /* gate */
>>
>> Please make this controlled by an option; this pass doesn't need to be run 
>> all
>> the time.
>>
>> IMHO, the pass shouldn't run at anything less than -O3, but that's for other
>> people to decide.
> 
> It was run unconditionally before, so unless we preserve the code at
> expansion time we have to do it here.

We were doing it unconditionally before because we were calling it through
folding and expansion, both of which only fired if we were expanding pow
calls; now we're groveling over the whole IR to look for optimization
opportunities that, let's be honest, the vast majority of code is never going
to care about.  The whole point of the patch is "to restore lost FMA
opportunities and expose vectorization opportunities".  The first reason
*might* be good justification for running it at -O2, but the second reason
calls for -O3 or at the very least flag_tree_vectorize.

However, I don't think anybody's going to notice/care if -O1 stopped folding
pow calls; could we at least add a flag_expensive_optimizations && optimize 
gate?

-Nathan

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[H.J. Lu]

On Fri, May 13, 2011 at 6:38 AM, Kai Tietz  wrote:
> 2011/5/13 Richard Guenther :
>> On Fri, May 13, 2011 at 1:31 PM, Kai Tietz  wrote:
>>> Hello,
>>>
>>> this patch adds a check to
>>>
>>> ChangeLog
>>>
>>> 2011-05-13  Kai Tietz
>>>
>>>          * gimplify.c (gimplify_expr): Make sure operand is boolified.
>>>          * tree-cfg.c (verify_gimple_assign_unary): Check for boolean
>>> compatible type
>>>          for TRUTH_NOT_EXPR.
>>>
>>> Bootstrapped for x86_64-pc-linux-gnu (multilib). Ok for apply?
>>
>> Ok with 
>>
>
> Committed at revision 173732 with your suggested adjustments.
>

This may have caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48989

-- 
H.J.

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Andrew Pinski]

On Fri, May 13, 2011 at 4:31 AM, Kai Tietz  wrote:
>
>     case TRUTH_NOT_EXPR:
> +      if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
> +          || !useless_type_conversion_p (boolean_type_node,  lhs_type))

In Fortran (and maybe other langauges) there are booleans with
different sizes but the same precision.
Can you explain how you handle those and why this can't just be a
BOOLEAN_TYPE type?

Thanks,
Andrew Pinski

RFA: patch to fix PR48633.

[Vladimir Makarov]

The patch fixes PR48633 described on 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633.


The patch was successfully bootstrapped on x86-64.

Ok to commit?

2011-05-13  Vladimir Makarov 

PR rtl-optimization/48633
* ira-build.c (loop_with_eh_edge_p): New function.
(mark_loops_for_removal): Use it.

2011-05-13  Michael Matz 

PR rtl-optimization/48633
* g++.dg/pr48633.C: New test.
Index: testsuite/g++.dg/pr48633.C
===
--- testsuite/g++.dg/pr48633.C  (revision 0)
+++ testsuite/g++.dg/pr48633.C  (revision 0)
@@ -0,0 +1,28 @@
+/* { dg-do compile} */
+/* { dg-options "-O2 -fira-region=all -fnon-call-exceptions" } */
+extern long double getme (void);
+extern void useme (long double);
+struct Frame {
+long double tmp;
+};
+void bugme (int n, long double ld1, long double ld2, long double ld3,
+long double ld4, long double ld5)
+{
+  Frame f;
+  int i;
+  f.tmp = getme();
+  try {
+for (i = 0; i < n; i++)
+  {
+f.tmp += 1.0;
+  }
+  } catch (...) {
+f.tmp += 1.0;
+  }
+  ld1++;
+  ld2++;
+  ld3++;
+  ld4++;
+  ld5++;
+  useme (f.tmp);
+}
Index: ira-build.c
===
--- ira-build.c (revision 173623)
+++ ira-build.c (working copy)
@@ -1806,6 +1806,25 @@ low_pressure_loop_node_p (ira_loop_tree_
   return true;
 }
 
+/* Return TRUE if LOOP has a EH enter or exit edge.  */
+static bool
+loop_with_eh_edge_p (struct loop *loop)
+{
+  int i;
+  edge_iterator ei;
+  edge e;
+  VEC (edge, heap) *edges;
+
+  FOR_EACH_EDGE (e, ei, loop->header->preds)
+if (e->flags & EDGE_EH)
+  return true;
+  edges = get_loop_exit_edges (loop);
+  FOR_EACH_VEC_ELT (edge, edges, i, e)
+if (e->flags & EDGE_EH)
+  return true;
+  return false;
+}
+
 /* Sort loops for marking them for removal.  We put already marked
loops first, then less frequent loops next, and then outer loops
next.  */
@@ -1829,14 +1848,18 @@ loop_compare_func (const void *v1p, cons
   return l1->loop->num - l2->loop->num;
 }
 
-
 /* Mark loops which should be removed from regional allocation.  We
remove a loop with low register pressure inside another loop with
register pressure.  In this case a separate allocation of the loop
hardly helps (for irregular register file architecture it could
help by choosing a better hard register in the loop but we prefer
faster allocation even in this case).  We also remove cheap loops
-   if there are more than IRA_MAX_LOOPS_NUM of them.  */
+   if there are more than IRA_MAX_LOOPS_NUM of them.  Loop with EH
+   exit or enter edges are removed too because the allocation might
+   require put pseudo moves on the EH edges (we could still do this
+   for pseudos with caller saved hard registers in some cases but it
+   is impossible to say here or during top-down allocation pass what
+   hard register the pseudos get finally).  */
 static void
 mark_loops_for_removal (void)
 {
@@ -1859,8 +1882,9 @@ mark_loops_for_removal (void)
  }
sorted_loops[n++] = &ira_loop_nodes[i];
ira_loop_nodes[i].to_remove_p
- = (low_pressure_loop_node_p (ira_loop_nodes[i].parent)
-&& low_pressure_loop_node_p (&ira_loop_nodes[i]));
+ = ((low_pressure_loop_node_p (ira_loop_nodes[i].parent)
+ && low_pressure_loop_node_p (&ira_loop_nodes[i]))
+|| loop_with_eh_edge_p (ira_loop_nodes[i].loop));
   }
   qsort (sorted_loops, n, sizeof (ira_loop_tree_node_t), loop_compare_func);
   for (i = 0; n - i + 1 > IRA_MAX_LOOPS_NUM; i++)

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Kai Tietz]

2011/5/13 Andrew Pinski :
> On Fri, May 13, 2011 at 4:31 AM, Kai Tietz  wrote:
>>
>>     case TRUTH_NOT_EXPR:
>> +      if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
>> +          || !useless_type_conversion_p (boolean_type_node,  lhs_type))
>
> In Fortran (and maybe other langauges) there are booleans with
> different sizes but the same precision.
> Can you explain how you handle those and why this can't just be a
> BOOLEAN_TYPE type?

Well, the issue is to be found in gimple_boolify. It is necessary that
it is ensured that operands getting boolified on demand. Doing this by
default boolean_type_node is used.
To verify that, patch converts also for wider-mode BOOLEAN-types back
to boolean_type_node type.
Before thi no boolification of operands were done for expressions with
any boolean type. As we want to make sure that operands getting fixed,
too, but gimplifier doesn't know which resulting type it should have,
we truncate it back to 1-bit boolean.
I assume that the underlying issue is here that some places introduce
- via the backdoor - gimple trees, with abitrary boolean-type. IMHO
those places should be fixed and use for this gimplication to make
sure things getting normalized.

Regards,
Kai

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Xinliang David Li]

On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini  wrote:
> On 05/13/2011 03:03 AM, Rong Xu wrote:
>>
>>        * gcc/coverage.c        (revision 173717): set a flag if building
>> for Linux kernel.
>>        * gcc/tree-profile.c    (revision 173717): don't emit TLS
>> declarations for Linux kernel builds.
>
> I think this should be done without touching at all the profiling machinery
> in GCC.
>
> 1) add a new TLS model -ftls-model=none and make the kernel uses it. The
> model would simply force targetm.have_tls to false.
>

This is a good idea.


> 2) as Richi mentioned, gcov-io and libgcov changes then can move to the
> kernel, and GCC needs no change at all here.
>

In fact -- reuse gcc code profiling machinery for FDO is the KEY
objective in this effort --- the effort tries to minimize gcc changes
by refactoring gcc code and isolating/abstracting away part of gcc
implementation that is user space program specific without using
runtime hooks.  Aside from the kernel FDO change -- the refactoring
itself actually makes the libgcov code more readable -- the existing
implementation has many huge functions etc.

Kernel source has their implementation of coverage testing -- but it
makes lots of data structure assumptions and hard coded -- it can
easily out of sync with gcc and is considered  unmaintainable.

Rong will have more explanation on the design.

Thanks,

David


> BTW, these parts of LIPO:
>
>> +      if (!is_kernel_build)
>> +        DECL_TLS_MODEL (dc_gcov_type_ptr_var) =
>> +         decl_default_tls_model (dc_gcov_type_ptr_var);
>>
>>       dc_void_ptr_var =
>>        build_decl (UNKNOWN_LOCATION, VAR_DECL,
>> @@ -1488,8 +1493,9 @@
>>                    ptr_void);
>>       DECL_ARTIFICIAL (dc_void_ptr_var) = 1;
>>       DECL_EXTERNAL (dc_void_ptr_var) = 1;
>> -      DECL_TLS_MODEL (dc_void_ptr_var) =
>> -       decl_default_tls_model (dc_void_ptr_var);
>> +      if (!is_kernel_build)
>> +        DECL_TLS_MODEL (dc_void_ptr_var) =
>> +         decl_default_tls_model (dc_void_ptr_var);
>
> Probably are missing a !targetm.have_tls.
>
> Paolo
>

Re: [PATCH] ARM fixed-point support [6/6]: target-specific parts

[Julian Brown]

On Fri, 13 May 2011 14:54:47 + (UTC)
"Joseph S. Myers"  wrote:

> On Fri, 13 May 2011, Julian Brown wrote:
> 
> > although Joseph's comments have (hopefully) all been addressed. One
> > must now configure with "--enable-fixed-point" to enable the
> > fixed-point support.
> 
> No, that's not how this configure logic works; it enables fixed point
> by default for the given targets.  The bit that enables it by default
> for MIPS (and that you're changing to cover ARM as well) is the code
> that is called if the user *doesn't* pass --enable-fixed-point or 
> --disable-fixed-point.

Yes, you're quite right: I had forgotten to run autoconf after changing
configure.ac whilst testing. Sorry for the misinformation!

Cheers,

Julian

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Paolo Bonzini]

On 05/13/2011 06:31 PM, Xinliang David Li wrote:

>  1) add a new TLS model -ftls-model=none and make the kernel uses it. The
>  model would simply force targetm.have_tls to false.
>


This is a good idea.


>  2) as Richi mentioned, gcov-io and libgcov changes then can move to the
>  kernel, and GCC needs no change at all here.


In fact -- reuse gcc code profiling machinery for FDO is the KEY
objective in this effort


Ok, removing in_kernel_build is already fixing 99% of what is 
undesirable with this patch IMO!


Paolo

Don't let search bots look at buglist.cgi

[Ian Lance Taylor]

I noticed that buglist.cgi was taking quite a bit of CPU time.  I looked
at some of the long running instances, and they were coming from
searchbots.  I can't think of a good reason for this, so I have
committed this patch to the gcc.gnu.org robots.txt file to not let
searchbots search through lists of bugs.  I plan to make a similar
change on the sourceware.org and cygwin.com sides.  Please let me know
if this seems like a mistake.

Does anybody have any experience with
http://code.google.com/p/bugzilla-sitemap/ ?  That might be a slightly
better approach.

Ian

Index: robots.txt
===
RCS file: /cvs/gcc/wwwdocs/htdocs/robots.txt,v
retrieving revision 1.9
diff -u -r1.9 robots.txt
--- robots.txt	22 Sep 2009 19:19:30 -	1.9
+++ robots.txt	13 May 2011 17:08:33 -
@@ -5,4 +5,5 @@
 User-Agent: *
 Disallow: /viewcvs/
 Disallow: /cgi-bin/
+Disallow: /bugzilla/buglist.cgi
 Crawl-Delay: 60

[PATCH] C++0x, implement final on classes

[Ville Voutilainen]

Tested on Linux/X86-32.

2011-05-13 Ville Voutilainen  

  Implement final on class.
  * class.c (check_bases): Diagnose derivation from a final class.
  * cp-tree.h (lang_type_class): Add is_final and adjust dummy.
  * cp-tree.h (CLASSTYPE_FINAL): New.
  * parser.c (cp_parser_class_head): Parse class-virt-specifier, set 
CLASSTYPE_FINAL.
  * pt.c (instantiate_class_template_1): Copy the CLASSTYPE_FINAL.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 293dd1c..44b1d8e 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1268,6 +1268,10 @@ check_bases (tree t,
 
   gcc_assert (COMPLETE_TYPE_P (basetype));
 
+  if (CLASSTYPE_FINAL (basetype))
+error ("cannot derive from from final base %qT in derived type %qT",
+   basetype, t);
+
   /* If any base class is non-literal, so is the derived class.  */
   if (!CLASSTYPE_LITERAL_P (basetype))
 CLASSTYPE_LITERAL_P (t) = false;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1705232..901a17d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1321,6 +1321,7 @@ struct GTY(()) lang_type_class {
   unsigned has_complex_move_ctor : 1;
   unsigned has_complex_move_assign : 1;
   unsigned has_constexpr_ctor : 1;
+  unsigned is_final : 1;
 
   /* When adding a flag here, consider whether or not it ought to
  apply to a template instance if it applies to the template.  If
@@ -1329,7 +1330,7 @@ struct GTY(()) lang_type_class {
   /* There are some bits left to fill out a 32-bit word.  Keep track
  of this by updating the size of this bitfield whenever you add or
  remove a flag.  */
-  unsigned dummy : 3;
+  unsigned dummy : 2;
 
   tree primary_base;
   VEC(tree_pair_s,gc) *vcall_indices;
@@ -1437,6 +1438,11 @@ struct GTY((variable_size)) lang_type {
 #define CLASSTYPE_LAZY_DESTRUCTOR(NODE) \
   (LANG_TYPE_CLASS_CHECK (NODE)->lazy_destructor)
 
+/* Nonzero means that NODE (a class type) is final */
+#define CLASSTYPE_FINAL(NODE) \
+  (LANG_TYPE_CLASS_CHECK (NODE)->is_final)
+
+
 /* Nonzero means that this _CLASSTYPE node overloads operator=(X&).  */
 #define TYPE_HAS_COPY_ASSIGN(NODE) (LANG_TYPE_CLASS_CHECK 
(NODE)->has_copy_assign)
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index fa6cd83..5e9b8a8 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17117,6 +17117,7 @@ cp_parser_class_head (cp_parser* parser,
   tree id = NULL_TREE;
   tree type = NULL_TREE;
   tree attributes;
+  cp_virt_specifiers virt_specifiers = VIRT_SPEC_UNSPECIFIED;
   bool template_id_p = false;
   bool qualified_p = false;
   bool invalid_nested_name_p = false;
@@ -17260,8 +17261,11 @@ cp_parser_class_head (cp_parser* parser,
   pop_deferring_access_checks ();
 
   if (id)
-cp_parser_check_for_invalid_template_id (parser, id,
-type_start_token->location);
+{
+  virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
+  cp_parser_check_for_invalid_template_id (parser, id,
+   type_start_token->location);
+}
 
   /* If it's not a `:' or a `{' then we can't really be looking at a
  class-head, since a class-head only appears as part of a
@@ -17493,6 +17497,8 @@ cp_parser_class_head (cp_parser* parser,
   if (type)
 DECL_SOURCE_LOCATION (TYPE_NAME (type)) = type_start_token->location;
   *attributes_p = attributes;
+  if (virt_specifiers & VIRT_SPEC_FINAL)
+CLASSTYPE_FINAL (type) = 1;
  out:
   parser->colon_corrects_to_scope_p = saved_colon_corrects_to_scope_p;
   return type;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5e24977..5e059e0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8209,6 +8209,7 @@ instantiate_class_template_1 (tree type)
   CLASSTYPE_VISIBILITY_SPECIFIED (type) = 1;
   CLASSTYPE_VISIBILITY (type) = CLASSTYPE_VISIBILITY (pattern);
 }
+  CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
 
   pbinfo = TYPE_BINFO (pattern);
 
diff --git a/gcc/testsuite/g++.dg/inherit/base4.C 
b/gcc/testsuite/g++.dg/inherit/base4.C
new file mode 100644
index 000..5736193
--- /dev/null
+++ b/gcc/testsuite/g++.dg/inherit/base4.C
@@ -0,0 +1,23 @@
+// { dg-do compile }
+// { dg-options "--std=c++0x" }
+struct B1 {};
+
+struct B2 final {};
+
+struct D1 : B1 {};
+
+struct D2 : B2 {}; // { dg-error "cannot derive from from final base" }
+
+template struct D3 : T {};
+
+template struct D4 : T {}; // { dg-error "cannot derive from from 
final base" }
+
+struct B3 final final {}; // { dg-error "duplicate virt-specifier" }
+
+int main()
+{
+  D3 d;
+  D4 d2;
+  struct B2 final{};
+  struct B1 final2{};
+}

Re: [PATCH] C++0x, implement final on classes

[Jason Merrill]

On 05/13/2011 01:24 PM, Ville Voutilainen wrote:

+error ("cannot derive from from final base %qT in derived type %qT",


Let's use % here.


if (id)
-cp_parser_check_for_invalid_template_id (parser, id,
-type_start_token->location);
+{
+  virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
+  cp_parser_check_for_invalid_template_id (parser, id,
+   type_start_token->location);
+}


Why did you put this before the invalid template-id check, rather than 
after?


Also, shouldn't we reject "override" on classes?

The test should include a class template marked final.

Jason

Re: [PATCH] C++0x, implement final on classes

[Ville Voutilainen]

On 13 May 2011 20:46, Jason Merrill  wrote:
> Why did you put this before the invalid template-id check, rather than
> after?

For no particular reason. Is it significant?

> Also, shouldn't we reject "override" on classes?

You can have stuff like
struct blah override{};

where struct blah is an elaborate-type-specifier, and override is a
variable name.
How do I tell the difference, or more precisely, how do I know when a
class is being defined for
the first time?

> The test should include a class template marked final.

Ok, I'll fix these issues, any guidance for the override question
above is highly appreciated.

Re: [PATCH] C++0x, implement final on classes

[Jason Merrill]

On 05/13/2011 01:53 PM, Ville Voutilainen wrote:

On 13 May 2011 20:46, Jason Merrill  wrote:

Why did you put this before the invalid template-id check, rather than
after?


For no particular reason. Is it significant?


Yes, the order affects the handling of

struct Undeclared final { };


Also, shouldn't we reject "override" on classes?


You can have stuff like
struct blah override{};

where struct blah is an elaborate-type-specifier, and override is a
variable name.
How do I tell the difference, or more precisely, how do I know when a
class is being defined for the first time?


Add the error after the call to cp_parser_commit_to_tentative_parse, at 
which point we've decided that we're dealing with a class definition.


Jason

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Kai Tietz]

2011/5/13 Kai Tietz :
> 2011/5/13 Andrew Pinski :
>> On Fri, May 13, 2011 at 4:31 AM, Kai Tietz  wrote:
>>>
>>>     case TRUTH_NOT_EXPR:
>>> +      if (!useless_type_conversion_p (boolean_type_node,  rhs1_type)
>>> +          || !useless_type_conversion_p (boolean_type_node,  lhs_type))
>>
>> In Fortran (and maybe other langauges) there are booleans with
>> different sizes but the same precision.
>> Can you explain how you handle those and why this can't just be a
>> BOOLEAN_TYPE type?
>
> Well, the issue is to be found in gimple_boolify. It is necessary that
> it is ensured that operands getting boolified on demand. Doing this by
> default boolean_type_node is used.
> To verify that, patch converts also for wider-mode BOOLEAN-types back
> to boolean_type_node type.
> Before thi no boolification of operands were done for expressions with
> any boolean type. As we want to make sure that operands getting fixed,
> too, but gimplifier doesn't know which resulting type it should have,
> we truncate it back to 1-bit boolean.
> I assume that the underlying issue is here that some places introduce
> - via the backdoor - gimple trees, with abitrary boolean-type. IMHO
> those places should be fixed and use for this gimplication to make
> sure things getting normalized.

I investigate this a bit more in detail and indeed it is the fortran
FE which do here enter in trans-*.c files their own gimple code. And
this code doesn't run over the gimplify_expr routines and so it gets
in conflict with tree-cfg.c checks.
There are two ways to go. A) Adjust fortran's trans-* stuff so that it
uses for conditionals and logical-expressions boolean_type consequent
(as in some place this type is used, but sometimes artifical
boolean_types direct). Or B) We relax tree-cfg checks for logical ops
to allow also BOOLEAN types with wider size then 1-bit.

Regards,
Kai

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Andrew Pinski]

On Fri, May 13, 2011 at 11:24 AM, Kai Tietz  wrote:
> boolean_types direct). Or B) We relax tree-cfg checks for logical ops
> to allow also BOOLEAN types with wider size then 1-bit.

The Boolean types which fortran produces are 1bit wide in precision
but not always the same width as the C  _Bool type.

That is TYPE_PRECISION is 1 for those types but TYPE_SIZE is not the same.

Thanks,
Andrew Pinski

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Rong Xu]

Thanks for the comments. This particular patch is not intended for
trunk. But we do want to hear your feedback on our designs.

On Fri, May 13, 2011 at 9:31 AM, Xinliang David Li  wrote:
> On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini  wrote:
>> On 05/13/2011 03:03 AM, Rong Xu wrote:
>>>
>>>        * gcc/coverage.c        (revision 173717): set a flag if building
>>> for Linux kernel.
>>>        * gcc/tree-profile.c    (revision 173717): don't emit TLS
>>> declarations for Linux kernel builds.
>>
>> I think this should be done without touching at all the profiling machinery
>> in GCC.
>>
>> 1) add a new TLS model -ftls-model=none and make the kernel uses it. The
>> model would simply force targetm.have_tls to false.
>>
>
> This is a good idea.
>

Agreed. We can use the option together with -fprofile-generate.

>
>> 2) as Richi mentioned, gcov-io and libgcov changes then can move to the
>> kernel, and GCC needs no change at all here.
>>
>
> In fact -- reuse gcc code profiling machinery for FDO is the KEY
> objective in this effort --- the effort tries to minimize gcc changes
> by refactoring gcc code and isolating/abstracting away part of gcc
> implementation that is user space program specific without using
> runtime hooks.  Aside from the kernel FDO change -- the refactoring
> itself actually makes the libgcov code more readable -- the existing
> implementation has many huge functions etc.
>
> Kernel source has their implementation of coverage testing -- but it
> makes lots of data structure assumptions and hard coded -- it can
> easily out of sync with gcc and is considered  unmaintainable.
>
> Rong will have more explanation on the design.
>

David has said most I want to say. I just add one more thing: kernel
can be compiled with many versions of gcc where libgcov is not
guaranteed to be compatible. It's will be messy if we put the all
versions of libgcov code into kernel. It's much cleaner to reuse the
libgcov code in gcc. For maintenance, it's better to have a central
place for one functionality.

The functionality in libgcov can be rough divided into the following part:
(1) gcov_init support: kernel need to have it's own version.
(2) runtime profile support: this part is mostly neutral to user-space
mode or kernel mode. Only some LIPO support needs to use a few libc
functions.
(3) dumping the profile file (traverse gcov_list, compute summary,
merging profile, wrtie gcda file etc). I would say most of the
functionalities are neutral. Only the file I/O  part is specific to
user-mode. Kernel's merging function is not necessary as it can be
done offline. We need to refactor gcov_exit() so it can dump one
individual gcov_info.

So I think it's reasonable to factor the libgcov code to provide
kernel support.  There are many place in this patch can be improved in
this regard, but here are the key points of our design that we want to
keep:
(1) The functionality of dumping gcov_info (independent of use-space
mode or kernel mode) should be in gcc.
(2) libgcov source in gcc will be exported to kernel.

We can re-factor current implementation to separate kernel code. I
have another patch that puts all the kernel code into separated files
(and they can easily be moved to kernel.)


> Thanks,
>
> David
>
>
>> BTW, these parts of LIPO:
>>
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_gcov_type_ptr_var) =
>>> +         decl_default_tls_model (dc_gcov_type_ptr_var);
>>>
>>>       dc_void_ptr_var =
>>>        build_decl (UNKNOWN_LOCATION, VAR_DECL,
>>> @@ -1488,8 +1493,9 @@
>>>                    ptr_void);
>>>       DECL_ARTIFICIAL (dc_void_ptr_var) = 1;
>>>       DECL_EXTERNAL (dc_void_ptr_var) = 1;
>>> -      DECL_TLS_MODEL (dc_void_ptr_var) =
>>> -       decl_default_tls_model (dc_void_ptr_var);
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_void_ptr_var) =
>>> +         decl_default_tls_model (dc_void_ptr_var);
>>
>> Probably are missing a !targetm.have_tls.
>>
>> Paolo
>>
>

Re: [google] support for building Linux kernel with FDO (issue4523061)

[Rong Xu]

Thanks for the comments. This particular patch is not intended for
trunk. But we do want to hear your feedback on our designs.

On Fri, May 13, 2011 at 9:31 AM, Xinliang David Li  wrote:
> On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini  wrote:
>> On 05/13/2011 03:03 AM, Rong Xu wrote:
>>>
>>>        * gcc/coverage.c        (revision 173717): set a flag if building
>>> for Linux kernel.
>>>        * gcc/tree-profile.c    (revision 173717): don't emit TLS
>>> declarations for Linux kernel builds.
>>
>> I think this should be done without touching at all the profiling machinery
>> in GCC.
>>
>> 1) add a new TLS model -ftls-model=none and make the kernel uses it. The
>> model would simply force targetm.have_tls to false.
>>
>
> This is a good idea.
>

Agreed. We can use the option together with -fprofile-generate.

>
>> 2) as Richi mentioned, gcov-io and libgcov changes then can move to the
>> kernel, and GCC needs no change at all here.
>>
>
> In fact -- reuse gcc code profiling machinery for FDO is the KEY
> objective in this effort --- the effort tries to minimize gcc changes
> by refactoring gcc code and isolating/abstracting away part of gcc
> implementation that is user space program specific without using
> runtime hooks.  Aside from the kernel FDO change -- the refactoring
> itself actually makes the libgcov code more readable -- the existing
> implementation has many huge functions etc.
>
> Kernel source has their implementation of coverage testing -- but it
> makes lots of data structure assumptions and hard coded -- it can
> easily out of sync with gcc and is considered  unmaintainable.
>
> Rong will have more explanation on the design.
>

David has said most I want to say. I just add one more thing: kernel
can be compiled with many versions of gcc where libgcov is not
guaranteed to be compatible. It's will be messy if we put the all
versions of libgcov code into kernel. It's much cleaner to reuse the
libgcov code in gcc. For maintenance, it's better to have a central
place for one functionality.

The functionality in libgcov can be rough divided into the following part:
(1) gcov_init support: kernel need to have it's own version.
(2) runtime profile support: this part is mostly neutral to user-space
mode or kernel mode. Only some LIPO support needs to use a few libc
functions.
(3) dumping the profile file (traverse gcov_list, compute summary,
merging profile, wrtie gcda file etc). I would say most of the
functionalities are neutral. Only the file I/O  part is specific to
user-mode. Kernel's merging function is not necessary as it can be
done offline. We need to refactor gcov_exit() so it can dump one
individual gcov_info.

So I think it's reasonable to factor the libgcov code to provide
kernel support.  There are many place in this patch can be improved in
this regard, but here are the key points of our design that we want to
keep:
(1) The functionality of dumping gcov_info (independent of use-space
mode or kernel mode) should be in gcc.
(2) libgcov source in gcc will be exported to kernel.

We can re-factor current implementation to separate kernel code. I
have another patch that puts all the kernel code into separated files
(and they can easily be moved to kernel.)


> Thanks,
>
> David
>
>
>> BTW, these parts of LIPO:
>>
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_gcov_type_ptr_var) =
>>> +         decl_default_tls_model (dc_gcov_type_ptr_var);
>>>
>>>       dc_void_ptr_var =
>>>        build_decl (UNKNOWN_LOCATION, VAR_DECL,
>>> @@ -1488,8 +1493,9 @@
>>>                    ptr_void);
>>>       DECL_ARTIFICIAL (dc_void_ptr_var) = 1;
>>>       DECL_EXTERNAL (dc_void_ptr_var) = 1;
>>> -      DECL_TLS_MODEL (dc_void_ptr_var) =
>>> -       decl_default_tls_model (dc_void_ptr_var);
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_void_ptr_var) =
>>> +         decl_default_tls_model (dc_void_ptr_var);
>>
>> Probably are missing a !targetm.have_tls.
>>
>> Paolo
>>
>

Re: [C++0x] contiguous bitfields race implementation

[Aldy Hernandez]

On 05/09/11 14:23, Jason Merrill wrote:

 From a quick look it seems that this patch considers bitfields
following the one we're deliberately touching, but not previous
bitfields in the same memory location; we need to include those as well.
With your struct foo, the bits touched are the same regardless of
whether we name .a or .b.


Thanks all for looking into this.

Attached is a new patch that takes into account the previous bitfields 
as well.


If I understand Jakub correctly, this patch also fixes the relative bit 
position problem he pointed out, by virtue of no longer using a relative 
bit position but the difference between the start of the memory region 
and the end.


I have hand tested various bitfield combinations (at the beginning, at 
the end, in the middle, with and without zero-lengthened bitfields, etc 
etc).  There is also the generic x86 test in the previous incantation.


Bootstrapped without any issues.  Running the entire testsuite with 
--param=allow-store-data-races=0 is still in progress.


How does this one look?

p.s. I would like to address BIT_FIELD_REF in a followup patch to keep 
things simple.
* params.h (ALLOW_STORE_DATA_RACES): New.
* params.def (PARAM_ALLOW_STORE_DATA_RACES): New.
* Makefile.in (expr.o): Depend on PARAMS_H.
* machmode.h (get_best_mode): Add argument.
* fold-const.c (optimize_bit_field_compare): Add argument to
get_best_mode.
(fold_truthop): Same.
* ifcvt.c (noce_emit_move_insn): Add argument to store_bit_field.
* expr.c (emit_group_store): Same.
(copy_blkmode_from_reg): Same.
(write_complex_part): Same.
(optimize_bitfield_assignment_op): Add argument.
Add argument to get_best_mode.
(max_field_size): New.
(expand_assignment): Calculate maxbits and pass it down
accordingly.
(store_field): New argument.
(expand_expr_real_2): New argument to store_field.
Include params.h.
* expr.h (store_bit_field): New argument.
* stor-layout.c (get_best_mode): Restrict mode expansion by taking
into account maxbits.
* calls.c (store_unaligned_arguments_into_pseudos): New argument
to store_bit_field.
* expmed.c (store_bit_field_1): New argument.  Use it.
(store_bit_field): Same.
(store_fixed_bit_field): Same.
(store_split_bit_field): Same.
(extract_bit_field_1): Pass new argument to get_best_mode.
(extract_bit_field): Same.
* stmt.c (store_bit_field): Pass new argument to store_bit_field.
* tree.h (DECL_THREAD_VISIBLE_P): New.
* doc/invoke.texi: Document parameter allow-store-data-races.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 173263)
+++ doc/invoke.texi (working copy)
@@ -8886,6 +8886,11 @@ The maximum number of conditional stores
 if either vectorization (@option{-ftree-vectorize}) or if-conversion
 (@option{-ftree-loop-if-convert}) is disabled.  The default is 2.
 
+@item allow-store-data-races
+Allow optimizers to introduce new data races on stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the @option{-fmemory-model=} option.
+
 @end table
 @end table
 
Index: machmode.h
===
--- machmode.h  (revision 173263)
+++ machmode.h  (working copy)
@@ -248,7 +248,9 @@ extern enum machine_mode mode_for_vector
 
 /* Find the best mode to use to access a bit field.  */
 
-extern enum machine_mode get_best_mode (int, int, unsigned int,
+extern enum machine_mode get_best_mode (int, int,
+   unsigned HOST_WIDE_INT,
+   unsigned int,
enum machine_mode, int);
 
 /* Determine alignment, 1<=result<=BIGGEST_ALIGNMENT.  */
Index: tree.h
===
--- tree.h  (revision 173263)
+++ tree.h  (working copy)
@@ -3156,6 +3156,10 @@ struct GTY(()) tree_parm_decl {
 #define DECL_THREAD_LOCAL_P(NODE) \
   (VAR_DECL_CHECK (NODE)->decl_with_vis.tls_model >= TLS_MODEL_REAL)
 
+/* Return true if a VAR_DECL is visible from another thread.  */
+#define DECL_THREAD_VISIBLE_P(NODE) \
+  (TREE_STATIC (NODE) && !DECL_THREAD_LOCAL_P (NODE))
+
 /* In a non-local VAR_DECL with static storage duration, true if the
variable has an initialization priority.  If false, the variable
will be initialized at the DEFAULT_INIT_PRIORITY.  */
Index: fold-const.c
===
--- fold-const.c(revision 173263)
+++ fold-const.c(working copy)
@@ -3409,7 +3409,7 @@ optimize_bit_field_compare (location_t l
   && flag_strict_volatile_bitfields > 0)
 nmode = lmode;
   else
-nmode = get_best_mode (lbitsize,

Minor tweaks

[Eric Botcazou]

The attached patch contains 3 minor tweaks:

  1. Jeff moved a dump message in cfg_layout_redirect_edge_and_branch up to 
before the call to redirect_edge_succ_nodup.  So the "redirected" is not fully 
true anymore and can be confusing since the call to redirect_edge_succ_nodup 
can dump messages too.  Changed to "redirecting" like a few lines above.

  2. regcprop.c tests MAY_HAVE_DEBUG_STMTS.  Now this is a RTL pass so the most 
correct incantation is MAY_HAVE_DEBUG_INSNS.

  3. remove_forwarder_block attempts to move debug statements.  There is no 
need to do it when !MAY_HAVE_DEBUG_STMTS.

Tested on i586-suse-linux, applied on the mainline as obvious.


2011-05-13  Eric Botcazou  

* cfgrtl.c (cfg_layout_redirect_edge_and_branch): Adjust dump message.
* regcprop.c (copyprop_hardreg_forward): Test MAY_HAVE_DEBUG_INSNS in
lieu of MAY_HAVE_DEBUG_STMTS.
* tree-cfgcleanup.c (remove_forwarder_block): Do not attempt to move
debug statements if !MAY_HAVE_DEBUG_STMTS.


-- 
Eric Botcazou
Index: cfgrtl.c
===
--- cfgrtl.c	(revision 173693)
+++ cfgrtl.c	(working copy)
@@ -2608,7 +2608,7 @@ cfg_layout_redirect_edge_and_branch (edg
 	delete_insn (BB_END (src));
 	}
   if (dump_file)
-	fprintf (dump_file, "Fallthru edge %i->%i redirected to %i\n",
+	fprintf (dump_file, "Redirecting fallthru edge %i->%i to %i\n",
 		 e->src->index, e->dest->index, dest->index);
   ret = redirect_edge_succ_nodup (e, dest);
 }
Index: regcprop.c
===
--- regcprop.c	(revision 173693)
+++ regcprop.c	(working copy)
@@ -990,7 +990,7 @@ copyprop_hardreg_forward (void)
   visited = sbitmap_alloc (last_basic_block);
   sbitmap_zero (visited);
 
-  if (MAY_HAVE_DEBUG_STMTS)
+  if (MAY_HAVE_DEBUG_INSNS)
 debug_insn_changes_pool
   = create_alloc_pool ("debug insn changes pool",
 			   sizeof (struct queued_debug_insn_change), 256);
@@ -1029,7 +1029,7 @@ copyprop_hardreg_forward (void)
   copyprop_hardreg_forward_1 (bb, all_vd + bb->index);
 }
 
-  if (MAY_HAVE_DEBUG_STMTS)
+  if (MAY_HAVE_DEBUG_INSNS)
 {
   FOR_EACH_BB (bb)
 	if (TEST_BIT (visited, bb->index)
Index: tree-cfgcleanup.c
===
--- tree-cfgcleanup.c	(revision 173693)
+++ tree-cfgcleanup.c	(working copy)
@@ -420,7 +420,7 @@ remove_forwarder_block (basic_block bb)
 	}
 }
 
-  can_move_debug_stmts = single_pred_p (dest);
+  can_move_debug_stmts = MAY_HAVE_DEBUG_STMTS && single_pred_p (dest);
 
   /* Redirect the edges.  */
   for (ei = ei_start (bb->preds); (e = ei_safe_edge (ei)); )
@@ -476,8 +476,7 @@ remove_forwarder_block (basic_block bb)
 	gsi_next (&gsi);
 }
 
-  /* Move debug statements if the destination has just a single
- predecessor.  */
+  /* Move debug statements if the destination has a single predecessor.  */
   if (can_move_debug_stmts)
 {
   gsi_to = gsi_after_labels (dest);

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

[Thomas Koenig]

Am 03.05.2011 22:12, schrieb Thomas Koenig:

Am 01.05.2011 11:49, schrieb Thomas Koenig:

Hello world,

after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.


Ping?


Ping**2?

There's been a bit of offline discussion with Tobias regarding -Os and
timings. At least for a simple test case, the patch made the resulting
program shorter. As for timing, I would confidently expect that, even
with -fstack-arrays, any useful function would take longer than a
malloc()/free() pair.

Thomas

Re: C6X port 12/11: htdocs

[Gerald Pfeifer]

On Fri, 13 May 2011, Bernd Schmidt wrote:
>> I forgot about it in my previous message, but there should be a release 
>> note in gcc-4.7/changes.html as well.
> New version below.

This looks good, thank you!

If you later want to refer to that part of the release notes directly,
you could write   C6X   in the release notes, but that
is really up to you.

Gerald

Re: [Patch, Fortran] Reject non-default-kind characters as flags to I/O statements

[H.J. Lu]

On Thu, May 12, 2011 at 2:56 PM, Tobias Burnus  wrote:
> The patch is a correctness issue as the Fortran standard has those as
> constraints - and the results of passing kind=4 strings is also odd ...
>
> I used also the chance to resolve INQUIRE's decimal ...
>
> Build and partially regtested on x86-64-linux.
> OK for the trunk?
>

It caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48991


--
H.J.

Re: [PATCH] Fix PR46728 (move pow/powi folds to tree phases)

[William J. Schmidt]

On Fri, 2011-05-13 at 10:52 -0500, William J. Schmidt wrote:
> On Fri, 2011-05-13 at 17:26 +0200, Richard Guenther wrote:

 -- snip --

> > 
> > The position of the pass is odd - why did you place it there?  I would
> > have placed it alongside pass_cse_sincos and pass_optimize_bswap.
> 
> That was where I wanted it initially also, but this seems necessary for
> the pass to run unconditionally.  If I recall correctly,
> gate_all_optimizations() was kicking in at -O0, so I had to move it
> earlier.

As an alternative, I could reinstate the "expand" transformations to
kick in when the lower_pow pass is disabled.  I can then move the
lower_pow pass to the neighborhood of pass_cse_sincos and
pass_optimize_bswap, and limit it to -O1 and above.  Optionally, I could
gate it on flag_expensive_optimizations as Nathan suggested, though that
is perhaps not appropriate for a simple linear scan.

I did a quick regtest of this and it held up without regressions.  Let
me know if you'd prefer me to implement it that way.  I'd probably vote
for it myself, as I wasn't happy with extra compile time at -O0 either.
Just a matter of whether we want to tolerate duplicated logic to avoid
that.

C++ PATCH for c++/48969 (infinite template recursion with enum scope)

[Jason Merrill]

In C++0x there are a couple of ways for a function signature to depend 
on itself, leading to infinite recursion in substitution during template 
argument deduction.  This patch adds checking for that.


My initial implementation used a VEC to keep track of current deductions 
in process, but I switched it to use a hash table instead; the overhead 
for using a hash table rather than a VEC on the most common case (very 
low deduction nesting) is small, but on highly recursive template 
metaprogramming the difference in complexity can make a difference.


Unfortunately, the difference one way or the other is dwarfed by the 
overhead from doing this checking at all (about 2% of compile time 
compiling stdc++.h), but I don't see how to avoid it.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit ec136d9e1be788f0045a9adbd58cba6014fe0405
Author: Jason Merrill 
Date:   Fri May 13 10:43:05 2011 -0400

	PR c++/48969
	* pt.c (deduction_tsubst_fntype): New.
	(fn_type_unification): Use it.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 50ed180..f155c1a 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -13525,6 +13525,53 @@ check_instantiated_args (tree tmpl, tree args, tsubst_flags_t complain)
   return result;
 }
 
+static GTY((param_is (spec_entry))) htab_t current_deduction_substs;
+
+/* In C++0x, it's possible to have a function template whose type depends
+   on itself recursively.  This is most obvious with decltype, but can also
+   occur with enumeration scope (c++/48969).  So we need to catch infinite
+   recursion and reject the substitution at deduction time.  */
+
+static tree
+deduction_tsubst_fntype (tree fn, tree targs)
+{
+  spec_entry **slot;
+  spec_entry elt;
+  tree r;
+  hashval_t hash;
+
+  tree fntype = TREE_TYPE (fn);
+
+  /* We don't need to worry about this in C++98.  */
+  if (cxx_dialect < cxx0x)
+return tsubst (fntype, targs, tf_none, NULL_TREE);
+
+  elt.tmpl = fn;
+  elt.args = targs;
+  elt.spec = NULL_TREE;
+  hash = hash_specialization (&elt);
+
+  slot = (spec_entry **)
+htab_find_slot_with_hash (current_deduction_substs, &elt, hash, INSERT);
+  if (*slot)
+/* We already have an entry for this.  */
+(*slot)->spec = r = error_mark_node;
+  else
+{
+  /* Create a new entry.  */
+  spec_entry *p = *slot = ggc_alloc_spec_entry ();
+  *p = elt;
+
+  r = tsubst (fntype, targs, tf_none, NULL_TREE);
+  if (p->spec == error_mark_node)
+	r = error_mark_node;
+
+  htab_remove_elt_with_hash (current_deduction_substs, p, hash);
+}
+
+  return r;
+}
+
 /* Instantiate the indicated variable or function template TMPL with
the template arguments in TARG_PTR.  */
 
@@ -13788,7 +13835,7 @@ fn_type_unification (tree fn,
 incomplete = NUM_TMPL_ARGS (explicit_targs) != NUM_TMPL_ARGS (targs);
 
   processing_template_decl += incomplete;
-  fntype = tsubst (fntype, converted_args, tf_none, NULL_TREE);
+  fntype = deduction_tsubst_fntype (fn, converted_args);
   processing_template_decl -= incomplete;
 
   if (fntype == error_mark_node)
@@ -13859,7 +13906,7 @@ fn_type_unification (tree fn,
substitution results in an invalid type, as described above,
type deduction fails.  */
 {
-  tree substed = tsubst (TREE_TYPE (fn), targs, tf_none, NULL_TREE);
+  tree substed = deduction_tsubst_fntype (fn, targs);
   if (substed == error_mark_node)
 	return 1;
 
@@ -19283,6 +19330,10 @@ init_template_processing (void)
 	  hash_specialization,
 	  eq_specializations,
 	  ggc_free);
+  if (cxx_dialect >= cxx0x)
+current_deduction_substs = htab_create_ggc (37, hash_specialization,
+		eq_specializations,
+		ggc_free);
 }
 
 /* Print stats about the template hash tables for -fstats.  */
@@ -19298,6 +19349,10 @@ print_template_statistics (void)
 	   "%f collisions\n", (long) htab_size (type_specializations),
 	   (long) htab_elements (type_specializations),
 	   htab_collisions (type_specializations));
+  fprintf (stderr, "current_deduction_substs: size %ld, %ld elements, "
+	   "%f collisions\n", (long) htab_size (current_deduction_substs),
+	   (long) htab_elements (current_deduction_substs),
+	   htab_collisions (current_deduction_substs));
 }
 
 #include "gt-cp-pt.h"
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype26.C b/gcc/testsuite/g++.dg/cpp0x/decltype26.C
new file mode 100644
index 000..9eb9411
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype26.C
@@ -0,0 +1,16 @@
+// { dg-options -std=c++0x }
+
+struct A { };
+
+template 
+decltype(f(T())) f(T t)
+{
+  return f(t);
+}
+
+int main()
+{
+  f(A());			// { dg-error "no match" }
+}
+
+// { dg-prune-output "note" }
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum11.C b/gcc/testsuite/g++.dg/cpp0x/enum11.C
new file mode 100644
index 000..98b6b00
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum11.C
@@ -0,0 +1,10 @@
+// PR c++/48969
+// { dg-options -std=c++0x }
+
+template struct Pair { };
+struct Foo { enum { Mask = 1

Re: [patch] Split Parse Timevar (rev 2) (issue4433076)

[Jason Merrill]

I'm applying this patch to fix a crash that I get when running cc1plus 
directly without -quiet; all the other TV_OVERLOAD bits use 
timevar_cond_*, so it seems that these should too.


Tested x86_64-pc-linux-gnu, applying to trunk.

commit 8de1530fc6ca07e3ca37ff7689c65931025d9f0d
Author: Jason Merrill 
Date:   Fri May 13 14:56:33 2011 -0400

	* call.c (build_op_call): Use timevar_cond_start/stop.
	(build_user_type_conversion): Likewise.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 095d1b0..09ad4ae 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -3521,7 +3521,7 @@ build_user_type_conversion (tree totype, tree expr, int flags)
   struct z_candidate *cand;
   tree ret;
 
-  timevar_start (TV_OVERLOAD);
+  bool subtime = timevar_cond_start (TV_OVERLOAD);
   cand = build_user_type_conversion_1 (totype, expr, flags);
 
   if (cand)
@@ -3537,7 +3537,7 @@ build_user_type_conversion (tree totype, tree expr, int flags)
   else
 ret = NULL_TREE;
 
-  timevar_stop (TV_OVERLOAD);
+  timevar_cond_stop (TV_OVERLOAD, subtime);
   return ret;
 }
 
@@ -4029,9 +4029,9 @@ tree
 build_op_call (tree obj, VEC(tree,gc) **args, tsubst_flags_t complain)
 {
   tree ret;
-  timevar_start (TV_OVERLOAD);
+  bool subtime = timevar_cond_start (TV_OVERLOAD);
   ret = build_op_call_1 (obj, args, complain);
-  timevar_stop (TV_OVERLOAD);
+  timevar_cond_stop (TV_OVERLOAD, subtime);
   return ret;
 }
 

Re: [patch] Split Parse Timevar (rev 2) (issue4433076)

[Lawrence Crowl]

On 5/13/11, Jason Merrill  wrote:
> I'm applying this patch to fix a crash that I get when running cc1plus
> directly without -quiet; all the other TV_OVERLOAD bits use
> timevar_cond_*, so it seems that these should too.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.

Looks good to me.

-- 
Lawrence Crowl

Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument

[Eric Botcazou]

> In Fortran (and maybe other langauges) there are booleans with
> different sizes but the same precision.

Ada doesn't have a C-like boolean type either.  The patches have introduced:

FAIL: gnat.dg/lto1.adb (test for excess errors)


/home/eric/svn/gcc/gcc/testsuite/gnat.dg/lto1_pkg.adb:23:1: error: type 
mismatch in binary truth expression
boolean
boolean
boolean
D.2419_18 = D.2417_16 || D.2418_17;
+===GNAT BUG DETECTED==+
| 4.7.0 20110513 (experimental) [trunk revision 173737] (i586-suse-linux-gnu) 
GCC error:|
| verify_gimple failed  

-- 
Eric Botcazou

Go patch committed: Fix bug with multiple results

[Ian Lance Taylor]

This patch to the Go frontend fixes a bug in which a function returns
multiple results and at least one of those results is a named struct.
For multiple results the Go frontend builds a struct.  In some cases the
function type may be built before the named struct type is completed, in
which case the result struct will be laid out incorrectly.  This patch
fixes the problem by postponing building the result struct until all
named types are converted.  I added an assertion to detect this kind of
thing in the future.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2011-05-13  Ian Lance Taylor  

* go-gcc.cc (Gcc_backend::function_type): When building a struct
for multiple results, check that all fields types have a size.
(Gcc_backend::placeholder_pointer_type): Permit name to be empty.


Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc	(revision 173712)
+++ gcc/go/go-gcc.cc	(working copy)
@@ -465,6 +465,7 @@ Gcc_backend::function_type(const Btyped_
 	  tree field_type_tree = p->btype->get_tree();
 	  if (field_type_tree == error_mark_node)
 	return this->error_type();
+	  gcc_assert(TYPE_SIZE(field_type_tree) != NULL_TREE);
 	  tree field = build_decl(location, FIELD_DECL, name_tree,
   field_type_tree);
 	  DECL_CONTEXT(field) = result;
@@ -573,10 +574,13 @@ Gcc_backend::placeholder_pointer_type(co
   source_location location, bool)
 {
   tree ret = build_variant_type_copy(ptr_type_node);
-  tree decl = build_decl(location, TYPE_DECL,
-			 get_identifier_from_string(name),
-			 ret);
-  TYPE_NAME(ret) = decl;
+  if (!name.empty())
+{
+  tree decl = build_decl(location, TYPE_DECL,
+			 get_identifier_from_string(name),
+			 ret);
+  TYPE_NAME(ret) = decl;
+}
   return this->make_type(ret);
 }
 
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc	(revision 173712)
+++ gcc/go/gofrontend/gogo.cc	(working copy)
@@ -2599,6 +2599,8 @@ Gogo::convert_named_types()
 
   Runtime::convert_types(this);
 
+  Function_type::convert_types(this);
+
   this->named_types_are_converted_ = true;
 }
 
Index: gcc/go/gofrontend/types.h
===
--- gcc/go/gofrontend/types.h	(revision 173685)
+++ gcc/go/gofrontend/types.h	(working copy)
@@ -1628,6 +1628,10 @@ class Function_type : public Type
   Function_type*
   copy_with_receiver(Type*) const;
 
+  // Finishing converting function types.
+  static void
+  convert_types(Gogo*);
+
   static Type*
   make_function_type_descriptor_type();
 
@@ -1666,6 +1670,16 @@ class Function_type : public Type
   type_descriptor_params(Type*, const Typed_identifier*,
 			 const Typed_identifier_list*);
 
+  Btype*
+  get_function_backend(Gogo*);
+
+  // A list of function types with multiple results and their
+  // placeholder backend representations, used to postpone building
+  // the structs we use for multiple results until all types are
+  // converted.
+  typedef std::vector > Placeholders;
+  static Placeholders placeholders;
+
   // The receiver name and type.  This will be NULL for a normal
   // function, non-NULL for a method.
   Typed_identifier* receiver_;
Index: gcc/go/gofrontend/backend.h
===
--- gcc/go/gofrontend/backend.h	(revision 173712)
+++ gcc/go/gofrontend/backend.h	(working copy)
@@ -113,7 +113,9 @@ class Backend
   // Create a placeholder pointer type.  This is used for a named
   // pointer type, since in Go a pointer type may refer to itself.
   // NAME is the name of the type, and the location is where the named
-  // type is defined.  FOR_FUNCTION is true if this is for a Go
+  // type is defined.  This function is also used for unnamed function
+  // types with multiple results, in which case the type has no name
+  // and NAME will be empty.  FOR_FUNCTION is true if this is for a Go
   // function type, which corresponds to a C/C++ pointer to function
   // type.  The return value will later be passed as the first
   // parameter to set_placeholder_pointer_type or
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc	(revision 173685)
+++ gcc/go/gofrontend/types.cc	(working copy)
@@ -831,7 +831,8 @@ Type::check_int_value(Expression* e, con
   return false;
 }
 
-// A hash table mapping unnamed types to trees.
+// A hash table mapping unnamed types to the backend representation of
+// those types.
 
 Type::Type_btypes Type::type_btypes;
 
@@ -2588,10 +2589,10 @@ Function_type::do_hash_for_method(Gogo* 
   return ret;
 }
 
-// Get the tree for a function type.
+// Get the backend representation for a function type.
 
 Btype*
-Function_type::do_get_backend(Gogo* gogo)
+Function_type::get_function_backend(Gogo* gogo)
 {
   Bac

Re: [PATCH] C++0x, implement final on classes

[Ville Voutilainen]

At Fri, 13 May 2011 14:13:52 -0400,
Jason Merrill wrote:
> Yes, the order affects the handling of
> struct Undeclared final { };
> Add the error after the call to cp_parser_commit_to_tentative_parse, at 
> which point we've decided that we're dealing with a class definition.

Here's a new patch. Hopefully it fixes the issues mentioned
before. Tests still pass, tested on Linux/X86-32.

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 293dd1c..40a7643 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1268,6 +1268,10 @@ check_bases (tree t,
 
   gcc_assert (COMPLETE_TYPE_P (basetype));
 
+  if (CLASSTYPE_FINAL (basetype))
+error ("cannot derive from % base %qT in derived type %qT",
+   basetype, t);
+
   /* If any base class is non-literal, so is the derived class.  */
   if (!CLASSTYPE_LITERAL_P (basetype))
 CLASSTYPE_LITERAL_P (t) = false;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 1705232..901a17d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1321,6 +1321,7 @@ struct GTY(()) lang_type_class {
   unsigned has_complex_move_ctor : 1;
   unsigned has_complex_move_assign : 1;
   unsigned has_constexpr_ctor : 1;
+  unsigned is_final : 1;
 
   /* When adding a flag here, consider whether or not it ought to
  apply to a template instance if it applies to the template.  If
@@ -1329,7 +1330,7 @@ struct GTY(()) lang_type_class {
   /* There are some bits left to fill out a 32-bit word.  Keep track
  of this by updating the size of this bitfield whenever you add or
  remove a flag.  */
-  unsigned dummy : 3;
+  unsigned dummy : 2;
 
   tree primary_base;
   VEC(tree_pair_s,gc) *vcall_indices;
@@ -1437,6 +1438,11 @@ struct GTY((variable_size)) lang_type {
 #define CLASSTYPE_LAZY_DESTRUCTOR(NODE) \
   (LANG_TYPE_CLASS_CHECK (NODE)->lazy_destructor)
 
+/* Nonzero means that NODE (a class type) is final */
+#define CLASSTYPE_FINAL(NODE) \
+  (LANG_TYPE_CLASS_CHECK (NODE)->is_final)
+
+
 /* Nonzero means that this _CLASSTYPE node overloads operator=(X&).  */
 #define TYPE_HAS_COPY_ASSIGN(NODE) (LANG_TYPE_CLASS_CHECK 
(NODE)->has_copy_assign)
 
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index fa6cd83..30cdb88 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17082,10 +17082,13 @@ cp_parser_class_specifier (cp_parser* parser)
 
class-head:
  class-key identifier [opt] base-clause [opt]
- class-key nested-name-specifier identifier base-clause [opt]
+ class-key nested-name-specifier identifier class-virt-specifier[opt] 
base-clause [opt]
  class-key nested-name-specifier [opt] template-id
base-clause [opt]
 
+   class-virt-specifier:
+ final
+
GNU Extensions:
  class-key attributes identifier [opt] base-clause [opt]
  class-key attributes nested-name-specifier identifier base-clause [opt]
@@ -17117,6 +17120,7 @@ cp_parser_class_head (cp_parser* parser,
   tree id = NULL_TREE;
   tree type = NULL_TREE;
   tree attributes;
+  cp_virt_specifiers virt_specifiers = VIRT_SPEC_UNSPECIFIED;
   bool template_id_p = false;
   bool qualified_p = false;
   bool invalid_nested_name_p = false;
@@ -17260,8 +17264,11 @@ cp_parser_class_head (cp_parser* parser,
   pop_deferring_access_checks ();
 
   if (id)
-cp_parser_check_for_invalid_template_id (parser, id,
-type_start_token->location);
+{
+  cp_parser_check_for_invalid_template_id (parser, id,
+   type_start_token->location);
+  virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
+}
 
   /* If it's not a `:' or a `{' then we can't really be looking at a
  class-head, since a class-head only appears as part of a
@@ -17277,6 +17284,13 @@ cp_parser_class_head (cp_parser* parser,
   /* At this point, we're going ahead with the class-specifier, even
  if some other problem occurs.  */
   cp_parser_commit_to_tentative_parse (parser);
+  if (virt_specifiers & VIRT_SPEC_OVERRIDE)
+{
+  cp_parser_error (parser,
+   "cannot specify % for a class");
+  type = error_mark_node;
+  goto out;
+}
   /* Issue the error about the overly-qualified name now.  */
   if (qualified_p)
 {
@@ -17493,6 +17507,8 @@ cp_parser_class_head (cp_parser* parser,
   if (type)
 DECL_SOURCE_LOCATION (TYPE_NAME (type)) = type_start_token->location;
   *attributes_p = attributes;
+  if (type && (virt_specifiers & VIRT_SPEC_FINAL))
+CLASSTYPE_FINAL (type) = 1;
  out:
   parser->colon_corrects_to_scope_p = saved_colon_corrects_to_scope_p;
   return type;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 5e24977..5e059e0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8209,6 +8209,7 @@ instantiate_class_template_1 (tree type)
   CLASSTYPE_VISIBILITY_SPECIFIED (type) = 1;
   CLASSTYPE_VISIBILITY (type) = CLASSTYPE_VISIBILITY (pattern);
 }
+  CLASSTYPE_FINAL (type) = CLASSTYPE_FINAL (pattern);
 
   pbinfo = TYPE_BINFO 

Re: [Patch, Fortran] PR 48961 - Fix EXECUTE_COMMAND_LINE w/ wait=.false. for non-fork systems

[Steve Kargl]

On Thu, May 12, 2011 at 12:23:36AM +0200, Tobias Burnus wrote:
> The attached patch fixes three issues:
> 
> a) If fork() is not supported, CMDSTAT is -2 (as required by the 
> standard) - and everything is executed synchronously. However, 
> set_cmdstat will abort if the cmdstat value is not 0.
> 
> b) The cmdstat value should be set to an error if  system returns an 
> error ("-1") -- also for WAIT=.false.
> 
> c) In the synchronous case with WAIT=.false. the EXITSTAT= value was not 
> set.
> 
> Additionally, I converted some literals to the EXEC_* enum values.
> 
> Build on x86-64-linux.
> OK for the trunk?
> 
> Tobias
> 
> PS: The next step would be to add support for asynchronous execution 
> under Windows, cf. PR.

This is OK with a proper ChangeLog entry.

-- 
Steve

Re: [Patch, libfortran] Thread safety and simplification of error printing

[Steve Kargl]

On Sun, May 08, 2011 at 07:53:43PM +0300, Janne Blomqvist wrote:
> 
> 2011-05-08  Janne Blomqvist  
> 
>   * gfortran.texi: Remove GFORTRAN_USE_STDERR documentation.
> 
> 
> library ChangeLog:
> 
> 2011-05-08  Janne Blomqvist  
> 
>   * io/unix.c (st_vprintf,st_printf): Move to runtime/error.c.
>   * libgfortran.h (struct options_t): Remove use_stderr field.
>   (st_vprintf,st_printf): Move prototypes.
>   (estr_write): New prototype.
>   * runtime/error.c (sys_exit): Use estr_write instead of st_printf.
>   (estr_write): New function.
>   (st_vprintf): Move from io/unix.c, use stack allocated buffer,
>   always output to stderr.
>   (st_printf): Move from io/unix.c.
>   (show_locus): Use a local variable instead of static.
>   (os_error): Use estr_write instead of st_printf.
>   (runtime_error): Likewise.
>   (runtime_error_at): Likewise.
>   (runtime_warning_at): Likewise.
>   (internal_error): Likewise.
>   (generate_error): Likewise.
>   (generate_warning): Likewise.
>   (notify_std): Likewise.
>   * runtime/pause.c (do_pause): Likewise.
>   (pause_string): Likewise.
>   * runtime/stop.c (stop_string): Likewise.
>   (error_stop_string): Likewise.
>   * config/fpu_aix.h (set_fpu): Likewise.
>   * config/fpu_generic.h (set_fpu): Likewise.
>   * config/fpu_glibc.h (set_fpu): Likewise.
>   * config/fpu-sysv.h (set_fpu): Likewise.
>   * runtime/backtrace.c (dump_glibc_backtrace): Likewise.
>   (show_backtrace): Likewise.
>   * runtime/environ.c (print_spaces): Likewise.
>   (show_string): Likewise.
>   (show_variables): Likewise.
>   (variable_table[]): Remove GFORTRAN_USE_STDERR entry.
> 

OK.

-- 
Steve

Re: [Patch, libfortran] PR 48915 Fix incorrect return code with -fdump-core, error handling changes

[Steve Kargl]

On Sat, May 07, 2011 at 10:52:13PM +0300, Janne Blomqvist wrote:
> 
> this simple bug led me to rethink normal and error termination and
> thus the patch changes some other related stuff as well. So the
> original problem was that when -fdump-core was enabled, STOP with a
> numeric stop code made the program terminate with an incorrect return
> code, since the core dump generation is done by the program killing
> itself.
> 
> The real problem is that previously, we were mixing up normal
> termination with a non-zero exit status (e.g. file not found) with
> aborting the program (e.g. some serious error detected). The attached
> patch reworks this so that normal termination (with a zero or non-zero
> exit code) is done with exit(), and no backtrace or core dump is
> generated in any circumstance. For serious errors, a backtrace and
> core dump are generated.
> 
> Since OS'es contain widely used ways to control core dump generation
> (e.g. ulimit -c), and we no longer "frivolously" try to generate a
> core dump just because we're exiting with non-zero status, there is
> IMHO no longer any need for a gfortran-specific option; if we hit a
> serious error, we call abort() and a core dump is always generated if
> the user environment is so configured (and the system supports core
> dumps).
> 
> Also, since backtraces and core dumps are now only generated for
> serious errors (not e.g. file not found). -fbacktrace is enabled by
> default.
> 
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
> 
> frontend ChangeLog:
> 
> 2011-05-07  Janne Blomqvist  
> 
>   PR libfortran/48915
>   * gfortran.h (gfc_option_t): Remove flag_dump_core.
>   * gfortran.texi (GFORTRAN_ERROR_DUMPCORE): Remove section.
>   (GFORTRAN_ERROR_BACKTRACE): Document that it's enabled by default.
>   * intrinsic.texi (ABORT): Remove explanation of -fdump-core.
>   * invoke.texi: Remove -fdump-core, document that -fbacktrace is
>   enabled by default.
>   * lang.opt: Remove -fdump-core.
>   * options.c (gfc_init_options): Make backtrace default to enabled,
>   remove dump_core.
>   (gfc_handle_option): Remove OPT_fdump-core.
>   * trans-decl.c: Pass a 0 to preserve ABI.
> 
> library ChangeLog:
> 
> 2011-05-07  Janne Blomqvist  
> 
>   PR libfortran/48915
>   * intrinsics/abort.c (abort): Call sys_abort().
>   * io/unix.c (st_vprintf): Call sys_abort().
>   * libgfortran.h (options_t): Remove dump_core member.
>   (handler): Rename to backtrace_handler.
>   (compile_options_t): Remove dump_core member.
>   (sys_exit): Remove.
>   (sys_abort): New function.
>   * runtime/backtrace.c (show_backtrace): Print a message if
>   backtrace is not available on target.
>   * runtime/compile_options.c (backtrace_handler): New
>   implementation based on example in Glibc manual.
>   (set_options): Remove dump_core handling, make signal handler
>   handle more signals.
>   (init_compile_options): Remove dump_core.
>   * runtime/environ.c (variable_table[]): Remove
>   GFORTRAN_ERROR_DUMPCORE element.
>   (show_variables): Update name, call exit().
>   * runtime/error.c (sys_exit): Remove.
>   (sys_abort): New function.
>   (recursion_check): Call sys_abort().
>   (os_error): Call exit().
>   (runtime_error): Likewise.
>   (runtime_error_at): Likewise.
>   (internal_error): Likewise.
>   (generate_error): Likewise.
>   (notify_std): Likewise.
>   * runtime/stop.c (stop_numeric): Call exit().
>   (stop_numeric_f08): Likewise.
>   (stop_string): Likewise.
>   (error_stop_string): Call sys_abort().
>   (error_stop_numeric): Print backtrace, exit with provided code.
> 

OK.

I suspect that there may be some out given that you're dealing
with signals and gfortran runs on so many different OS's.

-- 
Steve

Re: [Patch, Fortran] Fixes for scalar coarrays

[Steve Kargl]

On Sat, May 07, 2011 at 07:21:14AM +0200, Tobias Burnus wrote:
> The interface.c patch is to avoid a strange error ("actual argument must 
> be simply contiguous") which is a bit odd if the actual argument is a 
> scalar. As the dummy was an array, a rank mismatch would have been the 
> proper error. - The patch simply suppresses the error message such that 
> the later error check becomes active.
> 
> The rest of the patch: For scalar coarray dummy arguments, the cobounds 
> were not properly saved - thus calling the one of the coindex intrinsics 
> gave an ICE.
> 
> Build and regtested on x86-64-linux.
> OK for the trunk?
> 

OK.

-- 
Steve

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

[Steve Kargl]

On Fri, May 13, 2011 at 10:18:57PM +0200, Thomas Koenig wrote:
> Am 03.05.2011 22:12, schrieb Thomas Koenig:
> >Am 01.05.2011 11:49, schrieb Thomas Koenig:
> >>Hello world,
> >>
> >>after Paul's fix for allocate on assignment (thanks Paul!), here is a
> >>patch for the original test case from PR 22572, where the bounds of
> >>the function are unknown at compile time. This uses an allocatable
> >>temporary.
> >
> >Ping?
> 
> Ping**2?
> 
> There's been a bit of offline discussion with Tobias regarding -Os and
> timings. At least for a simple test case, the patch made the resulting
> program shorter. As for timing, I would confidently expect that, even
> with -fstack-arrays, any useful function would take longer than a
> malloc()/free() pair.
> 
>   Thomas

Thomas, I can't find the diff.  I read it over if you give me a pointer.

-- 
Steve

Re: [patch, fortran] Eliminate duplicate function calls with rank>0 and unknown shape

[Jerry DeLisle]

On 05/01/2011 02:49 AM, Thomas Koenig wrote:

Hello world,

after Paul's fix for allocate on assignment (thanks Paul!), here is a
patch for the original test case from PR 22572, where the bounds of
the function are unknown at compile time. This uses an allocatable
temporary.

In the long run, another option is to use interface mapping to evaluate
the bounds of intrinsics and explicit-shape functions. For this, it
would be necessary to write a front-end-only version of gfc_evaluate_now, which
would be complicated by the desire not to disturb common function elimination,
so I've put that on the back burner for now.

Regression-tested. OK for trunk?

Thomas

OK and thanks for patch.

Jerry