Fix PR ada/53517

[Eric Botcazou]

Tested on SPARC/Solaris, applied on the mainline and 4.7 branch.


2012-06-01  Eric Botcazou  

PR ada/53517
* gnat.dg/lto14.adb: Skip on Solaris.


-- 
Eric Botcazou
Index: gnat.dg/lto14.adb
===
--- gnat.dg/lto14.adb	(revision 188041)
+++ gnat.dg/lto14.adb	(working copy)
@@ -1,5 +1,6 @@
 -- { dg-do link }
 -- { dg-options "-largs -f -margs -flto" { target lto } }
+-- { dg-skip-if "missing linker support" { *-*-solaris2.* } }
 
 procedure Lto14 is
 begin

Re: [driver, LTO Patch]: Resurrect user specs support

[Christian Bruel]

On 05/29/2012 09:05 PM, Joseph S. Myers wrote:
> On Tue, 29 May 2012, Christian Bruel wrote:
> 
>> So I tested the following semantics, with the ones that you pointed.
> 
> Thanks for the testing.  The patch is OK with the ChangeLog conflict 
> markers removed (and the dates on log entries updated to the date of 
> commit).
> 

Thanks, committed on trunk.

[google] Add options to pattern match function name for hotness attributes

[Dehao Chen]

Hi,

This patch adds 4 flags to enable user to type in a list of name
patterns. Compiler will match the function name with the given
patterns, and add "hot", "cold", "likely_hot", "likely_cold"
attributes to function declaration. The static branch prediction
checks if a basic block contains call to a annotated function, and set
the branch probability accordingly.

Bootstrapped and passed gcc testsuites.

Ok for google branches?

Thanks,
Dehao

gcc/ChangeLog.google-4_6
2012-06-01  Dehao Chen  

* gcc/cgraph.c (cgraph_match_hotness_by_name): New function.
(cgraph_add_hotness_attribute): New function.
(cgraph_node): Add hotness attribute to function decl.
* gcc/opts.c (common_handle_option): Handle new options.
* gcc/predict.c (tree_bb_level_predictions): New prediction.
* gcc/predict.def (PRED_LIKELY_COLD_FUNCTION): New prediction.
* gcc/common.opt (flag_function_hot_list): New option.
(flag_function_cold_list): New option.
(flag_function_likely_hot_list): New option.
(flag_function_likely_cold_list): New option.

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 188050)
+++ gcc/doc/invoke.texi (working copy)
@@ -362,7 +362,9 @@
 -fdelete-null-pointer-checks -fdse -fdevirtualize -fdse @gol
 -fearly-inlining -fipa-sra -fexpensive-optimizations -ffast-math @gol
 -ffinite-math-only -ffloat-store -fexcess-precision=@var{style} @gol
--fforward-propagate -ffp-contract=@var{style} -ffunction-sections @gol
+-fforward-propagate -ffp-contract=@var{style} @gol
+-ffunction-cold-list -ffunction-hot-list -ffunction-likely-cold-list @gol
+-ffunction-likely-hot-list -ffunction-sections @gol
 -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity @gol
 -fgcse-sm -fif-conversion -fif-conversion2 -findirect-inlining @gol
 -finline-functions -finline-functions-called-once -finline-limit=@var{n} @gol
@@ -8585,6 +8587,22 @@
 specify this option and you may have problems with debugging if
 you specify both this option and @option{-g}.

+@item -ffunction-cold-list
+@opindex ffunction-cold-list
+List of function name patterns that will be applied "cold" attribute.
+
+@item -ffunction-hot-list
+@opindex ffunction-hot-list
+List of function name patterns that will be applied "hot" attribute.
+
+@item -ffunction-likely-cold-list
+@opindex ffunction-likely-cold-list
+List of function name patterns that will be applied "likely_cold" attribute.
+
+@item -ffunction-likely-hot-list
+@opindex ffunction-likely-hot-list
+List of function name patterns that will be applied "likely_hot" attribute.
+
 @item -fbranch-target-load-optimize
 @opindex fbranch-target-load-optimize
 Perform branch target register load optimization before prologue / epilogue
Index: gcc/cgraph.c
===
--- gcc/cgraph.c(revision 188050)
+++ gcc/cgraph.c(working copy)
@@ -520,6 +520,70 @@
 }
 }

+typedef char *char_pointer;
+DEF_VEC_P(char_pointer);
+DEF_VEC_ALLOC_P(char_pointer,heap);
+
+/* Match FNDECL's name with PATTERNS. If matched, add HOTNESS attribute
+   to FNDECL.
+   name matches with pattern, iff one of the following conditions satisfy:
+ 1. strcmp (name, pattern) != 0
+ 2. pattern[len - 1] = '*' && strncmp (name, pattern, len - 1) != 0  */
+static bool
+cgraph_match_hotness_by_name (tree fndecl,
+ VEC(char_pointer, heap) *patterns,
+ const char *hotness)
+{
+  unsigned i;
+  char_pointer n;
+  const char *name = lang_hooks.decl_printable_name(fndecl, 0);
+
+  if (!name)
+return false;
+
+  FOR_EACH_VEC_ELT (char_pointer, patterns, i, n)
+{
+  int len = strlen (n);
+  if ((n[len - 1] == '*' && !strncmp (name, n, len - 1))
+  || !strcmp (name, n))
+{
+  decl_attributes (&fndecl, tree_cons (
+  get_identifier (hotness), NULL, NULL), 0);
+  return true;
+}
+}
+  return false;
+}
+
+/* Add hotness attributes to FNDECL.  */
+static void
+cgraph_add_hotness_attribute (tree fndecl)
+{
+  if (lookup_attribute ("cold", DECL_ATTRIBUTES (fndecl))
+  || lookup_attribute ("hot", DECL_ATTRIBUTES (fndecl))
+  || lookup_attribute ("likely_cold", DECL_ATTRIBUTES (fndecl))
+  || lookup_attribute ("likely_hot", DECL_ATTRIBUTES (fndecl)))
+return;
+
+  if (cgraph_match_hotness_by_name (fndecl,
+   (VEC(char_pointer, heap) *) flag_function_cold_list, "cold"))
+return;
+
+  if (cgraph_match_hotness_by_name (fndecl,
+   (VEC(char_pointer, heap) *) flag_function_hot_list, "hot"))
+return;
+
+  if (cgraph_match_hotness_by_name (fndecl,
+   (VEC(char_pointer, heap) *) flag_function_likely_cold_list,
+   "likely_cold"))
+return;
+
+  if (cgraph_match_hotness_by_name (fndecl,
+   (VEC(char_pointer, heap) *) flag_function_likely_hot_list,
+   "likely_hot"))

Re: [PATCH 1/5] Access methods for jump functions

[Jan Hubicka]

> Hi,
> 
> the first patch mainly introduces access methods to read parts of jump
> functions.  I am no particular fan of these but the are now more
> widely spread than originally and above all checking asserts verifying
> that the correct part of the union is read should really be useful.
> 
> I have also unified creation of jump function in ipa-prop.c to new
> functions so that all fields are initialized.  On the contrary, I have
> left update_jump_functions_after_inlining largely alone because it
> modifies jump functions in place (and there may be good reason not to
> touch some parts in the future, if not now), dumping functions and
> streaming because they are a bit special and simple too.
> 
> There is also a tiny amount of other cleanup.
> 
> Bootstrapped separately on x86_64-linux.  OK for trunk?
> 
> Thanks,
> 
> Martin
> 
> 
> 
> 2012-05-03  Martin Jambor  
> 
>   * ipa-prop.h (ipa_get_jf_known_type_offset): New function.
>   (ipa_get_jf_known_type_base_type): Likewise.
>   (ipa_get_jf_known_type_component_type): Likewise.
>   (ipa_get_jf_constant): Likewise.
>   (ipa_get_jf_pass_through_formal_id): Likewise.
>   (ipa_get_jf_pass_through_operation): Likewise.
>   (ipa_get_jf_ancestor_offset): Likewise.
>   (ipa_get_jf_ancestor_type): Likewise.
>   (ipa_get_jf_ancestor_formal_id): Likewise.
>   (ipa_get_jf_member_ptr_pfn): Likewise.
> 
>   * ipa-prop.c (ipa_set_jf_known_type): New function.
>   (ipa_set_jf_constant): Likewise.
>   (ipa_set_jf_simple_pass_through): Likewise.
>   (ipa_set_jf_arith_pass_through): Likewise.
>   (ipa_set_ancestor_jf): Likewise.
>   (fill_member_ptr_cst_jump_function): Moved up and renamed to
>   ipa_set_jf_member_ptr_cst.
>   (detect_type_change_1): Use the new jump function creation functions.
>   (compute_complex_assign_jump_func): Likewise.
>   (compute_complex_ancestor_jump_func): Likewise.
>   (compute_known_type_jump_func): Likewise.
>   (compute_scalar_jump_functions): Likewise.
>   (compute_pass_through_member_ptrs): Likewise.
>   (determine_cst_member_ptr): Likewise.
>   (combine_known_type_and_ancestor_jfs): Likewise.
>   (try_make_edge_direct_simple_call): Likewise.
>   (try_make_edge_direct_virtual_call): Likewise.
>   (update_indirect_edges_after_inlining): Likewise.
> 
>   * ipa-cp.c (ipa_get_jf_pass_through_result): Use jump function
>   access functions.  Incorporat NOP_EXPR and BINFO handling from its
>   callers.
>   (ipa_get_jf_ancestor_result): Likewise.  Incorporate handling BINFOs
>   which was in its callers.
>   (ipa_value_from_jfunc): Use jump function access functions.  Some
>   functionality moved to functions above.
>   (propagate_vals_accross_ancestor): Likewise.
>   (propagate_vals_accross_pass_through): Use jump function access
>   functions.
>   (propagate_accross_jump_function): Likewise.
> 
>   * ipa-inline-analysis.c (remap_edge_change_prob): Use jump function
>   access functions.
>   (inline_merge_summary): Likewise.

OK,
thanks!
Honza

Re: [PATCH] Fix PR53501

[Eric Botcazou]

> The issue is that fold_plusminus_mult re-writes the multiplication
> from unsigned to signed for the failing testcase, introducing
> undefined overflow.

fold_plusminus_mult or fold_binary?  My understanding is that the problem is 
fold_binary incorrectly stripping the outer signedness conversion.  If so, 
then the fix could test for this case precisely instead of disabling the 
transformation in all cases, including when there is no signedness conversion.

-- 
Eric Botcazou

Re: [PATCH] Fix PR53501

[Richard Guenther]

On Fri, 1 Jun 2012, Eric Botcazou wrote:

> > The issue is that fold_plusminus_mult re-writes the multiplication
> > from unsigned to signed for the failing testcase, introducing
> > undefined overflow.
> 
> fold_plusminus_mult or fold_binary?  My understanding is that the problem is 
> fold_binary incorrectly stripping the outer signedness conversion.  If so, 
> then the fix could test for this case precisely instead of disabling the 
> transformation in all cases, including when there is no signedness conversion.

fold_binary is not "incorrectly" stripping the sign conversion, it is
fold_plusminus_mult not properly dealing with that situation.  In practice
non-sign-"nop"-conversions stipped by STRIP_NOPS are already stripped
by properly folding a conversion at generation time, so the STRIP_NOPS
calls should be no-ops (well, apart from stripping NON_LVALUE trees I 
suppose).

So, what case do you see disabled where there is no sign conversion
involved?

Richard.

[AArch64] Use snprintf instead sprintf

[Sofiane Naci]

Hi,

This patch replaces instances of sprintf with snprintf with sizeof(..) in
the AArch64 port.
It also fixes layout issues in the code it touches.

Thanks
Sofiane

-

ChangeLog

2012-06-01  Sofiane Naci 

[AArch64] Replace sprintf with snprintf.

* config/aarch64/aarch64.c
(aarch64_elf_asm_constructor): Replace sprintf with snprintf.
(aarch64_elf_asm_destructor): Likewise.
(aarch64_output_casesi): Likewise.
(aarch64_output_asm_insn): Likewise.
* config/aarch64/aarch64-builtins.c (init_aarch64_simd_builtins):
Likewise.
* config/aarch64/aarch64-simd.md (*aarch64_simd_mov): Replace
sprintf with snprintf, and fix code layout.

aarch64-snprintf.patch
Description: Binary data

[PATCH, GCC][AArch64] Use Enums for TLS dialect option selection

[Sofiane Naci]

Hi,

This patch re-factors TLS dialect option selection in the AArch64 port to
use the generic support for enumerated option arguments.

Thanks
Sofiane

-

2012-06-01  Sofiane Naci 

[AArch64] Use Enums for TLS option selection.

* config/aarch64/aarch64-opts.h (enum aarch64_tls_type): New.
* config/aarch64/aarch64.c
(aarch64_tls_dialect): Remove.
(tls_symbolic_operand_type): Update comment.
(aarch64_override_options): Remove TLS option setup code.
* config/aarch64/aarch64.h
(TARGET_TLS_TRADITIONAL): Remove.
(TARGET_TLS_DESC): Update definition.
(enum tls_dialect): Remove.
(enum tls_dialect aarch64_tls_dialect) Remove.
* config/aarch64/aarch64.opt
(tls_type): New.
(mtls-dialect): Update.

aarch64-use-enums-for-tls.patch
Description: Binary data

Re: [C++] Reject variably modified types in operator new

[Florian Weimer]

On 05/29/2012 06:00 PM, Florian Weimer wrote:

This patch flags operator new on variably modified types as an error.
If this is acceptable, this will simplify the implementation of the
C++11 requirement to throw std::bad_array_new_length instead of
allocating a memory region which is too short.


It turns out that the patch is not good enough.  Apparently, people write

  new (T[n])

instead of

  new T[n]

from time to time.  This is ill-formed (for variable n), and is 
currently accepted silently.  We even have test suite coverage for this.


I'll try to warn about this case and make the transformation to the 
proper operator new[] call.


--
Florian Weimer / Red Hat Product Security Team

Re: [patch] Fix many Makefile dependencies, round 3

[Richard Guenther]

On Thu, May 31, 2012 at 6:48 PM, Steven Bosscher  wrote:
> Hello,
>
> A smaller patch this time, but bigger impact: GIMPLE_H does not have
> to depend on TARGET_H. Only a few files need TARGET_H as well as
> GIMPLE_H, and most of them already included TARGET_H anyway. The ones
> that don't, are fixed with this patch.
>
> Bootstrapped&tested on powerpc64-unknown-linux-gnu, and verified that
> my contrib/check_makefile_deps.sh output has no new missing
> dependencies (and far fewer unneeded deps). OK?

Ok.

Thanks,
Richard.

> Ciao!
> Steven

Re: [patch] Do not include output.h everywhere

[Richard Guenther]

On Thu, May 31, 2012 at 9:21 PM, Diego Novillo  wrote:
> On 12-05-31 14:57 , Steven Bosscher wrote:
>>
>> Hello,
>>
>> Almost all files include output.h because it defines dump_file. IMHO
>> output.h should only be included in files that actually output
>> something to asm_out_file. Therefore wanted to I move dump_file to
>> some other include file. I ended up with system.h because I couldn't
>> find a more suitable place. Another option is coretypes.h, but no
>> other file is included everywhere, and system.h also already defines
>> fancy_abort, which is also for dumping things - sort of... Anyway, the
>> point is that with dump_file moved out of output.h, ~120 files don't
>> have to include output.h anymore.
>
>
> What about toplev.h?  dump_file is defined there, after all.  I don't mind
> it in system.h, if that's not a good place for it now.  The patch is OK
> either way.

I'd prefer toplev.h, too.  system.h is supposed to be for system header
inclusion (and related workarounds).

>
>> While working on the above, I noticed we can also move all dbxout
>> prototypes from output.h to dbxout.h, and move some stabs-related
>> target hooks there also.
>
>
> Sounds good.
>
>
>> Big patch, but IMHO a nice cleanup too :-)
>
>
> Indeed.

Thus, ok with moving to toplev.h instead.

>>
>>        * gcov-dump.c (dump_file): Rename to dump_gcov_file.  Update
>> callers.
>>
>>        * collect2.h (dump_file): Rename to dump_ld_file.
>
>
> Thanks.  I've always hated tagging for dump_file and stopping here.
>
>
> Diego.

Re: [PATCH] Fix PR53471, remove DECL_ASSEMBLER_NAME deferred compute

[Richard Guenther]

On Thu, 31 May 2012, Jason Merrill wrote:

> The comment mentions PCH in connection with deferred seting of
> DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that might be
> connected with anonymous unions, which need to have different linkage names in
> different translation units.

Not sure when PCH generation happens (or when we call 
rest_of_type_compilation), but shouldn't that be way earlier than
the debug output?  Anyway, any suggestion on how to tackle the issue
that we cannot compute new DECL_ASSEMBLER_NAMEs after the frontend
is finished?

Thanks,
Richard.

[wwwdocs,4.7,AVR,committed]: Mention the new %i asm print modifier

[Georg-Johann Lay]

Yet another new feature in 4.7, committed

Johann

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.108
diff -u -p -r1.108 changes.html
--- changes.html21 Apr 2012 00:00:20 -  1.108
+++ changes.html1 Jun 2012 09:15:18 -
@@ -676,6 +676,21 @@ int add_values (const __flash int *p, in
 New command-line options -maccumulate-args,
   -mbranch-cost=cost and -mstrict-X
   were added to allow better fine-tuning of code optimization.
+A new inline assembler print modifier %i to print a RAM
address as I/O
+address has been added:
+
+  
+#include  /* Port Definitions from AVR-LibC */
+
+void set_portb (uint8_t value)
+{
+asm volatile ("out %0, %i1" :: "r" (value), "n" (&PORTB) : "memory");
+}
+  The offset between an I/O address and a RAM address for that I/O
+  location is device-specific.  This offset is taken into account when
+  printing a RAM address with the %i modifier so that the
+  address is suitable to be used as operand in an I/O command.
+  The address must be a constant integer known at compile time.
 Many optimizations to:
   
64-bit integer arithmetic

Re: [RFC] Fix SRA with respect of BIT_FIELD_REF

[Richard Guenther]

On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
 wrote:
> Hi,
>  When I modified GCC to change the majority of bitfield accesses
> which were done via component ref to BIT_FIELD_REF, SRA messes up
> because when it does the replacement it still tries to use the
> BIT_FIELD_REF except it never places the old value in the struct for
> the BIT_FIELD_REF to work correctly.
>
> This patch fixes the problem by expanding what BIT_FIELD_REF does
> internally for both writing and reading.  Note we can't use
> BIT_FIELD_REF directly on the left hand since we don't support partial
> writes yet (except for vector and complex types).
>
> This is only a RFC since I don't know a way to reproduce this bug on
> the trunk. I tested it on x86_64-linux-gnu with no regressions.

I'd rather disqualify SRA of BIT_FIELD_REFs on the LHS for now.  My goal
was to enable SRA of bitfields using the DECL_BIT_FIELD_REPRESENTATIVE
work - something you go against with replacing them with BIT_FIELD_REFs.

You'd replace

  x = a.b;

with

  tem = a.;
  x = BIT_FIELD_REF ;

and for stores with a read-modify-write sequence, possibly adding
the bitfield-insert tree I proposed some time ago.  Replace

 a.b = x;

with

 tem = a.
 tem = BIT_FIELD_EXPR ;
 a. = tem;

and I'd do this replacement in SRA for now whenever it would decide to
SRA a bitfield.

Richard.

> Thanks,
> Andrew Pinski
>
> ChangeLog:
> * tree-sra.c (sra_modify_expr): Handle BIT_FIELD_REF specially if we
> are doing a replacement of the struct with one variable.

Re: [patch] PR 50134: improve docs for -Wmissing-prototypes and -Wmissing-declarations

[Jonathan Wakely]

For the record, Gaby approved this change (thanks, Gaby,) but his mail
didn't show up in the archives (gmail likes to send HTML mail, which
the GCC lists reject.)

