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

[H.J. Lu]

On Fri, Jun 1, 2012 at 9:50 AM, Jason Merrill  wrote:
> 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.

This caused:

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

-- 
H.J.

Re: Allow use of ranges in copyright notices

[David Edelsohn]

On Sat, Jun 30, 2012 at 10:58 AM, Joseph S. Myers
 wrote:
> I propose that GCC should allow the use of ranges of years (e.g.
> 1987-2012) in copyright notices on source files.  As described at
> :
>
> * This requires a notice in README about the use of range notation; I
> propose such a notice below.
>
> * It is not necessary to track the modification dates of individual files,
> only the package as a whole; as there have been public GCC releases or
> public version control in each year from 1987 onwards, the form
> -2012 is OK for all GCC source files (whose source is in GCC
> rather than being copied from another package) as long as  is
> 1987 or later.
>
> Comments?  GDB and glibc already make active use of ranges (as does the
> Ada front end in GCC).  I think it's a useful cleanup to convert source
> files to the -2012 form, and to set up automatic updates of
> all files at the start of the year so people don't need to care about
> copyright notice updates for the rest of the year, but don't plan to work
> on these things myself.  (gnulib has a script that can help with both of
> those things.  glibc has been converting individual files to the single
> range form whenever the dates needed updating to include 2012, but may do
> a general bulk conversion later.)

IBM's policy specifies a comma:

, 

and not a dash range.

- David

Re: Coverage unlinking

[Nathan Sidwell]

On 06/24/12 01:14, Xinliang David Li wrote:

thanks for the fix. It works fine for me.


Thanks. I have committed it.

Allow use of ranges in copyright notices

[Joseph S. Myers]

I propose that GCC should allow the use of ranges of years (e.g. 
1987-2012) in copyright notices on source files.  As described at 
:

* This requires a notice in README about the use of range notation; I 
propose such a notice below.

* It is not necessary to track the modification dates of individual files, 
only the package as a whole; as there have been public GCC releases or 
public version control in each year from 1987 onwards, the form 
-2012 is OK for all GCC source files (whose source is in GCC 
rather than being copied from another package) as long as  is 
1987 or later.

Comments?  GDB and glibc already make active use of ranges (as does the 
Ada front end in GCC).  I think it's a useful cleanup to convert source 
files to the -2012 form, and to set up automatic updates of 
all files at the start of the year so people don't need to care about 
copyright notice updates for the rest of the year, but don't plan to work 
on these things myself.  (gnulib has a script that can help with both of 
those things.  glibc has been converting individual files to the single 
range form whenever the dates needed updating to include 2012, but may do 
a general bulk conversion later.)

2012-06-30  Joseph Myers  

* README: Document use of ranges of years in copyright notices.

Index: README
===
--- README  (revision 189094)
+++ README  (working copy)
@@ -15,3 +15,8 @@
 version of the manual is in the files gcc/doc/gcc.info*.
 
 See http://gcc.gnu.org/bugs/ for how to report bugs usefully.
+
+Copyright years on GCC source files may be listed using range
+notation, e.g., 1987-2012, indicating that every year in the range,
+inclusive, is a copyrightable year that could otherwise be listed
+individually.

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

[patch] Move lowering of switches to bit tests to GIMPLE

[Steven Bosscher]

Hello,

This patch moves the emit_case_bit_tests method of switch lowering
from 'expand' to a GIMPLE pass.

Initially, I planned to move all switch lowering to something other
than a casesi or tablejump to GIMPLE, but this is more involved than I
anticipated. My plan was (and still is, but for later) to do the
switch lowering using a divide-and-conquer approach: Parts of a switch
may be best expanded as bit-tests, other parts maybe as a decision
tree, and yet others as casesi/tablejump (the code in stmt.c uses only
one of these approaches per GIMPLE_SWITCH). Also I wanted to use
profile information in the lowering decision making (using Freescale's
patch as a basis). But I need to come up with a way to handle the SJLJ
dispatch table issue.

I'll continue to work on all of the above, and I hope I can finish
everything I planned to work on for GCC 4.8.
But to make sure I don't miss the GCC 4.8 stage1 deadline, I'm
proposing this for trunk now.

Bootstrapped&tested on powerpc64-unknown-linux-gnu - several times in
fact, over the past few months.
Bootstrapped&tested on x86_64-unknown-linux-gnu. Also built&tested on
various powerpc64 X embedded targets.

OK for trunk?

Ciao!
Steven


move_switch_as_case_bit_tests_to_GIMPLE.diff
Description: Binary data

Re: [patch] Remove CASE_USE_BIT_TESTS target macro

[Steven Bosscher]

