RE: [RFC] Optimization to conditional and/or in ARM back-end

[Jiangning Liu]

> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Tuesday, November 22, 2011 1:14 PM
> To: Jiangning Liu
> Cc: gcc-patches@gcc.gnu.org; Richard Guenther; Richard Henderson
> Subject: Re: [RFC] Optimization to conditional and/or in ARM back-end
> 
> On Sun, Nov 20, 2011 at 6:17 PM, Jiangning Liu 
> wrote:
> > Hi,
> >
> > This patch is to implement a peephole like optimization in ARM back-
> end.
> >
> > If we have an if condition expression like "((r3 != 0) & r1) != 0",
> 
> So this is the same as:
> int f1(int r1, int r3)
> {
>   if (((r3 != 0) & r1) != 0)
> return g();
>   return 1;
> }
> --- CUT ---
> Can't you do this instead:
> Combine the following two instructions:
> (insn 17 15 18 2 (parallel [
> (set (reg:SI 150)
> (and:SI (ne:SI (reg:SI 0 r0 [ r1 ])
> (const_int 0 [0]))
> (reg:SI 1 r1 [ r3 ])))
> (clobber (reg:CC 24 cc))
> ]) t24.c:11 274 {*cond_arith}
>  (expr_list:REG_UNUSED (reg:CC 24 cc)
> (expr_list:REG_DEAD (reg:SI 1 r1 [ r3 ])
> (expr_list:REG_DEAD (reg:SI 0 r0 [ r1 ])
> (nil)
> 
> (insn 18 17 19 2 (set (reg:CC 24 cc)
> (compare:CC (reg:SI 150)
> (const_int 0 [0]))) t24.c:11 211 {*arm_cmpsi_insn}
>  (expr_list:REG_DEAD (reg:SI 150)
> (nil)))
> 
> And then have a pattern which expands it to (note the r3 here is the
> r3 in the function, likewise for r1):
> andi r1, r1, #1
> cmp r3, #0
> it  ne
> cmpne   r1, #0
> 
> Yes it is one extra instruction but it is still better than before
> right?

Hi Andrew,

Yes, and even the code generated can be like

cmp r3, #0
itt ne
andine  r1, r1, #1
cmpne   r1, #0

But this is not what I want. For performance purpose, I want to remove that 
andi instruction as well.

Also, actually if we don't modify r1, there might be other more optimization 
opportunities, for example register pressure can be reduced for some cases, I 
guess.

Thanks,
-Jiangning

Re: [PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks

[Tom de Vries]

On 17/11/11 17:53, Maxim Kuvyrkov wrote:
> On 17/11/2011, at 9:58 PM, Tom de Vries wrote:
> 
>> On 11/15/2011 10:07 PM, Maxim Kuvyrkov wrote:
>>> On 30/10/2011, at 8:17 AM, Tom de Vries wrote:
>>>
 Richard,

 I have a tentative fix for PR50764.
>>>
>>> Richard,
>>>
>>> Tom's patch is good (with the comments below addressed), and I would 
>>> appreciate you validating my review with your formal approval.
>>>
>>
>> Richard,
>>
>> Updated patch according to comments from Maxim. Added test-case. Bootstrapped
>> and reg-tested on x86_64.
>>
>> Ok for trunk?
>>

Ping.

Vladimir,

could you take a look at this patch?

Thanks,
- Tom

>> Thanks,
>> - Tom
>>
> ...
>> Index: gcc/sched-deps.c
>> ===
>> --- gcc/sched-deps.c (revision 181377)
>> +++ gcc/sched-deps.c (working copy)
>> @@ -2812,8 +2812,15 @@ sched_analyze_insn (struct deps_desc *de
>>  during prologue generation and avoid marking the frame pointer setup
>>  as frame-related at all.  */
>>   if (RTX_FRAME_RELATED_P (insn))
>> -deps->sched_before_next_jump
>> -  = alloc_INSN_LIST (insn, deps->sched_before_next_jump);
>> +{
>> +  /* Make sure prologue insn is scheduled before next jump.  */
>> +  deps->sched_before_next_jump
>> += alloc_INSN_LIST (insn, deps->sched_before_next_jump);
>> +
>> +  /* Make sure epilogue insn is scheduled after preceding jumps.  */
>> +  if (deps->pending_jump_insns)
> 
> You don't need this check, it's done anyway in add_dependence_list.  [No need 
> to resubmit or retest the patch after this change, it's trivial.]
> 
>> +add_dependence_list (insn, deps->pending_jump_insns, 1, REG_DEP_ANTI);
>> +}
>>
>>   if (code == COND_EXEC)
>> {
> 
> Thank you,
> 
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
> 
> 
> 
> 

[PATCH] PR c++/51143 - Alias template allows class definition

[Dodji Seketeli]

Hello,

As reminded in the audit trail of this PR, we shouldn't allow a type
definition in an alias template declaration.

Fixed thus, bootstrapped and tested on x86_64-unknown-linux-gnu
against trunk.

gcc/cp

PR c++/51143
* parser.c (cp_parser_alias_declaration): Don't allow type
definition in templates.

gcc/testsuite

PR c++/51143
* g++.dg/cpp0x/alias-decl-16.C: New test.
---
 gcc/cp/parser.c|   29 
 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C |   26 +
 2 files changed, 55 insertions(+), 0 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f839112..744ad3f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14940,6 +14940,7 @@ cp_parser_alias_declaration (cp_parser* parser)
   cp_declarator *declarator;
   cp_decl_specifier_seq decl_specs;
   bool member_p;
+  const char *saved_message = NULL;
 
   /* Look for the `using' keyword.  */
   cp_parser_require_keyword (parser, RID_USING, RT_USING);
@@ -14948,7 +14949,35 @@ cp_parser_alias_declaration (cp_parser* parser)
   attributes = cp_parser_attributes_opt (parser);
   cp_parser_require (parser, CPP_EQ, RT_EQ);
 
+  /* Now we are going to parse the type-id of the declaration.  */
+
+  /*
+[dcl.type]/3 says:
+
+   "A type-specifier-seq shall not define a class or enumeration
+unless it appears in the type-id of an alias-declaration (7.1.3) that
+is not the declaration of a template-declaration."
+
+In other words, if we currently are in an alias template, the
+type-id should not define a type.
+
+So let's set parser->type_definition_forbidden_message in that
+case; cp_parser_check_type_definition (called by
+cp_parser_class_specifier) will then emit an error if a type is
+defined in the type-id.  */
+  if (parser->num_template_parameter_lists)
+{
+  saved_message = parser->type_definition_forbidden_message;
+  parser->type_definition_forbidden_message =
+   G_("types may not be defined in alias template declarations");
+}
+
   type = cp_parser_type_id (parser);
+
+  /* Restore the error message if need be.  */
+  if (parser->num_template_parameter_lists)
+parser->type_definition_forbidden_message = saved_message;
+
   cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
 
   if (cp_parser_error_occurred (parser))
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
new file mode 100644
index 000..882e27b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
@@ -0,0 +1,26 @@
+// Origin PR c++/51143
+// { dg-options "-std=c++11" }
+
+template
+using A1 =
+struct B1 { // { dg-error "types may not be defined in alias template" }
+static auto constexpr value = N;
+};
+
+A1<0> a1;
+
+template
+using A2 =
+struct B2 {  // { dg-error "types may not be defined in alias template" }
+void f(T){}
+};
+
+A2 a2;
+
+template
+using A3 =
+enum B3 {b = 0;}; //{ dg-error "types may not be defined in alias 
template" }
+
+A3 a3;
+
+int main() { }
-- 
1.7.6.4


-- 
Dodji

Re: Ping! Re: [RFA/ARM][Patch 02/02]: ARM epilogues in RTL

[Sameera Deshpande]

On Fri, 2011-11-18 at 21:45 +, Ramana Radhakrishnan wrote:
> On 5 October 2011 17:04, Sameera Deshpande  wrote:
> > Ping!
> >
> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01855.html
> 
> 
> This should now be rebased given your other changes to the Thumb2
> epilogues patch or is there a newer version of this patch . This
> doesn't apply cleanly on top of the other patch.

Ramana, I have already sent the rebased patch at
gcc.gnu.org/ml/gcc-patches/2011-11/msg00885.html.
Can you please see if it is working? 

-- 

Re: [Patch RFA libitm] Deal with __USER_LABEL_PREFIX__ in the asm

[Iain Sandoe]

On 18 Nov 2011, at 17:36, Richard Henderson wrote:


On 11/18/2011 04:00 AM, Iain Sandoe wrote:

libitm:

   * config/x86/sjlj.S (CONCAT1, CONCAT2, SYM): Respond to
   __USER_LABEL_PREFIX__ for targets that use it.
   TYPE, SIZE, HIDDEN): New macros to assist on non-elf targets.
   (_ITM_beginTransaction): Use SYM, TYPE, SIZE macros to assist
   in portability to non-elf targets.
   (GTM_longjmp): LIkewise.
   * libitm_i.h (begin_transaction): Apply __USER_LABEL_PREFIX__
   where required.


Ok modulo the conflict you're going to have with RO's patch.
Adjust for his use of .hidden, of course, and the extra symbol ref.


This is what I applied (r181611) after checking I could build the lib  
on a cross to x86_64-unknown-linux and that the sjlj.S file assembled  
for the case where __USER_LABEL_PREFIX__ is not defined.

Iain

Index: libitm/libitm_i.h
===
--- libitm/libitm_i.h   (revision 181610)
+++ libitm/libitm_i.h   (working copy)
@@ -240,9 +240,15 @@
 
   // Invoked from assembly language, thus the "asm" specifier on
   // the name, avoiding complex name mangling.
+#ifdef __USER_LABEL_PREFIX__
+#define UPFX1(t) UPFX(t)
+#define UPFX(t) #t
   static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
+   __asm__(UPFX1(__USER_LABEL_PREFIX__) "GTM_begin_transaction") 
ITM_REGPARM;
+#else
+  static uint32_t begin_transaction(uint32_t, const gtm_jmpbuf *)
__asm__("GTM_begin_transaction") ITM_REGPARM;
-
+#endif
   // In eh_cpp.cc
   void revert_cpp_exceptions (gtm_transaction_cp *cp = 0);
 
Index: libitm/config/x86/sjlj.S
===
--- libitm/config/x86/sjlj.S(revision 181610)
+++ libitm/config/x86/sjlj.S(working copy)
@@ -25,12 +25,39 @@
 
 #include "asmcfi.h"
 
+#define CONCAT1(a, b) CONCAT2(a, b)
+#define CONCAT2(a, b) a ## b
+
+#ifdef __USER_LABEL_PREFIX__
+#  define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)
+#else
+#  define SYM(x) x
+#endif
+
+#ifdef __ELF__
+#  define TYPE(x) .type SYM(x), @function
+#  define SIZE(x) .size SYM(x), . - SYM(x)
+#  ifdef HAVE_ATTRIBUTE_VISIBILITY
+#define HIDDEN(x) .hidden SYM(x)
+#  else
+#define HIDDEN(x)
+#  endif
+#else
+#  define TYPE(x)
+#  define SIZE(x)
+#  ifdef __MACH__
+#define HIDDEN(x) .private_extern SYM(x)
+#  else
+#define HIDDEN(x)
+#  endif
+#endif
+
.text
 
.align 4
-   .globl  _ITM_beginTransaction
+   .globl  SYM(_ITM_beginTransaction)
 
-_ITM_beginTransaction:
+SYM(_ITM_beginTransaction):
cfi_startproc
 #ifdef __x86_64__
leaq8(%rsp), %rax
@@ -46,7 +73,7 @@
movq%r14, 48(%rsp)
movq%r15, 56(%rsp)
movq%rsp, %rsi
-   callGTM_begin_transaction
+   callSYM(GTM_begin_transaction)
addq$72, %rsp
cfi_def_cfa_offset(8)
ret
@@ -61,12 +88,12 @@
movl%ebp, 24(%esp)
leal8(%esp), %edx
 #if defined HAVE_ATTRIBUTE_VISIBILITY || !defined __PIC__
-   callGTM_begin_transaction
+   callSYM(GTM_begin_transaction)
 #elif defined __ELF__
call1f
 1: popl%ebx
addl$_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx
-   callGTM_begin_transaction@PLT
+   callSYM(GTM_begin_transaction)@PLT
movl12(%esp), %ebx
 #else
 # error "Unsupported PIC sequence"
@@ -77,15 +104,13 @@
 #endif
cfi_endproc
 
-#ifdef __ELF__
-   .type   _ITM_beginTransaction, @function
-   .size   _ITM_beginTransaction, .-_ITM_beginTransaction
-#endif
+   TYPE(_ITM_beginTransaction)
+   SIZE(_ITM_beginTransaction)
 
.align 4
-   .globl  GTM_longjmp
+   .globl  SYM(GTM_longjmp)
 
-GTM_longjmp:
+SYM(GTM_longjmp):
cfi_startproc
 #ifdef __x86_64__
movq(%rdi), %rcx
@@ -116,13 +141,9 @@
 #endif
cfi_endproc
 
-#ifdef __ELF__
-   .type   GTM_longjmp, @function
-#ifdef HAVE_ATTRIBUTE_VISIBILITY
-   .hidden GTM_longjmp
-#endif
-   .size   GTM_longjmp, .-GTM_longjmp
-#endif
+   TYPE(GTM_longjmp)
+   HIDDEN(GTM_longjmp)
+   SIZE(GTM_longjmp)
 
 #ifdef __linux__
 .section .note.GNU-stack, "", @progbits

Re: [Patch] make it possible for the target to rename ".tm_clone_table"

[Iain Sandoe]

On 21 Nov 2011, at 00:17, Richard Henderson wrote:


On 11/20/2011 05:34 AM, Iain Sandoe wrote:


gcc:

   * target.def (tm_clone_table_section): New hook.
   * doc/tm.texi.in (TARGET_ASM_TM_CLONE_TABLE_SECTION): Define.
   * doc/tm.texi: Regenerate.
   * varasm.c (dump_tm_clone_pairs): Use target  
tm_clone_table_section.

   * config/darwin.h (TARGET_ASM_TM_CLONE_TABLE_SECTION): New.
   * config/darwin-protos.h (darwin_tm_clone_table_section): New  
prototype.

   * config/darwin.c (darwin_tm_clone_table_section): New.

gcc/testsuite:

   * gcc.dg/tm/20100615.c: Adjust for Darwin tm_clone_table section  
name.


Ok.


This is what I committed (r181613)after accounting for:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02069.html
and
point 2 in http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02155.html
(and noting that I'd missed output.h from the original ChangeLog)

Iain

Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 181611)
+++ gcc/doc/tm.texi (working copy)
@@ -7090,6 +7090,10 @@ section names for mergeable constant data.  Define
 the string if a different section name should be used.
 @end deftypevr
 
+@deftypefn {Target Hook} {section *} TARGET_ASM_TM_CLONE_TABLE_SECTION (void)
+Return the section that should be used for transactional memory clone  tables.
+@end deftypefn
+
 @deftypefn {Target Hook} {section *} TARGET_ASM_SELECT_RTX_SECTION (enum 
machine_mode @var{mode}, rtx @var{x}, unsigned HOST_WIDE_INT @var{align})
 Return the section into which a constant @var{x}, of mode @var{mode},
 should be placed.  You can assume that @var{x} is some kind of
Index: gcc/doc/tm.texi.in
===
--- gcc/doc/tm.texi.in  (revision 181611)
+++ gcc/doc/tm.texi.in  (working copy)
@@ -7013,6 +7013,8 @@ otherwise.
 
 @hook TARGET_ASM_MERGEABLE_RODATA_PREFIX
 
+@hook TARGET_ASM_TM_CLONE_TABLE_SECTION
+
 @hook TARGET_ASM_SELECT_RTX_SECTION
 Return the section into which a constant @var{x}, of mode @var{mode},
 should be placed.  You can assume that @var{x} is some kind of
Index: gcc/target.def
===
--- gcc/target.def  (revision 181611)
+++ gcc/target.def  (working copy)
@@ -305,6 +305,13 @@ section names for mergeable constant data.  Define
 the string if a different section name should be used.",
  const char *, ".rodata")
 
+/* Return the section to be used for transactional memory clone tables.  */
+DEFHOOK
+(tm_clone_table_section,
+ "Return the section that should be used for transactional memory clone\
+  tables.",
+ section *, (void), default_clone_table_section)
+
 /* Output a constructor for a symbol with a given priority.  */
 DEFHOOK
 (constructor,
Index: gcc/testsuite/gcc.dg/tm/20100615.c
===
--- gcc/testsuite/gcc.dg/tm/20100615.c  (revision 181611)
+++ gcc/testsuite/gcc.dg/tm/20100615.c  (working copy)
@@ -3,7 +3,8 @@
 
 /* Since the non TM version of new_node() gets optimized away, it
shouldn't appear in the clone table either.  */
-/* { dg-final { scan-assembler-not "tm_clone_table" } } */
+/* { dg-final { scan-assembler-not "tm_clone_table" { target { ! *-*-darwin*  
} } } } */
+/* { dg-final { scan-assembler-not "__DATA,__tm_clone_table" { target 
*-*-darwin*  } } } */
 
 #define NULL 0
 extern void *malloc (__SIZE_TYPE__);
Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 181611)
+++ gcc/varasm.c(working copy)
@@ -5961,7 +5961,7 @@ dump_tm_clone_pairs (VEC(tm_alias_pair,heap) *tm_a
 
   if (!switched)
{
- switch_to_section (get_named_section (NULL, ".tm_clone_table", 3));
+ switch_to_section (targetm.asm_out.tm_clone_table_section ());
  assemble_align (POINTER_SIZE);
  switched = true;
}
@@ -5973,6 +5973,14 @@ dump_tm_clone_pairs (VEC(tm_alias_pair,heap) *tm_a
 }
 }
 
+/* Provide a default for the tm_clone_table section.  */
+
+section *
+default_clone_table_section (void)
+{
+  return get_named_section (NULL, ".tm_clone_table", 3);
+}
+
 /* Helper comparison function for qsorting by the DECL_UID stored in
alias_pair->emitted_diags.  */
 
Index: gcc/output.h
===
--- gcc/output.h(revision 181611)
+++ gcc/output.h(working copy)
@@ -638,6 +638,7 @@ extern section *default_elf_select_section (tree,
 extern void default_unique_section (tree, int);
 extern section *default_function_rodata_section (tree);
 extern section *default_no_function_rodata_section (tree);
+extern section *default_clone_table_section (void);
 extern section *default_select_rtx_section (enum machine_mode, rtx,
unsigned HOST_WIDE_INT);
 extern section *default_elf_select_rtx_section (enum machine_mod

RE: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

[Sameera Deshpande]

On Tue, 2011-11-22 at 01:55 +, Xinyu Qi wrote:
> At 2011-11-19 07:11:17,"Ramana Radhakrishnan" 
>  wrote:
> > On 10 November 2011 18:07, Sameera Deshpande
> >  wrote:
> > > Please find attached the reworked patch.
> > 
> > OK but for a very small bit .
> > 
> > I'll note that we need to add support for the iwMMXt registers but the
> > attached patch (untested) should be what is needed to support the iwMMxt
> > registers and this should be something that should be incorporated into your
> > ARM RTL epilogues patch as well. My understanding is that this is all you
> > should need to do as there is a wldrd as a part of *iwmmx*_movdi instruction
> > and therefore this should just work in this form.
> > 
> > Xinyu can you help in testing this patch once this is applied along with 
> > your
> > other patches to turn on Thumb2 for iwmmxt ?
> > 
> > cheers
> > Ramana
> 
> Hi, Ramana,
> 
> Though I don't fully understand this patch, I think it is unnecessary to 
> consider turn on Thumb2 for iwmmxt,
> because there is no chip that supports WMMX instructions with thumb2 mode.
> 
> Thanks,
> Xinyu
> 

Ramana, in that case, should I add the change you suggested in ARM RTL
epilogue patch only?

-- 

Re: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

[Ramana Radhakrishnan]

>>
>> Though I don't fully understand this patch, I think it is unnecessary to 
>> consider turn on Thumb2 for iwmmxt,
>> because there is no chip that supports WMMX instructions with thumb2 mode.

Xinyu: I seem to have mis-remembered that one of your patches was
turning on Thumb2 for wMMX.

>
> Ramana, in that case, should I add the change you suggested in ARM RTL
> epilogue patch only?

The comment in Thumb2 epilogues should remain and yes - it should be
added to the ARM RTL epilogue patch only. I'm also ok with that being
in with a #if 0 around it but given it's in the epilogue whoever tries
turning on Thumb2 for iwMMX will surely notice that in the first
testrun :)

I'll try and find some time later today to apply both the patches and
see where I get to.

cheers
Ramana

>
> --
>
>
>

Re: [PR 47382] We cannot simply fold OBJ_TYPE_REF at all in 4.6

[Martin Jambor]

Hi,

On Tue, Nov 22, 2011 at 07:45:39PM +1300, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> 
> > On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
> > 
> >> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
> >> 
> >>> However, both of these are really 4.8 material and since the patches
> >>> probably need only minor updates, it might be worthwhile to do that so
> >>> that gcc can handle the "embarrassing" simple cases.  So I will do
> >>> that (though it might need to wait for about a week), re-try them on
> >>> Firefox and probably propose them for submission.
> >> 
> >> Great!  Thank you.
> > 
> > Here is one of your patches updated to the latest mainline.  Just add 
> > water^W changelog.
> > 
> > It bootstraps, and I'm regtesting it on x86_64-linux-gnu {-m64,-m32} now.
> 
> Ping.
> 
> Martin, do you plan to have this pushed in for GCC 4.7?
> 

well, there were two patches.  I have managed to update and push
trough one of them in time
(http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00086.html) but
unfortunately I have not managed to do the same with the second one.
It's recent incarnation is here: 

http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00095.html

However, since the stage 1 ended and I still wasn't able to
demonstrate any real impact anywhere (other than my semi-silly example
attached to that patch), I gave up.  It is unfortunate but I also had
other pressing tasks and the patch does not do anything on simple
programs and I have not been able to compile Firefox even without LTO
with the current trunk to try it on something complex.

Therefore at the moment I see no other option but to queue it to stage 1
again.

Thanks,

Martin

Re: Fix PR rtl-optimization/51187

[Eric Botcazou]

> I saw this also when I looked into __builtin_unreachable in one bug
> report at one point on MIPS.  See
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054#c1 .

Yes, the Debian folks also saw the problem on other architectures.

-- 
Eric Botcazou

[C++ Patch] PR 51196

[Paolo Carlini]

Hi,

as also analyzed in the audit trail, we fail to produce the warning for 
pointer to member function == 0 (those for assignments and 
initializations are fine) for targets characterized by 
TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, for the 
obvious reason that in cp_build_binary_op we do not end up calling 
cp_convert (with integer_zero_node as second argument) and then 
cp_convert_to_pointer, something else entirely happens. But in 
cp_build_binary_op we have all the information we need in this case, 
thus the fix involves just doing the warning check here. I tried to 
figure out whether we could do something else, less "dumb" so to speak, 
but failed at that. Anyway, fix tested by me on x86_64-linux and both me 
and Greta on arm-none-eabi.


Ok?

Thanks,
Paolo.

//
2011-11-22  Paolo Carlini  

PR c++/51196
* typeck.c (cp_build_binary_op, [case EQ_EXPR]): For targets having
TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, do here
the -Wzero-as-null-pointer-constant warning for pmf == 0.
Index: typeck.c
===
--- typeck.c(revision 181613)
+++ typeck.c(working copy)
@@ -4056,6 +4056,13 @@ cp_build_binary_op (location_t location,
delta0,
integer_one_node,
complain);
+ 
+ if ((complain & tf_warning)
+ && c_inhibit_evaluation_warnings == 0
+ && !NULLPTR_TYPE_P (TREE_TYPE (op1)))
+   warning (OPT_Wzero_as_null_pointer_constant,
+"zero as null pointer constant");
+
  e2 = cp_build_binary_op (location,
   EQ_EXPR, e2, integer_zero_node,
   complain);

Re: [PATCH][PING^3] Vectorize conversions directly

[Dmitry Plotnikov]

Ping.  The ARM portion of this patch is still awaiting approval.

On 11/08/2011 12:35 PM, Dmitry Plotnikov wrote:

Ping.

On 10/28/2011 12:22 PM, Dmitry Plotnikov wrote:

Here is the patch updated according to recent comments.

2011-10-28 Dmitry Plotnikov 

gcc/
* tree-cfg.c (verify_gimple_assign_unary): Allow vector conversions.
* optabs.c (supportable_convert_operation): New function.
* optabs.h (supportable_convert_operation): New prototype.
* tree-vect-stmts.c (vectorizable_conversion): Change condition and
behavior
for NONE modifier case.
* tree.h (VECTOR_INTEGER_TYPE_P): New macro.

gcc/config/arm/
* neon.md (floatv2siv2sf2): New.
(floatunsv2siv2sf2): New.
(fix_truncv2sfv2si2): New.
(fix_truncunsv2sfv2si2): New.
(floatv4siv4sf2): New.
(floatunsv4siv4sf2): New.
(fix_truncv4sfv4si2): New.
(fix_truncunsv4sfv4si2): New.

gcc/testsuite/
* gcc.target/arm/vect-vcvt.c: New test.
* gcc.target/arm/vect-vcvtq.c: New test.

gcc/testsuite/lib/
* target-supports.exp (check_effective_target_vect_intfloat_cvt): True
for ARM NEON.
(check_effective_target_vect_uintfloat_cvt): Likewise.
(check_effective_target_vect_intfloat_cvt): Likewise.
(check_effective_target_vect_floatuint_cvt): Likewise.
(check_effective_target_vect_floatint_cvt): Likewise.
(check_effective_target_vect_extract_even_odd): Likewise.

Re: Re-merge crtstuff.c from the trans-mem branch

[Rainer Orth]

Richard Henderson  writes:

> On 11/21/2011 02:13 PM, Richard Henderson wrote:
>> This was actually a merge error on the branch.  When crtstuff.c
>> moved to libgcc/, Aldy failed to copy the changes.
>> 
>> I've tidied things even a bit more from the branch, with the
>> introduction of the USE_TM_CLONE_REGISTRY control macro, which
>> is in turn now predicated on ELF.
>> 
>> Tested on x86_64-linux.  I'm really not sure what non-elf
>> targets really use this file...
>
> It has been pointed out to me that I'm an idiot and sent an empty attachment.
> So lets try this again...

This patch broke bootstrap on Solaris 8 and 9/x86 with Sun as which
doesn't support .hidden: linking the stage2 lto-plugin fails like this:

ld: fatal: relocation error: R_386_GOTOFF: file 
/var/gcc/regression/trunk/8-gcc/build/./prev-gcc/crtbegin.o: symbol 
__TMC_END__: relocation must bind locally
collect2: error: ld returned 1 exit status
make[4]: *** [liblto_plugin.la] Error 1

Rainer

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

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

[Aldy Hernandez]

On 11/21/11 18:55, Richard Henderson wrote:

On 11/18/2011 01:24 PM, Aldy Hernandez wrote:

-  if (DECL_COMDAT (new_decl))
+  if (DECL_COMDAT (new_decl)&&  HAVE_COMDAT_GROUP)
  DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
+  else
+DECL_COMDAT_GROUP (new_decl) = DECL_COMDAT_GROUP (old_decl);


This looks weird -- you're seting D_C_G after H_C_G is false?

We've already done copy_decl anyway -- you should be able to drop the else.


r~


David, can you try the following and see if it fixes the problem on your 
end?


Index: trans-mem.c
===
--- trans-mem.c (revision 181588)
+++ trans-mem.c (working copy)
@@ -4198,7 +4198,7 @@ ipa_tm_create_version_alias (struct cgra
   TREE_SYMBOL_REFERENCED (tm_name) = 1;

   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP 
(old_decl));


   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);
@@ -4233,7 +4233,7 @@ ipa_tm_create_version (struct cgraph_nod
   TREE_SYMBOL_REFERENCED (tm_name) = 1;

   /* Perform the same remapping to the comdat group.  */
-  if (DECL_COMDAT (new_decl))
+  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
 DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP 
(old_decl));


   new_node = cgraph_copy_node_for_versioning (old_node, new_decl, 
NULL, NULL);

Re: Support enforcing use of libgcc_s even with LINK_EH_SPEC

[Michael Matz]

Hi,

On Mon, 21 Nov 2011, Jakub Jelinek wrote:

> On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote:
> > 2011-11-20  Rainer Orth  
> > 
> > * gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use
> > libgcc_s.
> > * config/sol2.h [USE_GLD] (USE_SHARED_LIBGCC_FOR_EH): Define.
> 
> That's an ugly hack.  IMHO we just want to do what has been discussed
> earlier, ensure that generated EH info and code generation isn't actually
> pessimized because of the clobbers, at least not in the common cases.

I'm working on something that will hopefully work for the outermost 
finally block.  But it won't be ready today.


Ciao,
Michael.

Re: [PATCH][PING] Vectorize conversions directly

[Ramana Radhakrishnan]

Sorry , it's taken me a while to get to this.

On 28 October 2011 09:22, Dmitry Plotnikov  wrote:
>
> gcc/config/arm/
>    * neon.md (floatv2siv2sf2): New.
>      (floatunsv2siv2sf2): New.
>      (fix_truncv2sfv2si2): New.
>      (fix_truncunsv2sfv2si2): New.
>      (floatv4siv4sf2): New.
>      (floatunsv4siv4sf2): New.
>      (fix_truncv4sfv4si2): New.
>      (fix_truncunsv4sfv4si2): New.

It would have been better to write these in the iterator forms as well
as is the style in all neon.md. Also, you are missing neon_type
attributes - therefore these would be treated as being standard ALU
instructions rather than the neon instructions and hence would flow
through the ALU pipeline description . In the V2SI / V2SF case,  these
instructions should have a neon_type of  neon_fp_vadd_ddd_vabs_dd and
the V4SI / V4SF case treat them as having a neon type of
neon_fp_vadd_qqq_vabs_qq.

For bonus points integrate this with the patterns already defined for
the neon intrinsics expansion and thus essentially remove the UNSPEC's
from the neon_vcvt patterns. Thus essentially converting your
define_insn patterns to define_expands and massaging the whole thing
through.


>
> gcc/testsuite/
>    * gcc.target/arm/vect-vcvt.c: New test.
>    * gcc.target/arm/vect-vcvtq.c: New test.

There's no need for -mvectorize-with-neon-quad in the tests. That is
the default these days on trunk.

>
> gcc/testsuite/lib/
>    * target-supports.exp (check_effective_target_vect_intfloat_cvt): True
>      for ARM NEON.
>      (check_effective_target_vect_uintfloat_cvt): Likewise.
>      (check_effective_target_vect_intfloat_cvt): Likewise.
>      (check_effective_target_vect_floatuint_cvt): Likewise.
>      (check_effective_target_vect_floatint_cvt): Likewise.
>      (check_effective_target_vect_extract_even_odd): Likewise.

I'm not sure about enabling the vect_extract_even_odd case. If this
assumes the presence of an extract-even-odd from registers type
operation, then the Neon port doesn't really support vec_extract_even
/ vec_extract_odd forms -  You do have them in one single instruction
if you tried to load them from / or store them to memory which is the
vld2 / vst2 instruction while the register form of vuzp which reads
and writes to both source operands is not really supported directly
from the backend.

The other testsuite changes look OK to me.

cheers
Ramana

>

[obvious] Fix PR51264

[Michael Matz]

Hi,

there's a superfluous break in a switch in tree.c, which together with the 
object clobbers confuses our warning machinery at -O0, leading to a 
bootstrap fail for Tom.  As we have testcases for that already in PR20681 
there's no need in GCCs source base itself to contain something like this.

Hence this patch.  Regstrapped on x86_64-linux, no regressions.  Checked 
in as r181615.


Ciao,
Michael.
PR c++/51264
* tree.c (iterative_hash_expr): Remove break after return.

Index: tree.c
===
--- tree.c  (revision 181582)
+++ tree.c  (working copy)
@@ -6994,7 +6994,6 @@ iterative_hash_expr (const_tree t, hashv
  val = iterative_hash_expr (TREE_OPERAND (t, i), val);
}
   return val;
-  break;
 }
 }
 

Re: [Patch RFC Darwin] provide the crt stuff for tm.

[Iain Sandoe]

On 21 Nov 2011, at 18:54, Richard Henderson wrote:


On 11/21/2011 01:17 AM, Iain Sandoe wrote:
1. should I be applying this constructor/destructor pair to shared  
libraries as well?

(the specs need minor amendment)


Yes.


this is what I applied (r181616)after checking that dylibs, bundles  
and executables get the c/dtors added

 (only when -fgnu-tm is given, so we don't add them for everything).

I don't have any test-cases to prove that anything other than a plain  
executable works - this is a TODO once the basic facility is working.


Iain

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 181614)
+++ libgcc/config.host  (working copy)
@@ -170,7 +170,7 @@ case ${host} in
 *-*-darwin*)
   asm_hidden_op=.private_extern
   tmake_file="$tmake_file t-darwin ${cpu_type}/t-darwin t-libgcc-pic 
t-slibgcc-darwin"
-  extra_parts=crt3.o
+  extra_parts="crt3.o crttms.o crttme.o"
   ;;
 *-*-freebsd*)
   # This is the generic ELF configuration of FreeBSD.  Later
Index: libgcc/config/t-darwin
===
--- libgcc/config/t-darwin  (revision 181614)
+++ libgcc/config/t-darwin  (working copy)
@@ -3,6 +3,12 @@ crt3.o: $(srcdir)/config/darwin-crt3.c
$(crt_compile) \
  -fno-tree-dominator-opts $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -c $<
 
+crttms.o: $(srcdir)/config/darwin-crt-tm.c
+   $(crt_compile) $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -DSTART -c $<
+
+crttme.o: $(srcdir)/config/darwin-crt-tm.c
+   $(crt_compile) $(DARWIN_EXTRA_CRT_BUILD_CFLAGS) -DEND -c $<
+
 # -pipe because there's an assembler bug, 4077127, which causes
 # it to not properly process the first # directive, causing temporary
 # file names to appear in stabs, causing the bootstrap to fail.  Using -pipe
Index: libgcc/config/darwin-crt-tm.c
===
--- libgcc/config/darwin-crt-tm.c   (revision 0)
+++ libgcc/config/darwin-crt-tm.c   (revision 0)
@@ -0,0 +1,83 @@
+/* Provide the runtime intrastructure the transactional memory lib.
+   Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Iain Sandoe 
+
+   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
+.  */
+
+#include 
+
+/* not listed in mach-o/dyld.h for some reason.  */
+extern char * getsectdata (const char*,const char*,unsigned long*); 
+
+#define WEAK __attribute__((weak))
+
+#ifndef ATTRIBUTE_UNUSED
+#define ATTRIBUTE_UNUSED __attribute__((unused))
+#endif
+
+extern void _ITM_registerTMCloneTable (void *, size_t) WEAK;
+extern void _ITM_deregisterTMCloneTable (void *) WEAK;
+
+#ifdef START
+
+void __doTMRegistrations (void) __attribute__ ((constructor));
+
+void __doTMRegistrations (void)
+{
+  char * tm_clone_table_sect_data;
+  unsigned long tmct_siz;
+  
+  tm_clone_table_sect_data = getsectdata ("__DATA",
+ "__tm_clone_table",
+ &tmct_siz);
+  tmct_siz /= (sizeof (size_t) * 2);
+  if (_ITM_registerTMCloneTable != NULL
+  && tm_clone_table_sect_data != NULL
+  && tmct_siz > 0)
+_ITM_registerTMCloneTable (tm_clone_table_sect_data, (size_t)tmct_siz);
+}
+
+#endif
+
+#ifdef END
+
+void __doTMdeRegistrations (void) __attribute__ ((destructor));
+
+void __doTMdeRegistrations (void)
+{
+  char * tm_clone_table_sect_data;
+  unsigned long tmct_siz;
+  
+  tm_clone_table_sect_data = getsectdata ("__DATA",
+ "__tm_clone_table",
+ &tmct_siz);
+  
+  if (_ITM_deregisterTMCloneTable != NULL
+  && tm_clone_table_sect_data != NULL
+  && tmct_siz > 0)
+_ITM_deregisterTMCloneTable (tm_clone_table_sect_data);
+
+}
+
+/* Provide dumy funcs for the weak ones - needed on most Darwin versions
+   for now.  */
+
+void _ITM_registerTMCloneTable (void *n ATTRIBUTE_UNUSED, size_t s 
ATTRIBUTE_UNUSED)
+{}
+void _ITM_deregisterTMCloneTable (void *n ATTRIBUTE_UNUSED)
+{}
+#endif
Index: gcc/config/i386/darwin.h
===
--- gcc/config/i386/darwin.h(revision 181614)
+++ gcc/config/i386/darwin.h(working copy)
@@ -132,7 +132,8 @@ extern int darwin_emit_branch_islands;
   "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
%{mpc32:crtprec32.o%s} \
 

Re: PR other/51174: handle architectures with no DECL_COMDAT_GROUP

[David Edelsohn]

On Tue, Nov 22, 2011 at 8:06 AM, Aldy Hernandez  wrote:

>> This looks weird -- you're seting D_C_G after H_C_G is false?
>>
>> We've already done copy_decl anyway -- you should be able to drop the
>> else.

> David, can you try the following and see if it fixes the problem on your
> end?
>
> Index: trans-mem.c
> ===
> --- trans-mem.c (revision 181588)
> +++ trans-mem.c (working copy)
> @@ -4198,7 +4198,7 @@ ipa_tm_create_version_alias (struct cgra
>   TREE_SYMBOL_REFERENCED (tm_name) = 1;
>
>   /* Perform the same remapping to the comdat group.  */
> -  if (DECL_COMDAT (new_decl))
> +  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
>     DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
>
>   new_node = cgraph_same_body_alias (NULL, new_decl, info->new_decl);
> @@ -4233,7 +4233,7 @@ ipa_tm_create_version (struct cgraph_nod
>   TREE_SYMBOL_REFERENCED (tm_name) = 1;
>
>   /* Perform the same remapping to the comdat group.  */
> -  if (DECL_COMDAT (new_decl))
> +  if (HAVE_COMDAT_GROUP && DECL_COMDAT (new_decl))
>     DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
>
>   new_node = cgraph_copy_node_for_versioning (old_node, new_decl, NULL,
> NULL);
>

I assume this will work because AIX never uses the info in DECL_COMDAT_GROUP.

Note that ipa_tm_create_version() calls copy_node(), but
ipa_tm_create_version_alias() *DOES NOT*, it calls build_decl(), so
D_C_G will be garbage.

Yes, setting D_C_G looks strange with !H_C_G, but note that many
places in GCC blindly copy D_C_G or initialize it to 0.

- David

Re: [C++ Patch] PR 51196

[Jason Merrill]

OK.

Jason

Re: [PATCH] PR c++/51143 - Alias template allows class definition

[Jason Merrill]

Do we have a test for allowing a class definition in a non-template 
alias definition?  If not, please add that too.  OK with that change.


Jason

Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

[Jason Merrill]

On 11/21/2011 11:41 AM, Dodji Seketeli wrote:

-template class Ptr;//{ dg-error "explicit instantiation|non-class templ|does 
not decl|anything" }
+template class Ptr;//{ dg-error "alias 
templ|specialization|Ptr|after|class" }


You seem to be using | to mean .* here.  Let's choose one key phrase to 
check for.  :)



-struct A { typedef int X; };// { dg-error "previous declaration" }
+struct A { typedef int X; };


Let's change dg-error to dg-message instead of dropping the check 
entirely on at least one of these tests to avoid a diagnostic quality 
regression.


OK with those changes.

Jason

[committed] Add testcase for PR tree-optimization/50765

[Jakub Jelinek]

Hi!

This PR got fixed by my recent vectorizable_conversion changes,
in particular the truncation of the vec_oprnds[01] vectors on
multistep type promotion if copies > 1.

Testcase tested on x86_64-linux and i686-linux, checked in as obvious.

2011-11-22  Jakub Jelinek  

PR tree-optimization/50765
* gcc.dg/pr50765.c: New test.

--- gcc/testsuite/gcc.dg/pr50765.c.jj   2011-11-22 11:43:17.614794630 +0100
+++ gcc/testsuite/gcc.dg/pr50765.c  2011-11-22 11:43:05.0 +0100
@@ -0,0 +1,10 @@
+/* PR tree-optimization/50765 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-tree-dce" } */
+
+void
+foo (long *w, long *x, unsigned char *y, int z)
+{
+  for (; z < 429; z++)
+w[z] = (-19 ^ y[z]) & x[z];
+}

Jakub

[PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)

[Jakub Jelinek]

Hi!

VEC_INTERLEAVE_*_EXPR trees are unfortunately dependent on BYTES_BIG_ENDIAN,
what is HIGH vs. LOW is different based on endianity.
The only place that creates these in the IL is:
  if (BYTES_BIG_ENDIAN)
{
  high_code = VEC_INTERLEAVE_HIGH_EXPR;
  low_code = VEC_INTERLEAVE_LOW_EXPR;
}
  else
{
  low_code = VEC_INTERLEAVE_HIGH_EXPR;
  high_code = VEC_INTERLEAVE_LOW_EXPR;
}
  perm_stmt = gimple_build_assign_with_ops (high_code, perm_dest,
vect1, vect2);
...
so either folding (and expansion if only vec_perm* is supported) needs to
be adjusted as done in the patch below, or we'd need to rename them
to VEC_INTERLEAVE_{FIRST,SECOND}_EXPR or similar and adjust all the patterns
etc.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested on the
testcase using powerpc cross.  Ok for trunk?

2011-11-22  Jakub Jelinek  

PR tree-optimization/51074
* fold-const.c (fold_binary_loc): Fix up VEC_INTERLEAVE_*_EXPR
handling for BYTES_BIG_ENDIAN.
* optabs.c (can_vec_perm_for_code_p): Likewise.

* gcc.dg/vect/pr51074.c: New test.

--- gcc/fold-const.c.jj 2011-11-21 16:22:02.0 +0100
+++ gcc/fold-const.c2011-11-22 09:59:15.606739333 +0100
@@ -13483,10 +13483,12 @@ fold_binary_loc (location_t loc,
sel[i] = i * 2 + 1;
break;
  case VEC_INTERLEAVE_HIGH_EXPR:
-   sel[i] = (i + nelts) / 2 + ((i & 1) ? nelts : 0);
+   sel[i] = (i + (BYTES_BIG_ENDIAN ? 0 : nelts)) / 2
++ ((i & 1) ? nelts : 0);
break;
  case VEC_INTERLEAVE_LOW_EXPR:
-   sel[i] = i / 2 + ((i & 1) ? nelts : 0);
+   sel[i] = (i + (BYTES_BIG_ENDIAN ? nelts : 0)) / 2
++ ((i & 1) ? nelts : 0);
break;
  default:
gcc_unreachable ();
--- gcc/optabs.c.jj 2011-11-21 16:22:02.0 +0100
+++ gcc/optabs.c2011-11-22 10:17:04.820399126 +0100
@@ -6932,9 +6932,9 @@ can_vec_perm_for_code_p (enum tree_code
  break;
 
case VEC_INTERLEAVE_HIGH_EXPR:
- alt = nelt / 2;
- /* FALLTHRU */
case VEC_INTERLEAVE_LOW_EXPR:
+ if ((BYTES_BIG_ENDIAN != 0) ^ (code == VEC_INTERLEAVE_HIGH_EXPR))
+   alt = nelt / 2;
  for (i = 0; i < nelt / 2; ++i)
{
  data[i * 2] = i + alt;
--- gcc/testsuite/gcc.dg/vect/pr51074.c.jj  2011-11-22 10:22:44.247377928 
+0100
+++ gcc/testsuite/gcc.dg/vect/pr51074.c 2011-11-22 10:22:16.0 +0100
@@ -0,0 +1,24 @@
+/* PR tree-optimization/51074 */
+
+#include "tree-vect.h"
+
+struct S { int a, b; } s[8];
+
+int
+main ()
+{
+  int i;
+  check_vect ();
+  for (i = 0; i < 8; i++)
+{
+  s[i].b = 0;
+  s[i].a = i;
+}
+  asm volatile ("" : : : "memory");
+  for (i = 0; i < 8; i++)
+if (s[i].b != 0 || s[i].a != i)
+  abort ();
+  return 0;
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */

Jakub

[PATCH] fix DO_STMT comment in cp-tree.def.

[Tom de Vries]

Richard,

The comment at DO_STMT led me to believe that DO_BODY was the first operand.

cp-tree.def:
...
./* Used to represent a 'do' statement. The operands are DO_BODY and
   DO_COND, respectively.  */
DEFTREECODE (DO_STMT, "do_stmt", tcc_statement, 2)
..

However, in cp-tree.h we see that DO_BODY is actually the second operand:
...
/* DO_STMT accessors. These give access to the condition of the do
   statement and the body of the do statement, respectively.  */
#define DO_COND(NODE)   TREE_OPERAND (DO_STMT_CHECK (NODE), 0)
#define DO_BODY(NODE)   TREE_OPERAND (DO_STMT_CHECK (NODE), 1)
...

The patch fixes the comment.

OK for trunk?

Thanks,
- Tom


2011-11-22  Tom de Vries  

* cp-tree.def (DO_STMT): Fix comment.
Index: gcc/cp/cp-tree.def
===
--- gcc/cp/cp-tree.def (revision 181172)
+++ gcc/cp/cp-tree.def (working copy)
@@ -308,8 +308,8 @@ DEFTREECODE (RANGE_FOR_STMT, "range_for_
and WHILE_BODY, respectively.  */
 DEFTREECODE (WHILE_STMT, "while_stmt", tcc_statement, 2)
 
-/* Used to represent a 'do' statement. The operands are DO_BODY and
-   DO_COND, respectively.  */
+/* Used to represent a 'do' statement. The operands are DO_COND and
+   DO_BODY, respectively.  */
 DEFTREECODE (DO_STMT, "do_stmt", tcc_statement, 2)
 
 /* Used to represent a 'break' statement.  */

[Patch libitm] minor adjustment to make flags.

[Iain Sandoe]

Hi,
since:
libitm_la_LDFLAGS
are now correctly applied Darwin no longer gets the "-Wl,- 
undefined,dynamic_lookup"
(which I had mentioned before was surprising me with -no-undefined in  
libitm_la_LDFLAGS).


Anyway, to make weak refs work with Darwin, we need that - and it  
turns out that other GCC libs are built without "-no-undefined".


is the following OK for trunk?
Iain

libitm:

* Makefile.am (libitm_la_LDFLAGS): Remove "-no-undefined".
* Makefile.in: Regenerate.


Index: libitm/Makefile.am
===
--- libitm/Makefile.am  (revision 181618)
+++ libitm/Makefile.am  (working copy)
@@ -54,8 +54,7 @@ libitm_version_info = -version-info $(libtool_VERS
 # want or need libstdc++.
 libitm_la_DEPENDENCIES = $(libitm_version_dep)
 libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
-libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) \
--no-undefined
+libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)

 libitm_la_SOURCES = \
aatree.cc alloc.cc alloc_c.cc alloc_cpp.cc barrier.cc beginend.cc \

[Patch testsuite] Use complex floating-point constant in the macro CDBL

[Yufeng Zhang]

Hi,

This patch changes the macro CDBL in gcc.dg/compat/compat-common.h
to use complex floating-point constant rather than complex integer
constant.

CDBL is a macro to help construct complex floating-point constants in a
number of compat tests.

I have been running the compat test against a compiler that only supports
floating-point complex types; having an integral complex constant in
CDBL has caused some troubles.

Is it OK for trunk?

Thanks,
Yufeng

gcc/testsuite/ChangeLog
2011-11-22  Yufeng Zhang 

Use complex floating-point constant in CDBL.

* gcc.dg/compat/compat-common.h (CDBL): Replace 1i with 1.0i.diff --git a/gcc/testsuite/gcc.dg/compat/compat-common.h 
b/gcc/testsuite/gcc.dg/compat/compat-common.h
index 8a92ea3..4b3fb9c 100644
--- a/gcc/testsuite/gcc.dg/compat/compat-common.h
+++ b/gcc/testsuite/gcc.dg/compat/compat-common.h
@@ -33,7 +33,7 @@
 #ifndef SKIP_COMPLEX
 #ifdef __GNUC__
 #define CINT(x, y) (x + y * __extension__ 1i)
-#define CDBL(x, y) (x + y * __extension__ 1i)
+#define CDBL(x, y) (x + y * __extension__ 1.0i)
 #else
 #ifdef __SUNPRO_C
 /* ??? Complex support without .  */

Add line table and line map debugging routines

[Diego Novillo]

I found these useful while debugging the trunk->pph merge that
brought in the new macro location tracking features.

OK for trunk?  We are in stage 3, but these are debugging
routines so I figured it should be safe.

Tested on x86_64.


Diego.


* include/line-map.h (linemap_dump): Declare.
(line_table_dump): Declare.
* line-map.c (linemap_dump): New.
(line_table_dump): New.

diff --git a/svnclient/libcpp/include/line-map.h 
b/svnclient/libcpp/include/line-map.h
index cfa6566..1facf03 100644
--- a/svnclient/libcpp/include/line-map.h
+++ b/svnclient/libcpp/include/line-map.h
@@ -710,4 +710,14 @@ void linemap_get_statistics (struct line_maps *, struct 
linemap_stats *);
stream STREAM. SET is the line map set LOC comes from.  */
 void linemap_dump_location (struct line_maps *, source_location, FILE *);
 
+/* Dump line map at index IX in line table SET to STREAM.  If STREAM
+   is NULL, use stderr.  IS_MACRO is true if the caller wants to
+   dump a macro map, false otherwise.  */
+void linemap_dump (FILE *, struct line_maps *, unsigned, bool);
+
+/* Dump line table SET to STREAM.  If STREAM is NULL, stderr is used.
+   NUM_ORDINARY specifies how many ordinary maps to dump.  NUM_MACRO
+   specifies how many macro maps to dump.  */
+void line_table_dump (FILE *, struct line_maps *, unsigned int, unsigned int);
+
 #endif /* !LIBCPP_LINE_MAP_H  */
diff --git a/svnclient/libcpp/line-map.c b/svnclient/libcpp/line-map.c
index 0c59106..fd35204 100644
--- a/svnclient/libcpp/line-map.c
+++ b/svnclient/libcpp/line-map.c
@@ -1152,6 +1152,57 @@ linemap_expand_location (struct line_maps *set,
   return xloc;
 }
 
+
+/* Dump line map at index IX in line table SET to STREAM.  If STREAM
+   is NULL, use stderr.  IS_MACRO is true if the caller wants to
+   dump a macro map, false otherwise.  */
+
+void
+linemap_dump (FILE *stream, struct line_maps *set, unsigned ix, bool is_macro)
+{
+  const char *lc_reasons_v[LC_ENTER_MACRO + 1]
+  = { "LC_ENTER", "LC_LEAVE", "LC_RENAME", "LC_RENAME_VERBATIM",
+ "LC_ENTER_MACRO" };
+  const char *reason;
+  struct line_map *map;
+
+  if (stream == NULL)
+stream = stderr;
+
+  if (!is_macro)
+map = LINEMAPS_ORDINARY_MAP_AT (set, ix);
+  else
+map = LINEMAPS_MACRO_MAP_AT (set, ix);
+
+  reason = (map->reason <= LC_ENTER_MACRO) ? lc_reasons_v[map->reason] : "???";
+
+  fprintf (stream, "Map #%u [%p] - LOC: %u - REASON: %s - SYSP: %s\n",
+  ix, (void *) map, map->start_location, reason,
+  (!is_macro && ORDINARY_MAP_IN_SYSTEM_HEADER_P (map)) ? "yes" : "no");
+  if (!is_macro)
+{
+  unsigned includer_ix;
+  struct line_map *includer_map;
+
+  includer_ix = ORDINARY_MAP_INCLUDER_FILE_INDEX (map);
+  includer_map = includer_ix < LINEMAPS_ORDINARY_USED (set)
+? LINEMAPS_ORDINARY_MAP_AT (set, includer_ix)
+: NULL;
+
+  fprintf (stream, "File: %s:%d\n", ORDINARY_MAP_FILE_NAME (map),
+  ORDINARY_MAP_STARTING_LINE_NUMBER (map));
+  fprintf (stream, "Included from: [%d] %s\n", includer_ix,
+  includer_map ? ORDINARY_MAP_FILE_NAME (includer_map) : "None");
+}
+  else
+fprintf (stream, "Macro: %s (%u tokens)\n",
+linemap_map_get_macro_name (map),
+MACRO_MAP_NUM_MACRO_TOKENS (map));
+
+  fprintf (stream, "\n");
+}
+
+
 /* Dump debugging information about source location LOC into the file
stream STREAM. SET is the line map set LOC comes from.  */
 
@@ -1253,3 +1304,42 @@ linemap_get_statistics (struct line_maps *set,
   s->duplicated_macro_maps_locations_size =
 duplicated_macro_maps_locations_size;
 }
+
+
+/* Dump line table SET to STREAM.  If STREAM is NULL, stderr is used.
+   NUM_ORDINARY specifies how many ordinary maps to dump.  NUM_MACRO
+   specifies how many macro maps to dump.  */
+
+void
+line_table_dump (FILE *stream, struct line_maps *set, unsigned int 
num_ordinary,
+unsigned int num_macro)
+{
+  unsigned int i;
+
+  if (set == NULL)
+return;
+
+  if (stream == NULL)
+stream = stderr;
+
+  fprintf (stream, "# of ordinary maps:  %d\n", LINEMAPS_ORDINARY_USED (set));
+  fprintf (stream, "# of macro maps: %d\n", LINEMAPS_MACRO_USED (set));
+  fprintf (stream, "Include stack depth: %d\n", set->depth);
+  fprintf (stream, "Highest location:%u\n", set->highest_location);
+
+  if (num_ordinary)
+{
+  fprintf (stream, "\nOrdinary line maps\n");
+  for (i = 0; i < num_ordinary && i < LINEMAPS_ORDINARY_USED (set); i++)
+   linemap_dump (stream, set, i, false);
+  fprintf (stream, "\n");
+}
+
+  if (num_macro)
+{
+  fprintf (stream, "\nMacro line maps\n");
+  for (i = 0; i < num_macro && i < LINEMAPS_MACRO_USED (set); i++)
+   linemap_dump (stream, set, i, true);
+  fprintf (stream, "\n");
+}
+}

Re: [v3] updated atomic configury

[Joseph S. Myers]

On Tue, 22 Nov 2011, Andrew MacLeod wrote:

> C currently doesn't have a char16_t and char32_t, so they aren't defined

It certainly does have those types, as typedefs defined in  for 
the same types as uint_least16_t and uint_least32_t.  And  is 
also required to define ATOMIC_CHAR16_T_LOCK_FREE and 
ATOMIC_CHAR32_T_LOCK_FREE.

Your code in c-cppbuiltin.c appears to be using sizeof applied to *host* 
types, which is definitely wrong.  You need to examine the precision of 
the relevant tree nodes.

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

Re: Add line table and line map debugging routines

[Jason Merrill]

OK.

Jason

Re: [PATCH] __atomic library calls which are external may require some label exporting

[Richard Henderson]

On 11/21/2011 09:18 PM, Andrew MacLeod wrote:
>   PR other/51011
>   * tree.h (is_builtin_name): No longer external.
>   * builtins.c (is_builtin_name): Make static.
>   * varasm.c (incorporeal_function_p): __sync and __atomic external calls
>   are not incorporeal and may need asm label processing.

Ok.


r~

Re: [patch] Handle MUST_NOT_THROW_EXPR in voidify_wrapper_expr.

[Jason Merrill]

Here's the patch to add an argument to MUST_NOT_THROW_EXPR.  You should 
be able to just use build_must_not_throw_expr in the tm code.


Jason

commit 205ca057f90db6c30d1acd64ec796e7d301b3eb8
Author: Jason Merrill 
Date:   Tue Nov 22 10:19:03 2011 -0500

build_must

diff --git a/gcc/cp/cp-tree.def b/gcc/cp/cp-tree.def
index 5fc5496..83e0b5b 100644
--- a/gcc/cp/cp-tree.def
+++ b/gcc/cp/cp-tree.def
@@ -281,8 +281,9 @@ DEFTREECODE (EH_SPEC_BLOCK, "eh_spec_block", tcc_statement, 2)
 DEFTREECODE (HANDLER, "handler", tcc_statement, 2)
 
 /* A MUST_NOT_THROW_EXPR wraps an expression that may not
-   throw, and must call terminate if it does.  */
-DEFTREECODE (MUST_NOT_THROW_EXPR, "must_not_throw_expr", tcc_expression, 1)
+   throw, and must call terminate if it does.  The second argument
+   is a condition, used in templates to express noexcept (condition).  */
+DEFTREECODE (MUST_NOT_THROW_EXPR, "must_not_throw_expr", tcc_expression, 2)
 
 /* A CLEANUP_STMT marks the point at which a declaration is fully
constructed.  The CLEANUP_EXPR is run on behalf of CLEANUP_DECL
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 3f4f408..bb304b3 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3006,6 +3006,11 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
 #define VEC_INIT_EXPR_VALUE_INIT(NODE) \
   TREE_LANG_FLAG_1 (VEC_INIT_EXPR_CHECK (NODE))
 
+/* The condition under which this MUST_NOT_THROW_EXPR actually blocks
+   exceptions.  NULL_TREE means 'true'.  */
+#define MUST_NOT_THROW_COND(NODE) \
+  TREE_OPERAND (MUST_NOT_THROW_EXPR_CHECK (NODE), 1)
+
 /* The TYPE_MAIN_DECL for a class template type is a TYPE_DECL, not a
TEMPLATE_DECL.  This macro determines whether or not a given class
type is really a template type, as opposed to an instantiation or
@@ -5138,6 +5143,7 @@ extern bool type_noexcept_p			(const_tree);
 extern bool type_throw_all_p			(const_tree);
 extern tree build_noexcept_spec			(tree, int);
 extern void choose_personality_routine		(enum languages);
+extern tree build_must_not_throw_expr		(tree,tree);
 extern tree eh_type_info			(tree);
 extern tree begin_eh_spec_block			(void);
 extern void finish_eh_spec_block		(tree, tree);
diff --git a/gcc/cp/dump.c b/gcc/cp/dump.c
index d1631fc..a461094 100644
--- a/gcc/cp/dump.c
+++ b/gcc/cp/dump.c
@@ -413,6 +413,7 @@ cp_dump_tree (void* dump_info, tree t)
 case MUST_NOT_THROW_EXPR:
   dump_stmt (di, t);
   dump_child ("body", TREE_OPERAND (t, 0));
+  dump_child ("cond", MUST_NOT_THROW_COND (t));
   break;
 
 case USING_STMT:
diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index 670a66f..c56dc2c 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -374,6 +374,28 @@ choose_personality_routine (enum languages lang)
   state = gave_error;
 }
 
+/* Wrap EXPR in a MUST_NOT_THROW_EXPR expressing that EXPR must
+   not throw any exceptions if COND is true.  A condition of
+   NULL_TREE is treated as 'true'.  */
+
+tree
+build_must_not_throw_expr (tree body, tree cond)
+{
+  tree type = body ? TREE_TYPE (body) : void_type_node;
+
+  if (cond && !value_dependent_expression_p (cond))
+{
+  cond = cxx_constant_value (cond);
+  if (integer_zerop (cond))
+	return body;
+  else if (integer_onep (cond))
+	cond = NULL_TREE;
+}
+
+  return build2 (MUST_NOT_THROW_EXPR, type, body, cond);
+}
+
+
 /* Initialize the catch parameter DECL.  */
 
 static void
@@ -418,7 +440,7 @@ initialize_handler_parm (tree decl, tree exp)
   /* Force cleanups now to avoid nesting problems with the
 	 MUST_NOT_THROW_EXPR.  */
   init = fold_build_cleanup_point_expr (TREE_TYPE (init), init);
-  init = build1 (MUST_NOT_THROW_EXPR, TREE_TYPE (init), init);
+  init = build_must_not_throw_expr (init, NULL_TREE);
 }
 
   decl = pushdecl (decl);
@@ -560,7 +582,8 @@ begin_eh_spec_block (void)
  MUST_NOT_THROW_EXPR.  */
   if (TYPE_NOEXCEPT_P (TREE_TYPE (current_function_decl)))
 {
-  r = build_stmt (spec_location, MUST_NOT_THROW_EXPR, NULL_TREE);
+  r = build_stmt (spec_location, MUST_NOT_THROW_EXPR,
+		  NULL_TREE, NULL_TREE);
   TREE_SIDE_EFFECTS (r) = 1;
 }
   else
@@ -664,7 +687,8 @@ wrap_cleanups_r (tree *tp, int *walk_subtrees ATTRIBUTE_UNUSED,
   cleanup = TARGET_EXPR_CLEANUP (exp);
   if (cleanup)
 {
-  cleanup = build1 (MUST_NOT_THROW_EXPR, void_type_node, cleanup);
+  cleanup = build2 (MUST_NOT_THROW_EXPR, void_type_node, cleanup,
+			NULL_TREE);
   TARGET_EXPR_CLEANUP (exp) = cleanup;
 }
 
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f817b6f..5382161 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14294,6 +14294,10 @@ tsubst_copy_and_build (tree t,
   return tsubst_expr(t, args, complain, in_decl,
 	 integral_constant_expression_p);
 
+case MUST_NOT_THROW_EXPR:
+  return build_must_not_throw_expr (RECUR (TREE_OPERAND (t, 0)),
+	RECUR (MUST_NOT_THROW_COND (t)));
+
 default:
   /* Handle Objective-C++ constructs, if ap

Re: [PATCH] PR c++/51143 - Alias template allows class definition

[Dodji Seketeli]

Jason Merrill  writes:

> Do we have a test for allowing a class definition in a non-template
> alias definition?  If not, please add that too.

Good catch.  I have a test for that in the test file.

>  OK with that change.

Thanks.  Below is what I have tested and checked in.

From: Dodji Seketeli 
Date: Mon, 21 Nov 2011 22:31:10 +0100
Subject: [PATCH] PR c++/51143 - Alias template allows class definition

gcc/cp

PR c++/51143
* parser.c (cp_parser_alias_declaration): Don't allow type
definition in templates.

gcc/testsuite

PR c++/51143
* g++.dg/cpp0x/alias-decl-16.C: New test.
---
 gcc/cp/ChangeLog   |6 +
 gcc/cp/parser.c|   29 
 gcc/testsuite/ChangeLog|5 
 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C |   28 +++
 4 files changed, 68 insertions(+), 0 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C

diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index c083144..290538c 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,9 @@
+2011-11-22  Dodji Seketeli  
+
+   PR c++/51143
+   * parser.c (cp_parser_alias_declaration): Don't allow type
+   definition in templates.
+
 2011-11-20  Jason Merrill  
 
* pt.c (tsubst_pack_expansion): Fix SFINAE.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f839112..744ad3f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14940,6 +14940,7 @@ cp_parser_alias_declaration (cp_parser* parser)
   cp_declarator *declarator;
   cp_decl_specifier_seq decl_specs;
   bool member_p;
+  const char *saved_message = NULL;
 
   /* Look for the `using' keyword.  */
   cp_parser_require_keyword (parser, RID_USING, RT_USING);
@@ -14948,7 +14949,35 @@ cp_parser_alias_declaration (cp_parser* parser)
   attributes = cp_parser_attributes_opt (parser);
   cp_parser_require (parser, CPP_EQ, RT_EQ);
 
+  /* Now we are going to parse the type-id of the declaration.  */
+
+  /*
+[dcl.type]/3 says:
+
+   "A type-specifier-seq shall not define a class or enumeration
+unless it appears in the type-id of an alias-declaration (7.1.3) that
+is not the declaration of a template-declaration."
+
+In other words, if we currently are in an alias template, the
+type-id should not define a type.
+
+So let's set parser->type_definition_forbidden_message in that
+case; cp_parser_check_type_definition (called by
+cp_parser_class_specifier) will then emit an error if a type is
+defined in the type-id.  */
+  if (parser->num_template_parameter_lists)
+{
+  saved_message = parser->type_definition_forbidden_message;
+  parser->type_definition_forbidden_message =
+   G_("types may not be defined in alias template declarations");
+}
+
   type = cp_parser_type_id (parser);
+
+  /* Restore the error message if need be.  */
+  if (parser->num_template_parameter_lists)
+parser->type_definition_forbidden_message = saved_message;
+
   cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
 
   if (cp_parser_error_occurred (parser))
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5c1fb00..8d6f16a 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2011-11-22  Dodji Seketeli  
+
+   PR c++/51143
+   * g++.dg/cpp0x/alias-decl-16.C: New test.
+
 2011-11-20  Joey Ye  
 
* gcc.dg/volatile-bitfields-1.c: New.
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
new file mode 100644
index 000..d0a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-16.C
@@ -0,0 +1,28 @@
+// Origin PR c++/51143
+// { dg-options "-std=c++11" }
+
+using A0 = struct B0 { void f() {} };
+
+template
+using A1 =
+struct B1 { // { dg-error "types may not be defined in alias template" }
+static auto constexpr value = N;
+};
+
+A1<0> a1;
+
+template
+using A2 =
+struct B2 {  // { dg-error "types may not be defined in alias template" }
+void f(T){}
+};
+
+A2 a2;
+
+template
+using A3 =
+enum B3 {b = 0;}; //{ dg-error "types may not be defined in alias 
template" }
+
+A3 a3;
+
+int main() { }
-- 
1.7.6.4


-- 
Dodji

Re: building trunk fails due to C++

[Gary Funck]

On 11/09/11 14:22:22, Steve Kargl wrote:
> > Besides bootstrapping, you could use --disable-libitm or it might also 
> > work to specify --disable-build-poststage1-with-cxx which also saves you 
> > from building the C++ compiler if you don't want it.
> 
> Doing a full bootstrap adds 3+ hours on my laptop.  Oh well, I 
> guess this is the price of progress.

It gots much worse, with --enable-checking=all in combination with
--enable-build-poststage1-with-cxx (the default, if c++ is built,
and --enable-bootstrap is asserted).

In fact, a build started last night on fast server hardware has yet
to finish.

This particular compilation (insn-emit.c) has been running for
5.5 hours.  Typically, a full bootstrap (with minimal checks) would
finish in much less than 30 minutes on this server.

Has anyone tried a full bootstrap with c,c++ and --enable-checking=all?
Were you successful?  How long did it take to complete?

I haven't looked into this in detail, however, I wonder that if the
C++ compiler is used for final build, whether the build/make will
honor CFLAGS or CXXFLAGS?

Presumably the latter (CXXFLAGS).  This seems like a potentially
surprising side effect, if true.

[C++ Patch] PR 51265

[Paolo Carlini]

Hi,

this is a 4.6/4.7 Regression (the ICE happens also in C++98 mode with 
__decltype).


The problem manifest itself as unhandled PTRMEM_CST in 
finish_decltype_type, and I'm avoiding it by just handling it like 
INTEGER_CST. Is it the correct/best thing to do? Anyway patch passes 
testing on x86_64-linux.


Thanks,
Paolo.

//
/cp
2011-11-22  Paolo Carlini  

PR c++/51265
* semantics.c (finish_decltype_type): Handle PTRMEM_CST.

/testsuite
2011-11-22  Paolo Carlini  

PR c++/51265
* g++.dg/cpp0x/decltype36.C: New.
Index: testsuite/g++.dg/cpp0x/decltype36.C
===
--- testsuite/g++.dg/cpp0x/decltype36.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype36.C (revision 0)
@@ -0,0 +1,21 @@
+// PR c++/51265
+// { dg-options -std=c++0x }
+
+struct Funny
+{
+  int print(int);
+};
+
+template
+void c();
+
+template
+void xx()
+{
+  c();
+}
+
+int main()
+{
+  xx();
+}
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 181627)
+++ cp/semantics.c  (working copy)
@@ -5234,6 +5234,7 @@ finish_decltype_type (tree expr, bool id_expressio
 case BIT_FIELD_REF:
   gcc_unreachable ();
 
+   case PTRMEM_CST:
 case INTEGER_CST:
   /* We can get here when the id-expression refers to an
  enumerator.  */

Re: PATCH RFA: Build stages 2 and 3 with C++

[Gary Funck]

A comment on the documentation:

> Index: gcc/doc/install.texi
> ===
> --- gcc/doc/install.texi  (revision 176348)
> +++ gcc/doc/install.texi  (working copy)
> @@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini
>  Build GCC using a C++ compiler rather than a C compiler.  This is an
>  experimental option which may become the default in a later release.
>  
> +@item --enable-build-poststage1-with-cxx
> +When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
> +rather than a C compiler.  Stage 1 is still built with a C compiler.
> +This is an experimental option which may become the default in a later
> +release.  This is enabled by default and may be disabled using
> +@option{--disable-build-poststage1-with-cxx}.
> +

The document says "This is an experimental option which may become the
default in a later release" and then says "This is enabled by default".
The latter statement is true.

Re: building trunk fails due to C++

[Michael Matz]

Hi,

On Tue, 22 Nov 2011, Gary Funck wrote:

> It gots much worse, with --enable-checking=all in combination with
> --enable-build-poststage1-with-cxx (the default, if c++ is built,
> and --enable-bootstrap is asserted).
> 
> In fact, a build started last night on fast server hardware has yet
> to finish.
> 
> This particular compilation (insn-emit.c) has been running for
> 5.5 hours.  Typically, a full bootstrap (with minimal checks) would
> finish in much less than 30 minutes on this server.

Yes, don't use --enable-checking=all for bootstraps.  =all enables some 
_extremely_ slow checking, you should usually just use =yes (which is the 
default for non-release branches).  This doesn't have to do with C vs C++ 
as bootstrap compiler, though.


Ciao,
Michael.

Re: [Patch libitm] minor adjustment to make flags.

[Richard Henderson]

On 11/22/2011 07:07 AM, Iain Sandoe wrote:
> * Makefile.am (libitm_la_LDFLAGS): Remove "-no-undefined".
> * Makefile.in: Regenerate.

Ok.


r~

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

Gary Funck  writes:

> A comment on the documentation:
>
>> Index: gcc/doc/install.texi
>> ===
>> --- gcc/doc/install.texi  (revision 176348)
>> +++ gcc/doc/install.texi  (working copy)
>> @@ -1286,6 +1286,13 @@ will try to guess whether the @code{.ini
>>  Build GCC using a C++ compiler rather than a C compiler.  This is an
>>  experimental option which may become the default in a later release.
>>  
>> +@item --enable-build-poststage1-with-cxx
>> +When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
>> +rather than a C compiler.  Stage 1 is still built with a C compiler.
>> +This is an experimental option which may become the default in a later
>> +release.  This is enabled by default and may be disabled using
>> +@option{--disable-build-poststage1-with-cxx}.
>> +
>
> The document says "This is an experimental option which may become the
> default in a later release" and then says "This is enabled by default".
> The latter statement is true.

Thanks for pointing this out.  I committed this patch to fix this in the
obvious way.  Bootstrapped on x86_64-unknown-linux-gnu.

Ian


2011-11-22  Ian Lance Taylor  

* doc/install.texi (Configuration): Correct doc of
--enable-build-poststage1-with-cxx: it is not experimental.


Index: doc/install.texi
===
--- doc/install.texi	(revision 181627)
+++ doc/install.texi	(working copy)
@@ -1298,8 +1298,7 @@ experimental option which may become the
 @item --enable-build-poststage1-with-cxx
 When bootstrapping, build stages 2 and 3 of GCC using a C++ compiler
 rather than a C compiler.  Stage 1 is still built with a C compiler.
-This is an experimental option which may become the default in a later
-release.  This is enabled by default and may be disabled using
+This is enabled by default and may be disabled using
 @option{--disable-build-poststage1-with-cxx}.
 
 @item --enable-maintainer-mode

Re: [PATCH] Fix up VEC_INTERLEAVE_*_EXPR folding and expansion for big endian (PR tree-optimization/51074)

[Richard Henderson]

On 11/22/2011 06:30 AM, Jakub Jelinek wrote:
>   PR tree-optimization/51074
>   * fold-const.c (fold_binary_loc): Fix up VEC_INTERLEAVE_*_EXPR
>   handling for BYTES_BIG_ENDIAN.
>   * optabs.c (can_vec_perm_for_code_p): Likewise.
> 
>   * gcc.dg/vect/pr51074.c: New test.

As we discussed on IRC, I think this is ok for the short term.

However, this does mean that the representation of vec_interleave_*_expr is 
wrong on *all* big-endian targets, and the only reason we havn't seen this 
before now is that we don't generally get to fold them.

The only good way to clean up this mixup is to remove vec_interleave_*_expr 
entirely, and always use vec_perm_expr, whose semantics are not in doubt.  This 
may sound like it's too heavy-weight for stage3, but the situation at the 
moment is that we're relying on rtl-folding not to occur for these targets.

If we don't change the vectorizer and the targets for gcc 4.7, then I think we 
should disable rtl folding of vec_select and vec_merge, as these are the rtl 
patterns used to implement vec_interleave.

Thoughts?


r~

Re: building trunk fails due to C++

[Gary Funck]

On 11/22/11 18:19:55, Michael Matz wrote:
> > This particular compilation (insn-emit.c) has been running for
> > 5.5 hours.  Typically, a full bootstrap (with minimal checks) would
> > finish in much less than 30 minutes on this server.
> 
> Yes, don't use --enable-checking=all for bootstraps.  =all enables some 
> _extremely_ slow checking, you should usually just use =yes (which is the 
> default for non-release branches).  This doesn't have to do with C vs C++ 
> as bootstrap compiler, though.

Michael,

Thanks for the tip.  Typically, we don't build with --enable-checking=all,
however ...

We build with --enable-checking=all when we're testing
major changes, moving GUPC to a new target architecture, etc.

In the past, it may have been slower, and certainly the final
compiler is slower (probably 3x-5x on average), but the extra checking
did help catch some bugs.

If --enable-checking=all is deemed currently unusable, perhaps it can be
re-designed so that the useful and not impractically expensive
checks are enabled but some other switch values are defined to
perform checks that are needed only in very specific circumstances.

This almost infinite compilation time seems like a new behavior to me,
and is potentially a side-effect of building with the g++ in the final stage.

FYI, on the *very* long running compilations that I checked,
the cc1plus compiler appeared to be stuck in the garbage collector.

#1  0x009e838e in gt_ggc_mx_lang_tree_node (x_p=0x7fff268282d0)
at ./gt-cp-tree.h:154
#2  0x009e98fc in gt_ggc_mx_lang_tree_node (x_p=0x7ffef042ad00)
at ./gt-cp-tree.h:381
#3  0x00acf2be in gt_ggc_mx_cp_binding_level (x_p=0x717878c0)
at ./gt-cp-name-lookup.h:80
#4  0x00acf4c8 in gt_ggc_mx_cxx_binding (x_p=0x7fffec638f78)
at ./gt-cp-name-lookup.h:105
[...]
#10 0x009e984e in gt_ggc_mx_lang_tree_node (x_p=0x7ffee794f100)
at ./gt-cp-tree.h:375
#11 0x0177eeac in gt_ggc_mx_cgraph_node (x_p=0x7ffef402ca20)
at gtype-desc.c:693
#12 0x01785fc9 in gt_ggc_m_P11cgraph_node4htab (x_p=0x7fffefbec3f0)
at gtype-desc.c:2774
#13 0x015c48cb in ggc_mark_root_tab (rt=0x4dbce40)
at src/gupc/gcc/ggc-common.c:142
#14 0x015c4967 in ggc_mark_roots ()
at src/gupc/gcc/ggc-common.c:161

[this was compiling insn_emit.c.  It racked up 5 hours of cpu time
before I canceled the job.]

This sort of thing would appear to be unrelated to --enable-checking=all,
or at least it is surprising to me that --enable-checking=all would
end up causing the compiler to spend a lot of time in the garbage
collector.

I only checked two/three long-running compilations, but each of them
demonstrated a similar backtrace to that shown above.

I will try rebuilding with --disable-build-poststage1-with-cxx and
--enable-checking=all to try to determine if this is g++ specific
behavior.

- Gary

Re: [patch] support LTO of transactional memory

[Aldy Hernandez]

On 11/21/11 13:45, Richard Henderson wrote:

On 11/21/2011 11:31 AM, Aldy Hernandez wrote:

  case GIMPLE_DEBUG:
+case GIMPLE_TRANSACTION:
for (i = 0; i<  gimple_num_ops (stmt); i++)
  {
tree op = gimple_op (stmt, i);
@@ -145,6 +146,8 @@ output_gimple_stmt (struct output_block
else
  stream_write_tree (ob, gimple_call_fntype (stmt), true);
  }
+  if (gimple_code (stmt) == GIMPLE_TRANSACTION)
+stream_write_tree (ob, gimple_transaction_label (stmt), true);



No point merging GIMPLE_TRANSACTION with those cases.  There are only two 
operands, BODY and LABEL, and BODY should have been lowered already.  Make this 
a separate case with an assert BODY == NULL, and writing the label.


Done.


Otherwise ok.


I added a few things.

First, I added the dummy calls as you suggested, but I also had to add a 
"used" attribute otherwise the hidden _ITM_* calls get swiped from under 
us before link time.


Second, I added another test to make sure linking clones actually works.

Lastly, I noticed lto_cgraph.c inputs/outputs the cgraph bits.  I added 
code to handle the tm_clone bit.  We do still need it, right?


Otherwise as before.  Tested on x86-64 Linux.

OK?
* opts.c (finish_options): Do not fail for -fgnu-tm.
* gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTION.
* gimple-streamer-in.c (input_gimple_stmt): Same.
* lto-cgraph.c (input_overwrite_node): Read tm_clone bit.
(lto_output_node): Write tm_clone bit.
lto/
* lto-lang.c (lto_attribute_table): Handle transaction_pure.
(handle_transaction_pure_attribute): New.

Index: gimple-streamer-out.c
===
--- gimple-streamer-out.c   (revision 181588)
+++ gimple-streamer-out.c   (working copy)
@@ -151,6 +151,11 @@ output_gimple_stmt (struct output_block
 case GIMPLE_PREDICT:
   break;
 
+case GIMPLE_TRANSACTION:
+  gcc_assert (gimple_transaction_body (stmt) == NULL);
+  stream_write_tree (ob, gimple_transaction_label (stmt), true);
+  break;
+
 default:
   gcc_unreachable ();
 }
Index: testsuite/gcc.dg/lto/trans-mem-2_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 0)
@@ -0,0 +1,19 @@
+/* { dg-lto-options {{-flto -fgnu-tm}} } */
+
+extern void foobar() __attribute__((transaction_callable));
+
+#define dummy(func) \
+  __attribute__((noinline,noclone,used)) void func() { asm (""); }
+
+dummy(_ITM_beginTransaction)
+dummy(_ITM_commitTransaction)
+dummy(_ITM_WU4)
+dummy(_ITM_WU8)
+
+main()
+{
+  __transaction_relaxed
+{
+  foobar();
+}
+}
Index: testsuite/gcc.dg/lto/trans-mem-2_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-2_1.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-2_1.c(revision 0)
@@ -0,0 +1,4 @@
+__attribute__((transaction_callable,noinline))
+void foobar() 
+{
+}
Index: testsuite/gcc.dg/lto/trans-mem-1_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-1_0.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-1_0.c(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-lto-options {{-flto -fgnu-tm}} } */
+
+int i;
+
+main()
+{
+  __transaction_atomic
+{
+  i = 0;
+}
+}
Index: testsuite/gcc.dg/lto/trans-mem-1_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 0)
+++ testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 0)
@@ -0,0 +1,7 @@
+#define dummy(func) \
+  __attribute__((noinline,noclone,used)) void func() { asm (""); }
+
+dummy(_ITM_beginTransaction)
+dummy(_ITM_commitTransaction)
+dummy(_ITM_WU4)
+dummy(_ITM_WU8)
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 181588)
+++ lto-cgraph.c(working copy)
@@ -522,6 +522,7 @@ lto_output_node (struct lto_simple_outpu
   bp_pack_value (&bp, node->frequency, 2);
   bp_pack_value (&bp, node->only_called_at_startup, 1);
   bp_pack_value (&bp, node->only_called_at_exit, 1);
+  bp_pack_value (&bp, node->tm_clone, 1);
   bp_pack_value (&bp, node->thunk.thunk_p && !boundary_p, 1);
   bp_pack_enum (&bp, ld_plugin_symbol_resolution,
LDPR_NUM_KNOWN, node->resolution);
@@ -928,6 +929,7 @@ input_overwrite_node (struct lto_file_de
   node->frequency = (enum node_frequency)bp_unpack_value (bp, 2);
   node->only_called_at_startup = bp_unpack_value (bp, 1);
   node->only_called_at_exit = bp_unpack_value (bp, 1);
+  node->tm_clone = bp_unpack_value (bp, 1);
   node->thunk.thunk_p = bp_unpack_value (bp, 1);
   node->resolution = bp_unpack_enum (bp, ld_plugin_symbol_resolution,
 LDPR_NUM_KNOWN);
Index:

Re: [PR50764, PATCH] Fix for ICE in maybe_record_trace_start with -fsched2-use-superblocks

[Vladimir Makarov]

On 11/22/2011 04:39 AM, Tom de Vries wrote:

On 17/11/11 17:53, Maxim Kuvyrkov wrote:

On 17/11/2011, at 9:58 PM, Tom de Vries wrote:


On 11/15/2011 10:07 PM, Maxim Kuvyrkov wrote:

On 30/10/2011, at 8:17 AM, Tom de Vries wrote:


Richard,

I have a tentative fix for PR50764.

Richard,

Tom's patch is good (with the comments below addressed), and I would appreciate 
you validating my review with your formal approval.


Richard,

Updated patch according to comments from Maxim. Added test-case. Bootstrapped
and reg-tested on x86_64.

Ok for trunk?


Ping.

Vladimir,

could you take a look at this patch?

The patch is ok for me.  It can go to the trunk.  Thanks for working on 
this.

Re: building trunk fails due to C++

[Diego Novillo]

On Tue, Nov 22, 2011 at 12:46, Gary Funck  wrote:
> On 11/22/11 18:19:55, Michael Matz wrote:
>> > This particular compilation (insn-emit.c) has been running for
>> > 5.5 hours.  Typically, a full bootstrap (with minimal checks) would
>> > finish in much less than 30 minutes on this server.
>>
>> Yes, don't use --enable-checking=all for bootstraps.  =all enables some
>> _extremely_ slow checking, you should usually just use =yes (which is the
>> default for non-release branches).  This doesn't have to do with C vs C++
>> as bootstrap compiler, though.
>
> Michael,
>
> Thanks for the tip.  Typically, we don't build with --enable-checking=all,

--enable-checking=all enables GC checking, so I am not really
surprised at the behaviour you observe.

> I will try rebuilding with --disable-build-poststage1-with-cxx and
> --enable-checking=all to try to determine if this is g++ specific
> behavior.

Yes, that will be an interesting piece of data to gather.  Thanks.


Diego.

Re: [PATCH] postreload: Invalidate reg_state info@barrier/volatile insns

[Eric Botcazou]

> Wouldn't this prevent optimizations in cases like:
>
> insn 1: r1 = r2 + r3
> insn 2: r4 = r1, r1 dead
> insn 3: unspec_volatile
>
> With the proposal above we would mark r1 with an invalid use when passing
> insn 3. But for registers which are already dead we should not do this.

You're right.  The patch is OK, thanks for explaining.

-- 
Eric Botcazou

Re: [v3] updated atomic configury

[Andrew MacLeod]

On 11/22/2011 10:32 AM, Joseph S. Myers wrote:

On Tue, 22 Nov 2011, Andrew MacLeod wrote:


C currently doesn't have a char16_t and char32_t, so they aren't defined

It certainly does have those types, as typedefs defined in  for
the same types as uint_least16_t and uint_least32_t.  And  is
also required to define ATOMIC_CHAR16_T_LOCK_FREE and
ATOMIC_CHAR32_T_LOCK_FREE.
but there isn't a stdatomic.h until we support C1x right? didnt we bail 
on that last release until things were more settled?   I just presumed 
that those types are part of C1x and then fix it all up for C1x support 
in the next release since I don't think we are yet.

Your code in c-cppbuiltin.c appears to be using sizeof applied to *host*
types, which is definitely wrong.  You need to examine the precision of
the relevant tree nodes.

hmm, yeah I was thinking that file was compiled for the target, so it 
would work.  Guess its a host file so I do need to look at the nodes 
instead:-P

Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

[Rainer Orth]

David Miller  writes:

> From: Rainer Orth 
> Date: Mon, 21 Nov 2011 14:53:33 +0100
>
>> Right now, it is only possible to clear the hardware capabilities
>> completely, while the new v2 mapfile syntax supports selectively adding
>> and removing capabilities.  It is only available in Solaris 11 and
>> Solaris 10 Update 10, though, so I'm restricting us to the v1 syntax for
>> now.
>
> I really wish Sun had never added this hwcap checking, 99 times out of
> 100 it's a nuisance rather than a help in any way.

I beg to differ: I prefer a ld.so.1 message telling me that my
executable or library uses ISA extension x, but my machine doesn't
support that, over the same binary beginning to run, but crashing with a
SIGILL every time.  I posit that's similar to symbol versioning where
the runtime linker can tell me: you're trying to use interface x in
liby.so.3, but the library doesn't provide it.  That's far better than
letting the programs start and crash later with an unsupported insn or
missing symbol, perhaps losing work.  True, you may be lucky and not
hit that codepath, but I'd rather not depend on my luck if running
software ;-)

I suppose that everyone who's able to play cute tricks with code
selection at runtime depending on machine hardware capabilities is smart
enough to deal with the linker's hwcap stuff, too.

As an aside, in Solaris 10 Update 10 and Solaris 11, there's direct
support in ld and ld.so.1 to select different implementations of the
same interface, depending on hardware capabilites present:

http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter2-13.html#giskh

Rainer

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

Re: PATCH RFA: Build stages 2 and 3 with C++

[Gary Funck]

On 07/15/11 23:52:46, Ian Lance Taylor wrote:
[...]
> @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@
>  #   the last argument when conflicting --enable arguments are passed.
>  # * Likewise, we force-disable coverage flags, since the installed
>  #   compiler probably has never heard of them.
> +# * Don't remove this, because above we added
> +#   POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which
> +#   we don't want for STAGE1_CONFIGURE_FLAGS.
>  STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \
> --disable-coverage --enable-languages="$(STAGE1_LANGUAGES)"

When g++ is used to compile gcc in stages 2 and 3, which
compilation flags (CFLAGS or CXXFLAGS) are in force?

If CXXFLAGS, is this a potentially surprising departure from
previous configure behavior?

thanks,
- Gary

Re: [PATCH] PR50325 store_bit_field: Fix for big endian targets

[Eric Botcazou]

> OK, I see how the two are different now, but I still don't get why the
> current version is right.  If we say words are 16 bits for simplicity,
> and we're storing VALUE == 0x0001_2345 into a 3-byte BLKmode bitfield,
> surely we want to store 0x01_2345 rather than 0x00_0123?

Why?  If you want this semantics, you need to use a bitfield with integer mode.
In Ada, the following case is frequent: you have a record type with BLKmode and 
an alignment that causes it to padded (because the size is always a multiple 
of the alignment).  You have a field in another record type whose type is the 
first record type but with a representation clause that prescribes the size 
without the padding.  The Ada compiler must accept that.  So the field is made 
a BLKmode bitfield, with DECL_SIZE (size w/o padding) smaller than TYPE_SIZE 
(size w/ padding).  When you're assigning a value to the field, you drop the 
rightmost bytes in memory order, which are junk since padding.

-- 
Eric Botcazou

Re: [patch] Handle MUST_NOT_THROW_EXPR in voidify_wrapper_expr.

[Torvald Riegel]

On Mon, 2011-11-21 at 14:58 -0800, Richard Henderson wrote:
> On 11/21/2011 01:58 PM, Torvald Riegel wrote:
> > On Mon, 2011-11-21 at 13:45 -0800, Richard Henderson wrote:
> >> On 11/21/2011 01:39 PM, Torvald Riegel wrote:
> >>> It still fails when combined
> >>> with transaction expressions (noexcept-4.C and noexcept-1.C) because
> >>> gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a
> >>> MUST_NOT_THROW_EXPR which it doesn't know to be a wrapper.  What's the
> >>> cleanest way to solve that?  Adding handling of MUST_NOT_THROW_EXPR
> >>> inside voidify_... will include C++ stuff there, right?  Or should there
> >>> be a C++ version of voidify_...?  Or something else?
> >>
> >> What's happening below gimplify_must_not_throw_expr?
> >>
> >> That *ought* to be recursing into voidify_wrapper_expr and
> >> doing the right thing.
> > 
> > gimplify_must_not_throw_expr does call voidify_wrapper_expr, with the
> > assumption that the latter understands that MNTE is a wrapper, and will
> > change the code contained in the wrapper (so, change the MNTE itself).
> > I thought about changing voidify_wrapper_expr so that its first argument
> > is a pointer to a tree, so that one can voidify the contained/inner
> > stuff even when the caller has already skipped a wrapper (MNTE in our
> > case).  But this didn't seem to be clearer either.
> 
> Try this, as discussed with Jason on IRC.

Works for me, no regressions. I'll look at Jason's patch later, and
adapt the transaction noexcept stuff. Thanks!

Torvald

Re: [libitm, build] Clear hardware capabilities on libitm.so with Sun ld

[Richard Henderson]

On 11/22/2011 10:14 AM, Rainer Orth wrote:
> As an aside, in Solaris 10 Update 10 and Solaris 11, there's direct
> support in ld and ld.so.1 to select different implementations of the
> same interface, depending on hardware capabilites present:
> 
> http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter2-13.html#giskh

Hum.  So, not entirely incompatible with the gnu ifunc extension,
but certainly not exactly like it either.

Off and on I've been pondering, post-toplevel-libgcc-move, whether
it would make sense to implement the functions therein with different
ISAs and either select the proper version with pre-processor macros
(generating a target-specific libgcc) or with ifuncs if available.

What support does the Solaris 11 assembler have for this feature?
The documentation only mentions the compiler...


r~

Re: [RFC] Use which_alternative in preparation-statements of define_insn_and_split

[Richard Henderson]

On 11/21/2011 05:38 PM, Jiangning Liu wrote:
> But I still want to know why we don't want to support this? I don't see any
> GCC documentation saying not allowing this usage.

Before reload, which_alternative doesn't make much sense, yet you compute it 
anyway.  After reload, but for raw define_split, which_alternative doesn't make 
much sense, yet you compute it anyway.

Now, either or both are fixable, but instead it seemed to me like maybe you 
were going down the wrong path entirely.


r~

[PATCH] Implement stap probe on ARM's unwinder

[Sergio Durigan Junior]

Hello,

This is the implementation of
 for the ARM
unwinder.  Since ARM has a different unwinder, I basically replicated
the existing code (on unwind-dw2.c) into it, with a few modifications in
order to gather the necessary information for the probe.  This feature
is pretty useful for GDB, which uses the probe inserted here to
implement the "next over throw" feature.

I built and regtested it on a Beagle board, and found no regressions.
Is it OK to apply?

Thanks,

Sergio.

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 305e8ad..f6e9dec 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,15 @@
+2011-11-22  Sergio Durigan Junior  
+
+   Implement ARM Unwinder SystemTap probe.
+   * unwind-arm-common.inc: Include `tconfig.h', `tsystem.h' and
+   `sys/sdt.h'.
+   (_Unwind_DebugHook): New function.
+   (uw_restore_core_regs): New define.
+   (unwind_phase2): Use `uw_restore_core_regs' instead of
+   `restore_core_regs'.
+   (unwind_phase2_forced): Likewise.
+   (__gnu_Unwind_Resume): Likewise.
+
 2011-11-22  Iain Sandoe  
 
* config/darwin-crt-tm.c: New file.
diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
index 0713056..bf16902 100644
--- a/libgcc/unwind-arm-common.inc
+++ b/libgcc/unwind-arm-common.inc
@@ -21,8 +21,15 @@
see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
.  */
 
+#include "tconfig.h"
+#include "tsystem.h"
 #include "unwind.h"
 
+/* Used for SystemTap unwinder probe.  */
+#ifdef HAVE_SYS_SDT_H
+#include 
+#endif
+
 /* We add a prototype for abort here to avoid creating a dependency on
target headers.  */
 extern void abort (void);
@@ -105,6 +112,44 @@ static inline _uw selfrel_offset31 (const _uw *p);
 
 static _uw __gnu_unwind_get_pr_addr (int idx);
 
+static void _Unwind_DebugHook (void *, void *)
+  __attribute__ ((__noinline__, __used__, __noclone__));
+
+/* This function is called during unwinding.  It is intended as a hook
+   for a debugger to intercept exceptions.  CFA is the CFA of the
+   target frame.  HANDLER is the PC to which control will be
+   transferred.  */
+
+static void
+_Unwind_DebugHook (void *cfa __attribute__ ((__unused__)),
+  void *handler __attribute__ ((__unused__)))
+{
+  /* We only want to use stap probes starting with v3.  Earlier
+ versions added too much startup cost.  */
+#if defined (HAVE_SYS_SDT_H) && defined (STAP_PROBE2) && _SDT_NOTE_TYPE >= 3
+  STAP_PROBE2 (libgcc, unwind, cfa, handler);
+#else
+  asm ("");
+#endif
+}
+
+/* This is a wrapper to be called when we need to restore core registers.
+   It will call `_Unwind_DebugHook' before restoring the registers, thus
+   making it possible to intercept and debug exceptions.
+
+   When calling `_Unwind_DebugHook', the first argument (the CFA) is zero
+   because we are not interested in it.  However, it must be there (even
+   being zero) because GDB expects to find it when using the probe.  */
+
+#define uw_restore_core_regs(TARGET, CORE)   \
+  do \
+{\
+  void *handler = __builtin_frob_return_addr ((void *) VRS_PC (TARGET));  \
+  _Unwind_DebugHook (0, handler);\
+  restore_core_regs (CORE);
  \
+}\
+  while (0)
+
 /* Perform a binary search for RETURN_ADDRESS in TABLE.  The table contains
NREC entries.  */
 
@@ -253,8 +298,8 @@ unwind_phase2 (_Unwind_Control_Block * ucbp, phase2_vrs * 
vrs)
   
   if (pr_result != _URC_INSTALL_CONTEXT)
 abort();
-  
-  restore_core_regs (&vrs->core);
+
+  uw_restore_core_regs (vrs, &vrs->core);
 }
 
 /* Perform phase2 forced unwinding.  */
@@ -339,7 +384,7 @@ unwind_phase2_forced (_Unwind_Control_Block *ucbp, 
phase2_vrs *entry_vrs,
   return _URC_FAILURE;
 }
 
-  restore_core_regs (&saved_vrs.core);
+  uw_restore_core_regs (&saved_vrs, &saved_vrs.core);
 }
 
 /* This is a very limited implementation of _Unwind_GetCFA.  It returns
@@ -450,7 +495,7 @@ __gnu_Unwind_Resume (_Unwind_Control_Block * ucbp, 
phase2_vrs * entry_vrs)
 {
 case _URC_INSTALL_CONTEXT:
   /* Upload the registers to enter the landing pad.  */
-  restore_core_regs (&entry_vrs->core);
+  uw_restore_core_regs (entry_vrs, &entry_vrs->core);
 
 case _URC_CONTINUE_UNWIND:
   /* Continue unwinding the next frame.  */

Re: PATCH RFA: Build stages 2 and 3 with C++

[Ian Lance Taylor]

Gary Funck  writes:

> On 07/15/11 23:52:46, Ian Lance Taylor wrote:
> [...]
>> @@ -444,6 +448,9 @@ STAGE1_LANGUAGES = @stage1_languages@
>>  #   the last argument when conflicting --enable arguments are passed.
>>  # * Likewise, we force-disable coverage flags, since the installed
>>  #   compiler probably has never heard of them.
>> +# * Don't remove this, because above we added
>> +#   POSTSTAGE1_CONFIGURE_FLAGS to STAGE[+id+]_CONFIGURE_FLAGS, which
>> +#   we don't want for STAGE1_CONFIGURE_FLAGS.
>>  STAGE1_CONFIGURE_FLAGS = --disable-intermodule $(STAGE1_CHECKING) \
>>--disable-coverage --enable-languages="$(STAGE1_LANGUAGES)"
>
> When g++ is used to compile gcc in stages 2 and 3, which
> compilation flags (CFLAGS or CXXFLAGS) are in force?

CXXFLAGS.

> If CXXFLAGS, is this a potentially surprising departure from
> previous configure behavior?

Perhaps.  I don't see how we could reasonably make any other choice,
though.

Ian

Re: [C++ Patch] PR 51265

[Jason Merrill]

OK, just adjust the comment to add "or non-type template parameter".

Jason

Go patch committed: New lock/note implementation

[Ian Lance Taylor]

This patch updates the implementations of locks and notes used in libgo
to use the current version from the master Go library.  This now uses
futexes when running on GNU/Linux, while still using semaphores on other
systems.  This implementation should be faster, and does not require
explicit initialization.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  I tested both the futex and the semaphore
versions.  Committed to mainline.

Ian

diff -r 8b1402d2f0d3 libgo/Makefile.am
--- a/libgo/Makefile.am	Tue Nov 22 12:16:53 2011 -0800
+++ b/libgo/Makefile.am	Tue Nov 22 12:18:39 2011 -0800
@@ -394,6 +394,12 @@
 rtems_task_variable_add_file =
 endif
 
+if LIBGO_IS_LINUX
+runtime_lock_files = runtime/lock_futex.c runtime/thread-linux.c
+else
+runtime_lock_files = runtime/lock_sema.c runtime/thread-sema.c
+endif
+
 runtime_files = \
 	runtime/go-append.c \
 	runtime/go-assert.c \
@@ -432,7 +438,6 @@
 	runtime/go-new-channel.c \
 	runtime/go-new-map.c \
 	runtime/go-new.c \
-	runtime/go-note.c \
 	runtime/go-panic.c \
 	runtime/go-print.c \
 	runtime/go-rec-big.c \
@@ -474,6 +479,7 @@
 	runtime/go-unsafe-pointer.c \
 	runtime/go-unwind.c \
 	runtime/cpuprof.c \
+	$(runtime_lock_files) \
 	runtime/mcache.c \
 	runtime/mcentral.c \
 	$(runtime_mem_file) \
diff -r 8b1402d2f0d3 libgo/runtime/cpuprof.c
--- a/libgo/runtime/cpuprof.c	Tue Nov 22 12:16:53 2011 -0800
+++ b/libgo/runtime/cpuprof.c	Tue Nov 22 12:18:39 2011 -0800
@@ -115,12 +115,6 @@
 static bool evict(Profile*, Entry*);
 static bool flushlog(Profile*);
 
-void
-runtime_cpuprofinit(void)
-{
-	runtime_initlock(&lk);
-}
-
 // LostProfileData is a no-op function used in profiles
 // to mark the number of profiling stack traces that were
 // discarded due to slow data writers.
diff -r 8b1402d2f0d3 libgo/runtime/go-main.c
--- a/libgo/runtime/go-main.c	Tue Nov 22 12:16:53 2011 -0800
+++ b/libgo/runtime/go-main.c	Tue Nov 22 12:18:39 2011 -0800
@@ -47,11 +47,10 @@
   g = &runtime_g0;
   m->curg = g;
   g->m = m;
-  runtime_initpanic ();
   runtime_mallocinit ();
-  runtime_cpuprofinit ();
   __go_gc_goroutine_init (&argc);
 
+  runtime_osinit();
   runtime_goargs();
   runtime_goenvs();
 
diff -r 8b1402d2f0d3 libgo/runtime/go-nanotime.c
--- a/libgo/runtime/go-nanotime.c	Tue Nov 22 12:16:53 2011 -0800
+++ b/libgo/runtime/go-nanotime.c	Tue Nov 22 12:18:39 2011 -0800
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// Return time in nanoseconds.  This is only used for computing runtime.
+// Return current time in nanoseconds.
 
 #include 
 
diff -r 8b1402d2f0d3 libgo/runtime/go-note.c
--- a/libgo/runtime/go-note.c	Tue Nov 22 12:16:53 2011 -0800
+++ /dev/null	Thu Jan 01 00:00:00 1970 +
@@ -1,74 +0,0 @@
-/* go-note.c -- implement notesleep, notewakeup and noteclear.
-
-   Copyright 2009 The Go Authors. All rights reserved.
-   Use of this source code is governed by a BSD-style
-   license that can be found in the LICENSE file.  */
-
-/* A note is a one-time notification.  noteclear clears the note.
-   notesleep waits for a call to notewakeup.  notewakeup wakes up
-   every thread waiting on the note.  */
-
-#include "go-assert.h"
-#include "runtime.h"
-
-/* We use a single global lock and condition variable.  It would be
-   better to use a futex on GNU/Linux.  */
-
-static pthread_mutex_t note_lock = PTHREAD_MUTEX_INITIALIZER;
-static pthread_cond_t note_cond = PTHREAD_COND_INITIALIZER;
-
-/* noteclear is called before any calls to notesleep or
-   notewakeup.  */
-
-void
-runtime_noteclear (Note* n)
-{
-  int32 i;
-
-  i = pthread_mutex_lock (¬e_lock);
-  __go_assert (i == 0);
-
-  n->woken = 0;
-
-  i = pthread_mutex_unlock (¬e_lock);
-  __go_assert (i == 0);
-}
-
-/* Wait until notewakeup is called.  */
-
-void
-runtime_notesleep (Note* n)
-{
-  int32 i;
-
-  i = pthread_mutex_lock (¬e_lock);
-  __go_assert (i == 0);
-
-  while (!n->woken)
-{
-  i = pthread_cond_wait (¬e_cond, ¬e_lock);
-  __go_assert (i == 0);
-}
-
-  i = pthread_mutex_unlock (¬e_lock);
-  __go_assert (i == 0);
-}
-
-/* Wake up every thread sleeping on the note.  */
-
-void
-runtime_notewakeup (Note *n)
-{
-  int32 i;
-
-  i = pthread_mutex_lock (¬e_lock);
-  __go_assert (i == 0);
-
-  n->woken = 1;
-
-  i = pthread_cond_broadcast (¬e_cond);
-  __go_assert (i == 0);
-
-  i = pthread_mutex_unlock (¬e_lock);
-  __go_assert (i == 0);
-}
diff -r 8b1402d2f0d3 libgo/runtime/go-semacquire.c
--- a/libgo/runtime/go-semacquire.c	Tue Nov 22 12:16:53 2011 -0800
+++ b/libgo/runtime/go-semacquire.c	Tue Nov 22 12:18:39 2011 -0800
@@ -117,35 +117,3 @@
   __go_assert (i == 0);
 }
 }
-
-
-#ifndef HAVE_SYNC_FETCH_AND_ADD_4
-
-/* For targets which don't have the required sync support.  Really
-   this should be provided by gcc itself.  FIXME.  */
-
-static pthread_mutex_t sync_lock = PTHREAD_MUTEX_INITIALIZER;
-
-uint32
-__sync_fetch_and_add_4(uint32*, uint32)
-  __attribute__((visibility("hidden")));
-
-u

Re: [patch] support LTO of transactional memory

[Richard Henderson]

On 11/22/2011 09:55 AM, Aldy Hernandez wrote:
>   * opts.c (finish_options): Do not fail for -fgnu-tm.
>   * gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTION.
>   * gimple-streamer-in.c (input_gimple_stmt): Same.
>   * lto-cgraph.c (input_overwrite_node): Read tm_clone bit.
>   (lto_output_node): Write tm_clone bit.
> lto/
>   * lto-lang.c (lto_attribute_table): Handle transaction_pure.
>   (handle_transaction_pure_attribute): New.

Ok.


r~

Re: Re-merge crtstuff.c from the trans-mem branch

[Richard Henderson]

On 11/22/2011 04:15 AM, Rainer Orth wrote:
> This patch broke bootstrap on Solaris 8 and 9/x86 with Sun as which
> doesn't support .hidden: linking the stage2 lto-plugin fails like this:
> 
> ld: fatal: relocation error: R_386_GOTOFF: file 
> /var/gcc/regression/trunk/8-gcc/build/./prev-gcc/crtbegin.o: symbol 
> __TMC_END__: relocation must bind locally
> collect2: error: ld returned 1 exit status
> make[4]: *** [liblto_plugin.la] Error 1

Blah, of course it does.

The first of these patches should fix this.  The second... well, I
don't recall why we use -fno-inline atm.  It works for i386-linux,
of course, to eliminate it.  But this is a twisty maze...

I can do several things: (1) leave things alone, let the "inline"
function continue to be out-of-line, (2) rewrite the code block
using a macro, (3) probably break something with the second patch.  ;-)

Thoughts?


r~
commit 371b252092b9d6aa3987ad73455d2512b9be0769
Author: Richard Henderson 
Date:   Tue Nov 22 10:33:29 2011 -0800

crtstuff: adjust tm clones for no attribute hidden

diff --git a/libgcc/crtstuff.c b/libgcc/crtstuff.c
index 6f06b62..77b8d42 100644
--- a/libgcc/crtstuff.c
+++ b/libgcc/crtstuff.c
@@ -252,9 +252,51 @@ STATIC void *__JCR_LIST__[]
 
 #if USE_TM_CLONE_REGISTRY
 STATIC func_ptr __TMC_LIST__[]
-  __attribute__((unused, section(".tm_clone_table"), aligned(sizeof(void*
+  __attribute__((used, section(".tm_clone_table"), aligned(sizeof(void*
   = { };
+# ifdef HAVE_GAS_HIDDEN
 extern func_ptr __TMC_END__[] __attribute__((__visibility__ ("hidden")));
+# endif
+
+static inline void
+deregister_tm_clones (void)
+{
+  void (*fn) (void *);
+
+#ifdef HAVE_GAS_HIDDEN
+  if (__TMC_END__ - __TMC_LIST__ == 0)
+return;
+#else
+  if (__TMC_LIST__[0] == NULL)
+return;
+#endif
+
+  fn = _ITM_deregisterTMCloneTable;
+  __asm ("" : "+r" (fn));
+  if (fn)
+fn (__TMC_LIST__);
+}
+
+static inline void
+register_tm_clones (void)
+{
+  void (*fn) (void *, size_t);
+  size_t size;
+
+#ifdef HAVE_GAS_HIDDEN
+  size = (__TMC_END__ - __TMC_LIST__) / 2;
+#else
+  for (size = 0; __TMC_LIST__[size * 2] != NULL; size++)
+continue;
+#endif
+  if (size == 0)
+return;
+
+  fn = _ITM_registerTMCloneTable;
+  __asm ("" : "+r" (fn));
+  if (fn)
+fn (__TMC_LIST__, size);
+}
 #endif /* USE_TM_CLONE_REGISTRY */
 
 #if defined(INIT_SECTION_ASM_OP) || defined(INIT_ARRAY_SECTION_ASM_OP)
@@ -347,13 +389,7 @@ __do_global_dtors_aux (void)
 #endif /* !defined(FINI_ARRAY_SECTION_ASM_OP) */
 
 #if USE_TM_CLONE_REGISTRY
-  if (__TMC_END__ - __TMC_LIST__ > 0)
-{
-  void (*deregister_clones) (void *) = _ITM_deregisterTMCloneTable;
-  __asm ("" : "+r" (deregister_clones));
-  if (deregister_clones)
-   deregister_clones (__TMC_LIST__);
-}
+  deregister_tm_clones ();
 #endif /* USE_TM_CLONE_REGISTRY */
 
 #ifdef USE_EH_FRAME_REGISTRY
@@ -422,16 +458,7 @@ frame_dummy (void)
 #endif /* JCR_SECTION_NAME */
 
 #if USE_TM_CLONE_REGISTRY
-  if (__TMC_END__ - __TMC_LIST__ > 0)
-{
-  void (*register_clones) (void *, size_t) = _ITM_registerTMCloneTable;
-  __asm ("" : "+r" (register_clones));
-  if (register_clones)
-   {
- size_t size = (size_t)(__TMC_END__ - __TMC_LIST__) / 2;
- _ITM_registerTMCloneTable (__TMC_LIST__, size);
-   }
-}
+  register_tm_clones ();
 #endif /* USE_TM_CLONE_REGISTRY */
 }
 
@@ -500,13 +527,7 @@ __do_global_dtors (void)
 f ();
 
 #if USE_TM_CLONE_REGISTRY
-  if (__TMC_END__ - __TMC_LIST__ > 0)
-{
-  void (*deregister_clones) (void *) = _ITM_deregisterTMCloneTable;
-  __asm ("" : "+r" (deregister_clones));
-  if (deregister_clones)
-   deregister_clones (__TMC_LIST__);
-}
+  deregister_tm_clones ();
 #endif /* USE_TM_CLONE_REGISTRY */
 
 #ifdef USE_EH_FRAME_REGISTRY
@@ -542,16 +563,7 @@ __do_global_ctors_1(void)
 #endif
 
 #if USE_TM_CLONE_REGISTRY
-  if (__TMC_END__ - __TMC_LIST__ > 0)
-{
-  void (*register_clones) (void *, size_t) = _ITM_registerTMCloneTable;
-  __asm ("" : "+r" (register_clones));
-  if (register_clones)
-   {
- size_t size = (size_t)(__TMC_END__ - __TMC_LIST__) / 2;
- register_clones (__TMC_LIST__, size);
-   }
-}
+  register_tm_clones ();
 #endif /* USE_TM_CLONE_REGISTRY */
 }
 #endif /* USE_EH_FRAME_REGISTRY || JCR_SECTION_NAME || USE_TM_CLONE_REGISTRY */
@@ -639,10 +651,16 @@ STATIC void *__JCR_END__[1]
 #endif /* JCR_SECTION_NAME */
 
 #if USE_TM_CLONE_REGISTRY
+# ifndef HAVE_GAS_HIDDEN
+static
+# endif
 func_ptr __TMC_END__[]
-  __attribute__((unused, section(".tm_clone_table"), aligned(sizeof(void *)),
-__visibility__ ("hidden")))
-  = { };
+  __attribute__((used, section(".tm_clone_table"), aligned(sizeof(void *
+# ifdef HAVE_GAS_HIDDEN
+  __attribute__((__visibility__ ("hidden"))) = { };
+# else
+  = { 0, 0 };
+# endif
 #endif /* USE_TM_CLONE_REGISTRY */
 
 #ifdef INIT_ARRAY_SECTION_ASM_OP
commit bd6fe04af465d65d146e7ea7fd66b4a98cecff46
Author: Rich

Re: [v3] updated atomic configury

[Joseph S. Myers]

On Tue, 22 Nov 2011, Andrew MacLeod wrote:

> On 11/22/2011 10:32 AM, Joseph S. Myers wrote:
> > On Tue, 22 Nov 2011, Andrew MacLeod wrote:
> > 
> > > C currently doesn't have a char16_t and char32_t, so they aren't defined
> > It certainly does have those types, as typedefs defined in  for
> > the same types as uint_least16_t and uint_least32_t.  And  is
> > also required to define ATOMIC_CHAR16_T_LOCK_FREE and
> > ATOMIC_CHAR32_T_LOCK_FREE.
> but there isn't a stdatomic.h until we support C1x right? didnt we bail on

It still seems better to predefine the macros for those types, using 
char16_type_node and char32_type_node, using them initially for C++ and 
then later for C as well.

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

Ping: Java, disable -fdelete-null-pointer-checks

[Jeff Law]

* lang.c (java_init_options_struct): Disable optimizations
which assume a NULL pointer dereference will cause a fault.

Index: lang.c
===
*** lang.c  (revision 181321)
--- lang.c  (working copy)
*** java_init_options_struct (struct gcc_opt
*** 556,561 
--- 556,565 
  
/* Java requires left-to-right evaluation of subexpressions.  */
opts->x_flag_evaluation_order = 1;
+ 
+   /* Java catches catch NULL pointer exceptions, thus we can not necessarily
+  rely on a pointer having a non-NULL value after a dereference.  */
+   opts->x_flag_delete_null_pointer_checks = 0;
  }
  
  static void

Re: PATCH RFA: Build stages 2 and 3 with C++

[Gary Funck]

On 11/22/11 11:32:03, Ian Lance Taylor wrote:
> > If CXXFLAGS, is this a potentially surprising departure from
> > previous configure behavior?
> 
> Perhaps.  I don't see how we could reasonably make any other choice,though.

Agreed.  Just wondering if there might be potential documentation impact,
re: configure/build.

Re: [patch] support LTO of transactional memory

[Jack Howarth]

On Tue, Nov 22, 2011 at 10:30:44AM -0800, Richard Henderson wrote:
> On 11/22/2011 09:55 AM, Aldy Hernandez wrote:
> > * opts.c (finish_options): Do not fail for -fgnu-tm.
> > * gimple-streamer-out.c (output_gimple_stmt): Handle GIMPLE_TRANSACTION.
> > * gimple-streamer-in.c (input_gimple_stmt): Same.
> > * lto-cgraph.c (input_overwrite_node): Read tm_clone bit.
> > (lto_output_node): Write tm_clone bit.
> > lto/
> > * lto-lang.c (lto_attribute_table): Handle transaction_pure.
> > (handle_transaction_pure_attribute): New.
> 
> Ok.
> 
> 
> r~

  On x86_64-apple-darwin11, we see the link-time failures...

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, 
-flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o link, 
-flto -fgnu-tm

at -m32/-m64. These fail as...

Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/ c_lto_trans-mem-1_0.o 
c_lto_trans-mem-1_1.o   -flto
 -fgnu-tm   -m32 -o gcc-dg-lto-trans-mem-1-01.exe(timeout = 300)
Undefined symbols for architecture i386:^M
  "__ITM_registerTMCloneTable", referenced from:^M
  ___doTMRegistrations in crttms.o^M
  ___doTMRegistrations in crttms.o^M
  "__ITM_deregisterTMCloneTable", referenced from:^M
  ___doTMdeRegistrations in crttme.o^M
  ___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
  "__ITM_registerTMCloneTable", referenced from:^M
  ___doTMRegistrations in crttms.o^M
  ___doTMRegistrations in crttms.o^M  "__ITM_deregisterTMCloneTable", 
referenced from:^M
  ___doTMdeRegistrations in crttme.o^M
  ___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, 
-flto -fgnu-tm

Perhaps these are related to the run-time execution failures seen on i386 
linux...

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02303.html

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
execute -flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o 
execute -flto -fgnu-tm

--enable-checking=all results in long running compiles, where the compiler spends long periods of time in the garbage collector (GC)

[Gary Funck]

On 11/22/11 12:57:38, Diego Novillo wrote:
> --enable-checking=all enables GC checking, so I am not really
> surprised at the behaviour you observe.

Good to know.  Thanks.

> > I will try rebuilding with --disable-build-poststage1-with-cxx and
> > --enable-checking=all to try to determine if this is g++ specific
> > behavior.
> 
> Yes, that will be an interesting piece of data to gather.  Thanks.

Early indications are that this is _not_ strictly a g++ related issue.
Some compiles with cc1 have been running 90 mins. so far, and
inspection via gdb indicates they're spending a lot of time in the
garbage collector.

At this point, I'm going to stop the test build, and rebuild
with --enable-checking only.

- Gary

Re: [patch] support LTO of transactional memory

[Iain Sandoe]

On 22 Nov 2011, at 20:57, Jack Howarth wrote:


On Tue, Nov 22, 2011 at 10:30:44AM -0800, Richard Henderson wrote:

On 11/22/2011 09:55 AM, Aldy Hernandez wrote:

* opts.c (finish_options): Do not fail for -fgnu-tm.
	* gimple-streamer-out.c (output_gimple_stmt): Handle  
GIMPLE_TRANSACTION.

* gimple-streamer-in.c (input_gimple_stmt): Same.
* lto-cgraph.c (input_overwrite_node): Read tm_clone bit.
(lto_output_node): Write tm_clone bit.
lto/
* lto-lang.c (lto_attribute_table): Handle transaction_pure.
(handle_transaction_pure_attribute): New.


Ok.


r~


 On x86_64-apple-darwin11, we see the link-time failures...

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans- 
mem-1_1.o link, -flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans- 
mem-2_1.o link, -flto -fgnu-tm


at -m32/-m64. These fail as...

Executing on host: /sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/ 
gcc/xgcc -B/sw/src/fink.build/gcc47-4.7.0-1/darwin_objdir/gcc/  
c_lto_trans-mem-1_0.o c_lto_trans-mem-1_1.o   -flto
-fgnu-tm   -m32 -o gcc-dg-lto-trans-mem-1-01.exe(timeout =  
300)

Undefined symbols for architecture i386:^M
 "__ITM_registerTMCloneTable", referenced from:^M
 ___doTMRegistrations in crttms.o^M
 ___doTMRegistrations in crttms.o^M
 "__ITM_deregisterTMCloneTable", referenced from:^M
 ___doTMdeRegistrations in crttme.o^M
 ___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
 "__ITM_registerTMCloneTable", referenced from:^M
 ___doTMRegistrations in crttms.o^M
 ___doTMRegistrations in crttms.o^M   
"__ITM_deregisterTMCloneTable", referenced from:^M

 ___doTMdeRegistrations in crttme.o^M
 ___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans- 
mem-1_1.o link, -flto -fgnu-tm


I think we will need to ensure that libitm.dylib is on the link line -
 - maybe we're not picking up the spec properly

(or I will have to cook up a more complex build for the crts).

Iain

[google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

[Teresa Johnson]

This patch is for google-main only.
Tested with bootstrap and regression tests.
Under LIPO, estimate the code size footprint from the partial call
graph, and if it is large limit unrolling and peeling to avoid
increasing icache pressure.
Teresa

2011-11-21   Teresa Johnson  

* loop-unroll.c (loop_has_FP_comp): New function.
(limit_code_size): New function.
(unroll_and_peel_loops): Check if unrolling and/or peeling
should be disabled due to large code size estimates.
* common.opt (fripa-peel-size-limit): New option.
(fripa-unroll-size-limit): New option.
* tree-optimize.c (compute_codesize_estimate): New function.
(execute_cleanup_cfg_post_optimizing): Invoke
compute_codesize_estimate at the end of tree optimization.
* params.def (codesize-hotness-threshold): New parameter.
(unrollpeel-codesize-threshold): New parameter.
* doc/invoke.texi: Document the new options and parameters.


-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 181550)
+++ doc/invoke.texi (working copy)
@@ -400,7 +400,8 @@ Objective-C and Objective-C++ Dialects}.
 -freorder-blocks-and-partition -freorder-functions @gol
 -frerun-cse-after-loop -freschedule-modulo-scheduled-loops @gol
 -fripa -fripa-disallow-asm-modules -fripa-disallow-opt-mismatch @gol
--fripa-no-promote-always-inline-func -fripa-verbose -frounding-math @gol
+-fripa-no-promote-always-inline-func -fripa-verbose @gol
+-fripa-peel-size-limit -fripa-unroll-size-limit -frounding-math @gol
 -fsched2-use-superblocks -fsched-pressure @gol
 -fsched-spec-load -fsched-spec-load-dangerous @gol
 -fsched-stalled-insns-dep[=@var{n}] -fsched-stalled-insns[=@var{n}] @gol
@@ -8267,6 +8268,20 @@ Do not promote static functions with alw
 Enable printing of verbose information about dynamic inter-procedural 
optimizations.
 This is used in conjunction with the @option{-fripa}.
 
+@item -fripa-peel-size-limit
+@opindex fripa-peel-size-limit
+Limit loop peeling of non-const non-FP loops in a LIPO compilation under 
estimates
+of a large code footprint. Enabled by default under @option{-fripa}. Code size
+estimation and thresholds are controlled by the 
@option{codesize-hotness-threshold}
+and @option{unrollpeel-codesize-threshold} parameters.
+
+@item -fripa-unroll-size-limit
+@opindex fripa-unroll-size-limit
+Limit loop unrolling of non-const non-FP loops in a LIPO compilation under 
estimates
+of a large code footprint. Enabled by default under @option{-fripa}. Code size
+estimation and thresholds are controlled by the 
@option{codesize-hotness-threshold}
+and @option{unrollpeel-codesize-threshold} parameters.
+
 @item -fcallgraph-profiles-sections
 @opindex fcallgraph-profiles-sections
 Emit call graph edge profile counts in .note.callgraph.text sections. This is
@@ -8991,6 +9006,13 @@ hot loops. Its default value is 16.
 @item max-completely-peel-loop-nest-depth
 The maximum depth of a loop nest suitable for complete peeling.
 
+@item codesize-hotness-threshold
+The minimum profile count of basic blocks to look at when estimating
+the code size footprint of the call graph in a LIPO compile.
+
+@item unrollpeel-codesize-threshold
+Maximum LIPO code size footprint estimate for loop unrolling and peeling.
+
 @item max-unswitch-insns
 The maximum number of insns of an unswitched loop.
Index: loop-unroll.c
===
--- loop-unroll.c   (revision 181550)
+++ loop-unroll.c   (working copy)
@@ -181,6 +181,81 @@ report_unroll_peel(struct loop *loop, lo
 "" : iter_str);
 }
 
+/* Determine whether LOOP contains floating-point computation. */
+static bool
+loop_has_FP_comp(struct loop *loop)
+{
+  rtx set, dest;
+  basic_block *body, bb;
+  unsigned i;
+  rtx insn;
+
+  body = get_loop_body (loop);
+  for (i = 0; i < loop->num_nodes; i++)
+{
+  bb = body[i];
+
+  FOR_BB_INSNS (bb, insn)
+  {
+set = single_set (insn);
+if (!set)
+  continue;
+
+dest = SET_DEST (set);
+if (FLOAT_MODE_P (GET_MODE (dest)))
+{
+  free (body);
+  return true;
+}
+  }
+}
+  free (body);
+  return false;
+}
+
+/* This returns a bit vector */
+typedef enum {
+  NO_LIMIT = 0,
+  LIMIT_UNROLL = 0x1,
+  LIMIT_PEEL = 0x2,
+  LIMIT_BOTH = 0x3
+} limit_type;
+
+extern int cgraph_codesize_estimate;
+
+/* Determine whether LOOP unrolling/peeling should be constrained based
+   on code footprint estimates. */
+static limit_type
+limit_code_size(struct loop *loop)
+{
+  unsigned size_threshold;
+  limit_type result = NO_LIMIT;
+  int result_int = 0;
+
+  if (!flag_dyn_ipa)
+return NO_LIMIT;
+
+  gcc_assert (cgraph_codesize_estimate >= 0);
+
+  /* Ignore FP loops, which are more likely to benefit heavily from
+ 

Re: [patch] support LTO of transactional memory

[Aldy Hernandez]

-fgnu-tm -m32 -o gcc-dg-lto-trans-mem-1-01.exe (timeout = 300)
Undefined symbols for architecture i386:^M
"__ITM_registerTMCloneTable", referenced from:^M
___doTMRegistrations in crttms.o^M
___doTMRegistrations in crttms.o^M
"__ITM_deregisterTMCloneTable", referenced from:^M
___doTMdeRegistrations in crttme.o^M
___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
"__ITM_registerTMCloneTable", referenced from:^M
___doTMRegistrations in crttms.o^M
___doTMRegistrations in crttms.o^M "__ITM_deregisterTMCloneTable",
referenced from:^M
___doTMdeRegistrations in crttme.o^M
___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/lto/trans-mem-1
c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm


I think we will need to ensure that libitm.dylib is on the link line -
- maybe we're not picking up the spec properly


This is a missing dummy declaration for the test, since we're not 
linking with libitm.  On Linux x86-64 there was no call to 
_ITM_registerTMCloneTable generated by the compiler.


Can you try this?
testsuite/
* gcc.dg/lto/trans-mem-2_0.c: Add _ITM_registerTMCloneTable dummy.
* gcc.dg/lto/trans-mem-1_1.c: Add _ITM_registerTMCloneTable dummy.

Index: testsuite/gcc.dg/lto/trans-mem-2_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 181629)
+++ testsuite/gcc.dg/lto/trans-mem-2_0.c(working copy)
@@ -9,6 +9,7 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
 
 main()
 {
Index: testsuite/gcc.dg/lto/trans-mem-1_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 181629)
+++ testsuite/gcc.dg/lto/trans-mem-1_1.c(working copy)
@@ -5,3 +5,4 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

[Diego Novillo]

On 11-11-22 16:06 , Teresa Johnson wrote:

This patch is for google-main only.
Tested with bootstrap and regression tests.
Under LIPO, estimate the code size footprint from the partial call
graph, and if it is large limit unrolling and peeling to avoid
increasing icache pressure.


So, currently, there are several broken LIPO tests in google/main, so 
I'm not sure how testable LIPO is on the branch.  Is your patch related 
to any of them?  (see 
contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail for a list 
of broken tests).



Diego.

Re: [patch] support LTO of transactional memory

[Iain Sandoe]

On 22 Nov 2011, at 21:09, Aldy Hernandez wrote:




-fgnu-tm -m32 -o gcc-dg-lto-trans-mem-1-01.exe (timeout = 300)
Undefined symbols for architecture i386:^M
"__ITM_registerTMCloneTable", referenced from:^M
___doTMRegistrations in crttms.o^M
___doTMRegistrations in crttms.o^M
"__ITM_deregisterTMCloneTable", referenced from:^M
___doTMdeRegistrations in crttme.o^M
___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
"__ITM_registerTMCloneTable", referenced from:^M
___doTMRegistrations in crttms.o^M
___doTMRegistrations in crttms.o^M "__ITM_deregisterTMCloneTable",
referenced from:^M
___doTMdeRegistrations in crttme.o^M
___doTMdeRegistrations in crttme.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/lto/trans-mem-1
c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o link, -flto -fgnu-tm


I think we will need to ensure that libitm.dylib is on the link  
line -

- maybe we're not picking up the spec properly


This is a missing dummy declaration for the test, since we're not  
linking with libitm.  On Linux x86-64 there was no call to  
_ITM_registerTMCloneTable generated by the compiler.


It's a consequence of a combination of the way that "weak" works on  
Darwin, and the fact that I tried to make a "one size fits all" crt.




Can you try this?



we will need a dummy for _ITM_deregisterTMCloneTable as well.

(building at present .. will hopefully try before the end of today -  
GMT :-)


Iain

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

[Xinliang David Li]

The failures are independent which will be looked into at some point.
Teresa's patch is/will be tested cleanly on google-46.

David

On Tue, Nov 22, 2011 at 1:12 PM, Diego Novillo  wrote:
> On 11-11-22 16:06 , Teresa Johnson wrote:
>>
>> This patch is for google-main only.
>> Tested with bootstrap and regression tests.
>> Under LIPO, estimate the code size footprint from the partial call
>> graph, and if it is large limit unrolling and peeling to avoid
>> increasing icache pressure.
>
> So, currently, there are several broken LIPO tests in google/main, so I'm
> not sure how testable LIPO is on the branch.  Is your patch related to any
> of them?  (see contrib/testsuite-management/x86_64-unknown-linux-gnu.xfail
> for a list of broken tests).
>
>
> Diego.
>

Re: [PATCH] __atomic error reporting

[Joseph S. Myers]

On Tue, 22 Nov 2011, Andrew MacLeod wrote:

> int n = get_atomic_generic_size (loc, function, params);
>   
> +   /* Size of 0 is an error condition.  */
> +   if (n == 0)
> + {
> +   *new_return = error_mark_node;
> +   return true;
> + }

As far as I can see, get_atomic_generic_size can return 0 in various cases 
where it did not print an error message:

* The "default" case in the initial switch statement.  If this is not 
actually reachable, use gcc_unreachable () there.

* If TYPE_SIZE_UNIT if the pointer target type is zero.  This could be the 
case for empty structures or zero-size arrays (both GNU extensions).  
Logically there's nothing wrong with atomic operations on such a zero-size 
object (they should evaluate all operands for their side effects and then 
need do nothing more).  But if you don't want to make them work now, there 
should be a sorry () call and a PR for making them work.

In looking at that function, I also see another unrelated problem: it has 
a statement "return MEMMODEL_SEQ_CST;" (i.e. return 5;) but is otherwise 
meant to be returning a size not a memory model, so something doesn't make 
sense there.  A second unrelated problem:

void f (int n) { int a[n], b[n]; __atomic_load (&a, &b, __ATOMIC_SEQ_CST); }

ICEs in tree_low_cst.  C1X doesn't require atomic operations on 
variable-length types - arrays can't be _Atomic-qualified and atomic 
operations are only required on atomic types - but there should be a 
proper error not an ICE.

It seems a bad idea to put error_mark_node in the IR for code that has not 
generated an error.  So maybe you need to change get_atomic_generic_size's 
interface so that errors can be unambiguously distinguished from zero-size 
objects - and make the comment above that function explicitly say that on 
error return it has output an error message.

Finally, the patch needs a testcase added to the testsuite for the case 
reported in the PR as ICEing - and for any other problems found and fixed 
in the process.

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

Re: [patch] support LTO of transactional memory

[Aldy Hernandez]

It's a consequence of a combination of the way that "weak" works on
Darwin, and the fact that I tried to make a "one size fits all" crt.



Can you try this?



we will need a dummy for _ITM_deregisterTMCloneTable as well.


Then try this; similarly for any other symbols Darwin may be generating.

Feel free to commit as obvious, or just let me know if it works and I 
can commit.
testsuite/
* gcc.dg/lto/trans-mem-2_0.c: Add _ITM_*registerTMCloneTable dummy.
* gcc.dg/lto/trans-mem-1_1.c: Add _ITM_*registerTMCloneTable dummy.

Index: testsuite/gcc.dg/lto/trans-mem-2_0.c
===
--- testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 181629)
+++ testsuite/gcc.dg/lto/trans-mem-2_0.c(working copy)
@@ -9,6 +9,8 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
+dummy(_ITM_deregisterTMCloneTable)
 
 main()
 {
Index: testsuite/gcc.dg/lto/trans-mem-1_1.c
===
--- testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 181629)
+++ testsuite/gcc.dg/lto/trans-mem-1_1.c(working copy)
@@ -5,3 +5,5 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
+dummy(_ITM_deregisterTMCloneTable)

Re: [patch] support LTO of transactional memory

[Jack Howarth]

On Tue, Nov 22, 2011 at 03:30:22PM -0600, Aldy Hernandez wrote:
>
>> It's a consequence of a combination of the way that "weak" works on
>> Darwin, and the fact that I tried to make a "one size fits all" crt.
>>
>>>
>>> Can you try this?
>>> 
>>
>> we will need a dummy for _ITM_deregisterTMCloneTable as well.
>
> Then try this; similarly for any other symbols Darwin may be generating.
>
> Feel free to commit as obvious, or just let me know if it works and I  
> can commit.

On x86_64-apple-darwin11, this converts the link failures into run-time failures
as are seen on i386 linux.

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
execute -flto -fgnu-tm
FAIL: gcc.dg/lto/trans-mem-2 c_lto_trans-mem-2_0.o-c_lto_trans-mem-2_1.o 
execute -flto -fgnu-tm

at -m32

FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o 
execute -flto -fgnu-tm

at -m64.

> testsuite/
>   * gcc.dg/lto/trans-mem-2_0.c: Add _ITM_*registerTMCloneTable dummy.
>   * gcc.dg/lto/trans-mem-1_1.c: Add _ITM_*registerTMCloneTable dummy.
> 
> Index: testsuite/gcc.dg/lto/trans-mem-2_0.c
> ===
> --- testsuite/gcc.dg/lto/trans-mem-2_0.c  (revision 181629)
> +++ testsuite/gcc.dg/lto/trans-mem-2_0.c  (working copy)
> @@ -9,6 +9,8 @@ dummy(_ITM_beginTransaction)
>  dummy(_ITM_commitTransaction)
>  dummy(_ITM_WU4)
>  dummy(_ITM_WU8)
> +dummy(_ITM_registerTMCloneTable)
> +dummy(_ITM_deregisterTMCloneTable)
>  
>  main()
>  {
> Index: testsuite/gcc.dg/lto/trans-mem-1_1.c
> ===
> --- testsuite/gcc.dg/lto/trans-mem-1_1.c  (revision 181629)
> +++ testsuite/gcc.dg/lto/trans-mem-1_1.c  (working copy)
> @@ -5,3 +5,5 @@ dummy(_ITM_beginTransaction)
>  dummy(_ITM_commitTransaction)
>  dummy(_ITM_WU4)
>  dummy(_ITM_WU8)
> +dummy(_ITM_registerTMCloneTable)
> +dummy(_ITM_deregisterTMCloneTable)

Re: [patch] support LTO of transactional memory

[Richard Henderson]

On 11/22/2011 01:37 PM, Jack Howarth wrote:
> On x86_64-apple-darwin11, this converts the link failures into run-time 
> failures
> as are seen on i386 linux.


These aren't supposed to be runtime tests.  Did a { dg-do link } marker get 
missed?


r~

Re: [google] Limit unrolling and peeling under LIPO estimates of large code size/icache pressure

[Xinliang David Li]

Ok for google branches.

David

On Tue, Nov 22, 2011 at 1:06 PM, Teresa Johnson  wrote:
> This patch is for google-main only.
> Tested with bootstrap and regression tests.
> Under LIPO, estimate the code size footprint from the partial call
> graph, and if it is large limit unrolling and peeling to avoid
> increasing icache pressure.
> Teresa
>
> 2011-11-21   Teresa Johnson  
>
>        * loop-unroll.c (loop_has_FP_comp): New function.
>        (limit_code_size): New function.
>        (unroll_and_peel_loops): Check if unrolling and/or peeling
>        should be disabled due to large code size estimates.
>        * common.opt (fripa-peel-size-limit): New option.
>        (fripa-unroll-size-limit): New option.
>        * tree-optimize.c (compute_codesize_estimate): New function.
>        (execute_cleanup_cfg_post_optimizing): Invoke
>        compute_codesize_estimate at the end of tree optimization.
>        * params.def (codesize-hotness-threshold): New parameter.
>        (unrollpeel-codesize-threshold): New parameter.
>        * doc/invoke.texi: Document the new options and parameters.
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
>

Re: [PATCH 0/7] Sparc atomic optabs errata

[Richard Henderson]

On 11/21/2011 09:21 PM, David Miller wrote:
> Hey Richard, after the ICE fix you made today the only test that
> fails is gcc.dg/atomic-flag.c at -O0.  Below is the assembler
> generated.

Yeah, that test is in error.

Andrew and I are discussing how to re-arrange the atomic_bool support.


r~

Re: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier

[Dodji Seketeli]

Jason Merrill  writes:

> On 11/21/2011 11:41 AM, Dodji Seketeli wrote:
>> -template class Ptr;//{ dg-error "explicit instantiation|non-class 
>> templ|does not decl|anything" }
>> +template class Ptr;//{ dg-error "alias 
>> templ|specialization|Ptr|after|class" }
>
> You seem to be using | to mean .* here.  Let's choose one key phrase
> to check for.  :)

Actually, I wanted to avoid the verbosity of \[^\n\r\]*, as .* is so
greedy that it eats even end of lines.  Now I just did bite the bullet
and used \[^\n\r\]* instead.

>
>> -struct A { typedef int X; };// { dg-error "previous 
>> declaration" }
>> +struct A { typedef int X; };
>
> Let's change dg-error to dg-message instead of dropping the check
> entirely on at least one of these tests to avoid a diagnostic quality
> regression.

OK.  I did the change on all the tests.

> OK with those changes.

Thanks.  I am running the test suite again, just in case, with the patch
below.  I'll commit it tomorrow if it passes.

From: Dodji Seketeli 
Date: Fri, 18 Nov 2011 00:50:21 +0100
Subject: [PATCH] PR c++/51145 - Alias template in elaborated-type-specifier
 accepted

gcc/cp/

PR c++/51145
* decl.c (check_elaborated_type_specifier): Gracefully handle
error_mark_node.  Accept bound template template parameters.
Update diagnostics for alias template specializations.  Update
comment.
* parser.c (cp_parser_elaborated_type_specifier): Use
check_elaborated_type_specifier for simple-template-ids as well.

gcc/testsuite/

PR c++/51145
* g++.dg/cpp0x/alias-decl-14.C: New test.
* g++.dg/cpp0x/alias-decl-2.C: Adjust for tests that were wrongly
passing before.
* g++.dg/cpp0x/alias-decl-10.C: Likewise and adjust for diagnostic
change.
* g++.dg/ext/attrib27.C: Adjust for diagnostic change.
* g++.dg/lookup/struct1.C: Likewise.
* g++.dg/parse/elab1.C: Likewise.
* g++.dg/parse/elab2.C: Likewise.
* g++.dg/parse/int-as-enum1.C: Likewise.
* g++.dg/parse/typedef1.C: Likewise.
* g++.dg/parse/typedef3.C: Likewise.
* g++.dg/parse/typedef4.C: Likewise.
* g++.dg/parse/typedef5.C: Likewise.
* g++.dg/template/crash26.C: Likewise.
* g++.dg/template/nontype4.C: Likewise.
* g++.old-deja/g++.benjamin/typedef01.C: Likewise.
* g++.old-deja/g++.brendan/line1.C: Likewise.
* g++.old-deja/g++.other/elab1.C: Likewise.
* g++.old-deja/g++.other/syntax4.C: Likewise.
---
 gcc/cp/ChangeLog   |   10 
 gcc/cp/decl.c  |   21 ++---
 gcc/cp/parser.c|3 +-
 gcc/testsuite/ChangeLog|   24 
 gcc/testsuite/g++.dg/cpp0x/alias-decl-10.C |   16 ++---
 gcc/testsuite/g++.dg/cpp0x/alias-decl-14.C |   14 +++
 gcc/testsuite/g++.dg/cpp0x/alias-decl-2.C  |2 +-
 gcc/testsuite/g++.dg/ext/attrib27.C|2 +-
 gcc/testsuite/g++.dg/lookup/struct1.C  |4 +-
 gcc/testsuite/g++.dg/parse/elab1.C |2 +-
 gcc/testsuite/g++.dg/parse/elab2.C |2 +-
 gcc/testsuite/g++.dg/parse/int-as-enum1.C  |2 +-
 gcc/testsuite/g++.dg/parse/typedef1.C  |2 +-
 gcc/testsuite/g++.dg/parse/typedef3.C  |2 +-
 gcc/testsuite/g++.dg/parse/typedef4.C  |2 +-
 gcc/testsuite/g++.dg/parse/typedef5.C  |2 +-
 gcc/testsuite/g++.dg/template/crash26.C|2 +-
 gcc/testsuite/g++.dg/template/nontype4.C   |2 +-
 .../g++.old-deja/g++.benjamin/typedef01.C  |4 +-
 gcc/testsuite/g++.old-deja/g++.brendan/line1.C |2 +-
 gcc/testsuite/g++.old-deja/g++.other/elab1.C   |2 +-
 gcc/testsuite/g++.old-deja/g++.other/syntax4.C |2 +-
 22 files changed, 97 insertions(+), 27 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-14.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index b77963b..8406432 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11342,6 +11342,9 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
 {
   tree type;
 
+  if (decl == error_mark_node)
+return error_mark_node;
+
   /* In the case of:
 
struct S { struct S *p; };
@@ -11361,10 +11364,15 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
 type, tag_name (tag_code));
   return error_mark_node;
 }
+  /* Accept bound template template parameters.  */
+  else if (allow_template_p
+  && TREE_CODE (type) == BOUND_TEMPLATE_TEMPLATE_PARM)
+;
   /*   [dcl.type.elab]
 
-   If the identifier resolves to a typedef-name or a template
-   type-parameter, the elaborated-type-specifier is ill-formed.
+   If the identifier resolves to a typedef-name or the
+   simple-template-id resolv

Re: [PATCH 0/7] Sparc atomic optabs errata

[David Miller]

From: Richard Henderson 
Date: Tue, 22 Nov 2011 14:36:53 -0800

> On 11/21/2011 09:21 PM, David Miller wrote:
>> Hey Richard, after the ICE fix you made today the only test that
>> fails is gcc.dg/atomic-flag.c at -O0.  Below is the assembler
>> generated.
> 
> Yeah, that test is in error.
> 
> Andrew and I are discussing how to re-arrange the atomic_bool support.

Great, then with that in mind I'm totally fine with pushing those sparc
changes to trunk.

Thanks a lot for doing this work Richard.

Re: [patch] support LTO of transactional memory

[Iain Sandoe]

On 22 Nov 2011, at 21:43, Richard Henderson wrote:


On 11/22/2011 01:37 PM, Jack Howarth wrote:
On x86_64-apple-darwin11, this converts the link failures into run- 
time failures

as are seen on i386 linux.



These aren't supposed to be runtime tests.  Did a { dg-do link }  
marker get missed?


this works for me if that was the intention
Iain


Index: gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c
===
--- gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c(revision 181634)
+++ gcc/testsuite/gcc.dg/lto/trans-mem-2_0.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-lto-options {{-flto -fgnu-tm}} } */
+/* { dg-lto-do link } */
 
 extern void foobar() __attribute__((transaction_callable));
 
@@ -9,6 +10,8 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
+dummy(_ITM_deregisterTMCloneTable)
 
 main()
 {
Index: gcc/testsuite/gcc.dg/lto/trans-mem-1_0.c
===
--- gcc/testsuite/gcc.dg/lto/trans-mem-1_0.c(revision 181634)
+++ gcc/testsuite/gcc.dg/lto/trans-mem-1_0.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-lto-options {{-flto -fgnu-tm}} } */
+/* { dg-lto-do link } */
 
 int i;
 
Index: gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c
===
--- gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c(revision 181634)
+++ gcc/testsuite/gcc.dg/lto/trans-mem-1_1.c(working copy)
@@ -5,3 +5,5 @@ dummy(_ITM_beginTransaction)
 dummy(_ITM_commitTransaction)
 dummy(_ITM_WU4)
 dummy(_ITM_WU8)
+dummy(_ITM_registerTMCloneTable)
+dummy(_ITM_deregisterTMCloneTable)

Re: [patch] support LTO of transactional memory

[Aldy Hernandez]

On 11/22/11 16:40, Iain Sandoe wrote:


On 22 Nov 2011, at 21:43, Richard Henderson wrote:


On 11/22/2011 01:37 PM, Jack Howarth wrote:

On x86_64-apple-darwin11, this converts the link failures into
run-time failures
as are seen on i386 linux.



These aren't supposed to be runtime tests. Did a { dg-do link } marker
get missed?


this works for me if that was the intention
Iain





Whoops, that was indeed the intention.  They are link tests, not runtime 
tests.

RE: [RFA/ARM][Patch 01/02]: Thumb2 epilogue in RTL

[Xinyu Qi]

At 2011-11-22 18:37:16,"Ramana Radhakrishnan"  
wrote: 
> >>
> >> Though I don't fully understand this patch, I think it is unnecessary to
> consider turn on Thumb2 for iwmmxt,
> >> because there is no chip that supports WMMX instructions with thumb2
> mode.
> 
> Xinyu: I seem to have mis-remembered that one of your patches was
> turning on Thumb2 for wMMX.

Hi Ramana,
I remember I just enable iwmmxt with vfp in the first part of my patch.

> 
> >
> > Ramana, in that case, should I add the change you suggested in ARM RTL
> > epilogue patch only?
> 
> The comment in Thumb2 epilogues should remain and yes - it should be
> added to the ARM RTL epilogue patch only. I'm also ok with that being
> in with a #if 0 around it but given it's in the epilogue whoever tries
> turning on Thumb2 for iwMMX will surely notice that in the first
> testrun :)
> 
> I'll try and find some time later today to apply both the patches and
> see where I get to.
> 
> cheers
> Ramana
> 
> >
> > --
> >
> >
> >

[arm-embedded] Fix restrict volatile bitfield

[Joey Ye]

Committed to ARM/embedded-4_6-branch

Partly apply restrict volatile bitfield fix from bernd.
2010-12-02  Bernd Schmidt  

* expr.c (store_field): Avoid a direct store if the mode is larger
than the size of the bit field.
* stor-layout.c (layout_decl): If flag_strict_volatile_bitfields,
treat non-volatile bit fields like volatile ones.

testsuite:

2011-11-23  Joey Ye  
* g++.dg/abi/bitfield12.C: Add option
-fno-strict-volatile-bitfields.

volatile-bitfields-embedded-branch.patch
Description: Binary data