On 1 June 2012 05:22, Gabriel Dos Reis wrote:
> Ok.

Re: [PATCH] Fix PR53501

[Eric Botcazou]

> So, what case do you see disabled where there is no sign conversion
> involved?

For the Ada testcase I attached, in fold_binary_loc we have:

(gdb) p debug_tree(op0)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76fdd0a8 precision 
64 min  max >
readonly
arg 0  unit size 
align 64 symtab 0 alias set -1 canonical type 0x76fdd000 
precision 64 min  max >
readonly

(gdb) p debug_tree(arg0)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76fdd000 precision 
64 min  max >
readonly

-- 
Eric Botcazou

Re: [PATCH] Fix PR53501

[Richard Guenther]

On Fri, 1 Jun 2012, Eric Botcazou wrote:

> > So, what case do you see disabled where there is no sign conversion
> > involved?
> 
> For the Ada testcase I attached, in fold_binary_loc we have:
> 
> (gdb) p debug_tree(op0)
>   type  size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x76fdd0a8 
> precision 
> 64 min  max >
> readonly
> arg 0  type  DI 
> size  unit size 
> align 64 symtab 0 alias set -1 canonical type 0x76fdd000 
> precision 64 min  max  0x76fccf20 -1>>
> readonly
> 
> (gdb) p debug_tree(arg0)
>   type  size 
> unit size 
> align 64 symtab 0 alias set -1 canonical type 0x76fdd000 
> precision 
> 64 min  max >
> readonly

Ah, I see.  So the proper fix would be to use STRIP_NOP()ed op0/op1,
something not readily available though.

Richard.

Re: [PATCH] Fix PR53501

[Eric Botcazou]

> Ah, I see.  So the proper fix would be to use STRIP_NOP()ed op0/op1,
> something not readily available though.

Why not just add

  TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
  && TYPE_UNSIGNED (TREE_TYPE (op1)) == TYPE_UNSIGNED (TREE_TYPE (arg1))

with a small comment?

-- 
Eric Botcazou

Re: [PATCH] Fix PR53501

[Richard Guenther]

On Fri, 1 Jun 2012, Eric Botcazou wrote:

> > Ah, I see.  So the proper fix would be to use STRIP_NOP()ed op0/op1,
> > something not readily available though.
> 
> Why not just add
> 
>   TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
>   && TYPE_UNSIGNED (TREE_TYPE (op1)) == TYPE_UNSIGNED (TREE_TYPE (arg1))
> 
> with a small comment?

Well, it would rather be

  TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
  && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))

but only in the !FLOAT_TYPE_P path.  We could even compare
TYPE_OVERFLOW_UNDEFINED I think.  Or even just make sure
that when TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)) also
TYPE_OVERFLOW_UNDEFINED (type), thus

  !TYPE_OVERFLOW_UNDEFINED (type)
  || ((TREE_CODE (arg0) != MULT_EXPR
   || TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)))
  && (TREE_CODE (arg1) != MULT_EXPR
  || TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1

That is, the newly created multiplication in type TYPE should
either not have undefined overflow or the inner multiplications
all should already have.  Best done with a comment in
fold_plusminus_mult_expr.

Richard.

Re: [PATCH 1/2] SH epilogue unwind, dwarf2 pass changes

[Chung-Lin Tang]

On 12/5/23 1:46 AM, Richard Henderson wrote:
> On 05/18/12 03:48, Chung-Lin Tang wrote:
>> @@ -2401,6 +2401,7 @@ scan_trace (dw_trace_info *trace)
>>  {
>>/* Propagate across fallthru edges.  */
>>dwarf2out_flush_queued_reg_saves ();
>> +  def_cfa_1 (&this_cfa);
>>maybe_record_trace_start (insn, NULL);
>>break;
>>  }
>> @@ -2455,6 +2456,18 @@ scan_trace (dw_trace_info *trace)
>>cur_cfa = &this_cfa;
>>continue;
>>  }
>> +  else
>> +{
>> +  /* If ELT is a annulled branch-taken instruction (i.e. 
>> executed
>> + only when branch is not taken), the args_size and CFA 
>> should
>> + not change through the jump.  */
>> +  create_trace_edges (control);
>> +
>> +  /* Update and continue with the trace.  */
>> +  add_cfi_insn = insn;
>> +  scan_insn_after (elt);
>> +  continue;
>> +}
> 
> I think the def_cfa_1 is misplaced.  It should be immediately before
> that last continue.  That mirrors the sort of flow you get via the
> other paths through the loop.

Or possibly moved before the dwarf2out_flush_queued_reg_saves () call in
the patch? (in the save_point_p () break case)  Note I'm only saying
this based on overall ordering of those two routine calls in the loop.

Attached is a testcase (adapted from libgomp) that, with the SH epilogue
unwind patch applied alone, produces the ICE I'm seeing (-O2
-funwind-tables).

This dwarf2 patch, with any of the three new def_cfa_1() call sites
seems to solve it, though you might want to comment on which call site
seems "correct"

Thanks,
Chung-Lin
typedef unsigned long long gomp_ull;
int
foo (gomp_ull *pstart, gomp_ull *pend, int mode,
 gomp_ull next_ull, gomp_ull end_ull, gomp_ull chunk_size_ull)
{
  gomp_ull start, end, chunk, left;
  start = next_ull;
  if (start == end_ull)
return 0;

  chunk = chunk_size_ull;
  left = end_ull - start;
  if (mode & 2)
{
  if (chunk < left)
chunk = left;
}
  else
{
  if (chunk > left)
chunk = left;
}
  end = start + chunk;
  *pstart = start;
  *pend = end;
  return 1;
}

Re: [PATCH] Fix PR53501

[Eric Botcazou]

> Well, it would rather be
>
>   TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
>   && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
>
> but only in the !FLOAT_TYPE_P path.

That works in all cases I think, see existing cases in the folder.

> We could even compare 
> TYPE_OVERFLOW_UNDEFINED I think.  Or even just make sure
> that when TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)) also
> TYPE_OVERFLOW_UNDEFINED (type), thus
>
>   !TYPE_OVERFLOW_UNDEFINED (type)
>
>   || ((TREE_CODE (arg0) != MULT_EXPR
>   ||
>|| TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)))
>
>   && (TREE_CODE (arg1) != MULT_EXPR
>
>   || TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1
>
> That is, the newly created multiplication in type TYPE should
> either not have undefined overflow or the inner multiplications
> all should already have.  Best done with a comment in
> fold_plusminus_mult_expr.

I'm a little lost here. :-)  I don't really care about the mainline at this 
point, but the fix on the branches should be the minimal working one.

-- 
Eric Botcazou

Re: [PATCH] Fix PR53501

[Richard Guenther]

On Fri, 1 Jun 2012, Eric Botcazou wrote:

> > Well, it would rather be
> >
> >   TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> >   && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
> >
> > but only in the !FLOAT_TYPE_P path.
> 
> That works in all cases I think, see existing cases in the folder.

(*)

> > We could even compare 
> > TYPE_OVERFLOW_UNDEFINED I think.  Or even just make sure
> > that when TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)) also
> > TYPE_OVERFLOW_UNDEFINED (type), thus
> >
> >   !TYPE_OVERFLOW_UNDEFINED (type)
> >
> >   || ((TREE_CODE (arg0) != MULT_EXPR
> >   ||
> >|| TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg0)))
> >
> >   && (TREE_CODE (arg1) != MULT_EXPR
> >
> >   || TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (arg1
> >
> > That is, the newly created multiplication in type TYPE should
> > either not have undefined overflow or the inner multiplications
> > all should already have.  Best done with a comment in
> > fold_plusminus_mult_expr.
> 
> I'm a little lost here. :-)  I don't really care about the mainline at this 
> point, but the fix on the branches should be the minimal working one.

Ok ... the (*) fix is ok then on both branch and trunk.

We can leave improving trunk for a followup.

Richard.

_FORTIFY_SOURCE for std::vector

[Florian Weimer]

I forgot to send this to the libstdc++ list the first time.

This patch evaluates _FORTIFY_SOURCE in a way similar to GNU libc.
If set, std::vector::operator[] throws if the index is out of bounds.
This is compliant with the standard because such usage triggers
undefined behavior.  _FORTIFY_SOURCE users expect some performance hit.

In contrast to debugging mode, this does not change ABI and is more 
widely applicable.


Okay for trunk?

2012-05-29  Florian Weimer  

* include/bits/stl_vector.h (vector::_M_fortify_range_check):
New.
* (vector::operator[]): Call it.
* testsuite/23_containers/vector/element_access/2.cc: New.

--
Florian Weimer / Red Hat Product Security Team

Index: libstdc++-v3/include/bits/stl_vector.h
===
--- libstdc++-v3/include/bits/stl_vector.h	(revision 187951)
+++ libstdc++-v3/include/bits/stl_vector.h	(working copy)
@@ -768,7 +768,10 @@
*/
   reference
   operator[](size_type __n)
-  { return *(this->_M_impl._M_start + __n); }
+  {
+	_M_fortify_range_check(__n);
+	return *(this->_M_impl._M_start + __n);
+  }
 
   /**
*  @brief  Subscript access to the data contained in the %vector.
@@ -783,7 +786,10 @@
*/
   const_reference
   operator[](size_type __n) const
-  { return *(this->_M_impl._M_start + __n); }
+  { 
+	_M_fortify_range_check(__n);
+	return *(this->_M_impl._M_start + __n);
+  }
 
 protected:
   /// Safety check used only from at().
@@ -794,6 +800,16 @@
 	  __throw_out_of_range(__N("vector::_M_range_check"));
   }
 
+  /// Range check used by operator[].
+  /// No-op unless _FORTIFY_SOURCE is enabled.
+  void
+  _M_fortify_range_check(size_type __n) const
+  {
+#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
+	_M_range_check(__n);
+#endif
+  }
+
 public:
   /**
*  @brief  Provides access to the data contained in the %vector.
Index: libstdc++-v3/testsuite/23_containers/vector/element_access/2.cc
===
--- libstdc++-v3/testsuite/23_containers/vector/element_access/2.cc	(revision 0)
+++ libstdc++-v3/testsuite/23_containers/vector/element_access/2.cc	(revision 0)
@@ -0,0 +1,71 @@
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// 23.2.4 vector 
+
+// { dg-add-options no_pch }
+
+#undef _FORTIFY_SOURCE
+#define _FORTIFY_SOURCE 2
+
+#include 
+#include 
+#include 
+
+void test01()
+{
+  std::vector v(5);
+  try
+{
+  v[5];
+  VERIFY( false );
+}
+  catch(std::out_of_range& err)
+{
+  VERIFY( true );
+}
+  catch(...)
+{
+  VERIFY( false );
+}
+}
+
+void test02()
+{
+  std::vector v(5);
+  const std::vector u(v);
+  try
+{
+  u[5];
+  VERIFY( false );
+}
+  catch(std::out_of_range& err)
+{
+  VERIFY( true );
+}
+  catch(...)
+{
+  VERIFY( false );
+}
+}
+
+int main()
+{
+  test01();
+  test02();
+  return 0;
+}

Re: [PATCH 2/5] Build aggregate jump functions

[Richard Guenther]

On Fri, Jun 1, 2012 at 2:02 AM, Martin Jambor  wrote:
> Hi,
>
> this patch adds the capability to build aggregate jump functions.
> These consist of:
>
> 1) information what known compile time IPA-invariants are at various
>   offsets of an aggregate passed to a callee either by reference
>   (when the parameter is pointer) or by value (when it is an
>   aggregate).  This patch simply scans the current BB backwards from
>   the call statement and examines what values are stored there.  Even
>   this simple approach does not look particularly simple
>   (determine_known_aggregate_parts), it is however usually sufficient
>   for Fortran array descriptions (in the testcases I have seen).  For
>   more advanced uses like devirtualization we'll need something that
>   will examine the whole function but will look quite like this, only
>   even more messy, I'm afraid.
>
>   When we do this, we also record the type through which data was
>   stored into the aggregate, which is either the type of a DECL or
>   type stored in the offset of a  MEM_REF.
>
> 2) Being able to conservatively but usefully recognize that an
>   aggregate (passed either by reference or a value) that we got from
>   a caller and pass it to a callee has not changed.
>
>   This is slightly complex in cases where aggregates are passed by
>   reference.  Because in gimple pointer types carry more-or-less no
>   information about the data it points to, we'd normally have to feed
>   AA with a type that aliases all in order to get conservatively
>   correct results.  That might however be too much conservative.  We
>   circumvent this problem by feeding AA the pointed-to type but also
>   verifying that the aggregate data was stored with the same type (or
>   a type containing the pointed-to type at the expected offset).
>
>   The data structures can also represent such pass-through functions
>   with known listed exceptions but that is not currently implemented
>   and is left for later.
>
> However, this patch does not use the collected data in any way, that
> is what two subsequent patches do.
>
> The patch passes bootstrap and testing on x86_64-linux.

Quite a large patch ... let's iterate a bit about the aliasing stuff.
If I understand
correctly you have

... foo (struct X *p)
{
   (1)
  bar (p);
}

and want to know whether *p was modified before the call to bar so you
can pass thru the jump function (you are not interested to modify the jump
function, clearing clobbered information yet?).

Now I don't understand on how you might be able to ever use type-based
alias info to disambiguate any may-defs of *p.  Can you explain why
you believe you can do so?

I understand you possibly want to verify whether a consumer of *p
can eventually be replaced by the jump function value, thus the value
is of matching type, but would that be not only applicable at transform time?
Given that you'd always be able to fallback to

 'const' typeof (*p) tem = ;
 ... = properly-typed-read-from-tem-with-alias-set-zero;

and leave constant propagation to the optimizers?

At least I think you confuse what "type" you can use at value-replacement
time with the "type" you use for determining whether *p is invalidated.


>  static void
> -compute_cst_member_ptr_arguments (struct ipa_edge_args *args,
> -                                 gimple call)
> +init_ao_ref_for_byref_agg_jf (ao_ref *r, tree base, tree type)
> +{
> +  static tree alias_all_type = NULL;
> +
> +  if (!alias_all_type)
> +    alias_all_type = build_pointer_type_for_mode (char_type_node,
> +                                                 ptr_mode, true);
> +  ao_ref_init (r, build2 (MEM_REF, type, base,
> +                         build_int_cst (alias_all_type, 0)));
> +}

this won't survive garbage collection I believe.  I think you can more easily
use ao_ref_init_from_ptr_and_size here:

  ao_ref_init_from_ptr_and_size (r, base, TYPE_SIZE_UNIT (TREE_TYPE (base)));

that makes sure to use alias-set zero.

As you've seen in the recent bugreport the alias stmt walking can be quite
a compile-time hog so you should eventually limit yourself conservatively
by using the number of stmts walked returned by walk_aliased_vdefs.

Richard.

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 01:00:46PM +0200, Florian Weimer wrote:
> I forgot to send this to the libstdc++ list the first time.
> 
> This patch evaluates _FORTIFY_SOURCE in a way similar to GNU libc.
> If set, std::vector::operator[] throws if the index is out of bounds.
> This is compliant with the standard because such usage triggers
> undefined behavior.  _FORTIFY_SOURCE users expect some performance hit.
> 
> In contrast to debugging mode, this does not change ABI and is more
> widely applicable.
> 
> Okay for trunk?

Have you looked at the assembly differences with this in?
I wonder e.g. if we don't need to add __builtin_expect around the
_M_range_check test.  As it needs to read in many cases two pointers,
subtract them (+ divide by size of entry (or shift right if power of two))
and compare that to something likely in a register, it is likely to be more
expensive than most of other _FORTIFY_SOURCE checks, but perhaps bearable.
Also, I wonder if the addition of a throw spot (even in cold .text chunk)
doesn't add too much cost (code having to deal with possible EH even when
otherwise it wouldn't be expected) and whether calling __chk_fail () in
that case instead wouldn't be cheaper.  Even in C++ memcpy etc. _FORTIFY_SOURCE
failures will result in __chk_fail, not throwing some exception, so
operator[] on std::vector could work the same.  operator[] is documented
as not doing the range check (unlike ->at()), so you probably need to
tweak the documentation too.

> 2012-05-29  Florian Weimer  
> 
>   * include/bits/stl_vector.h (vector::_M_fortify_range_check):
>   New.
>   * (vector::operator[]): Call it.
>   * testsuite/23_containers/vector/element_access/2.cc: New.
>
> Index: libstdc++-v3/include/bits/stl_vector.h
> ===
> --- libstdc++-v3/include/bits/stl_vector.h(revision 187951)
> +++ libstdc++-v3/include/bits/stl_vector.h(working copy)
> @@ -768,7 +768,10 @@
> */
>reference
>operator[](size_type __n)
> -  { return *(this->_M_impl._M_start + __n); }
> +  {
> + _M_fortify_range_check(__n);
> + return *(this->_M_impl._M_start + __n);
> +  }
>  
>/**
> *  @brief  Subscript access to the data contained in the %vector.
> @@ -783,7 +786,10 @@
> */
>const_reference
>operator[](size_type __n) const
> -  { return *(this->_M_impl._M_start + __n); }
> +  { 
> + _M_fortify_range_check(__n);
> + return *(this->_M_impl._M_start + __n);
> +  }
>  
>  protected:
>/// Safety check used only from at().
> @@ -794,6 +800,16 @@
> __throw_out_of_range(__N("vector::_M_range_check"));
>}
>  
> +  /// Range check used by operator[].
> +  /// No-op unless _FORTIFY_SOURCE is enabled.
> +  void
> +  _M_fortify_range_check(size_type __n) const
> +  {
> +#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
> + _M_range_check(__n);
> +#endif
> +  }
> +
>  public:
>/**
> *  @brief  Provides access to the data contained in the %vector.

Jakub

[PATCH][4/n] loop distribution TLC

[Richard Guenther]

This fixes an oversight.

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

Richard.

2012-06-01  Richard Guenther  

* tree-loop-distribution.c (stmt_has_scalar_dependences_outside_loop):
Handle PHIs.
(classify_partition): Likewise.

Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 188104)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -129,6 +129,9 @@ stmt_has_scalar_dependences_outside_loop
   def_operand_p def_p;
   ssa_op_iter op_iter;
 
+  if (gimple_code (stmt) == GIMPLE_PHI)
+return ssa_name_has_uses_outside_loop_p (gimple_phi_result (stmt), loop);
+
   FOR_EACH_SSA_DEF_OPERAND (def_p, stmt, op_iter, SSA_OP_DEF)
 if (ssa_name_has_uses_outside_loop_p (DEF_FROM_PTR (def_p), loop))
   return true;
@@ -813,8 +816,7 @@ classify_partition (loop_p loop, struct
   /* If the stmt has uses outside of the loop fail.
 ???  If the stmt is generated in another partition that
 is not created as builtin we can ignore this.  */