On Sat, Jun 30, 2012 at 10:58 AM, Georg-Johann Lay  wrote:
> Steven Bosscher schrieb:
>>
>> Hello,
>>
>> This patch removes the CASE_USE_BIT_TESTS target macro. The default
>> value of the macro is defined in stmt.c, where the only user of the
>> macro is also. No target re-defines the macro.
>>
>> (I wonder if the test is necessary at all. AFAICT all targets support
>> shifts in word_mode. The macro was originally written to test for
>> ashlsi3, which is _not_ supported on all targets -- but word_mode
>> shifts are. Oh well, another day perhaps...)
>
>
> Even if a target supports ward_mode shifts with variable offsets
> it might be the case that it's not appropriate to use it in switch/case
> expansion because it is too expensive.
>
> For example, avr supports word_mode shifts but because there is no
> barrel shifter, a loop has to be used. Likewise for "odd" shift
> offsets with const_int offsets.

Cost is an orthogonal issue.

The CASE_USE_BIT_TESTS macro tests whether the operation is supported
at all for a target. There is a cost check after that to see if the
shift is cheap, see lshift_cheap_p().

Ciao!
Steven

Re: [patch] Remove CASE_USE_BIT_TESTS target macro

[Georg-Johann Lay]

Steven Bosscher schrieb:

Hello,

This patch removes the CASE_USE_BIT_TESTS target macro. The default
value of the macro is defined in stmt.c, where the only user of the
macro is also. No target re-defines the macro.

(I wonder if the test is necessary at all. AFAICT all targets support
shifts in word_mode. The macro was originally written to test for
ashlsi3, which is _not_ supported on all targets -- but word_mode
shifts are. Oh well, another day perhaps...)


Even if a target supports ward_mode shifts with variable offsets
it might be the case that it's not appropriate to use it in switch/case
expansion because it is too expensive.

For example, avr supports word_mode shifts but because there is no
barrel shifter, a loop has to be used. Likewise for "odd" shift
offsets with const_int offsets.

Johann


Bootstrapped and tested on powerpc64-unknown-linux-gnu. OK for trunk?

Ciao!
Steven


* stmt.c (CASE_USE_BIT_TESTS): Fold away into its only user ...
(expand_switch_using_bit_tests_p): ...here.
* doc/tm.texi.in (CASE_USE_BIT_TESTS): Remove documentation.
* doc/tm.texi (CASE_USE_BIT_TESTS): Regenerate.

Re: [RFC, ARM] later split of symbol_refs

[Georg-Johann Lay]

Dmitry Melnik schrieb:

On 06/27/2012 07:53 PM, Richard Earnshaw wrote:

Please update the ChangeLog entry (it's not appropriate to mention
Sourcery G++) and add a comment as Steven has suggested.

Otherwise OK.



Updated.
Ok to commit now?

--
Best regards,
  Dmitry

2009-05-29  Julian Brown  

gcc/
* config/arm/arm.md (movsi): Don't split symbol refs here.
(define_split): New.

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 0654564..98ff382 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -5472,14 +5472,6 @@
   optimize && can_create_pseudo_p ());
   DONE;
 }
-
-  if (TARGET_USE_MOVT && !target_word_relocations
- && GET_CODE (operands[1]) == SYMBOL_REF
- && !flag_pic && !arm_tls_referenced_p (operands[1]))
-   {
- arm_emit_movpair (operands[0], operands[1]);
- DONE;
-   }
 }
   else /* TARGET_THUMB1...  */
 {
@@ -5588,6 +5580,23 @@
   "
 )
 
+;; Split symbol_refs at the later stage (after cprop), instead of generating

+;; movt/movw pair directly at expand.  Otherwise corresponding high_sum
+;; and lo_sum would be merged back into memory load at cprop.  However,
+;; movt/movw is preferable, because it usually executes faster than a load.
+(define_split
+  [(set (match_operand:SI 0 "arm_general_register_operand" "")
+   (match_operand:SI 1 "general_operand" ""))]
+  "TARGET_32BIT
+   && TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF


Is there a special reason to restrict it to SYMBOL_REF?
Doesn't the same issue occur with, e.g.
(const (plus (symbol_ref const_int))) or label_ref?

Johann


+   && !flag_pic && !target_word_relocations
+   && !arm_tls_referenced_p (operands[1])"
+  [(clobber (const_int 0))]
+{
+  arm_emit_movpair (operands[0], operands[1]);
+  DONE;
+})
+
 (define_insn "*thumb1_movsi_insn"
   [(set (match_operand:SI 0 "nonimmediate_operand" "=l,l,l,l,l,>,l, m,*l*h*k")
(match_operand:SI 1 "general_operand"  "l, I,J,K,>,l,mi,l,*l*h*k"))]