-  if (gimple_code (stmt) != GIMPLE_PHI
- && stmt_has_scalar_dependences_outside_loop (loop, stmt))
+  if (stmt_has_scalar_dependences_outside_loop (loop, stmt))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "not generating builtin, partition has "

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

Hi

a bunch of minor comments, first:
1- What happens with make check-debug? I suppose the debug-mode checks 
trigger before the check in normal code, and the testcase doesn't pass. 
Maybe for this kind of work you need a // { dg-require-normal-mode "" }
2- Something sound weird with debug-mode which doesn't throw, just 
errors out, and the new check in normal-mode which throws. If there are 
other reasons to not throw, per Jakub's comment, I would support the idea.

2- Make sure to have the test variable in the testcases.
3- We definitely need a comment explaining *who* provided _M_range_check
4- Maybe I'm misremembering, sorry in case, but Isn't:

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0

the same as:

#if _FORTIFY_SOURCE > 0

?

Thanks,
Paolo.

Re: [RFC] Fix SRA with respect of BIT_FIELD_REF

[Martin Jambor]

Hi,

On Fri, Jun 01, 2012 at 11:31:20AM +0200, Richard Guenther wrote:
> On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
>  wrote:
> > Hi,
> >  When I modified GCC to change the majority of bitfield accesses
> > which were done via component ref to BIT_FIELD_REF, SRA messes up
> > because when it does the replacement it still tries to use the
> > BIT_FIELD_REF except it never places the old value in the struct for
> > the BIT_FIELD_REF to work correctly.
> >
> > This patch fixes the problem by expanding what BIT_FIELD_REF does
> > internally for both writing and reading.  Note we can't use
> > BIT_FIELD_REF directly on the left hand since we don't support partial
> > writes yet (except for vector and complex types).
> >
> > This is only a RFC since I don't know a way to reproduce this bug on
> > the trunk. I tested it on x86_64-linux-gnu with no regressions.
> 
> I'd rather disqualify SRA of BIT_FIELD_REFs on the LHS for now.  My goal
> was to enable SRA of bitfields using the DECL_BIT_FIELD_REPRESENTATIVE
> work - something you go against with replacing them with BIT_FIELD_REFs.

SRA of bit-fields works now, it is just rather simple and can't
optimize the bit-field accesses as we probably should.  Therefore I am
all for using DECL_BIT_FIELD_REPRESENTATIVEs and looked at those
patches with interest, I'm just wondering why we'd want to do it for
non-addressable structures only, which is something SRA would imply if
this "lowering" was part of it.

BIT_FIELD_REFs of non-vectors on the LHS are not much tested, I'm
afraid. I it is quite possible it does not do the right thing.
Nevertheless, making regions accessed through them unscalarizable
might also be an option, if it does not induce significant penalties
anywhere.

Thanks,

Martin

> 
> You'd replace
> 
>   x = a.b;
> 
> with
> 
>   tem = a.;
>   x = BIT_FIELD_REF ;
> 
> and for stores with a read-modify-write sequence, possibly adding
> the bitfield-insert tree I proposed some time ago.  Replace
> 
>  a.b = x;
> 
> with
> 
>  tem = a.
>  tem = BIT_FIELD_EXPR ;
>  a. = tem;
> 
> and I'd do this replacement in SRA for now whenever it would decide to
> SRA a bitfield.
> 
> Richard.
> 
> > Thanks,
> > Andrew Pinski
> >
> > ChangeLog:
> > * tree-sra.c (sra_modify_expr): Handle BIT_FIELD_REF specially if we
> > are doing a replacement of the struct with one variable.

RE: [Patch, ARM][0/8] Epilogue in RTL: introduction (Sameera's patches, Part I)

[Greta Yorsh]

On 31 May 2012 19:18, Paul Brook wrote:
> > Testing:
> > * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp
> and
> > tested in three configuration: -marm (default), -mthumb, -mapcs-
> frame. No
> > regression on qemu.
> > * Crossbuild for target arm-none-eabi thumb2 with cpu cortex-m3. No
> > regression on qemu.
> > * Crossbuild for target arm-none-eabi thumb1 with cpu arm7tdmi and
> > arm1136jf-s. No regression on qemu.
> > * Crossbuild for target arm-linux-gnueabi with cpu cortex-a9 with
> eglibc
> > and used this compiler to build AEL linux kernel. It boots
> successfully. *
> > Bootstrap the compiler on cortex-a8 successfully for
> > --languages=c,c++,fortran and used this compiler to build gdb. No
> > regression with check-gcc and check-gdb.
> 
> What other testing have you done?  Thate's a good number of
> combinations not
> covered by your above list.  In particular:
> - Coverage of old cores looks pretty thin.  In particular ARMv4t has
> different
> interworking requirements.

I ran a full regression test of gcc configured with cpu arm7tdmi on qemu. Is
there another ARMv4t configuration that should be tested?

> - iWMMXT has special alignment requirements.
> - Interrupt functions with special prologue/epilogue.  Both traditional
> ARM
> and Cortex-M3.

A few tests for interrupt functions are included in gcc's regression suite.
Specifically, the test gcc.target/arm/handler-align.c checks that the stack
pointer is handled correctly in prologue/epilogue of Cortex-M interrupt
handlers. I have a patch (not yet posted) to make this test more effective. 

> - -mtpcs-frame and -mtpcs-leaf-frame
> 
> Some of these options are orthogonal.
> 
> As you've proved with -mapcs-frame it's near impossible to get these
> right
> without actually testing them.I'm not saying you have to do a full
> testrun
> in every combination, but it's worth testing a representative selection
> of
> functions (large and small frame, leaf or not, with and without frame
> pointer,
> uses alloca, etc).  
> Also worth explicitly clobbering a selection (both
> odd and
> even numbers) of callee saved registers to make sure we get that right.
> Any
> difference in the output should be manually verified (ideally the
> assembly
> output would be identical).

For interrupt-related tests, interworking, and several other tests, I've
compared the assembly outputs before and after the patch (and caught a
couple of bugs this way).
In most cases now, the assembly outputs before and after the patch are
identical. The few differences I have seen are due to successful compiler
optimizations, where we benefit from having generated epilogues in RTL. For
example, replacing "sub sp, fp, #0" with "mov sp, fp" in epilogue. Also,
explicit write to callee-saved registers to restore them in epilgoue allows
the data flow analysis pass to deduce that registers are dead and enables
peephole optimizations that were not possible before. 

> 
> > * The patches have not been explicitly tested with any FPA variants
> (which
> > are deprecated in 4.7 and expected to become obsolete in 4.8).
> 
> I'm not keen on breaking these without actually removing them.

Thanks for pointing out additional configurations to test. I will test
-mtpcs-frame and -mtpcs-leaf-frame as you suggested and run regression tests
for iWMMXT. 

Properly testing FPA variants at this point is a lot of work, especially
considering the fact that these variants are obsolete. What minimal
configurations would be sufficient to test?

Thank you,
Greta

Re: [C++] Reject variably modified types in operator new

[Florian Weimer]

On 06/01/2012 11:00 AM, Florian Weimer wrote:


I'll try to warn about this case and make the transformation to the
proper operator new[] call.


Here's the version.  I've added a warning for the ill-formed code.

The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C, 
specifically (b is not a constant):


  int (*x)[b] = new int[a][b];  // { dg-error "not usable" }

The new warning I've added fires on this line, too.  How can I check for 
the pending error and suppress the warning?


2012-06-01  Florian Weimer  

* init.c (build_new): Reject variably modified types.

2012-06-01  Florian Weimer  

* g++.dg/init/new35.C: New.
* g++.dg/init/new36.C: New.
* g++.dg/ext/vla5.C: New warning.
* g++.dg/ext/vla8.C: New warning.

--
Florian Weimer / Red Hat Product Security Team
Index: gcc/testsuite/g++.dg/ext/vla5.C
===
--- gcc/testsuite/g++.dg/ext/vla5.C	(revision 188104)
+++ gcc/testsuite/g++.dg/ext/vla5.C	(working copy)
@@ -6,5 +6,5 @@
 void
 test (int a)
 {
-  new (char[a]);
+  new (char[a]); // { dg-warning "variable array length" }
 }
Index: gcc/testsuite/g++.dg/ext/vla8.C
===
--- gcc/testsuite/g++.dg/ext/vla8.C	(revision 188104)
+++ gcc/testsuite/g++.dg/ext/vla8.C	(working copy)
@@ -8,7 +8,7 @@
 
   AvlTreeIter()
   {
-new (void* [Num()]);
+new (void* [Num()]); // { dg-warning "variable array length" }
   }
 };
 
Index: gcc/testsuite/g++.dg/init/new35.C
===
--- gcc/testsuite/g++.dg/init/new35.C	(revision 0)
+++ gcc/testsuite/g++.dg/init/new35.C	(revision 0)
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-Wno-vla" }
+
+int
+main (int argc, char **argv)
+{
+  typedef char A[argc];
+  new A;
+  new A[0]; // { dg-error "variably modified" }
+  new A[5]; // { dg-error "variably modified" }
+  new (A[0]); // { dg-error "variably modified" }
+  new (A[5]); // { dg-error "variably modified" }
+}
Index: gcc/testsuite/g++.dg/init/new36.C
===
--- gcc/testsuite/g++.dg/init/new36.C	(revision 0)
+++ gcc/testsuite/g++.dg/init/new36.C	(revision 0)
@@ -0,0 +1,153 @@
+// Testcase for invocation of constructors/destructors in operator new[].
+// { dg-do run }
+
+#include 
+
+struct E {
+  virtual ~E() { }
+};
+
+struct S {
+  S();
+  ~S();
+};
+
+static int count;
+static int max;
+static int throwAfter = -1;
+static S *pS;
+
+S::S()
+{
+  if (throwAfter >= 0 && count >= throwAfter)
+throw E();
+  if (pS)
+{
+  ++pS;
+  if (this != pS)
+	abort();
+}
+  else
+pS = this;
+  ++count;
+  max = count;
+}
+
+S::~S()
+{
+  if (count > 1)
+{
+  if (this != pS)
+	abort();
+  --pS;
+}
+  else
+pS = 0;
+  --count;
+}
+
+void __attribute__((noinline)) doit(int n)
+{
+  {
+S *s = new S[n];
+if (count != n)
+  abort();
+if (pS != s + n - 1)
+  abort();
+delete [] s;
+if (count != 0)
+  abort();
+  }
+  throwAfter = 2;
+  max = 0;
+  try
+{
+  new S[n];
+  abort();
+}
+  catch (E)
+{
+  if (max != 2)
+	abort();
+}
+  throwAfter = -1;
+}
+
+int main()
+{
+  {
+S s;
+if (count != 1)
+  abort();
+if (pS != &s)
+  abort();
+  }
+  if (count != 0)
+abort();
+  {
+S *s = new S;
+if (count != 1)
+  abort();
+if (pS != s)
+  abort();
+delete s;
+if (count != 0)
+  abort();
+  }
+  {
+S *s = new S[1];
+if (count != 1)
+  abort();
+if (pS != s)
+  abort();
+delete [] s;
+if (count != 0)
+  abort();
+  }
+  {
+S *s = new S[5];
+if (count != 5)
+  abort();
+if (pS != s + 4)
+  abort();
+delete [] s;
+if (count != 0)
+  abort();
+  }
+  typedef S A[5];
+  {
+S *s = new A;
+if (count != 5)
+  abort();
+if (pS != s + 4)
+  abort();
+delete [] s;
+if (count != 0)
+  abort();
+  }
+  throwAfter = 2;
+  max = 0;
+  try
+{
+  new S[5];
+  abort();
+}
+  catch (E)
+{
+  if (max != 2)
+	abort();
+}
+  max = 0;
+  try
+{
+  new A;
+  abort();
+}
+  catch (E)
+{
+  if (max != 2)
+	abort();
+}
+  throwAfter = -1;
+  doit(5);
+}
Index: gcc/cp/init.c
===
--- gcc/cp/init.c	(revision 188104)
+++ gcc/cp/init.c	(working copy)
@@ -2805,6 +2805,34 @@
   make_args_non_dependent (*init);
 }
 
+  /* If the type is variably modified (a GNU extension for C
+ compatibility), we could end up with a variable-times-variable
+ multiplication at run time, complicating overflow checking.  */
+  if (variably_modified_type_p (type, NULL_TREE))
+{
+  /* Try to transform new (T[n]) to new T[n], and accept the
+	 result if T is not variably modified. */
+  bool good = false;
+  if (nelt

[C++ Patch] PR 26155 (improved patch)

[Paolo Carlini]

Hi,

this is my last and best try ;) Seriously, compared to the last posted 
version:
1- I added a rather large comment explaining what's going on wrt error 
recovery.
2- Took the occasion to clean-up a bit the code about bool vs int for 
flags (we had a mix).
3- Cleaned-up a bit the code itself (didn't notice that need_new is 
initialized as true)


Tested x86_64-linux, as usual.

Thanks,
Paolo.




/cp
2012-06-01  Paolo Carlini  

PR c++/26155
* name-lookup.c (push_namespace): When error recovery is
impossible just error out in duplicate_decls.

/testsuite
2012-06-01  Paolo Carlini  

PR c++/26155
* g++.dg/parse/namespace-alias-1.C: New.

Index: testsuite/g++.dg/parse/namespace-alias-1.C
===
--- testsuite/g++.dg/parse/namespace-alias-1.C  (revision 0)
+++ testsuite/g++.dg/parse/namespace-alias-1.C  (revision 0)
@@ -0,0 +1,7 @@
+// PR c++/26155
+
+namespace N
+{
+  namespace M = N;  // { dg-error "previous declaration" }
+  namespace M {}// { dg-error "declaration of namespace" }
+}
Index: cp/name-lookup.c
===
--- cp/name-lookup.c(revision 188104)
+++ cp/name-lookup.c(working copy)
@@ -3518,8 +3518,8 @@ void
 push_namespace (tree name)
 {
   tree d = NULL_TREE;
-  int need_new = 1;
-  int implicit_use = 0;
+  bool need_new = true;
+  bool implicit_use = false;
   bool anon = !name;
 
   bool subtime = timevar_cond_start (TV_NAME_LOOKUP);
@@ -3535,8 +3535,8 @@ push_namespace (tree name)
   d = IDENTIFIER_NAMESPACE_VALUE (name);
   if (d)
/* Reopening anonymous namespace.  */
-   need_new = 0;
-  implicit_use = 1;
+   need_new = false;
+  implicit_use = true;
 }
   else
 {
@@ -3544,13 +3544,36 @@ push_namespace (tree name)
   d = IDENTIFIER_NAMESPACE_VALUE (name);
   if (d != NULL_TREE && TREE_CODE (d) == NAMESPACE_DECL)
{
- need_new = 0;
- if (DECL_NAMESPACE_ALIAS (d))
-   {
- error ("namespace alias %qD not allowed here, assuming %qD",
-d, DECL_NAMESPACE_ALIAS (d));
- d = DECL_NAMESPACE_ALIAS (d);
+ tree dna = DECL_NAMESPACE_ALIAS (d);
+ if (dna)
+   {
+ /* We do some error recovery for, eg, the redeclaration
+of M here:
+
+namespace N {}
+namespace M = N;
+namespace M {}
+
+However, in nasty cases like:
+
+namespace N
+{
+  namespace M = N;
+  namespace M {}
+}
+
+we just error out below, in duplicate_decls.  */
+ if (NAMESPACE_LEVEL (dna)->level_chain
+ == current_binding_level)
+   {
+ error ("namespace alias %qD not allowed here, "
+"assuming %qD", d, dna);
+ d = dna;
+ need_new = false;
+   }
}
+ else
+   need_new = false;
}
 }
 

Re: _FORTIFY_SOURCE for std::vector

[Florian Weimer]

On 06/01/2012 01:42 PM, Paolo Carlini wrote:

Hi

a bunch of minor comments, first:
1- What happens with make check-debug? I suppose the debug-mode checks
trigger before the check in normal code, and the testcase doesn't pass.
Maybe for this kind of work you need a // { dg-require-normal-mode "" }


I'm now running "make check-debug", didn't know about it.


2- Something sound weird with debug-mode which doesn't throw, just
errors out, and the new check in normal-mode which throws. If there are
other reasons to not throw, per Jakub's comment, I would support the idea.


Yes, that's true.


2- Make sure to have the test variable in the testcases.


I've seen the variable, but I don't understand how to use it.  I would 
like to add something about it to the testing documentation.



3- We definitely need a comment explaining *who* provided _M_range_check


Sorry, I don't understand this suggestion.


4- Maybe I'm misremembering, sorry in case, but Isn't:

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0

the same as:

#if _FORTIFY_SOURCE > 0

?


I think you're right, but I'm just copying literally what GNU libc is 
doing.  I can change it to the shorter version if you want me to.



--
Florian Weimer / Red Hat Product Security Team

Re: [C++] Reject variably modified types in operator new

[Alexander Monakov]

As someone who wrote code that does such allocations, I'm surprised that this
is a GNU extension, and is rejected even by the C++11 standard.  How is one
supposed to perform allocations of two-dimensional arrays when inner dimension
is given as function argument?

I'm relatively inexperienced, but let me disagree about the assessment of this
feature as "obscure".  I would expect that some existing programs that
perform, say, CFD calculations on two- or three-dimensional regular grids,
or, better yet, do image processing, would allocate grid data in exactly that
manner, and would be broken by this change:

void foo(int gridSizeH, int gridSizeV)
{
  typedef double gridRow[gridSizeH];
  
  gridRow *grid = new gridRow[gridSizeV];

  ...
}

Therefore I suggest a deprecation period with -fpermissive.

Thanks.

Alexander

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

Hi,

On 06/01/2012 02:53 PM, Florian Weimer wrote:
I've seen the variable, but I don't understand how to use it.  I would 
like to add something about it to the testing documentation.
Just copy what *all* the other testcase in the library testsuite have, 
just define it, with attribute unused. If you are curious why, just look 
inside testsuite_hooks.h

3- We definitely need a comment explaining *who* provided _M_range_check

Sorry, I don't understand this suggestion.
You are right, sorry, I went through your changes too quickly and didn't 
realize that you are just using the existing _M_range_check. Anyway, I 
confirm that probably we want something more consistent with debug-mode, 
thus not throwing in this case. Maybe just a __builtin_abort(), I don't 
know. Or adjust the code in c++config to make available a non-trivial 
__glibcxx_assert also when _FORTIFY_SOURCE > 0.



4- Maybe I'm misremembering, sorry in case, but Isn't:

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0

the same as:

#if _FORTIFY_SOURCE > 0

?


I think you're right, but I'm just copying literally what GNU libc is 
doing.  I can change it to the shorter version if you want me to.

I think we should yes.

Paolo.

Re: [SH] PR 53512 - Allow fsca and fsrra for non-SH4A

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch addresses PR 53512.
> Tested with
> make all-gcc
> make info dvi pdf
> 
> Previous default behavior for SH4A:
> make check-gcc RUNTESTFLAGS="sh.exp=sh4a-sincosf*
> --target_board=sh-sim/-m4a-single/-ml"
> 
>  check-gcc RUNTESTFLAGS="sh.exp=sh4a-fsrra*
> --target_board=sh-sim/-m4a-single/-ml"
> 
> New behavior:
> make check-gcc RUNTESTFLAGS="sh.exp=pr53512-* --target_board=sh-sim
> \{-m4a-single/-ml,-m2/-ml,-m2a/-mb,-m2e/-ml,-m4a/-ml,-m4a-single/-ml,-m4a-single-only/-ml,-m4a-nofpu/-ml}"
> 
> OK for 4.8?

I see a new failure

  FAIL: gcc.target/sh/pr53512-1.c scan-assembler fsca

on sh4-unknown-linux-gnu with the patch.  Looks that the test
fails due to TARGET_HAS_SINCOS which is defined on linux targets.
It seems that we need a sincossf3 expander for this test on
TARGET_HAS_SINCOS targets.

Regards,
kaz

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 03:09 PM, Paolo Carlini wrote:
You are right, sorry, I went through your changes too quickly and 
didn't realize that you are just using the existing _M_range_check. 
Anyway, I confirm that probably we want something more consistent with 
debug-mode, thus not throwing in this case. Maybe just a 
__builtin_abort(), I don't know. Or adjust the code in c++config to 
make available a non-trivial __glibcxx_assert also when 
_FORTIFY_SOURCE > 0.
Then, if you do this, you probably don't need a new 
_M_fortify_range_check function.


Paolo.

Re: _FORTIFY_SOURCE for std::vector

[Pedro Alves]

On 06/01/2012 02:09 PM, Paolo Carlini wrote:

>>> 4- Maybe I'm misremembering, sorry in case, but Isn't:
>>>
>>> #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
>>>
>>> the same as:
>>>
>>> #if _FORTIFY_SOURCE > 0
>>>
>>> ?
>>
>> I think you're right, but I'm just copying literally what GNU libc is doing. 
>>  I can change it to the shorter version if you want me to.
> I think we should yes.


The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not 
defined.

-- 
Pedro Alves

[PATCH][AARCH64][libgcc] Remove t-softfp-sfdf and t-softfp-excl from aarch64 configuration

[Jim MacArthur]

In response to a comment from  
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01721.html, this patch removes 
t-softfp-sfdf and t-softfp-excl from the aarch64 entries in libgcc/config.host. 
Every setting in these files is overridden by t-softfp.

Addition to libgcc/ChangeLog:

2012-06-01  Jim MacArthur

* config.host (aarch64*-*-elf): Remove references to t-softfp-sfdf and
t-softfp-excl.
(aarch64*-*-linux*): Likewise.

diff --git a/libgcc/config.host b/libgcc/config.host
index 56beddd..0b80afd 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -291,12 +291,10 @@ case ${host} in
;;
 aarch64*-*-elf)
extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
-   tmake_file="${tmake_file} t-softfp-sfdf t-softfp-excl"
tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp"
;;
 aarch64*-*-linux*)
md_unwind_header=aarch64/linux-unwind.h
-   tmake_file="${tmake_file} t-softfp-sfdf t-softfp-excl"
tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp"
tmake_file="${tmake_file} ${cpu_type}/t-linux"
;;

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 03:09:19PM +0200, Paolo Carlini wrote:
> On 06/01/2012 02:53 PM, Florian Weimer wrote:
> >I've seen the variable, but I don't understand how to use it.  I
> >would like to add something about it to the testing documentation.
> Just copy what *all* the other testcase in the library testsuite
> have, just define it, with attribute unused. If you are curious why,
> just look inside testsuite_hooks.h
> >3- We definitely need a comment explaining *who* provided _M_range_check
> >
> >Sorry, I don't understand this suggestion.
> You are right, sorry, I went through your changes too quickly and
> didn't realize that you are just using the existing _M_range_check.
> Anyway, I confirm that probably we want something more consistent
> with debug-mode, thus not throwing in this case. Maybe just a
> __builtin_abort(), I don't know. Or adjust the code in c++config to
> make available a non-trivial __glibcxx_assert also when
> _FORTIFY_SOURCE > 0.

The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function.  You'd need to use
#if __USE_FORTIFY_LEVEL > 0
test instead (as __chk_fail is only provided by glibcs that on
_FORTIFY_SOURCE definition sets __USE_FORTIFY_LEVEL), but it would be
consistent with all other fortification failures (and, even
-fstack-protector failures are similar).

Or of course if you want it to do something else on failures, better
enable it using a different macro.

Jakub

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 03:22 PM, Pedro Alves wrote:
The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is 
not defined. 

Interesting, but does it happen in system headers too?

Paolo.

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO if 
this is presented as _FORTIFY_SOURCE check, it should call that and 
not some other function.
I understand. I don't know much about -D_FORTIFY_SOURCE, honestly. I 
hope the diagnostics provided by __chk_fail is good enough. And well, 
then we really do have to explain in a comment where __chk_fail is 
coming from ;)


Paolo.

Re: [PATCH] Atom: Scheduler improvements for better imul placement

[H.J. Lu]

On Tue, May 29, 2012 at 12:01 PM, Igor Zamyatin  wrote:
> Hi, Uros!
>
> Sorry, I didn't realize that patch was missed. I attached new version.
>
> Changelog:
>
> 2012-05-29  Yuri Rumyantsev  
>
>       * config/i386/i386.c (x86_sched_reorder): New function.
>       Added new function x86_sched_reorder.
>
> As for multiply modes, currently we handled most frequent case for
> Atom and in the future this could be enhanced.
>

This may have caused:

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

-- 
H.J.

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:
> On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
> >if this is presented as _FORTIFY_SOURCE check, it should call that
> >and not some other function.
> I understand. I don't know much about -D_FORTIFY_SOURCE, honestly. I
> hope the diagnostics provided by __chk_fail is good enough. And
> well, then we really do have to explain in a comment where
> __chk_fail is coming from ;)

The default error output is like:
*** buffer overflow detected ***: /tmp/a terminated
=== Backtrace: =
/lib64/libc.so.6(__fortify_fail+0x37)[0x388e3097e7]
/lib64/libc.so.6[0x388e3079a0]
/tmp/a[0x40050a]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x388e221735]
/tmp/a[0x400419]
=== Memory map: 
0040-00401000 r-xp  08:02 147893 /tmp/a
0060-00601000 rw-p  08:02 147893 /tmp/a
01b63000-01b84000 rw-p  00:00 0  [heap]
388de0-388de2 r-xp  08:02 1201564
/usr/lib64/ld-2.15.so
388e01f000-388e02 r--p 0001f000 08:02 1201564
/usr/lib64/ld-2.15.so
388e02-388e021000 rw-p 0002 08:02 1201564
/usr/lib64/ld-2.15.so
388e021000-388e022000 rw-p  00:00 0 
388e20-388e3ac000 r-xp  08:02 1201757
/usr/lib64/libc-2.15.so
388e3ac000-388e5ac000 ---p 001ac000 08:02 1201757
/usr/lib64/libc-2.15.so
388e5ac000-388e5b r--p 001ac000 08:02 1201757
/usr/lib64/libc-2.15.so
388e5b-388e5b2000 rw-p 001b 08:02 1201757
/usr/lib64/libc-2.15.so
388e5b2000-388e5b7000 rw-p  00:00 0 
389120-3891215000 r-xp  08:02 1201763
/usr/lib64/libgcc_s-4.7.0-20120507.so.1
3891215000-3891414000 ---p 00015000 08:02 1201763
/usr/lib64/libgcc_s-4.7.0-20120507.so.1
3891414000-3891415000 rw-p 00014000 08:02 1201763
/usr/lib64/libgcc_s-4.7.0-20120507.so.1
7feee518f000-7feee5192000 rw-p  00:00 0 
7feee51a5000-7feee51a7000 rw-p  00:00 0 
7fff27a66000-7fff27a87000 rw-p  00:00 0  [stack]
7fff27bff000-7fff27c0 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0  
[vsyscall]
Aborted (core dumped)

Jakub

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

Hi,

On 06/01/2012 03:49 PM, Jakub Jelinek wrote:

On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:

On 06/01/2012 03:34 PM, Jakub Jelinek wrote:

The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function.

I understand. I don't know much about -D_FORTIFY_SOURCE, honestly. I
hope the diagnostics provided by __chk_fail is good enough. And
well, then we really do have to explain in a comment where
__chk_fail is coming from ;)

The default error output is like:
I understand it's some sort of "standard" thus certainly I'm not going 
to insist, but I would like to see more clearly displayed the line 
number of the library assertion failing, see what I mean?


Thanks,
Paolo.

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 03:52:24PM +0200, Paolo Carlini wrote:
> On 06/01/2012 03:49 PM, Jakub Jelinek wrote:
> >On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:
> >>On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >>>The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
> >>>if this is presented as _FORTIFY_SOURCE check, it should call that
> >>>and not some other function.
> >>I understand. I don't know much about -D_FORTIFY_SOURCE, honestly. I
> >>hope the diagnostics provided by __chk_fail is good enough. And
> >>well, then we really do have to explain in a comment where
> >>__chk_fail is coming from ;)
> >The default error output is like:
> I understand it's some sort of "standard" thus certainly I'm not
> going to insist, but I would like to see more clearly displayed the
> line number of the library assertion failing, see what I mean?

Well, you have the core file often (unless disabled), or could use
addr2line to decode the addresses.  The point is that the fortification
checks must be very lightweight (so that people can enable them by default
for everything), and e.g. storing __LINE__ and __FILE__
everywhere where operator[] is used would be too expensive (grow .rodata too
much).

Jakub

Re: _FORTIFY_SOURCE for std::vector

[Pedro Alves]

On 06/01/2012 02:36 PM, Paolo Carlini wrote:

> On 06/01/2012 03:22 PM, Pedro Alves wrote:
>> The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not 
>> defined. 
> Interesting, but does it happen in system headers too?


Good point.  I just tried and it doesn't.

-- 
Pedro Alves

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 03:11:51PM +0100, Pedro Alves wrote:
> On 06/01/2012 02:36 PM, Paolo Carlini wrote:
> 
> > On 06/01/2012 03:22 PM, Pedro Alves wrote:
> >> The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not 
> >> defined. 
> > Interesting, but does it happen in system headers too?
> 
> 
> Good point.  I just tried and it doesn't.

But with -Wsystem-headers it does again.  It doesn't hurt to add that
defined ... && check to quiet it up.

Jakub

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 04:04 PM, Jakub Jelinek wrote:
Well, you have the core file often (unless disabled), or could use 
addr2line to decode the addresses. The point is that the fortification 
checks must be very lightweight (so that people can enable them by 
default for everything), and e.g. storing __LINE__ and __FILE__ 
everywhere where operator[] is used would be too expensive (grow 
.rodata too much).
I see. Then, I'm coming to the conclusion that if we start deploying 
such lightweight checks in the normal-mode library we should document 
the thing in the library documentation, under "debugging". Just a few 
sentences explaining what you and Florian just clarified, vs debug-mode too.


Paolo.

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 04:13 PM, Jakub Jelinek wrote:

On Fri, Jun 01, 2012 at 03:11:51PM +0100, Pedro Alves wrote:

On 06/01/2012 02:36 PM, Paolo Carlini wrote:


On 06/01/2012 03:22 PM, Pedro Alves wrote:

The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not 
defined.

Interesting, but does it happen in system headers too?


Good point.  I just tried and it doesn't.

But with -Wsystem-headers it does again.

... together with another TON of warnings everywhere, yes ;)

Paolo.

[lra] hard reg splitting

[Vladimir Makarov]

  Register-pressure sensitive scheduling decreased greatly probability 
of a long standing bug when 1st insn scheduling may result in reload 
pass failure of finding a hard reg for a reload.  Still the bug is present.


  The following patch adds hard-reg splitting to LRA which should 
finally solve the bug (or course if LRA is used instead of reload).  I 
hope the patch can also improve the code for some targets on which 1st 
insn scheduling is used and ABI requires hard regs usage for parameter 
passing.


  The patch was successfully bootstrapped on x86-64.

  Committed as rev. 188109.

2012-06-01  Vladimir Makarov 

* lra-constraints.c (struct usage_insns): Use registers instead
pseudos in comments about splitting.
(check_only_pseudos): Rename to check_only_regs.
(need_for_call_save_p): Assert that argument is a pseudo regno.
(need_for_split_p): Process hard reg too.
(split_pseudo): Rename to split_reg, process hard reg too.
(live_pseudos): Rename to live_regs.
(inherit_in_ebb): Process hard regs too for splitting.
(get_pseudo_regno): Rename to get_regno.  Process hard reg too.
(remove_inheritance_pseudos): Process hard regs too.
(lra_undo_inheritance): Ditto.


Index: lra-constraints.c
===
--- lra-constraints.c	(revision 188108)
+++ lra-constraints.c	(working copy)
@@ -3654,15 +3654,15 @@ static int calls_num;
USAGE_INSNS.  */
 static int curr_usage_insns_check;
 
-/* Info about last usage of pseudos in EBB to do inheritance/split
+/* Info about last usage of registers in EBB to do inheritance/split
transformation.  Inheritance transformation is done from a spilled
-   pseudo and split transformations from a pseudo to assigned to a
-   hard register.  */
+   pseudo and split transformations from a hard register or a pseudo
+   assigned to a hard register.  */
 struct usage_insns
 {
   /* If the value is equal to the above variable value, then the INSNS
  is valid.  The insns is chain of optional debug insns and a
- finishing non-debug insn using the corresponding pseudo.  */
+ finishing non-debug insn using the corresponding reg.  */
   int check;
   /* Value of global reloads_num at the corresponding next insns.  */
   int reloads_num;
@@ -3671,12 +3671,11 @@ struct usage_insns
   /* It can be true only for splitting.  And it means that the restore
  insn should be put after insn give by the following member.  */
   bool after_p;
-  /* Next insns in the current EBB which use the original pseudo and
- the original pseudo value is not changed between the current insn
- and the next insns.  In order words, if we need to use the
- original pseudo value again in the next insns we can try to use
- the value in a hard register from a reload insn of the current
- insn.  */
+  /* Next insns in the current EBB which use the original reg and the
+ original reg value is not changed between the current insn and
+ the next insns.  In order words, if we need to use the original
+ reg value again in the next insns we can try to use the value in
+ a hard register from a reload insn of the current insn.  */
   rtx insns;
 };
 
@@ -3723,9 +3722,9 @@ substitute_pseudo (rtx *loc, int old_reg
   return result;
 }
 
-/* Pseudos involved in inheritance/split in the current EBB
-   (inheritance/split and original pseudos).  */
-static bitmap_head check_only_pseudos;
+/* Registers involved in inheritance/split in the current EBB
+   (inheritance/split pseudos and original registers).  */
+static bitmap_head check_only_regs;
 
 /* Do inheritance transformation for insn INSN defining (if DEF_P) or
using ORIGINAL_REGNO where the subsequent insn(s) in EBB (remember
@@ -3827,8 +3826,8 @@ inherit_reload_reg (bool def_p, bool uni
 fprintf (lra_dump_file, "Original reg change %d->%d:\n",
 	 original_regno, REGNO (new_reg));
   lra_reg_info[REGNO (new_reg)].restore_regno = original_regno;
-  bitmap_set_bit (&check_only_pseudos, REGNO (new_reg));
-  bitmap_set_bit (&check_only_pseudos, original_regno);
+  bitmap_set_bit (&check_only_regs, REGNO (new_reg));
+  bitmap_set_bit (&check_only_regs, original_regno);
   bitmap_set_bit (&lra_inheritance_pseudos, REGNO (new_reg));
   if (def_p)
 lra_process_new_insns (insn, NULL_RTX, new_insns,
@@ -3871,31 +3870,36 @@ inherit_reload_reg (bool def_p, bool uni
 static inline bool
 need_for_call_save_p (int regno)
 {
-  gcc_assert (reg_renumber[regno] >= 0);
+  gcc_assert (regno >= FIRST_PSEUDO_REGISTER && reg_renumber[regno] >= 0);
   return (usage_insns[regno].calls_num < calls_num
 	  && (lra_hard_reg_set_intersection_p
 	  (reg_renumber[regno], PSEUDO_REGNO_MODE (regno),
 	   call_used_reg_set)));
 }
 
-/* Return true if we need a split for pseudo REGNO which was assigned
-   to a hard register.  POTENTIAL_RELOAD_HARD_REGS contains hard
-   registers which mi

Re: _FORTIFY_SOURCE for std::vector

[Florian Weimer]

On 06/01/2012 03:34 PM, Jakub Jelinek wrote:

The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function.  You'd need to use
#if __USE_FORTIFY_LEVEL>  0
test instead (as __chk_fail is only provided by glibcs that on
_FORTIFY_SOURCE definition sets __USE_FORTIFY_LEVEL), but it would be
consistent with all other fortification failures (and, even
-fstack-protector failures are similar).


__chk_fail it is, then.  This means that the test case will be specific 
to GNU libc platforms.  How can I mark it as such?



Or of course if you want it to do something else on failures, better
enable it using a different macro.


I'm aiming for a consistent developer experience.

There is little documentation for _FORTIFY_SOURCE, and we plan to change 
that.  However, due to the way most additional checks are implemented 
(reliance upon __builtin_object_size in particular), it will always be 
magic you cannot rely on, which makes good documentation difficult.  But 
we should at least explain that!  (Obviously, the std::vector check 
doesn't share this problem.)


--
Florian Weimer / Red Hat Product Security Team

Re: _FORTIFY_SOURCE for std::vector

[Paolo Carlini]

On 06/01/2012 05:00 PM, Florian Weimer wrote:

On 06/01/2012 03:34 PM, Jakub Jelinek wrote:

The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function.  You'd need to use
#if __USE_FORTIFY_LEVEL>  0
test instead (as __chk_fail is only provided by glibcs that on
_FORTIFY_SOURCE definition sets __USE_FORTIFY_LEVEL), but it would be
consistent with all other fortification failures (and, even
-fstack-protector failures are similar).


__chk_fail it is, then.  This means that the test case will be 
specific to GNU libc platforms.  How can I mark it as such?
If nothing else comes to mind, you can always add a 
check_v3_target_glibc to libstdc++.exp and then a dg-require-glibc using 
it to dg-options.exp. Inside the former, just check that __GLIBC__ is 
defined, maybe with an appropriate value.


Then you can use

Paolo.

Re: _FORTIFY_SOURCE for std::vector

[Jakub Jelinek]

On Fri, Jun 01, 2012 at 05:00:58PM +0200, Florian Weimer wrote:
> On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
> >if this is presented as _FORTIFY_SOURCE check, it should call that
> >and not some other function.  You'd need to use
> >#if __USE_FORTIFY_LEVEL>  0
> >test instead (as __chk_fail is only provided by glibcs that on
> >_FORTIFY_SOURCE definition sets __USE_FORTIFY_LEVEL), but it would be
> >consistent with all other fortification failures (and, even
> >-fstack-protector failures are similar).
> 
> __chk_fail it is, then.  This means that the test case will be
> specific to GNU libc platforms.  How can I mark it as such?

{ target *-*-linux* } or so?

> >Or of course if you want it to do something else on failures, better
> >enable it using a different macro.
> 
> I'm aiming for a consistent developer experience.

For other platforms there is always libssp included with gcc, which can be
used instead (users then have to link -lssp if they compile with
-D_FORTIFY_SOURCE).

Note, __chk_fail () isn't prototyped in glibc headers, so you want
probably in the checking method declare it in some __gnu* namespace
as extern "C" __chk_fail () __attribute__((unused));
and then use.

Jakub

Re: [C++ Patch] PR 26155 (improved patch)

[Jason Merrill]

OK.

Jason

Re: [PR tree-optimization/52558]: RFC: questions on store data race

[Aldy Hernandez]

On 06/01/12 01:22, Tobias Burnus wrote:


gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^


Is this still the case with the code currently in mainline:

  return flag_tm && bb->flags & BB_IN_TRANSACTION;

??

Re: _FORTIFY_SOURCE for std::vector

[Florian Weimer]

On 06/01/2012 05:09 PM, Jakub Jelinek wrote:

__chk_fail it is, then.  This means that the test case will be
specific to GNU libc platforms.  How can I mark it as such?


{ target *-*-linux* } or so?


Wouldn't this match Bionic libc environments, too?


Note, __chk_fail () isn't prototyped in glibc headers, so you want
probably in the checking method declare it in some __gnu* namespace
as extern "C" __chk_fail () __attribute__((unused));
and then use.


Good point, thanks.  I'm asking the libc folks if we may use this symbol 
from libstdc++, just to be on the safe side.


--
Florian Weimer / Red Hat Product Security Team

Re: [PATCH] Fix PR53471, remove DECL_ASSEMBLER_NAME deferred compute

[Jason Merrill]

On 06/01/2012 05:22 AM, Richard Guenther wrote:

On Thu, 31 May 2012, Jason Merrill wrote:


The comment mentions PCH in connection with deferred seting of
DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that might be
connected with anonymous unions, which need to have different linkage names in
different translation units.


Not sure when PCH generation happens (or when we call
rest_of_type_compilation), but shouldn't that be way earlier than
the debug output?


PCH generation happens at the beginning of cp_write_global_declarations; 
rest_of_type_compilation, which triggers the debug output, is called 
after each class definition.



Anyway, any suggestion on how to tackle the issue
that we cannot compute new DECL_ASSEMBLER_NAMEs after the frontend
is finished?


Fix up the deferred_asm_name list somewhere between the call to 
c_common_write_pch and the call to free_lang_data.  I guess this would 
mean another debug hook for processing that needs to happen before 
free_lang_data.


Or fix free_lang_data to deal with these types, too.

Or use your first patch, and decide that we don't care about the linkage 
name of unreachable types.  What types are affected by this, anyway?


Jason

Re: [C++] Reject variably modified types in operator new

[Jason Merrill]

On 06/01/2012 08:09 AM, Florian Weimer wrote:

The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (b is not a constant):

   int (*x)[b] = new int[a][b];// { dg-error "not usable" }

The new warning I've added fires on this line, too.  How can I check for
the pending error and suppress the warning?


Warning only if the array is a typedef might do the trick.

Jason

Re: [C++] Reject variably modified types in operator new

[Florian Weimer]

On 06/01/2012 05:37 PM, Jason Merrill wrote:

On 06/01/2012 08:09 AM, Florian Weimer wrote:

The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (b is not a constant):

int (*x)[b] = new int[a][b]; // { dg-error "not usable" }

The new warning I've added fires on this line, too. How can I check for
the pending error and suppress the warning?


Warning only if the array is a typedef might do the trick.


I'm afraid not.  We really want to warn for

  new (char[n])

as well.

I'm puzzled why build_new is even invoked after detecting that there is 
a non-constant expression.



--
Florian Weimer / Red Hat Product Security Team

Re: sparc build broken...

[Rainer Orth]

Steven Bosscher  writes:

> On Thu, May 31, 2012 at 11:15 PM, David Miller  wrote:
>>
>> Removing output.h from reload1.c broke the sparc build because
>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>> reload1.c) references current_function_is_leaf.
>
> I was afraid of some fall-out. This is why target macros must die...
>
> Could you please give the attached patch a try?

It currently fails like this:

/vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:4557:1: error: unused 
parameter 'from' [-Werror=unused-parameter]
 sparc_initial_elimination_offset (int from, int to)
 ^

I've just restarted the build with from marked unused.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PR tree-optimization/52558]: RFC: questions on store data race

[Aldy Hernandez]

On 06/01/12 10:11, Aldy Hernandez wrote:

On 06/01/12 01:22, Tobias Burnus wrote:


gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^


Is this still the case with the code currently in mainline:

return flag_tm && bb->flags & BB_IN_TRANSACTION;

??


Whoops, I forgot to commit that last patch.  Check now.

Re: [C++] Reject variably modified types in operator new

[Jason Merrill]

On 06/01/2012 11:40 AM, Florian Weimer wrote:

I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.


I'd accept a patch to change that.

Jason

restore "do {" mistakenly taken out in SUBSUBTARGET_OVERRIDE_OPTIONS for ppc-vxworks

[Olivier Hainque]

This fixes a glitch introduced by me with rev 187581.
Committing as obvious.

2012-07-01  Olivier Hainque  

* config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
the "do {" part of the do-while(0) loop.



vxoverride.diff
Description: Binary data

Re: [google] Add options to pattern match function name for hotness attributes

[Xinliang David Li]

On Fri, Jun 1, 2012 at 1:26 AM, Dehao Chen  wrote:
> Hi,
>
> This patch adds 4 flags to enable user to type in a list of name
> patterns. Compiler will match the function name with the given
> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
> attributes to function declaration. The static branch prediction
> checks if a basic block contains call to a annotated function, and set
> the branch probability accordingly.

This is generally useful for cases where shared library code exhibits
different behavior among the applications  (so that source annotation
is not applicable).

You need to explain more on the likely_cold|hot attribute and the
intuition behind it.

>
> Bootstrapped and passed gcc testsuites.
>
> Ok for google branches?
>
> Thanks,
> Dehao
>
> gcc/ChangeLog.google-4_6
> 2012-06-01  Dehao Chen  
>
>        * gcc/cgraph.c (cgraph_match_hotness_by_name): New function.
>        (cgraph_add_hotness_attribute): New function.
>        (cgraph_node): Add hotness attribute to function decl.
>        * gcc/opts.c (common_handle_option): Handle new options.
>        * gcc/predict.c (tree_bb_level_predictions): New prediction.
>        * gcc/predict.def (PRED_LIKELY_COLD_FUNCTION): New prediction.
>        * gcc/common.opt (flag_function_hot_list): New option.
>        (flag_function_cold_list): New option.
>        (flag_function_likely_hot_list): New option.
>        (flag_function_likely_cold_list): New option.
>
> Index: gcc/doc/invoke.texi
> ===
> --- gcc/doc/invoke.texi (revision 188050)
> +++ gcc/doc/invoke.texi (working copy)
> @@ -362,7 +362,9 @@
>  -fdelete-null-pointer-checks -fdse -fdevirtualize -fdse @gol
>  -fearly-inlining -fipa-sra -fexpensive-optimizations -ffast-math @gol
>  -ffinite-math-only -ffloat-store -fexcess-precision=@var{style} @gol
> --fforward-propagate -ffp-contract=@var{style} -ffunction-sections @gol
> +-fforward-propagate -ffp-contract=@var{style} @gol
> +-ffunction-cold-list -ffunction-hot-list -ffunction-likely-cold-list @gol
> +-ffunction-likely-hot-list -ffunction-sections @gol
>  -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity @gol
>  -fgcse-sm -fif-conversion -fif-conversion2 -findirect-inlining @gol
>  -finline-functions -finline-functions-called-once -finline-limit=@var{n} @gol
> @@ -8585,6 +8587,22 @@
>  specify this option and you may have problems with debugging if
>  you specify both this option and @option{-g}.
>
> +@item -ffunction-cold-list
> +@opindex ffunction-cold-list
> +List of function name patterns that will be applied "cold" attribute.
> +
> +@item -ffunction-hot-list
> +@opindex ffunction-hot-list
> +List of function name patterns that will be applied "hot" attribute.
> +
> +@item -ffunction-likely-cold-list
> +@opindex ffunction-likely-cold-list
> +List of function name patterns that will be applied "likely_cold" attribute.
> +
> +@item -ffunction-likely-hot-list
> +@opindex ffunction-likely-hot-list
> +List of function name patterns that will be applied "likely_hot" attribute.
> +
>  @item -fbranch-target-load-optimize
>  @opindex fbranch-target-load-optimize
>  Perform branch target register load optimization before prologue / epilogue
> Index: gcc/cgraph.c
> ===
> --- gcc/cgraph.c        (revision 188050)
> +++ gcc/cgraph.c        (working copy)
> @@ -520,6 +520,70 @@
>     }
>  }
>
> +typedef char *char_pointer;
> +DEF_VEC_P(char_pointer);
> +DEF_VEC_ALLOC_P(char_pointer,heap);
> +
> +/* Match FNDECL's name with PATTERNS. If matched, add HOTNESS attribute
> +   to FNDECL.
> +   name matches with pattern, iff one of the following conditions satisfy:
> +     1. strcmp (name, pattern) != 0


strcmp(name, pattern) == 0


> +     2. pattern[len - 1] = '*' && strncmp (name, pattern, len - 1) != 0  */
> +static bool

strncmp (name, pattern, len -1 ) == 0

> +cgraph_match_hotness_by_name (tree fndecl,
> +                             VEC(char_pointer, heap) *patterns,
> +                             const char *hotness)
> +{
> +  unsigned i;
> +  char_pointer n;
> +  const char *name = lang_hooks.decl_printable_name(fndecl, 0);
> +
> +  if (!name)
> +    return false;
> +
> +  FOR_EACH_VEC_ELT (char_pointer, patterns, i, n)
> +    {
> +      int len = strlen (n);
> +      if ((n[len - 1] == '*' && !strncmp (name, n, len - 1))
> +          || !strcmp (name, n))
> +        {
> +          decl_attributes (&fndecl, tree_cons (
> +              get_identifier (hotness), NULL, NULL), 0);
> +          return true;
> +        }
> +    }
> +  return false;
> +}
> +
> +/* Add hotness attributes to FNDECL.  */

Empty line after.

> +static void
> +cgraph_add_hotness_attribute (tree fndecl)
> +{
> +  if (lookup_attribute ("cold", DECL_ATTRIBUTES (fndecl))
> +      || lookup_attribute ("hot", DECL_ATTRIBUTES (fndecl))
> +      || lookup_attribute ("likely_cold", DECL_ATTRIBUTES (fndecl))
> +      || lookup_at

Re: [RFA] PowerPC e5500 and e6500 cores support

[Edmar]

Freescale would like to contribute these patches to gcc.

It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
description, and set proper default flags for the e5500 and e6500 cores.

Some Altivec extensions for e6500 will be submitted as a separate process.

The patch was regression tested for ppc64 target under these conditions:
--enable-checking --disable-decimal-float --enable-languages=all
svn revision number: 187734

We thank in advance for your time to review this patch.

Regards,
Edmar

2012-06-01  Edmar Wienskoski

* config/rs6000/e5500.md: New file.
* config/rs6000/e6500.md: New file.
* config/rs6000/rs6000.c (processor_costs): Add new costs for
e5500 and e6500.
(rs6000_option_override_internal): Altivec and Spe options not
allowed with e5500. Spe options not allowed with e6500. Increase
move inline limit for e5500 and e6500. Disable string instructions
for e5500 and e6500. Enable branch targets alignment for e5500 and
e6500. Initialize rs6000_cost for e5500 and e6500.
(rs6000_adjust_cost): Add extra scheduling cycles between compare
and brnach for e5500 and e6500.
(rs6000_issue_rate): Set issue rate for e5500 and e6500.
* config/rs6000/rs6000-cpus.def: Add cpu definitions for e5500 and
e6500.
* config/rs6000/rs6000.h (ASM_CPU_SPEC): Add e5500 and e6500.
* config/rs6000/rs6000.md (define_attr "cpu"): Add ppce5500 and
ppce6500.
Include e5500.md and e6500.md.
* config/rs6000/rs6000-opt.h (processor_type): Add
PROCESSOR_PPCE5500 and PROCESSOR_PPCE6500.
* config.gcc (cpu_is_64bit): Add new cores e5500, e6500.
(powerpc*-*-*): Add new cores e5500, e6500.
* doc/invoke.texi: (item -mcpu): Add e5500 and e6500 to list of cpus.


2012-06-01  Edmar Wienskoski

* gcc.dg/tree-ssa/vector-3.c: Adjust regular expression.


diff -ruN gcc-20120516-orig/gcc/config/rs6000/e5500.md gcc-20120516-new/gcc/config/rs6000/e5500.md
--- gcc-20120516-orig/gcc/config/rs6000/e5500.md	1969-12-31 18:00:00.0 -0600
+++ gcc-20120516-new/gcc/config/rs6000/e5500.md	2012-05-16 12:29:04.0 -0500
@@ -0,0 +1,176 @@
+;; Pipeline description for Freescale PowerPC e5500 core.
+;;   Copyright (C) 2012 Free Software Foundation, Inc.
+;;   Contributed by Edmar Wienskoski (ed...@freescale.com)
+;;
+;; 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
+;; .
+;;
+;; e5500 64-bit SFX(2), CFX, LSU, FPU, BU
+;; Max issue 3 insns/clock cycle (includes 1 branch)
+
+(define_automaton "e5500_most,e5500_long")
+(define_cpu_unit "e5500_decode_0,e5500_decode_1" "e5500_most")
+
+;; SFX.
+(define_cpu_unit "e5500_sfx_0,e5500_sfx_1" "e5500_most")
+
+;; CFX.
+(define_cpu_unit "e5500_cfx_stage0,e5500_cfx_stage1" "e5500_most")
+
+;; Non-pipelined division.
+(define_cpu_unit "e5500_cfx_div" "e5500_long")
+
+;; LSU.
+(define_cpu_unit "e5500_lsu" "e5500_most")
+
+;; FPU.
+(define_cpu_unit "e5500_fpu" "e5500_long")
+
+;; BU.
+(define_cpu_unit "e5500_bu" "e5500_most")
+
+;; The following units are used to make the automata deterministic.
+(define_cpu_unit "present_e5500_decode_0" "e5500_most")
+(define_cpu_unit "present_e5500_sfx_0" "e5500_most")
+(presence_set "present_e5500_decode_0" "e5500_decode_0")
+(presence_set "present_e5500_sfx_0" "e5500_sfx_0")
+
+;; Some useful abbreviations.
+(define_reservation "e5500_decode"
+"e5500_decode_0|e5500_decode_1+present_e5500_decode_0")
+(define_reservation "e5500_sfx"
+   "e5500_sfx_0|e5500_sfx_1+present_e5500_sfx_0")
+
+;; SFX.
+(define_insn_reservation "e5500_sfx" 1
+  (and (eq_attr "type" "integer,insert_word,insert_dword,delayed_compare,\
+	shift,cntlz,exts")
+   (eq_attr "cpu" "ppce5500"))
+  "e5500_decode,e5500_sfx")
+
+(define_insn_reservation "e5500_sfx2" 2
+  (and (eq_attr "type" "cmp,compare,fast_compare,trap")
+   (eq_attr "cpu" "ppce5500"))
+  "e5500_decode,e5500_sfx")
+
+(define_insn_reservation "e5500_delayed" 2
+  (and (eq_attr "type" "var_shift_rotate,var_delayed_compare")
+   (eq_attr "cpu" "ppce5500"))
+  "e5500_decode,e5500_sfx*2")
+
+(define_insn_reservation "e5500_two" 2
+  (and (eq_attr "type" "two")
+   (eq_attr "cpu" "ppce5500"))
+  "e5500_decode,e5500_decode+e5500_sfx,e5500_sfx")
+
+(define_insn_reservation "e5500_three" 3
+  (and (eq_attr "type" "three")

Fix typo in intrinsics/time_1.h

[rbmj]

Hi all,

In libgfortran/intrinsics/time_1.h:181, there is a typo that refers to 
user_usecs (should be user_usec).  This patch fixes it.  I don't have 
commit access, so someone please apply this for me.  It should be obvious.


Robert Mason


diff --git a/libgfortran/intrinsics/time_1.h b/libgfortran/intrinsics/time_1.h
index 98a20d2..920b175 100644
--- a/libgfortran/intrinsics/time_1.h
+++ b/libgfortran/intrinsics/time_1.h
@@ -178,7 +178,7 @@ gf_cputime (long *user_sec, long *user_usec, long *system_sec, long *system_usec
   struct timespec ts;
   int err = clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &ts);
   *user_sec = ts.tv_sec;
-  *user_usecs = ts.tv_nsec / 1000;
+  *user_usec = ts.tv_nsec / 1000;
   *system_sec = *system_usec = 0;
   return err;

Re: restore "do {" mistakenly taken out in SUBSUBTARGET_OVERRIDE_OPTIONS for ppc-vxworks

[Eric Botcazou]

> 2012-07-01  Olivier Hainque  
>
>   * config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
>   the "do {" part of the do-while(0) loop.

This is needed on the 4.7 branch as well.

-- 
Eric Botcazou

Re: [PATCH] Atom: Scheduler improvements for better imul placement

[Eric Botcazou]

> Sorry, I didn't realize that patch was missed. I attached new version.
>
> Changelog:
>
> 2012-05-29  Yuri Rumyantsev  
>
>* config/i386/i386.c (x86_sched_reorder): New function.
>Added new function x86_sched_reorder.

Reading it, you get the impression that the new function is unused.  Replace 
the second line with the description of the second hunk.

-- 
Eric Botcazou

Re: sparc build broken...

[David Miller]

From: Rainer Orth 
Date: Fri, 01 Jun 2012 18:01:45 +0200

> Steven Bosscher  writes:
> 
>> On Thu, May 31, 2012 at 11:15 PM, David Miller  wrote:
>>>
>>> Removing output.h from reload1.c broke the sparc build because
>>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>>> reload1.c) references current_function_is_leaf.
>>
>> I was afraid of some fall-out. This is why target macros must die...
>>
>> Could you please give the attached patch a try?
> 
> It currently fails like this:
> 
> /vol/gcc/src/hg/trunk/local/gcc/config/sparc/sparc.c:4557:1: error: unused 
> parameter 'from' [-Werror=unused-parameter]
>  sparc_initial_elimination_offset (int from, int to)
>  ^
> 
> I've just restarted the build with from marked unused.

I hit the same problem, but solved it by removing the
'from' parameter entirely.

Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)

[Sterling Augustine]

The enclosed patch updates the earlier patch to address all of the feedback I
have gotten regarding generating pubnames. It fixes the offset problem in
the pubtypes table; switches DW_AT_pubtypes to a flag and so on.

It also adds and documents a new option "-g[no-]pubtypes" which allows users
to generate pubtypes even if the target disables them by default.

Tested with bootstrap and running the test_pubnames_and_indices.py script
recently contributed to the GDB project.

OK for mainline?

Sterling

2012-05-10   Sterling Augustine  
Cary Coutant  

* gcc/dwarf2out.c (is_cu_die, is_namespace_die, is_class_die,
add_AT_pubnames, add_enumerator_pubname, want_pubnames): New functions.
(comdat_type_struct): New field 'skeleton_die'.
(breakout_comdat_types): Update it.
(add_pubname): Rework logic.  Call is_class_die, is_cu_die and
is_namespace_die.  Fix minor style violation.  Call want_pubnames.
(add_pubname_string): Call want_pubnames.
(add_pubtype): Rework logic for calculating type name.  Call
is_namespace_die.  Call want_pubnames.
(output_pubnames): Move conditional logic deciding when to produce the
section from dwarf2out_finish.  Use new skeleton_die field.
(base_type_die): Call add_pubtype.
(gen_enumeration_type_die): Unconditionally call add_pubtype.
(gen_subprogram_die): Adjust calls to add_pubname.
(gen_namespace_die): Call add_pubname_string.
(dwarf2out_finish): Call add_AT_pubnames; Move logic on when to
produce pubnames and pubtypes sections to output_pubnames.
(gcc/common.opt): New option '-gpubnames'.
(gcc/invoke.texi): Document it.

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 188035)
+++ gcc/dwarf2out.c (working copy)
@@ -2539,6 +2539,7 @@
 {
   dw_die_ref root_die;
   dw_die_ref type_die;
+  dw_die_ref skeleton_die;
   char signature[DWARF_TYPE_SIGNATURE_SIZE];
   struct comdat_type_struct *next;
 }
@@ -3013,6 +3014,7 @@
 static void output_comdat_type_unit (comdat_type_node *);
 static const char *dwarf2_name (tree, int);
 static void add_pubname (tree, dw_die_ref);
+static void add_enumerator_pubname (const char *, dw_die_ref);
 static void add_pubname_string (const char *, dw_die_ref);
 static void add_pubtype (tree, dw_die_ref);
 static void output_pubnames (VEC (pubname_entry,gc) *);
@@ -3142,6 +3144,7 @@
 const char *, const char *);
 static void output_loc_list (dw_loc_list_ref);
 static char *gen_internal_sym (const char *);
+static bool want_pubnames (void);
 
 static void prune_unmark_dies (dw_die_ref);
 static void prune_unused_types_mark_generic_parms_dies (dw_die_ref);
@@ -5972,6 +5975,23 @@
   return c && c->die_tag == DW_TAG_compile_unit;
 }
 
+/* Returns true iff C is a namespace DIE.  */
+
+static inline bool
+is_namespace_die (dw_die_ref c)
+{
+  return c && c->die_tag == DW_TAG_namespace;
+}
+
+/* Returns true iff C is a class or structure DIE.  */
+
+static inline bool
+is_class_die (dw_die_ref c)
+{
+  return c && (c->die_tag == DW_TAG_class_type
+   || c->die_tag == DW_TAG_structure_type);
+}
+
 static char *
 gen_internal_sym (const char *prefix)
 {
@@ -6559,6 +6579,7 @@
declaration into the new type unit DIE, then remove this DIE
   from the main CU (or replace it with a skeleton if necessary).  */
replacement = remove_child_or_replace_with_skeleton (unit, c, prev);
+   type_node->skeleton_die = replacement;
 
 /* Break out nested types into their own type units.  */
 break_out_comdat_types (c);
@@ -8034,6 +8055,27 @@
 }
 }
 
+/* Whether to generate the DWARF accelerator tables in .debug_pubnames
+   and .debug_pubtypes.  This is configured per-target, but can be
+   overridden by the -gpubnames or -gno-pubnames options.  */
+
+static inline bool
+want_pubnames (void)
+{
+  return (debug_generate_pub_sections != -1
+ ? debug_generate_pub_sections
+ : targetm.want_debug_pub_sections);
+}
+
+/* Add the DW_AT_GNU_pubnames and DW_AT_GNU_pubtypes attributes.  */
+
+static void
+add_AT_pubnames (dw_die_ref die)
+{
+  if (want_pubnames ())
+add_AT_flag (die, DW_AT_GNU_pubnames, 1);
+}
+
 /* Output a comdat type unit DIE and its children.  */
 
 static void
@@ -8104,7 +8146,7 @@
 static void
 add_pubname_string (const char *str, dw_die_ref die)
 {
-  if (targetm.want_debug_pub_sections)
+  if (want_pubnames ())
 {
   pubname_entry e;
 
@@ -8117,14 +8159,32 @@
 static void
 add_pubname (tree decl, dw_die_ref die)
 {
-  if (targetm.want_debug_pub_sections && TREE_PUBLIC (decl))
+  if (!want_pubnames ())
+return;
+
+  if ((TREE_PUBLIC (decl) && !is_class_die (die->die_parent))
+  || is_cu_die (die->die_parent) || is_namespace_die (die->die_parent))
 {
   const char *name = dwarf2_name (decl, 1);
+
  

C++ PATCH for c++/53137 (ICE with lambda in template)

[Jason Merrill]

In 4.7, this is one bug: we are doing a push_to_top_level to instantiate 
the lambda, and then not pushing back into the function scope that the 
lambda belongs to.  Fixed by following the lead of synthesize_method and 
only doing push_function_context if we're dealing with a local class.


On the trunk, after that issue was fixed I also had to fix our handling 
of 'this' capture in template lambdas after my work on return type 
deduction for arbitrary functions.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 1409620970858e91fc55f90935e724b511f98d6c
Author: Jason Merrill 
Date:   Thu May 31 17:25:52 2012 -0400

	PR c++/53137
	* pt.c (instantiate_class_template_1): Set LAMBDA_EXPR_THIS_CAPTURE.
	(instantiate_decl): Don't push_to_top_level for local class methods.
	(instantiate_class_template_1): Or for local classes.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index b58dd13..4d4e8ad 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -8698,6 +8698,7 @@ instantiate_class_template_1 (tree type)
   tree pbinfo;
   tree base_list;
   unsigned int saved_maximum_field_alignment;
+  tree fn_context;
 
   if (type == error_mark_node)
 return error_mark_node;
@@ -8756,7 +8757,9 @@ instantiate_class_template_1 (tree type)
  it now.  */
   push_deferring_access_checks (dk_no_deferred);
 
-  push_to_top_level ();
+  fn_context = decl_function_context (TYPE_MAIN_DECL (type));
+  if (!fn_context)
+push_to_top_level ();
   /* Use #pragma pack from the template context.  */
   saved_maximum_field_alignment = maximum_field_alignment;
   maximum_field_alignment = TYPE_PRECISION (pattern);
@@ -9154,8 +9157,14 @@ instantiate_class_template_1 (tree type)
   tree decl = lambda_function (type);
   if (decl)
 	{
+	  tree lam = CLASSTYPE_LAMBDA_EXPR (type);
+	  LAMBDA_EXPR_THIS_CAPTURE (lam)
+	= lookup_field_1 (type, get_identifier ("__this"), false);
+
 	  instantiate_decl (decl, false, false);
 	  maybe_add_lambda_conv_op (type);
+
+	  LAMBDA_EXPR_THIS_CAPTURE (lam) = NULL_TREE;
 	}
   else
 	gcc_assert (errorcount);
@@ -9186,7 +9195,8 @@ instantiate_class_template_1 (tree type)
   perform_deferred_access_checks ();
   pop_nested_class ();
   maximum_field_alignment = saved_maximum_field_alignment;
-  pop_from_top_level ();
+  if (!fn_context)
+pop_from_top_level ();
   pop_deferring_access_checks ();
   pop_tinst_level ();
 
@@ -18435,9 +18445,10 @@ instantiate_decl (tree d, int defer_ok,
   tree spec;
   tree gen_tmpl;
   bool pattern_defined;
-  int need_push;
   location_t saved_loc = input_location;
   bool external_p;
+  tree fn_context;
+  bool nested;
 
   /* This function should only be used to instantiate templates for
  functions and static member variables.  */
@@ -18672,9 +18683,12 @@ instantiate_decl (tree d, int defer_ok,
 	goto out;
 }
 
-  need_push = !cfun || !global_bindings_p ();
-  if (need_push)
+  fn_context = decl_function_context (d);
+  nested = (current_function_decl != NULL_TREE);
+  if (!fn_context)
 push_to_top_level ();
+  else if (nested)
+push_function_context ();
 
   /* Mark D as instantiated so that recursive calls to
  instantiate_decl do not try to instantiate it again.  */
@@ -18784,8 +18798,10 @@ instantiate_decl (tree d, int defer_ok,
   /* We're not deferring instantiation any more.  */
   TI_PENDING_TEMPLATE_FLAG (DECL_TEMPLATE_INFO (d)) = 0;
 
-  if (need_push)
+  if (!fn_context)
 pop_from_top_level ();
+  else if (nested)
+pop_function_context ();
 
 out:
   input_location = saved_loc;
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template5.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template5.C
new file mode 100644
index 000..b91b89f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template5.C
@@ -0,0 +1,17 @@
+// PR c++/53137
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+  template  void f();
+
+  template  void g()
+  {
+[this]{ f(); }();
+  }
+
+  void h()
+  {
+g();
+  }
+};

C++ PATCH for c++/53484 (wrong auto in template)

[Jason Merrill]

Back when we added C++11 auto deduction, I thought we could shortcut the 
normal deduction in some templates, when the type is adequately 
describable (thus the late, unlamented function describable_type).  Over 
time various problems with this have arisen, of which this is the most 
recent; as a result, I'm giving up the attempt as a bad idea and just 
deferring auto deduction if the initializer is type-dependent.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 639eddf82da171a041d5184d5dd2917f102dde3c
Author: Jason Merrill 
Date:   Thu May 31 11:50:20 2012 -0400

	PR c++/53484
	* pt.c (do_auto_deduction): Don't try to deduce from a
	type-dependent initializer.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c55687b..b58dd13 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20318,10 +20318,9 @@ do_auto_deduction (tree type, tree init, tree auto_node)
   if (init == error_mark_node)
 return error_mark_node;
 
-  if (processing_template_decl
-  && (TREE_TYPE (init) == NULL_TREE
-	  || BRACE_ENCLOSED_INITIALIZER_P (init)))
-/* Not enough information to try this yet.  */
+  if (type_dependent_expression_p (init))
+/* Defining a subset of type-dependent expressions that we can deduce
+   from ahead of time isn't worth the trouble.  */
 return type;
 
   /* [dcl.spec.auto]: Obtain P from T by replacing the occurrences of auto
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto33.C b/gcc/testsuite/g++.dg/cpp0x/auto33.C
new file mode 100644
index 000..dade5a8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto33.C
@@ -0,0 +1,15 @@
+// PR c++/53484
+// { dg-do compile { target c++11 } }
+
+template struct ST;
+template struct ST {};
+
+template 
+void f(T x){
+   [&]{
+ auto y = x;
+ ST();
+   }();
+}
+
+int main(){ f(0); }

Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks

[rbmj]

Hi everyone,

These fixes are to allow building on vxWorks.  Currently there are two 
issues:


1.  VxWorks does not have a variadic open - it must receive three 
arguments.  gcc/gcov.c however opens a file for reading and does not 
pass in a mode argument, which causes an error on vxWorks.  This just 
adds a platform-based ifdef around this.  I am aware that this is 
against coding conventions, and if that is an issue, I can think of two 
resolutions.  One, an autoconf macro to check for a non-variadic open, 
or two, simply pass the extra mode argument in unconditionally, as it 
should be transparent to the function and ignored if it is variadic (I'm 
no expert on calling conventions though).


2.  VxWorks has a two argument mkdir().  libgcc/libgcov.c uses mkdir() 
and calls it with two arguments if TARGET_POSIX_IO is defined and only 
one argument otherwise.  I don't know what TARGET_POSIX_IO is, but if 
it's anything more than just mkdir(), this is probably correct, as 
vxworks is only partially POSIX compliant.  Again, another 
platform-based ifdef, so if that is anathema, it can be replaced by more 
autoconf hackery.


The patch as-is compiles targeting on vxworks and bootstraps on a native 
x86_64-linux-gnu build (which makes sense, since it doesn't touch 
anything for non-vxworks).


Gerald Pfeifer has volunteered to apply the patch if approved.

Also, in an earlier message [1] Janne Blomqvist mentioned that newer 
versions of VxWorks do have the variadic open(), and this is true.  
However, as far as I know, this version is still not available for 
kernel modules, only real-time processes.


Thanks,

Robert Mason
>From ad3b2df4d172eea2e0edfd61153133b25a7ed640 Mon Sep 17 00:00:00 2001
From: rbmj 
Date: Wed, 30 May 2012 08:42:37 -0400
Subject: [PATCH 3/5] Make changes to gcov to allow compilation targeting
 vxworks.

gcc/gcov-io.c: add mode argument to open() on vxworks
libgcc/libgcov.c: fall back to single argument mkdir() on vxworks
---
 gcc/ChangeLog|5 +
 gcc/gcov-io.c|4 
 libgcc/ChangeLog |5 +
 libgcc/libgcov.c |2 +-
 4 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 71451d2..c362fc6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
 2012-05-30  Robert Mason  
 
+	* gcov-io.c (gcov_open):  VxWorks does not have variadic open(), so pass
+	in a mode argument (ignored for O_RDONLY) on that platform.
+
+2012-05-30  Robert Mason  
+
 	* config/rs6000/vxworks.h: Fix bad macro SUBSUBTARGET_OVERRIDE_OPTIONS.
 
 2012-05-29  Joseph Myers  
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 37c1c3e..823067a 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -92,7 +92,11 @@ gcov_open (const char *name, int mode)
 {
   /* Read-only mode - acquire a read-lock.  */
   s_flock.l_type = F_RDLCK;
+#ifdef __VXWORKS__
+  fd = open (name, O_RDONLY, 0666);
+#else
   fd = open (name, O_RDONLY);
+#endif
 }
   else
 {
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 5c048f5..04a6653 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2012-05-30  Robert Mason  
+
+* libgcov.c (create_file_directory):  VxWorks does not have two-argument
+mkdir, so fall back to the single-argument call on that platform.
+
 2012-05-25  Ian Lance Taylor  
 
 	* config/i386/morestack.S (__morestack_non_split): Check whether
diff --git a/libgcc/libgcov.c b/libgcc/libgcov.c
index 8ed8971..27117b4 100644
--- a/libgcc/libgcov.c
+++ b/libgcc/libgcov.c
@@ -133,7 +133,7 @@ create_file_directory (char *filename)
 
 /* Try to make directory if it doesn't already exist.  */
 if (access (filename, F_OK) == -1
-#ifdef TARGET_POSIX_IO
+#if defined(TARGET_POSIX_IO) && !defined(__VXWORKS__)
 && mkdir (filename, 0755) == -1
 #else
 && mkdir (filename) == -1
-- 
1.7.5.4

Re: Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks

[rbmj]

On 06/01/2012 02:40 PM, rbmj wrote:

Hi everyone,

These fixes are to allow building on vxWorks.  Currently there are two 
issues:


1.  VxWorks does not have a variadic open - it must receive three 
arguments.  gcc/gcov.c however opens a file for reading and does not 
pass in a mode argument, which causes an error on vxWorks.  This just 
adds a platform-based ifdef around this.  I am aware that this is 
against coding conventions, and if that is an issue, I can think of 
two resolutions.  One, an autoconf macro to check for a non-variadic 
open, or two, simply pass the extra mode argument in unconditionally, 
as it should be transparent to the function and ignored if it is 
variadic (I'm no expert on calling conventions though).


2.  VxWorks has a two argument mkdir().  libgcc/libgcov.c uses mkdir() 
and calls it with two arguments if TARGET_POSIX_IO is defined and only 
one argument otherwise.  I don't know what TARGET_POSIX_IO is, but if 
it's anything more than just mkdir(), this is probably correct, as 
vxworks is only partially POSIX compliant.  Again, another 
platform-based ifdef, so if that is anathema, it can be replaced by 
more autoconf hackery.


The patch as-is compiles targeting on vxworks and bootstraps on a 
native x86_64-linux-gnu build (which makes sense, since it doesn't 
touch anything for non-vxworks).


Gerald Pfeifer has volunteered to apply the patch if approved.

Also, in an earlier message [1] Janne Blomqvist mentioned that newer 
versions of VxWorks do have the variadic open(), and this is true.  
However, as far as I know, this version is still not available for 
kernel modules, only real-time processes.


Thanks,

Robert Mason


Sorry, forgot to add in the link.
[1]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01102.html

Re: [google/gcc-4_6] Backport r171031 from upstream to fix ICE on PowerPC64 (issue6255070)

[關振德]

ping?

On Thu, May 31, 2012 at 4:02 PM, Doug Kwan  wrote:
> Hi Diego,
>
>        This is a backport of this patch to fix an ICE on PowerPC64.
>
>        http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00829.html
>
> -Doug
>
>
> 2012-05-31   Doug Kwan  
>
>        Backport r171031 from upstream trunk in gcc/.
>        2011-03-16  Alan Modra  
>
>                PR target/45844
>                * config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
>                Don't create invalid offset address for vsx splat insn.
>                * config/rs6000/predicates.md (splat_input_operand): New.
>                * config/rs6000/vsx.md (vsx_splat_*): Use it.
>
>        * contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail:
>        Remove expected failures because now the bug is fixed by the above.
>
> Index: contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail
> ===
> --- contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail       
> (revision 188083)
> +++ contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail       
> (working copy)
> @@ -69,8 +69,6 @@ FAIL: gcc.target/powerpc/pr47755-2.c execution tes
>
>  # *** gfortran:
>  XPASS: gfortran.dg/nint_2.f90  -O0  execution test
> -FAIL: gfortran.dg/vect/pr45714-b.f  -O  (internal compiler error)
> -FAIL: gfortran.dg/vect/pr45714-b.f  -O  (test for excess errors)
>  FAIL: gfortran.dg/vect/fast-math-pr38968.f90 execution test
>
>  # *** g++:
> Index: gcc/config/rs6000/predicates.md
> ===
> --- gcc/config/rs6000/predicates.md     (revision 188083)
> +++ gcc/config/rs6000/predicates.md     (working copy)
> @@ -1,5 +1,5 @@
>  ;; Predicate definitions for POWER and PowerPC.
> -;; Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010
> +;; Copyright (C) 2005, 2006, 2007, 2008, 2009, 2010, 2011
>  ;; Free Software Foundation, Inc.
>  ;;
>  ;; This file is part of GCC.
> @@ -871,6 +871,23 @@
>   return 0;
>  })
>
> +;; Return 1 if this operand is a valid input for a vsx_splat insn.
> +(define_predicate "splat_input_operand"
> +  (match_code "label_ref,symbol_ref,const,high,reg,subreg,mem,
> +              const_double,const_vector,const_int,plus")
> +{
> +  if (MEM_P (op))
> +    {
> +      if (mode == DFmode)
> +       mode = V2DFmode;
> +      else if (mode == DImode)
> +       mode = V2DImode;
> +      else
> +       gcc_unreachable ();
> +    }
> +  return input_operand (op, mode);
> +})
> +
>  ;; Return true if OP is an invalid SUBREG operation on the e500.
>  (define_predicate "rs6000_nonimmediate_operand"
>   (match_code "reg,subreg,mem")
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c  (revision 188083)
> +++ gcc/config/rs6000/rs6000.c  (working copy)
> @@ -6703,6 +6703,14 @@ rs6000_legitimize_reload_address (rtx x, enum mach
>  {
>   bool reg_offset_p = reg_offset_addressing_ok_p (mode);
>
> +  /* Nasty hack for vsx_splat_V2DF/V2DI load from mem, which takes a
> +     DFmode/DImode MEM.  */
> +  if (reg_offset_p
> +      && opnum == 1
> +      && ((mode == DFmode && recog_data.operand_mode[0] == V2DFmode)
> +         || (mode == DImode && recog_data.operand_mode[0] == V2DImode)))
> +    reg_offset_p = false;
> +
>   /* We must recognize output that we have already generated ourselves.  */
>   if (GET_CODE (x) == PLUS
>       && GET_CODE (XEXP (x, 0)) == PLUS
> Index: gcc/config/rs6000/vsx.md
> ===
> --- gcc/config/rs6000/vsx.md    (revision 188083)
> +++ gcc/config/rs6000/vsx.md    (working copy)
> @@ -1076,7 +1076,7 @@
>  (define_insn "vsx_splat_"
>   [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wd,wd,wd,?wa,?wa,?wa")
>        (vec_duplicate:VSX_D
> -        (match_operand: 1 "input_operand" "ws,f,Z,wa,wa,Z")))]
> +        (match_operand: 1 "splat_input_operand" 
> "ws,f,Z,wa,wa,Z")))]
>   "VECTOR_MEM_VSX_P (mode)"
>   "@
>    xxpermdi %x0,%x1,%x1,0
>
> --
> This patch is available for review at http://codereview.appspot.com/6255070

Re: [C++] Reject variably modified types in operator new

[Florian Weimer]

On 06/01/2012 06:19 PM, Jason Merrill wrote:

On 06/01/2012 11:40 AM, Florian Weimer wrote:

I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.


I'd accept a patch to change that.


I don't really now what I'm doing here.  But I noticed that in 
cp_parser_constant_expression, a failure in 
require_potential_rvalue_constant_expression is not reported to the caller.


This changes error reporting, and a few test cases need adjustment.  In 
some, reporting is better, in others, it's slightly worse.  I need to 
make a second pass over the changes to make sure that they are alright.


Does this change make any sense at all?

Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 188104)
+++ gcc/cp/parser.c (working copy)
@@ -7701,8 +7701,9 @@ cp_parser_constant_expression (cp_parser* parser,
 separately in e.g. cp_parser_template_argument.  */
   bool is_const = potential_rvalue_constant_expression (expression);
   parser->non_integral_constant_expression_p = !is_const;
-  if (!is_const && !allow_non_constant_p)
-   require_potential_rvalue_constant_expression (expression);
+  if (!is_const && !allow_non_constant_p
+ && !require_potential_rvalue_constant_expression (expression))
+   expression = error_mark_node;
 }
   if (allow_non_constant_p)
 *non_constant_p = parser->non_integral_constant_expression_p;


--
Florian Weimer / Red Hat Product Security Team

Re: [google/gcc-4_6] Backport r171031 from upstream to fix ICE on PowerPC64 (issue6255070)

[Diego Novillo]

On 12-05-31 19:02 , Doug Kwan wrote:


2012-05-31   Doug Kwan

Backport r171031 from upstream trunk in gcc/.
2011-03-16  Alan Modra

PR target/45844
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
Don't create invalid offset address for vsx splat insn.
* config/rs6000/predicates.md (splat_input_operand): New.
* config/rs6000/vsx.md (vsx_splat_*): Use it.

* contrib/testsuite-management/powerpc64-grtev2-linux-gnu.xfail:
Remove expected failures because now the bug is fixed by the above.


OK.


Diego.

[google] libgcov workaround for weak reference issue (issue6276043)

[Teresa Johnson]

This patch works around a subtlety in the way weak references to
symbols defined in archives are handled by the linker. This is an
issue because google binaries are using weak references to detect
whether the libgcov.a version contains the new __gcov_reset and
__gcov_dump interfaces. Since they are defined in their own object
file within the archive, and no strong references are made to any
other symbols within the same object file, the linker does not
resolve the weak references. The workaround is to add dummy
strong references to the new routines from the main object file
(defined under L_gcov) that will always be referenced during
-fprofile-generate builds.

Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for google
branches?

Thanks,
Teresa

2012-06-01   Teresa Johnson  

* libgcov.c: Add references to gcov_reset and gcov_dump
from L_gcov section.

Index: libgcov.c
===
--- libgcov.c   (revision 188119)
+++ libgcov.c   (working copy)
@@ -119,6 +119,21 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN;
 #ifdef L_gcov
 #include "gcov-io.c"
 
+/* Create a strong reference to these symbols so that they are
+   unconditionally pulled into the instrumented binary, even when
+   the only reference is a weak reference. This is necessary because
+   we are using weak references to handle older compilers that
+   pre-date these new functions. A subtlety of the linker is that
+   it will only resolve weak references defined within archive libraries
+   when there is a string reference to something else defined within
+   the same object file. Since these two functions are defined within
+   their own object files (using L_gcov_reset and L_gcov_dump), they
+   would not get resolved. Since there are symbols within the main L_gcov
+   section that are strongly referenced during -fprofile-generate builds,
+   these symbols will always need to be resolved.  */
+void (*unused1)() = &__gcov_reset;
+void (*unused2)() = &__gcov_dump;
+
 /* Utility function for outputing errors.  */
 static int
 gcov_error (const char *fmt, ...)

--
This patch is available for review at http://codereview.appspot.com/6276043

C++ PATCH for c++/52725 (bogus lambda error with array new)

[Jason Merrill]

When parsing a new-expression, we first try to parse a new-placement 
before the type.  In this case, the tokens don't make a valid 
expression, but we were still trying to parse [n] as a 
lambda-introducer.  Fixed by bailing out of cp_parser_binary_expression 
sooner if we encounter a parse error while parsing tentatively.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit 17ee6c495d4ab68f1de3d17bceb5f344c1491642
Author: Jason Merrill 
Date:   Fri Jun 1 14:53:46 2012 -0400

	PR c++/52725
	* parser.c (cp_parser_binary_expression): Bail early if we're parsing
	tentatively and the LHS has a parse error.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 547f9e2..7f9a94b 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7246,6 +7246,9 @@ cp_parser_binary_expression (cp_parser* parser, bool cast_p,
   current.lhs_type = ERROR_MARK;
   current.prec = prec;
 
+  if (cp_parser_error_occurred (parser))
+return error_mark_node;
+
   for (;;)
 {
   /* Get an operator token.  */
diff --git a/gcc/testsuite/g++.dg/parse/new6.C b/gcc/testsuite/g++.dg/parse/new6.C
new file mode 100644
index 000..213837c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/new6.C
@@ -0,0 +1,10 @@
+// PR c++/52725
+
+struct A { };
+
+const int n = 42;
+
+void f()
+{
+  A** p = new (A*[n]);
+}
diff --git a/gcc/testsuite/g++.dg/template/sizeof-template-argument.C b/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
index 2cdc328..31aeeec 100644
--- a/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
+++ b/gcc/testsuite/g++.dg/template/sizeof-template-argument.C
@@ -3,9 +3,9 @@
 
 template struct A {};
 
-template struct B : A  {}; /* { dg-error "parse error in template argument list" } */
+template struct B : A  {}; /* { dg-error "template argument" } */
 
-template struct C : A  {}; /* { dg-error "parse error in template argument list" } */
+template struct C : A  {}; /* { dg-error "template argument" } */
 
 int a;
 

Re: [google] libgcov workaround for weak reference issue (issue 6276043)

[davidxl]

Ok with better naming for the dummy function such as
'__gcov_dummy_ref1'. Another choice is to let __gcov_flush calls
__gcov_dump + __gcov_reset -- but the dump_completed state needs to be
saved and restored.

David

http://codereview.appspot.com/6276043/

[google/gcc-4_6] Use const offset for DW_AT_high_pc and end of loc list entries (issue6279043)

[Cary Coutant]

This patch is for the google/gcc-4_6 branch.

Import pending patch from upstream to generate DW_AT_high_pc as a constant
offset relative to DW_AT_low_pc.  When splitting DWARF info, generate new
format for location list entries using a start symbol and a length.
Together, these changes reduce the size of the .debug_addr section by half.

Tested with GCC test suite and validate_failures.py.


2012-04-27  Mark Wielaard  
Cary Coutant  

include/
* dwarf2.h (enum dwarf_location_list_entry_type): New enum.

gcc/
* dwarf2out.c (enum dw_val_class): Add dw_val_class_high_pc.
(struct dw_loc_list_struct): Remove end_index.
(add_AT_low_high_pc): New function.
(AT_lbl): Handle dw_val_class_high_pc.
(print_die): Likewise.
(attr_checksum): Likewise.
(attr_checksum_ordered): Likewise.
(same_dw_val_p): Likewise.
(size_of_die): Likewise.
(value_format): Likewise.
(new_loc_list): Remove end_index.
(output_loc_list): Use new DW_LLE_start_length_entry format.
(output_die): Handle dw_val_class_high_pc.
(gen_subprogram_die): Use add_AT_low_high_pc.
(add_high_low_attributes): Likewise.
(index_location_lists): Remove end_index.
(dwarf2out_finish): Use add_AT_low_high_pc.


Index: include/dwarf2.h
===
--- include/dwarf2.h(revision 188123)
+++ include/dwarf2.h(working copy)
@@ -750,6 +750,17 @@ enum dwarf_line_number_x_ops
 DW_LNE_hi_user = 0xff
   };
 
+/* Type codes for location list entries.
+   Extension for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
+
+enum dwarf_location_list_entry_type
+  {
+DW_LLE_end_of_list_entry = 0,
+DW_LLE_base_address_selection_entry = 1,
+DW_LLE_start_end_entry = 2,
+DW_LLE_start_length_entry = 3
+  };
+
 /* Call frame information.  */
 enum dwarf_call_frame_info
   {
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 188123)
+++ gcc/dwarf2out.c (working copy)
@@ -4366,7 +4366,8 @@ enum dw_val_class
   dw_val_class_file,
   dw_val_class_data8,
   dw_val_class_decl_ref,
-  dw_val_class_vms_delta
+  dw_val_class_vms_delta,
+  dw_val_class_high_pc
 };
 
 /* Describe a floating point constant value, or a vector constant value.  */
@@ -4438,8 +4439,7 @@ typedef struct GTY(()) dw_loc_list_struc
   dw_loc_list_ref dw_loc_next;
   const char *begin; /* Label and index for begin address of range */
   unsigned int begin_index;
-  const char *end;  /* Label and index for end address of range */
-  unsigned int end_index;
+  const char *end;  /* Label for end address of range */
   char *ll_symbol; /* Label for beginning of location list.
  Only on head of list */
   const char *section; /* Section this loclist is relative to */
@@ -7566,6 +7566,26 @@ add_AT_data8 (dw_die_ref die, enum dwarf
   add_dwarf_attr (die, &attr);
 }
 
+/* Add DW_AT_low_pc and DW_AT_high_pc to a DIE.  */
+static inline void
+add_AT_low_high_pc (dw_die_ref die, const char *lbl_low, const char *lbl_high)
+{
+  dw_attr_node attr;
+
+  attr.dw_attr = DW_AT_low_pc;
+  attr.dw_attr_val.val_class = dw_val_class_lbl_id;
+  attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_low);
+  add_dwarf_attr (die, &attr);
+
+  attr.dw_attr = DW_AT_high_pc;
+  if (dwarf_version < 4)
+attr.dw_attr_val.val_class = dw_val_class_lbl_id;
+  else
+attr.dw_attr_val.val_class = dw_val_class_high_pc;
+  attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_high);
+  add_dwarf_attr (die, &attr);
+}
+
 /* Hash and equality functions for debug_str_hash.  */
 
 static hashval_t
@@ -8048,7 +8068,8 @@ AT_lbl (dw_attr_ref a)
 {
   gcc_assert (a && (AT_class (a) == dw_val_class_lbl_id
|| AT_class (a) == dw_val_class_lineptr
-   || AT_class (a) == dw_val_class_macptr));
+   || AT_class (a) == dw_val_class_macptr
+   || AT_class (a) == dw_val_class_high_pc));
   return a->dw_attr_val.v.val_lbl_id;
 }
 
@@ -8902,6 +8923,7 @@ print_die (dw_die_ref die, FILE *outfile
case dw_val_class_lbl_id:
case dw_val_class_lineptr:
case dw_val_class_macptr:
+   case dw_val_class_high_pc:
  fprintf (outfile, "label: %s", AT_lbl (a));
  break;
case dw_val_class_str:
@@ -9081,6 +9103,7 @@ attr_checksum (dw_attr_ref at, struct md
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
+case dw_val_class_high_pc:
   break;
 
 case dw_val_class_file:
@@ -9353,6 +9376,7 @@ attr_checksum_ordered (enum dwarf_tag ta
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_class_macptr:
+case dw_val_class_high_pc:
   break;
 
 case dw_val_class_file:
@@ -9812,6 +9836,7 @@ same_dw_val_p (const dw_val_node *v1, co
 case dw_val_class_lbl_id:
 case d

Re: [google] libgcov workaround for weak reference issue (issue 6276043)

[Teresa Johnson]

Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
approach for now to keep the differences with trunk to a minimum.

Thanks,
Teresa

On Fri, Jun 1, 2012 at 2:18 PM,   wrote:
> Ok with better naming for the dummy function such as
> '__gcov_dummy_ref1'. Another choice is to let __gcov_flush calls
> __gcov_dump + __gcov_reset -- but the dump_completed state needs to be
> saved and restored.
>
> David
>
> http://codereview.appspot.com/6276043/



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [google] libgcov workaround for weak reference issue (issue 6276043)

[Xinliang David Li]

ok.

thanks,

David

On Fri, Jun 1, 2012 at 2:26 PM, Teresa Johnson  wrote:
> Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
> approach for now to keep the differences with trunk to a minimum.
>
> Thanks,
> Teresa
>
> On Fri, Jun 1, 2012 at 2:18 PM,   wrote:
>> Ok with better naming for the dummy function such as
>> '__gcov_dummy_ref1'. Another choice is to let __gcov_flush calls
>> __gcov_dump + __gcov_reset -- but the dump_completed state needs to be
>> saved and restored.
>>
>> David
>>
>> http://codereview.appspot.com/6276043/
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

[C++ Patch] Produce canonical names for debug info without changing normal pretty-printing (issue6215052)

[Sterling Augustine]

After finding yet another bug in the previous patch dealing with pretty-printing
decls for dwarf in canonical form, I have figured out a way to do it that is
less invasive and much cleaner.

This updated patch simply wraps the two entry points into the decl pretty-
printer called from cxx_dwarf_name with new functions that set the
appropriate flag on the pretty printer. This is much cleaner and avoids
the need for translating flags for C++ pretty-printing into standard C
pretty printing flags.

OK for mainline?

Sterling

2012-06-01   Sterling Augustine  

* gcc/c-family/c-pretty-print.h (pp_c_flag_gnu_v3): New enumerator.
* gcc/c-family/c-pretty-print.c (pp_c_specifier_qualifier_list): Check
it at both the start and end of the function.
* gcc/cp/error.c (dump_decl): Check pp_c_flag_gnu_v3.
(decl_as_dwarf_string, lang_decl_dwarf_name): New functions.
(lang_decl_name): Handle namespace decls.
* gcc/cp/cp-tree.h: Declare decl_as_dwarf_string, lang_decl_dwarf_name.
* gcc/cp/cp-lang.c: Call them.

Index: gcc/c-family/c-pretty-print.c
===
--- gcc/c-family/c-pretty-print.c   (revision 188034)
+++ gcc/c-family/c-pretty-print.c   (working copy)
@@ -446,7 +446,7 @@
 {
   const enum tree_code code = TREE_CODE (t);
 
-  if (TREE_CODE (t) != POINTER_TYPE)
+  if (!(pp->flags & pp_c_flag_gnu_v3) && code != POINTER_TYPE)
 pp_c_type_qualifier_list (pp, t);
   switch (code)
 {
@@ -494,6 +494,8 @@
   pp_simple_type_specifier (pp, t);
   break;
 }
+  if ((pp->flags & pp_c_flag_gnu_v3) && code != POINTER_TYPE)
+pp_c_type_qualifier_list (pp, t);
 }
 
 /* parameter-type-list:
Index: gcc/c-family/c-pretty-print.h
===
--- gcc/c-family/c-pretty-print.h   (revision 188034)
+++ gcc/c-family/c-pretty-print.h   (working copy)
@@ -30,7 +30,8 @@
 typedef enum
   {
  pp_c_flag_abstract = 1 << 1,
- pp_c_flag_last_bit = 2
+ pp_c_flag_gnu_v3 = 1 << 2,
+ pp_c_flag_last_bit = 3
   } pp_c_pretty_print_flags;
 
 
Index: gcc/cp/error.c
===
--- gcc/cp/error.c  (revision 188034)
+++ gcc/cp/error.c  (working copy)
@@ -1028,7 +1028,12 @@
dump_scope (CP_DECL_CONTEXT (t), flags);
  flags &= ~TFF_UNQUALIFIED_NAME;
  if (DECL_NAME (t) == NULL_TREE)
-   pp_cxx_ws_string (cxx_pp, M_("{anonymous}"));
+{
+  if (!(pp_c_base (cxx_pp)->flags & pp_c_flag_gnu_v3))
+pp_cxx_ws_string (cxx_pp, M_("{anonymous}"));
+  else
+pp_cxx_ws_string (cxx_pp, M_("(anonymous namespace)"));
+}
  else
pp_cxx_tree_identifier (cxx_pp, DECL_NAME (t));
}
@@ -2556,7 +2561,22 @@
   return pp_formatted_text (cxx_pp);
 }
 
+/* Wrap decl_as_string with options appropriate for dwarf.  */
+
 const char *
+decl_as_dwarf_string (tree decl, int flags)
+{
+  const char *name;
+  /* Curiously, reinit_cxx_pp doesn't reset the flags field, so setting the 
flag
+ here will be adequate to get the desired behaviour.  */
+  pp_c_base (cxx_pp)->flags |= pp_c_flag_gnu_v3;
+  name = decl_as_string (decl, flags);
+  /* Subsequent calls to the pretty printer shouldn't use this style.  */
+  pp_c_base (cxx_pp)->flags &= ~pp_c_flag_gnu_v3;
+  return name;
+}
+
+const char *
 decl_as_string (tree decl, int flags)
 {
   reinit_cxx_pp ();
@@ -2573,6 +2593,21 @@
   return pp_formatted_text (cxx_pp);
 }
 
+/* Wrap lang_decl_name with options appropriate for dwarf.  */
+
+const char *
+lang_decl_dwarf_name (tree decl, int v, bool translate)
+{
+  const char *name;
+  /* Curiously, reinit_cxx_pp doesn't reset the flags field, so setting the 
flag
+ here will be adequate to get the desired behaviour.  */
+  pp_c_base (cxx_pp)->flags |= pp_c_flag_gnu_v3;
+  name = lang_decl_name (decl, v, translate);
+  /* Subsequent calls to the pretty printer shouldn't use this style.  */
+  pp_c_base (cxx_pp)->flags &= ~pp_c_flag_gnu_v3;
+  return name;
+}
+
 /* Generate the three forms of printable names for cxx_printable_name.  */
 
 const char *
@@ -2596,6 +2631,9 @@
 
   if (TREE_CODE (decl) == FUNCTION_DECL)
 dump_function_name (decl, TFF_PLAIN_IDENTIFIER);
+  else if ((DECL_NAME (decl) == NULL_TREE)
+   && TREE_CODE (decl) == NAMESPACE_DECL)
+dump_decl (decl, TFF_PLAIN_IDENTIFIER);
   else
 dump_decl (DECL_NAME (decl), TFF_PLAIN_IDENTIFIER);
 
Index: gcc/cp/cp-lang.c
===
--- gcc/cp/cp-lang.c(revision 188034)
+++ gcc/cp/cp-lang.c(working copy)
@@ -118,11 +118,11 @@
   && (ANON_AGGRNAME_P (DECL_NAME (t)) || LAMBDANAME_P (DECL_NAME (t
 return NULL;
   if (verbosity >= 2)
-return decl_as_string (t,
-  TFF_DECL_SPECIFIERS | TFF_UNQUALIFI

Re: [C++ Patch] Produce canonical names for debug info without changing normal pretty-printing (issue6215052)

[Gabriel Dos Reis]

On Fri, Jun 1, 2012 at 6:07 PM, Sterling Augustine
 wrote:
> After finding yet another bug in the previous patch dealing with 
> pretty-printing
> decls for dwarf in canonical form, I have figured out a way to do it that is
> less invasive and much cleaner.
>
> This updated patch simply wraps the two entry points into the decl pretty-
> printer called from cxx_dwarf_name with new functions that set the
> appropriate flag on the pretty printer. This is much cleaner and avoids
> the need for translating flags for C++ pretty-printing into standard C
> pretty printing flags.
>
> OK for mainline?

OK.

Use const offset for DW_AT_high_pc and end of loc list entries (issue6279043)

[Cary Coutant]

This patch is for the google/gcc-4_6 branch.

[Revised to fix an latent bug exposed by changes to the numbering of the
slots in .debug_addr. The location list comparison code had an assertion
that two otherwise equal location expressions would have the same opcode
sizes, but that's not always true with split dwarf because of LEB128
operands to the DW_OP_GNU_addr_index operator.]

Import pending patch from upstream to generate DW_AT_high_pc as a constant
offset relative to DW_AT_low_pc.  When splitting DWARF info, generate new
format for location list entries using a start symbol and a length.
Together, these changes reduce the size of the .debug_addr section by half.

Tested with GCC test suite and validate_failures.py.


2012-04-27  Mark Wielaard  
Cary Coutant  

include/
* dwarf2.h (enum dwarf_location_list_entry_type): New enum.

gcc/
* dwarf2out.c (enum dw_val_class): Add dw_val_class_high_pc.
(struct dw_loc_list_struct): Remove end_index.
(add_AT_low_high_pc): New function.
(AT_lbl): Handle dw_val_class_high_pc.
(print_die): Likewise.
(attr_checksum): Likewise.
(attr_checksum_ordered): Likewise.
(same_dw_val_p): Likewise.
(size_of_die): Likewise.
(value_format): Likewise.
(new_loc_list): Remove end_index.
(output_loc_list): Use new DW_LLE_start_length_entry format.
(output_die): Handle dw_val_class_high_pc.
(gen_subprogram_die): Use add_AT_low_high_pc.
(add_high_low_attributes): Likewise.
(compare_loc_operands): Relax irrelevant assertion when splitting
DWARF.
(index_location_lists): Remove end_index.
(dwarf2out_finish): Use add_AT_low_high_pc.


Index: include/dwarf2.h
===
--- include/dwarf2.h(revision 188123)
+++ include/dwarf2.h(working copy)
@@ -750,6 +750,17 @@ enum dwarf_line_number_x_ops
 DW_LNE_hi_user = 0xff
   };
 
+/* Type codes for location list entries.
+   Extension for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
+
+enum dwarf_location_list_entry_type
+  {
+DW_LLE_end_of_list_entry = 0,
+DW_LLE_base_address_selection_entry = 1,
+DW_LLE_start_end_entry = 2,
+DW_LLE_start_length_entry = 3
+  };
+
 /* Call frame information.  */
 enum dwarf_call_frame_info
   {
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 188123)
+++ gcc/dwarf2out.c (working copy)
@@ -4366,7 +4366,8 @@ enum dw_val_class
   dw_val_class_file,
   dw_val_class_data8,
   dw_val_class_decl_ref,
-  dw_val_class_vms_delta
+  dw_val_class_vms_delta,
+  dw_val_class_high_pc
 };
 
 /* Describe a floating point constant value, or a vector constant value.  */
@@ -4438,8 +4439,7 @@ typedef struct GTY(()) dw_loc_list_struc
   dw_loc_list_ref dw_loc_next;
   const char *begin; /* Label and index for begin address of range */
   unsigned int begin_index;
-  const char *end;  /* Label and index for end address of range */
-  unsigned int end_index;
+  const char *end;  /* Label for end address of range */
   char *ll_symbol; /* Label for beginning of location list.
  Only on head of list */
   const char *section; /* Section this loclist is relative to */
@@ -7566,6 +7566,26 @@ add_AT_data8 (dw_die_ref die, enum dwarf
   add_dwarf_attr (die, &attr);
 }
 
+/* Add DW_AT_low_pc and DW_AT_high_pc to a DIE.  */
+static inline void
+add_AT_low_high_pc (dw_die_ref die, const char *lbl_low, const char *lbl_high)
+{
+  dw_attr_node attr;
+
+  attr.dw_attr = DW_AT_low_pc;
+  attr.dw_attr_val.val_class = dw_val_class_lbl_id;
+  attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_low);
+  add_dwarf_attr (die, &attr);
+
+  attr.dw_attr = DW_AT_high_pc;
+  if (dwarf_version < 4)
+attr.dw_attr_val.val_class = dw_val_class_lbl_id;
+  else
+attr.dw_attr_val.val_class = dw_val_class_high_pc;
+  attr.dw_attr_val.v.val_lbl_id = xstrdup (lbl_high);
+  add_dwarf_attr (die, &attr);
+}
+
 /* Hash and equality functions for debug_str_hash.  */
 
 static hashval_t
@@ -8048,7 +8068,8 @@ AT_lbl (dw_attr_ref a)
 {
   gcc_assert (a && (AT_class (a) == dw_val_class_lbl_id
|| AT_class (a) == dw_val_class_lineptr
-   || AT_class (a) == dw_val_class_macptr));
+   || AT_class (a) == dw_val_class_macptr
+   || AT_class (a) == dw_val_class_high_pc));
   return a->dw_attr_val.v.val_lbl_id;
 }
 
@@ -8902,6 +8923,7 @@ print_die (dw_die_ref die, FILE *outfile
case dw_val_class_lbl_id:
case dw_val_class_lineptr:
case dw_val_class_macptr:
+   case dw_val_class_high_pc:
  fprintf (outfile, "label: %s", AT_lbl (a));
  break;
case dw_val_class_str:
@@ -9081,6 +9103,7 @@ attr_checksum (dw_attr_ref at, struct md
 case dw_val_class_lbl_id:
 case dw_val_class_lineptr:
 case dw_val_clas

[google/main] Copy TREE_STATIC() property from id in dwarf2asm.c (issue 6273045)

[asharif]

Reviewers: davidxl, xur, bjanakiraman_google.com,

Message:
A trunk version of this patch is already under review. I'm creating this
CL in order to get this patch in before the branch date.



Please review this at http://codereview.appspot.com/6273045/

Affected files:
  M gcc/ChangeLog.google-main
  M gcc/dwarf2asm.c


Index: gcc/dwarf2asm.c
===
--- gcc/dwarf2asm.c (revision 188129)
+++ gcc/dwarf2asm.c (working copy)
@@ -907,6 +907,7 @@
   DECL_IGNORED_P (decl) = 1;
   DECL_INITIAL (decl) = decl;
   TREE_READONLY (decl) = 1;
+  TREE_STATIC (decl) = TREE_STATIC(id);

   if (TREE_PUBLIC (id))
 {
@@ -915,8 +916,6 @@
   if (USE_LINKONCE_INDIRECT)
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
 }
-  else
-TREE_STATIC (decl) = 1;

   sym_ref = gen_rtx_SYMBOL_REF (Pmode, sym);
   assemble_variable (decl, 1, 1, 1);
Index: gcc/ChangeLog.google-main
===
--- gcc/ChangeLog.google-main   (revision 188129)
+++ gcc/ChangeLog.google-main   (working copy)
@@ -1,3 +1,8 @@
+2012-06-01   Ahmad Sharif  
+
+   * gcc/dwarf2asm.c: (dw2_output_indirect_constant_1) copy the TREE_STATIC
+   attribute from id to decl.
+
 2012-05-30  Dehao Chen  

* predict.c (predict_extra_loop_exit): New function to predict for

C++ PATCH for c++/52973 (wrong visibility with template base)

[Jason Merrill]

The change in 4.7 to properly restrict visibility of a class based on 
its template arguments exposed this bug: we were waiting until after the 
base list is parsed to apply attributes, so if a class is used as a 
template argument in its own base list, it has the wrong visibility in 
that context.  Fixed by applying infix attributes before parsing the 
base list.  Happily, this also allows us to stop passing attributes 
around so much.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit c9c80ae94d625b4bddb767441a90543db077127f
Author: Jason Merrill 
Date:   Fri Jun 1 23:24:36 2012 -0400

	PR c++/52973
	* parser.c (cp_parser_class_head): Apply attributes here.
	* semantics.c (begin_class_definition): Not here.
	* cp-tree.h: Adjust.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 626c61f..d21c2bf 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5585,7 +5585,7 @@ extern tree finish_fname			(tree);
 extern void finish_translation_unit		(void);
 extern tree finish_template_type_parm		(tree, tree);
 extern tree finish_template_template_parm   (tree, tree);
-extern tree begin_class_definition		(tree, tree);
+extern tree begin_class_definition		(tree);
 extern void finish_template_decl		(tree);
 extern tree finish_template_type		(tree, tree, int);
 extern tree finish_base_specifier		(tree, tree, bool);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7f9a94b..16139d6 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -2008,7 +2008,7 @@ static tree cp_parser_class_name
 static tree cp_parser_class_specifier
   (cp_parser *);
 static tree cp_parser_class_head
-  (cp_parser *, bool *, tree *, tree *);
+  (cp_parser *, bool *, tree *);
 static enum tag_types cp_parser_class_key
   (cp_parser *);
 static void cp_parser_member_specification_opt
@@ -17908,7 +17908,6 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   /* Parse the class-head.  */
   type = cp_parser_class_head (parser,
 			   &nested_name_specifier_p,
-			   &attributes,
 			   &bases);
   /* If the class-head was a semantic disaster, skip the entire body
  of the class.  */
@@ -17967,7 +17966,7 @@ cp_parser_class_specifier_1 (cp_parser* parser)
   scope = CP_DECL_CONTEXT (TYPE_MAIN_DECL (type));
   old_scope = push_inner_scope (scope);
 }
-  type = begin_class_definition (type, attributes);
+  type = begin_class_definition (type);
 
   if (type == error_mark_node)
 /* If the type is erroneous, skip the entire body of the class.  */
@@ -18224,7 +18223,6 @@ cp_parser_class_specifier (cp_parser* parser)
 static tree
 cp_parser_class_head (cp_parser* parser,
 		  bool* nested_name_specifier_p,
-		  tree *attributes_p,
 		  tree *bases)
 {
   tree nested_name_specifier;
@@ -18592,6 +18590,14 @@ cp_parser_class_head (cp_parser* parser,
   else if (type == error_mark_node)
 type = NULL_TREE;
 
+  if (type)
+{
+  /* Apply attributes now, before any use of the class as a template
+	 argument in its base list.  */
+  cplus_decl_attributes (&type, attributes, (int)ATTR_FLAG_TYPE_IN_PLACE);
+  fixup_attribute_variants (type);
+}
+
   /* We will have entered the scope containing the class; the names of
  base classes should be looked up in that context.  For example:
 
@@ -18618,7 +18624,6 @@ 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:
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 263ebc2..8fefce0 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2516,7 +2516,7 @@ check_template_template_default_arg (tree argument)
 /* Begin a class definition, as indicated by T.  */
 
 tree
-begin_class_definition (tree t, tree attributes)
+begin_class_definition (tree t)
 {
   if (error_operand_p (t) || error_operand_p (TYPE_MAIN_DECL (t)))
 return error_mark_node;
@@ -2573,9 +2573,6 @@ begin_class_definition (tree t, tree attributes)
   pushclass (t);
   TYPE_BEING_DEFINED (t) = 1;
 
-  cplus_decl_attributes (&t, attributes, (int) ATTR_FLAG_TYPE_IN_PLACE);
-  fixup_attribute_variants (t);
-
   if (flag_pack_struct)
 {
   tree v;
@@ -8696,7 +8693,7 @@ begin_lambda_type (tree lambda)
   xref_basetypes (type, /*bases=*/NULL_TREE);
 
   /* Start the class.  */
-  type = begin_class_definition (type, /*attributes=*/NULL_TREE);
+  type = begin_class_definition (type);
   if (type == error_mark_node)
 return error_mark_node;
 
diff --git a/gcc/objcp/objcp-decl.c b/gcc/objcp/objcp-decl.c
index ecc2b2b..8040469 100644
--- a/gcc/objcp/objcp-decl.c
+++ b/gcc/objcp/objcp-decl.c
@@ -49,7 +49,7 @@ objcp_start_struct (location_t loc ATTRIBUTE_UNUSED,
   CLASSTYPE_DECLARED_CLASS (s) = 0;  /* this is a 'struct', not a 'class'.  */
   xref_basetypes (s, NULL_TREE); /* no base classes here!  */
 
-  return begin_class_defi

Re: restore "do {" mistakenly taken out in SUBSUBTARGET_OVERRIDE_OPTIONS for ppc-vxworks

[Olivier Hainque]

On Jun 1, 2012, at 19:09 , Eric Botcazou wrote:

>>  * config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
>>  the "do {" part of the do-while(0) loop.
> 
> This is needed on the 4.7 branch as well.

 Hmm, I don't think so. The removal was part of the E500
 related reorg, which was not committed to the branch.

 Indeed, the original code, with both the E500 resets and
 the 'do {', is there.