[patch, fortran] Fix PR 51858, wrong-code regression with function elimination

[Thomas Koenig]

Hello world,

the attached patch fixes the PR by converting

if (foo) then
...
else if (bar) then
...
end if

to if (foo) then
else
  if (bar) then
  end if
end if

so inserting a block for temporary variables around the converted
if statement works.

OK for trunk?

Thomas

2012-01-29  Thomas König  

PR fortran/51858
* frontend-passes.c (convert_elseif):  New function.
(optimize_namespace):  Call it.

2012-01-29  Thomas König  

PR fortran/51858
* gfortran.dg/function_optimize_10.f90:  New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 183449)
+++ frontend-passes.c	(Arbeitskopie)
@@ -509,6 +509,63 @@ convert_do_while (gfc_code **c, int *walk_subtrees
   return 0;
 }
 
+/* Code callback function for converting
+   if (a) then
+   ...
+   else if (b) then
+   end if
+
+   into
+   if (a) then
+   else
+ if (b) then
+ end if
+   end if
+
+   because otherwise common function elimination would place the BLOCKs
+   into the wrong place.  */
+
+static int
+convert_elseif (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,
+		void *data ATTRIBUTE_UNUSED)
+{
+  gfc_code *co = *c;
+  gfc_code *c_if1, *c_if2, *else_stmt;
+
+  if (co->op != EXEC_IF)
+return 0;
+
+  /* This loop starts out with the first ELSE statement.  */
+  for (else_stmt = co->block->block; else_stmt != NULL;
+   else_stmt = else_stmt->block)
+{
+  /* If there is no condition, we're set.  */
+  if (else_stmt->expr1 == NULL)
+	break;
+
+  /* Generate the new IF statement.  */
+  c_if2 = XCNEW (gfc_code);
+  c_if2->op = EXEC_IF;
+  c_if2->expr1 = else_stmt->expr1;
+  c_if2->next = else_stmt->next;
+  c_if2->loc = else_stmt->loc;
+  c_if2->block = else_stmt->block;
+
+  /* ... plus the one to chain it to.  */
+  c_if1 = XCNEW (gfc_code);
+  c_if1->op = EXEC_IF;
+  c_if1->block = c_if2;
+  c_if1->loc = else_stmt->loc;
+
+  /* Insert the new IF after the ELSE.  */
+  else_stmt->expr1 = NULL;
+  else_stmt->next = c_if1;
+  else_stmt->block = NULL;
+  else_stmt->next = c_if1;
+}
+  /*  Don't walk subtrees.  */
+  return 1;
+}
 /* Optimize a namespace, including all contained namespaces.  */
 
 static void
@@ -520,6 +577,7 @@ optimize_namespace (gfc_namespace *ns)
   in_omp_workshare = false;
 
   gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
+  gfc_code_walker (&ns->code, convert_elseif, dummy_expr_callback, NULL);
   gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
   gfc_code_walker (&ns->code, optimize_code, optimize_expr, NULL);
 
! { do-do run }
! PR 51858 - this used to generate wrong code.
! Original test case by Don Simons.

program main
  implicit none
  logical :: test1_ok
  logical :: test2_ok
  character(len=1):: charq
  
  test1_ok = .true.
  test2_ok = .false.
  charq = 'c'
  if (charq .eq. ' ') then
 test1_ok = .false.
  else if ((my_ichar(charq).ge.97 .and. my_ichar(charq).le.103)) then
 test2_OK = .true.
  end if
  if ((.not. test1_ok) .or. (.not. test2_ok)) call abort
contains
  pure function my_ichar(c)
integer :: my_ichar
character(len=1), intent(in) :: c
my_ichar = ichar(c)
  end function my_ichar
end program main

Re: [patch, fortran] Fix PR 51858, wrong-code regression with function elimination

[Thomas Koenig]

I wrote:


OK for trunk?


I forgot: Regression-tested.

Thomas

Re: [Patch] PR51374: combine.c and volatile correctness

[Richard Sandiford]

Georg-Johann Lay  writes:
> This patch fixes PR51374 by more strictly updating mem_last_set.
> Sloppy handling of mem_last_set can lead to error in volatile correctness
> because combine then is allowed to drag one volatile access over an other
> volatile thing (volatile access, asm volatile, unspec_volatile...).
>
> As explained in the source comment, any volatile might change memory, even a
> volatile read.

This looks too broad to me.  Volatile MEMs don't usually alias
non-volatile ones (so for example, reads from volatile memory shouldn't
affect reads from non-volatile memory).  What do you think about
instead changing:

  /* If there are any volatile insns between INSN and I3, reject, because
 they might affect machine state.  */

  for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (INSN_P (p) && p != succ && p != succ2 && volatile_insn_p (PATTERN (p)))
  return 0;

to:

  /* If INSN contains volatile references (specifically volatile MEMs),
 we cannot combine across any other volatile references.
 Even if INSN doesn't contain volatile references, any intervening
 volatile insn might affect machine state.  */

  pred = volatile_refs_p (insn) ? volatile_refs_p : volatile_insn_p;
  for (p = NEXT_INSN (insn); p != i3; p = NEXT_INSN (p))
if (NONDEBUG_INSN_P (p) && p != succ && p != succ2 && pred (PATTERN (p)))
  return 0;

As you say in the PR notes, we've already handled volatile_insn_p (insn)
by this stage, so the new loop is handling:

   volatile_refs_p (insn) && !volatile_insn_p (insn)

> Moreover, writes of the shape (set (zero_extract (mem ... update mem_last_set.

Good catch.  I think we should use note_stores for added safety though,
rather than call zero_extract out as a special case.  (I realise the
function already handles subregs, but still.)

BTW, just for the record:

> Index: combine.c
> ===
> --- combine.c (revision 183472)
> +++ combine.c (working copy)
> @@ -12365,7 +12365,24 @@ record_dead_and_set_regs_1 (rtx dest, co
>else if (MEM_P (dest)
>  /* Ignore pushes, they clobber nothing.  */
>  && ! push_operand (dest, GET_MODE (dest)))
> -mem_last_set = DF_INSN_LUID (record_dead_insn);
> +{
> +  mem_last_set = DF_INSN_LUID (record_dead_insn);
> +}

the existing formatting is the correct one here.

Thanks,
Richard

[Patch, Fortran, committed] PR 52038 - Remove unused, wrongly added function

[Tobias Burnus]

The patch fixes a build error. The function was accidentally added Rev. 
183620 of 2012-01-27 for PR 52016.


The function is part of the (uncommitted) draft patch for PR 50981.

Committed as Rev. 183675.

Tobias

Re: [Patch, Fortran, committed] PR 52038 - Remove unused, wrongly added function

[Tobias Burnus]

I forgot to attach the committed patch ...

Tobias Burnus wrote:
The patch fixes a build error. The function was accidentally added 
Rev. 183620 of 2012-01-27 for PR 52016.


The function is part of the (uncommitted) draft patch for PR 50981.

Committed as Rev. 183675.

Tobias
Index: ChangeLog
===
--- ChangeLog	(Revision 183674)
+++ ChangeLog	(Arbeitskopie)
@@ -1,3 +1,9 @@
+2012-01-29  Tobias Burnus  
+
+	PR fortran/52038
+	* resolve.c (symbol_as): Remove unused, accidentally
+	added function.
+
 2012-01-28  Tobias Burnus  
 
 	PR fortran/51972
Index: resolve.c
===
--- resolve.c	(Revision 183674)
+++ resolve.c	(Arbeitskopie)
@@ -1582,16 +1582,6 @@
 }
 
 
-gfc_array_spec *
-symbol_as (gfc_symbol *sym)
-{
-  if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
-return CLASS_DATA (sym)->as;
-  else
-return sym->as;
-}
-
-
 /* Resolve an actual argument list.  Most of the time, this is just
resolving the expressions in the list.
The exception is that we sometimes have to decide whether arguments

Re: [PATCH] Fix PR 51505

[Eric Botcazou]

> As discussed in Bugzilla, this is the patch implementing Paolo's suggestion
> of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes.  The code assumes
> there is at most one such note per insn.

That's wrong though and wreaks havoc during reload, e.g.:

(insn 169 60 62 4 (set (reg:TF 158)
(mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
(const_int -16 [0xfff0])) [3 S16 A64])) 
960513-1.c:13 97 {*movtf_insn_sp32}
 (expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
(const_int -16 [0xfff0])) [3 S16 A64])
(expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ])
(reg:TF 154))
(nil

because the REG_EQUIV note disappears behind reload's back and it isn't 
prepared for that.  This is the cause of the following regression on SPARC:

FAIL: gcc.c-torture/execute/960513-1.c execution,  -Os

-- 
Eric Botcazou

[patch libjava]: Fix PR target/51500

[Kai Tietz]

Hello,

this patch adds thiscall-call feature via libffi for 32-bit Windows
native target.

ChangeLog

2012-01-29  Kai Tietz  

PR target/51500
* interpret.cc (_Jv_init_cif): Handle thiscall
convention for 32-bit Windows.
* java/lang/reflect/natMethod.cc (_Jv_CallAnyMethodA):
Likewise.
* java/lang/reflect/natVMProxy.cc (ncode): Force SYSV
closure for 32-bit Windows.
(invoke_t): Add thiscall-attribute for 32-bit Windows.

Patch tested for i686-w64-mingw32, i686-pc-cygwin, and
x86_64-unknown-linux-gnu.  Ok for apply?

Regards,
Kai

Index: gcc/libjava/interpret.cc
===
--- gcc.orig/libjava/interpret.cc
+++ gcc/libjava/interpret.cc
@@ -1303,7 +1303,12 @@ _Jv_init_cif (_Jv_Utf8Const* signature,
   if (ptr != (unsigned char*)signature->chars() + signature->len())
 throw_internal_error ("did not find end of signature");

-  if (ffi_prep_cif (cif, FFI_DEFAULT_ABI,
+  ffi_abi cabi = FFI_DEFAULT_ABI;
+#if defined (X86_WIN32) && !defined (__CYGWIN__)
+  if (!staticp)
+cabi = FFI_THISCALL;
+#endif
+  if (ffi_prep_cif (cif, cabi,
arg_count, rtype, arg_types) != FFI_OK)
 throw_internal_error ("ffi_prep_cif failed");

Index: gcc/libjava/java/lang/reflect/natMethod.cc
===
--- gcc.orig/libjava/java/lang/reflect/natMethod.cc
+++ gcc/libjava/java/lang/reflect/natMethod.cc
@@ -436,7 +436,12 @@ _Jv_CallAnyMethodA (jobject obj,
   p += size_per_arg;
 }

-  if (ffi_prep_cif (&cif, FFI_DEFAULT_ABI, param_count,
+  ffi_abi cabi = FFI_DEFAULT_ABI;
+#if defined (X86_WIN32) && !defined (__CYGWIN__)
+  if (needs_this)
+cabi = FFI_THISCALL;
+#endif
+  if (ffi_prep_cif (&cif, cabi, param_count,
rtype, argtypes) != FFI_OK)
 throw new java::lang::VirtualMachineError(JvNewStringLatin1("internal
error: ffi_prep_cif failed"));

Index: gcc/libjava/java/lang/reflect/natVMProxy.cc
===
--- gcc.orig/libjava/java/lang/reflect/natVMProxy.cc
+++ gcc/libjava/java/lang/reflect/natVMProxy.cc
@@ -79,7 +79,11 @@ typedef void (*closure_fun) (ffi_cif*, v
 static void *ncode (int method_index, jclass klass, _Jv_Method *self,
closure_fun fun);
 static void run_proxy (ffi_cif*, void*, void**, void*);

-typedef jobject invoke_t (jobject, Proxy *, Method *, JArray< jobject > *);
+typedef jobject
+#if defined (X86_WIN32) && !defined (__CYGWIN__)
+ __attribute__ ((thiscall))
+#endif
+ invoke_t (jobject, Proxy *, Method *, JArray< jobject > *);

 // True if pc points to a proxy frame.

@@ -442,6 +446,11 @@ ncode (int method_index, jclass klass, _
&closure->cif,
&closure->arg_types[0],
NULL);
+#if defined (X86_WIN32) && !defined (__CYGWIN__)
+  /* Redirect via SYSV, as actual function will be invoked via
+ invoke methods.  */
+  closure->cif.abi = FFI_SYSV;
+#endif
   closure->self = self;

   JvAssert ((self->accflags & Modifier::NATIVE) == 0);

Re: [PATCH] invoke.texi: "compile time", "run time" cleanup

[Joseph S. Myers]

On Sat, 28 Jan 2012, Sandra Loosemore wrote:

> 2012-01-28  Sandra Loosemore  
> 
>   gcc/
>   * doc/invoke.texi: Make usage of "compile time" and
>   "run time"/"runtime" consistent throughout the file.

OK.  Could you post a patch to codingconventions.html to document the 
conventions you described in your message?

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

Re: [PATCH] Fix PR 51505

[Eric Botcazou]

> > As discussed in Bugzilla, this is the patch implementing Paolo's
> > suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes.  The
> > code assumes there is at most one such note per insn.
>
> That's wrong though and wreaks havoc during reload, e.g.:
>
> (insn 169 60 62 4 (set (reg:TF 158)
> (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
> (const_int -16 [0xfff0])) [3 S16 A64]))
> 960513-1.c:13 97 {*movtf_insn_sp32}
>  (expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
> (const_int -16 [0xfff0])) [3 S16 A64])
> (expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ])
> (reg:TF 154))
> (nil
>
> because the REG_EQUIV note disappears behind reload's back and it isn't
> prepared for that.  This is the cause of the following regression on SPARC:
>
> FAIL: gcc.c-torture/execute/960513-1.c execution,  -Os

As well as:

FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O2 
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -Os 
FAIL: gcc.c-torture/execute/stdarg-2.c 
execution,  -O2 -flto -flto-partition=none 
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O2 -flto 

for the exact same reason.

-- 
Eric Botcazou

Re: Fix multi-reg regno_reg_rtx entry

[Eric Botcazou]

> [ BTw, I think the MIPS comment is wrong.  HARD_REGNO_NREGS (fpreg, SFmode)
>   is (now) 1, even when using paired FPRs.  And the suggestion doesn't
>   seem at all ideal to me.  OK to remove? ]

You're the MIPS maintainer, so it's up to you.

> A simple fix, which I've used below, is to make sure that the previous
> mode requires only one register.  We could drop the new assert if we want
> to be even more conservative at this stage.

That doesn't seem decisively better to me.  Why not use REGNO_REG_CLASS, i.e. 
copy the mode only if we stay within the same class?

> A riskier but perhaps more logical fix would be to call choose_hard_reg_mode
> again, this time telling it to ignore HARD_REGNO_MODE_OK.

Yes, that's probably a little too risky at this stage.


Btw, could you fix the comment about regno_reg_rtx in emit-rtl.c/function.h?
It talks about pseudo-registers while we are talking about hard registers.

-- 
Eric Botcazou

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-4.7-b20120128.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120128/gcc-4.7-20120128.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/cpplib-4.7-b20120128.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120128/gcc-4.7-20120128.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [Patch, fortran] PR 51808 Heap allocate binding labels

[Janne Blomqvist]

On Wed, Jan 18, 2012 at 14:45, Mikael Morin  wrote:
> On 18.01.2012 10:12, Tobias Burnus wrote:
>>
>>
>> Dear Janne,
>>
>>> the attached patch changes the binding labels that are needed for
>>> bind(C) symbols to be heap allocated rather than, as currently, being
>>> fixed size arrays of size 127 (or 64 in module.c!?).
>>
>>
>>  wonder whether it would have been smarter to use string matching rather
>> than the manual matching in gfc_match_name_C to obtain longer strings.
>> (Cf. PR 36275. Different but related binding label issue: PR 38839.)
>> On the other hand, that's separate issues, deserving patches on their own.
>>
>>
>>> --- a/gcc/fortran/resolve.c
>>> +++ b/gcc/fortran/resolve.c
>>> @@ -2744,14 +2747,16 @@ gfc_iso_c_func_interface (gfc_symbol *sym,
>>>        {
>>>          /* two args.  */
>>>          sprintf (name, "%s_2", sym->name);
>>> -         sprintf (binding_label, "%s_2", sym->binding_label);
>>> +         if (sym->binding_label)
>>> +           sprintf (binding_label, "%s_2", sym->binding_label);
>>>          optional_arg = 1;
>>
>>
>> I wonder whether one can get rid of all those binding names. I think
>> they date back to the time when a libgfortran function was called for
>> ISOCBINDING_ASSOCIATED instead of just generating in trans-intrinsics.c
>> one (ptr != NULL) or two (ptr != NULL&&  ptr == tgt) pointer comparisons.
>>
>> I also believe that C_LOC and C_FUNLOC are (now) handled in
>> trans-intrinsics.c. Thus, you could confirm that no binding name is
>> needed and remove them.
>>
>>
>> Otherwise, the patch looks relatively mechnical and is OK.
>>
>> Tobias
>
>
> Hello,
>
> We could consider using gfc_get_string (instead of the many strcpy) to ease
> memory management.

Taking into account the suggestions by Tobias and Mikael, attached is
the patch I just committed. Thanks for the reviews!

2012-01-29  Janne Blomqvist  

PR fortran/51808
* decl.c (set_binding_label): Move prototype from match.h to here.
(curr_binding_label): Make a pointer rather than static array.
(build_sym): Check sym->binding_label pointer rather than array,
update set_binding_label call, handle curr_binding_label changes.
(set_binding_label): Handle new curr_binding_label, dest_label
double ptr, and sym->binding_label.
(verify_bind_c_sym): Handle sym->binding_label being a pointer.
(set_verify_bind_c_sym): Check sym->binding_label pointer rather
than array, update set_binding_label call.
(gfc_match_bind_c_stmt): Handle curr_binding_label change.
(match_procedure_decl): Update set_binding_label call.
(gfc_match_bind_c): Change binding_label to pointer, update
gfc_match_name_C call.
* gfortran.h (GFC_MAX_BINDING_LABEL_LEN): Remove macro.
(gfc_symbol): Make binding_label a pointer.
(gfc_common_head): Likewise.
* match.c (gfc_match_name_C): Heap allocate bind(C) name.
* match.h (gfc_match_name_C): Change prototype argument.
(set_binding_label): Move prototype to decl.c.
* module.c (struct pointer_info): Make binding_label a pointer.
(free_pi_tree): Free unused binding_label.
(mio_read_string): New function.
(mio_write_string): New function.
(load_commons): Redo reading of binding_label.
(read_module): Likewise.
(write_common_0): Change to write empty string instead of name if
no binding_label.
(write_blank_common): Write empty string for binding label.
(write_symbol): Change to write empty string instead of name if no
binding_label.
* resolve.c (gfc_iso_c_func_interface): Don't set binding_label.
(set_name_and_label): Make binding_label double pointer, use
asprintf.
(gfc_iso_c_sub_interface): Make binding_label a pointer.
(resolve_bind_c_comms): Handle cases if
gfc_common_head->binding_label is NULL.
(gfc_verify_binding_labels): sym->binding_label is a pointer.
* symbol.c (gfc_free_symbol): Free binding_label.
(gfc_new_symbol): Rely on XCNEW zero init for binding_label.
(gen_special_c_interop_ptr): Don't set binding label.
(generate_isocbinding_symbol): Insert binding_label into symbol
table.
(get_iso_c_sym): Use pointer assignment instead of strcpy.
* trans-common.c (gfc_sym_mangled_common_id): Handle
com->binding_label being a pointer.
* trans-decl.c (gfc_sym_mangled_identifier): Handle
sym->binding_label being a pointer.
(gfc_sym_mangled_function_id): Likewise.


testsuite ChangeLog

2012-01-29  Janne Blomqvist  

PR fortran/51808
* gfortran.dg/module_md5_1.f90: Update MD5 sum.


-- 
Janne Blomqvist
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 7f3fad2..0cfb0ef 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.  If not see
 #include 

Re: [pph] Refuse to generate PPH with #include_next (issue5558045)

[Diego Novillo]

On 1/28/12 5:00 PM, Gabriel Charette wrote:

Why do you need two functions: pph_stream_close and
pph_stream_close_no_flush only to call pph_stream_close_1 with a
different flag? Seems like leaving
pph_stream_close_1 as pph_stream_close and simply making the calls
themselves with true/false flags is simpler...


Well, I find it clearer to have more explicit names for the API than 
using flags.



Diego.

New Russian PO file for 'cpplib' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Russian team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/ru.po

(This file, 'cpplib-4.7-b20120128.ru.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-4.7-b20120128.ru.po'

[Translation Project Robot]

cpplib-4.7-b20120128.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

[PATCH, alpha]: Default to full IEEE compliance mode for Go language.

[Uros Bizjak]

On Fri, Jan 20, 2012 at 12:39 AM, Ian Lance Taylor  wrote

>> Attached patch adds -mieee to tests that need full IEEE compliance to
>> pass. While working on patch, I have noticed that go-test.exp doesn't
>> pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
>> format (so, these simply get ignored). With this issue fixed, we can
>> add -mieee to DEFAULT_GOCFLAGS. Tests, compiled through torture
>> procedure, expects their special flags in a separate driver file.
>
> And I just have to repeat that this patch is an ugly ugly hack, since
> -mieee should be the default.  Perhaps we should investigate having
> gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those
> targets which require it.

After trying some other approaches (including adding libgo.spec,
similar to java soultion), I think that attached patch is the most
straight-forward solution to enable full IEEE compliance to Go
language.

2012-01-29  Uros Bizjak  

* config/alpha/alpha.c (alpha_option_overrride): Default to
full IEEE compliance mode for Go language.

Tested on alphaev68-pc-linux-gnu, where it fixes all go testsuite
failures that depend of full IEEE compliance.

OK for mainline?

Uros.
Index: config/alpha/alpha.c
===
--- config/alpha/alpha.c(revision 183675)
+++ config/alpha/alpha.c(working copy)
@@ -250,6 +250,11 @@ alpha_option_override (void)
   SUBTARGET_OVERRIDE_OPTIONS;
 #endif
 
+  /* Default to full IEEE compliance mode for Go language.  */
+  if (strcmp (lang_hooks.name, "GNU Go") == 0
+  && !(target_flags_explicit & MASK_IEEE))
+target_flags |= MASK_IEEE;
+
   alpha_fprm = ALPHA_FPRM_NORM;
   alpha_tp = ALPHA_TP_PROG;
   alpha_fptm = ALPHA_FPTM_N;

[Fortran, Patch] PR 51972 - deep copy of class components

[Tobias Burnus]

Dear all,

for derived type assignment one needs to call "vtab->_copy" for 
polymorphic components. Currently, this does not happen.


The attached draft patch adds support for this, fixing the 
gfortran.dg/class_allocate_12.f90 test case (with STOP removed), 
chapter07/strategy_surrogate_f2003 of Damian's book, and the example of 
comment 3 of the PR - as well as the more extended attached test case.


With this patch, all examples of Damian's book* now compile and run with 
gfortran. The only exception failures with polymorphic coarrays (PR 
51947) and those examples which use unimplemented features 
(deferred-length character components and finalization subroutines). [* 
see http://www.cambridge.org/rouson]


Test case issues:
- I failed to check the result of test3 as couldn't find a way to test 
for the result without hitting PR46356 / PR51754.

- For test4, I get an ICE for the allocate statement, cf. PR 52044.

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: Other patches which have still to be reviewed:
- http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html (default init ICE)
- http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html (ambiguity check fix)
- http://gcc.gnu.org/ml/fortran/2012-01/msg00247.html (FE optimization)

2012-01-29  Tobias Burnus  

	PR fortran/51972
	* trans-array.c (structure_alloc_comps): Fix assignment of
	polymorphic components (polymorphic deep copying).

2012-01-29  Tobias Burnus  

	PR fortran/51972
	* gfortran.dg/class_allocate_12.f90: Enable disabled test.
	* gfortran.dg/class_48.f90: New.

Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c	(Revision 183676)
+++ gcc/fortran/trans-array.c	(Arbeitskopie)
@@ -7532,6 +7532,57 @@ structure_alloc_comps (gfc_symbol * der_type, tree
   cdecl, NULL_TREE);
 	  dcmp = fold_convert (TREE_TYPE (comp), dcmp);
 
+	  if (c->ts.type == BT_CLASS && CLASS_DATA (c)->attr.allocatable)
+	{
+	  tree ftn_tree;
+	  tree size;
+	  tree dst_data;
+	  tree src_data;
+	  tree null_data;
+
+	  dst_data = gfc_class_data_get (dcmp);
+	  src_data = gfc_class_data_get (comp);
+	  size = fold_convert (size_type_node, gfc_vtable_size_get (comp));
+
+	  if (CLASS_DATA (c)->attr.dimension)
+		{
+		  nelems = gfc_conv_descriptor_size (src_data,
+		 CLASS_DATA (c)->as->rank);
+		  src_data = gfc_conv_descriptor_data_get (src_data);
+		  dst_data = gfc_conv_descriptor_data_get (dst_data);
+		}
+	  else
+		nelems = build_int_cst (size_type_node, 1);
+
+	  gfc_init_block (&tmpblock);
+
+	  /* We need to use CALLOC as _copy might try to free allocatable
+		 components of the destination.  */
+	  ftn_tree = builtin_decl_explicit (BUILT_IN_CALLOC);
+  tmp = build_call_expr_loc (input_location, ftn_tree, 2, nelems,
+	 size);
+	  gfc_add_modify (&tmpblock, dst_data,
+			  fold_convert (TREE_TYPE (dst_data), tmp));
+
+	  tmp = gfc_copy_class_to_class (comp, dcmp, nelems);
+	  gfc_add_expr_to_block (&tmpblock, tmp);
+	  tmp = gfc_finish_block (&tmpblock);
+
+	  gfc_init_block (&tmpblock);
+	  gfc_add_modify (&tmpblock, dst_data,
+			  fold_convert (TREE_TYPE (dst_data),
+	null_pointer_node));
+	  null_data = gfc_finish_block (&tmpblock);
+
+	  null_cond = fold_build2_loc (input_location, NE_EXPR,
+	   boolean_type_node, src_data,
+   null_pointer_node); 	
+
+	  gfc_add_expr_to_block (&fnblock, build3_v (COND_EXPR, null_cond,
+			 tmp, null_data));
+	  continue;
+	}
+
 	  if (c->attr.allocatable && !cmp_has_alloc_comps)
 	{
 	  rank = c->as ? c->as->rank : 0;
Index: gcc/testsuite/gfortran.dg/class_allocate_12.f90
===
--- gcc/testsuite/gfortran.dg/class_allocate_12.f90	(Revision 183676)
+++ gcc/testsuite/gfortran.dg/class_allocate_12.f90	(Arbeitskopie)
@@ -4,10 +4,6 @@
 !
 ! Contributed by Damian Rouson
 !
-! TODO: Remove the STOP line below after fixing
-!   The remaining issue of the PR
-!
-
 module surrogate_module
   type ,abstract :: surrogate
   end type
@@ -78,7 +74,6 @@ contains
   class is (integrand)
 allocate (this_half, source=this)
 end select
-STOP 'SUCESS!' ! See TODO above
   end subroutine
 end module 
 
Index: gcc/testsuite/gfortran.dg/class_48.f90
===
--- gcc/testsuite/gfortran.dg/class_48.f90	(Revision 0)
+++ gcc/testsuite/gfortran.dg/class_48.f90	(Arbeitskopie)
@@ -0,0 +1,110 @@
+! { dg-do run }
+!
+! PR fortran/51972
+!
+! Check whether DT assignment with polymorphic components works.
+!
+
+subroutine test1 ()
+  type t
+integer :: x
+  end type t
+
+  type t2
+class(t), allocatable :: a
+  end type t2
+
+  type(t2) :: one, two
+
+  one = two
+  if (allocated (o

Contents of PO file 'cpplib-4.7-b20120128.fi.po'

[Translation Project Robot]

cpplib-4.7-b20120128.fi.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Finnish PO file for 'cpplib' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Finnish team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/fi.po

(This file, 'cpplib-4.7-b20120128.fi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [Fortran, Patch] PR 51972 - deep copy of class components

[Paul Richard Thomas]

Dear Tobias,

I cry foul at this point :-)  I have gone gallivanting off to try to
fix really horrid regressions like 52012, whilst you are have fun
doing interesting things.

Pah!  Good call - OK for trunk

Thanks for the patch.

I notice that you are making good use of recent additions to
trans-expr.c.  Should we do trans-class.c before the release?

Paul

On Sun, Jan 29, 2012 at 7:48 PM, Tobias Burnus  wrote:
> Dear all,
>
> for derived type assignment one needs to call "vtab->_copy" for polymorphic
> components. Currently, this does not happen.
>
> The attached draft patch adds support for this, fixing the
> gfortran.dg/class_allocate_12.f90 test case (with STOP removed),
> chapter07/strategy_surrogate_f2003 of Damian's book, and the example of
> comment 3 of the PR - as well as the more extended attached test case.
>
> With this patch, all examples of Damian's book* now compile and run with
> gfortran. The only exception failures with polymorphic coarrays (PR 51947)
> and those examples which use unimplemented features (deferred-length
> character components and finalization subroutines). [* see
> http://www.cambridge.org/rouson]
>
> Test case issues:
> - I failed to check the result of test3 as couldn't find a way to test for
> the result without hitting PR46356 / PR51754.
> - For test4, I get an ICE for the allocate statement, cf. PR 52044.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
> 
> PS: Other patches which have still to be reviewed:
> - http://gcc.gnu.org/ml/fortran/2012-01/msg00197.html (default init ICE)
> - http://gcc.gnu.org/ml/fortran/2012-01/msg00241.html (ambiguity check fix)
> - http://gcc.gnu.org/ml/fortran/2012-01/msg00247.html (FE optimization)
> 



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: Fix multi-reg regno_reg_rtx entry

[Richard Sandiford]

Eric Botcazou  writes:
>> [ BTw, I think the MIPS comment is wrong.  HARD_REGNO_NREGS (fpreg, SFmode)
>>   is (now) 1, even when using paired FPRs.  And the suggestion doesn't
>>   seem at all ideal to me.  OK to remove? ]
>
> You're the MIPS maintainer, so it's up to you.

OK, I'll remove it.

>> A simple fix, which I've used below, is to make sure that the previous
>> mode requires only one register.  We could drop the new assert if we want
>> to be even more conservative at this stage.
>
> That doesn't seem decisively better to me.  Why not use REGNO_REG_CLASS, i.e. 
> copy the mode only if we stay within the same class?

I'm not sure REGNO_REG_CLASS is meaningful here, because many ports define
subclasses of the natural architectural classes.  E.g. MIPS has MD0_REG
and MD1_REG for HI and LO (which is which depends on endianness), even
though both are logically the same in terms of architectural class and
register width.  Same for things like LEA_REGS, PIC_FN_ADDR_REG, etc.
If we switch to word_mode even when the previous mode has the right
number of registers, we risk breaking ports that define subclasses of
smaller-than-word registers.

It's not like the mode class is really significant here.  If a floating-point
register can store an integer mode, choose_hard_reg_mode will pick an integer
mode instead of a floating-point one.  E.g. in the original testcase,
FPRs get DImode rather than DFmode.  So if the previous mode is OK, there
doesn't seem any harm in using it, and continuing to use it seems more
conservative at this stage of development than hoping that word_mode is OK.

> Btw, could you fix the comment about regno_reg_rtx in emit-rtl.c/function.h?
> It talks about pseudo-registers while we are talking about hard registers.

OK, how's this:

/* Indexed by register number, gives an rtx for that register (and only
   that register).  For pseudo registers, it is the unique rtx for
   that pseudo.  For hard registers, it is an rtx of the mode specified
   by reg_raw_mode.

   FIXME: We could put it into emit_status struct, but gengtype is not
   able to deal with length attribute nested in top level structures.  */

Richard

PR middle-end/24306 revisited: va_arg and zero-sized objects

[Richard Sandiford]

[ Nick, you might remember mentioning this bug a few months back.
  I think I've finally got a proper fix, rather than the failed
  attempt I originally sent. ]

2005-12-20  Richard Guenther  

PR middle-end/24306
* builtins.c (std_gimplify_va_arg_expr): Do not align
va frame for zero sized types.
* config/i386/i386.c (ix86_gimplify_va_arg): Likewise.

made va_arg ignore function_arg_boundary for zero-sized types.
I think this was due to the x86_64 definition of function_arg_advance:

static void
function_arg_advance_64 (CUMULATIVE_ARGS *cum, enum machine_mode mode,
 const_tree type, HOST_WIDE_INT words, bool named)
{
  int int_nregs, sse_nregs;

  /* Unnamed 256bit vector mode parameters are passed on stack.  */
  if (!named && VALID_AVX256_REG_MODE (mode))
return;

  if (examine_argument (mode, type, 0, &int_nregs, &sse_nregs)
  && sse_nregs <= cum->sse_nregs && int_nregs <= cum->nregs)
{
  cum->nregs -= int_nregs;
  cum->sse_nregs -= sse_nregs;
  cum->regno += int_nregs;
  cum->sse_regno += sse_nregs;
}
  else
{
  int align = ix86_function_arg_boundary (mode, type) / BITS_PER_WORD;
  cum->words = (cum->words + align - 1) & ~(align - 1);
  cum->words += words;
}
}

which does indeed ignore ix86_function_arg_boundary for zero-sized
objects within the regparm range.  But the target-independent handling
of stack arguments doesn't have a similar check, so things go wrong
with 6+ arguments.  See the testcase below, which fails at count == 6
on x86_64-linux-gnu.

I've just realised this is also the cause of a MIPS bug that Nick pointed
me at a while ago, and also the cause of the mips-sde-elf struct-layout-1
failures.  The MIPS ABIs effectively treat the register parameters
as a memory image, and alignment is always honoured:

static void
mips_get_arg_info (struct mips_arg_info *info, const CUMULATIVE_ARGS *cum,
   enum machine_mode mode, const_tree type, bool named)
{
  [...]
  /* See whether the argument has doubleword alignment.  */
  doubleword_aligned_p = (mips_function_arg_boundary (mode, type)
  > BITS_PER_WORD);

So MIPS wants the original behaviour of always aligning.

[ The reason the struct-layout-1 tests didn't fail for mips*-linux-gnu
  is that the tests were passing a long double after the 16-byte aligned
  type.  n32 and n64 long doubles are usually 16 bytes and usually have
  16-byte alignment, so that alignment was saving us.  But mips-sde-elf
  uses a variation of n32 in which long doubles are only 8 bytes. ]

The easiest way of fixing this for MIPS without affecting other targets
seemed to be to define a std_gimplify_va_arg_expr_always_align function
to go alongside std_gimplify_va_arg.  This avoids duplicating the whole
function in the MIPS backend.  The PR trail suggests that this might be
a problem for PowerPC too, so maybe other targets would want to use it.

Tested on mips64-linux-gnu, mips-sde-elf and x86_64-linux-gnu.
OK to install?

What about x86_64?  The test fails before and after the patch,
so should I XFAIL it there for now?  I certainly don't know enough
about the x86_64 ABI to fix it myself.

Thanks,
Richard


gcc/
PR middle-end/24306
* tree.h (std_gimplify_va_arg_expr_always_align): Declare.
* builtins.c (std_gimplify_va_arg_expr_1): New function,
split out from...
(std_gimplify_va_arg_expr): ...here.
(std_gimplify_va_arg_expr_always_align): New function.
* config/mips/mips.c (mips_gimplify_va_arg_expr): Call it
instead of std_gimplify_va_arg_expr.

gcc/testsuite/
PR middle-end/24306
* gcc.dg/va-arg-6.c: New test.

Index: gcc/tree.h
===
--- gcc/tree.h  2012-01-29 11:15:28.0 +
+++ gcc/tree.h  2012-01-29 11:27:25.0 +
@@ -5442,6 +5442,8 @@ extern tree build_call_expr (tree, int,
 extern tree mathfn_built_in (tree, enum built_in_function fn);
 extern tree c_strlen (tree, int);
 extern tree std_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
+extern tree std_gimplify_va_arg_expr_always_align (tree, tree, gimple_seq *,
+  gimple_seq *);
 extern tree build_va_arg_indirect_ref (tree);
 extern tree build_string_literal (int, const char *);
 extern bool validate_arglist (const_tree, ...);
Index: gcc/builtins.c
===
--- gcc/builtins.c  2012-01-29 11:15:28.0 +
+++ gcc/builtins.c  2012-01-29 11:27:25.0 +
@@ -4229,12 +4229,13 @@ expand_builtin_va_start (tree exp)
   return const0_rtx;
 }
 
-/* The "standard" implementation of va_arg: read the value from the
-   current (padded) address and increment by the (padded) size.  */
-
-tree
-std_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,
-  

Re: [Fortran, Patch] PR 51972 - deep copy of class components

[Tobias Burnus]

Dear Paul,

thanks for the review!


I cry foul at this point :-)  I have gone gallivanting off to try to
fix really horrid regressions like 52012, whilst you are have fun
doing interesting things.


Well, that way my revenge for not getting a review for my 
default-initializer patch since over a week ... ;-)


I hope that fixing the regression will not be too complicated, it didn't 
look trivial, though. I have to admit that I didn't quite see whether 
gfortran currently does a reallocation or not. In principle it shouldn't 
if the shape doesn't change - especially not if the left-hand side has 
the target attribute.




I notice that you are making good use of recent additions to
trans-expr.c.  Should we do trans-class.c before the release?


Maybe. Though, I have to admit, having those macros in trans-expr.c is 
also fine with me.


Tobias

[Patch, fortran] Reduce size of pointer_info tree

[Janne Blomqvist]

Hi,

the attached patch reduces the size of the pointer_info tree used when
reading and writing module files by making the module and symbol names
pointers rather than arrays. As the strings are already put into heap
memory and resized to their correct size during parsing, we have
already paid the price of using the heap and we can just point to
those parsed strings instead of copying them.

Also, a few minor cleanups from my previous patch to heap allocate
binding_label.

Committed as obvious.

2012-01-29  Janne Blomqvist  

* module.c (pointer_info): Make true_name and module pointers
rather than arrays, order pointers before other fields.
(free_pi_tree): free true_name and module as well.
(mio_read_string): Rename to read_string.
(mio_write_string): Remove.
(load_commons): Use read_string.
(read_module): Use read_string rather than mio_internal_string.
(write_blank_common): Call write_atom directly.
(write_symbol): Likewise.



-- 
Janne Blomqvist
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4e6c520..c68277b 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -155,13 +155,12 @@ typedef struct pointer_info
 struct
 {
   gfc_symbol *sym;
-  char true_name[GFC_MAX_SYMBOL_LEN + 1], module[GFC_MAX_SYMBOL_LEN + 1];
+  char *true_name, *module, *binding_label;
+  fixup_t *stfixup;
+  gfc_symtree *symtree;
   enum gfc_rsym_state state;
   int ns, referenced, renamed;
   module_locus where;
-  fixup_t *stfixup;
-  gfc_symtree *symtree;
-  char* binding_label;
 }
 rsym;
 
@@ -229,7 +228,11 @@ free_pi_tree (pointer_info *p)
   free_pi_tree (p->right);
 
   if (iomode == IO_INPUT)
-XDELETEVEC (p->u.rsym.binding_label);
+{
+  XDELETEVEC (p->u.rsym.true_name);
+  XDELETEVEC (p->u.rsym.module);
+  XDELETEVEC (p->u.rsym.binding_label);
+}
 
   free (p);
 }
@@ -1442,6 +1445,19 @@ find_enum (const mstring *m)
 }
 
 
+/* Read a string. The caller is responsible for freeing.  */
+
+static char*
+read_string (void)
+{
+  char* p;
+  require_atom (ATOM_STRING);
+  p = atom_string;
+  atom_string = NULL;
+  return p;
+}
+
+
 / Module output subroutines ***/
 
 /* Output a character to a module file.  */
@@ -1816,27 +1832,6 @@ mio_internal_string (char *string)
 }
 
 
-/* Read a string. The caller is responsible for freeing.  */
-
-static char*
-mio_read_string (void)
-{
-  char* p;
-  require_atom (ATOM_STRING);
-  p = atom_string;
-  atom_string = NULL;
-  return p;
-}
-
-
-/* Write a string.  */
-static void
-mio_write_string (const char* string)
-{
-  write_atom (ATOM_STRING, string);
-}
-
-
 typedef enum
 { AB_ALLOCATABLE, AB_DIMENSION, AB_EXTERNAL, AB_INTRINSIC, AB_OPTIONAL,
   AB_POINTER, AB_TARGET, AB_DUMMY, AB_RESULT, AB_DATA,
@@ -4168,7 +4163,7 @@ load_commons (void)
   /* Get whether this was a bind(c) common or not.  */
   mio_integer (&p->is_bind_c);
   /* Get the binding label.  */
-  label = mio_read_string ();
+  label = read_string ();
   if (strlen (label))
 	p->binding_label = IDENTIFIER_POINTER (get_identifier (label));
   XDELETEVEC (label);
@@ -4531,9 +4526,9 @@ read_module (void)
   info->type = P_SYMBOL;
   info->u.rsym.state = UNUSED;
 
-  mio_internal_string (info->u.rsym.true_name);
-  mio_internal_string (info->u.rsym.module);
-  bind_label = mio_read_string ();
+  info->u.rsym.true_name = read_string ();
+  info->u.rsym.module = read_string ();
+  bind_label = read_string ();
   if (strlen (bind_label))
 	info->u.rsym.binding_label = bind_label;
   else
@@ -4960,7 +4955,7 @@ write_blank_common (void)
   mio_integer (&is_bind_c);
 
   /* Write out an empty binding label.  */
-  mio_write_string ("");
+  write_atom (ATOM_STRING, "");
 
   mio_rparen ();
 }
@@ -5064,7 +5059,7 @@ write_symbol (int n, gfc_symbol *sym)
   mio_pool_string (&label);
 }
   else
-mio_write_string ("");
+write_atom (ATOM_STRING, "");
 
   mio_pointer_ref (&sym->ns);
 

Re: [Fortran, Patch] PR 51972 - deep copy of class components

[Paul Richard Thomas]

Dear Tobias,

> Well, that way my revenge for not getting a review for my
> default-initializer patch since over a week ... ;-)

To be perfectly frank, I was hoping that somebody else would get their
ass in gear :-)

I'll do it.

Paul

Re: *ping* - [Patch, Fortran] PR41600 - fix ICE with type conversion in default initializer

[Paul Richard Thomas]

Dear Tobias,

As I said just a moment ago - I was hoping somebody else would get
involved.  I looked at this earlier today and it is OK for trunk.

Thanks for the patch.

Cheers

Paul

On Sat, Jan 28, 2012 at 3:09 PM, Dominique Dhumieres  wrote:
> Dear Tobias,
>
> I have this patch in my working tree since Jan 22. It works as advertised
> without regression. Note that it does not fix the ICE for the first test:
>
> pr41600.f90:1:0: internal compiler error: in gfc_conv_component_ref, at 
> fortran/trans-expr.c:1131
>
> Thanks,
>
> Dominique



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: [PATCH, alpha]: Default to full IEEE compliance mode for Go language.

[Richard Henderson]

On 01/30/2012 05:22 AM, Uros Bizjak wrote:
> 2012-01-29  Uros Bizjak  
> 
>   * config/alpha/alpha.c (alpha_option_overrride): Default to
>   full IEEE compliance mode for Go language.

I'm not keen on this, but I also don't have an alternative to suggest.

Ok.


r~

Re: [PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw

[Richard Henderson]

On 01/29/2012 07:57 AM, Tom de Vries wrote:
> Richard,
> 
> [now cc-ing gcc-patches]
> 
> this patch fixes PR50283 in a target-independent way.
> 
> it asserts on frame-related insns in the delay slot of insns that can throw,
> and prevents the assert by testing for the same condition in
> eligible_for_{delay,annul_true,annul_false}.
> 
> build and reg-tested on mips64el.
> 
> I don't know of any tests currently failing on this, so I think it's not
> appropriate for stage4. OK for stage1 ?
> 

If we can't tell one unwinder (eh) what to do with this, how do we
expect to be able to tell another unwinder (gdb)?  Thus I'm not sure
how "throwing" has anything to do with it.

I certainly agree that we shouldn't do anything during stage4 unless
we can come up with a wrong-code test case.


r~

Re: [PATCH] PR c++/51641 - Lookup finds enclosing class member instead of template parameter

[Jason Merrill]

On 01/27/2012 06:19 PM, Dodji Seketeli wrote:

+  /* BINDING_VALUE must be a template parm.  */
+  if (binding_value == NULL_TREE
+  && (!DECL_P (binding_value)
+  || !DECL_TEMPLATE_PARM_P (binding_value)))
+return false;


I think the && should be || here.

OK with that change.

Jason

Re: Fix multi-reg regno_reg_rtx entry

[Eric Botcazou]

> I'm not sure REGNO_REG_CLASS is meaningful here, because many ports define
> subclasses of the natural architectural classes.  E.g. MIPS has MD0_REG
> and MD1_REG for HI and LO (which is which depends on endianness), even
> though both are logically the same in terms of architectural class and
> register width.  Same for things like LEA_REGS, PIC_FN_ADDR_REG, etc.
> If we switch to word_mode even when the previous mode has the right
> number of registers, we risk breaking ports that define subclasses of
> smaller-than-word registers.

Fair enough.

> It's not like the mode class is really significant here.  If a
> floating-point register can store an integer mode, choose_hard_reg_mode
> will pick an integer mode instead of a floating-point one.  E.g. in the
> original testcase, FPRs get DImode rather than DFmode.  So if the previous
> mode is OK, there doesn't seem any harm in using it, and continuing to use
> it seems more conservative at this stage of development than hoping that
> word_mode is OK.

There doesn't seem to be any harm until this breaks!  Clearly anything can 
happen at a boundary between register classes, but your solution is indeed 
probably the least disturbing one.

I'm not sure about the assertion though: if it happens to trigger, the fix will 
probably entail far-reaching changes in the back-end, so it's probably safer 
to delay it until the next stage #1.

FWIW, reg_raw_mode contains completely bogus values for the upper FP regs on 
the 32-bit SPARC (w/ or w/o your patch): all SImode!

> OK, how's this:
>
> /* Indexed by register number, gives an rtx for that register (and only
>that register).  For pseudo registers, it is the unique rtx for
>that pseudo.  For hard registers, it is an rtx of the mode specified
>by reg_raw_mode.
>
>FIXME: We could put it into emit_status struct, but gengtype is not
>able to deal with length attribute nested in top level structures.  */

Perfect, thanks.

-- 
Eric Botcazou

Re: [C++ Patch] PR 51327

[Jason Merrill]

OK, just please add a comment about why we aren't using locate_ctor.

Jason

Re: [Patch, fortran] PR 51808 Heap allocate binding labels

[Gerald Pfeifer]

On Sun, 29 Jan 2012, Janne Blomqvist wrote:
> Taking into account the suggestions by Tobias and Mikael, attached is
> the patch I just committed. Thanks for the reviews!

I am now seeing the following bootstrap error on all my FreeBSD testers, 
and this does not appear to be operating system-specific:

.../gcc-HEAD/gcc/fortran/decl.c: In function 'gfc_try set_binding_label(char**, 
const char*, int)':
.../gcc-HEAD/gcc/fortran/decl.c:3828:23: error: invalid conversion from 'const 
char*' to 'char*' [-fpermissive]
.../gcc-HEAD/gcc/fortran/decl.c: In function 'match 
gfc_match_bind_c(gfc_symbol*, bool)':
.../gcc-HEAD/gcc/fortran/decl.c:5820:23: error: invalid conversion from 'const 
char*' to 'char*' [-fpermissive]
gmake[3]: *** [fortran/decl.o] Error 1

How and where was this patch tested?

Gerald

Re: [Patch, fortran] PR 51808 Heap allocate binding labels

[Janne Blomqvist]

On Sun, Jan 29, 2012 at 23:36, Gerald Pfeifer  wrote:
> On Sun, 29 Jan 2012, Janne Blomqvist wrote:
>> Taking into account the suggestions by Tobias and Mikael, attached is
>> the patch I just committed. Thanks for the reviews!
>
> I am now seeing the following bootstrap error on all my FreeBSD testers,
> and this does not appear to be operating system-specific:
>
> .../gcc-HEAD/gcc/fortran/decl.c: In function 'gfc_try 
> set_binding_label(char**, const char*, int)':
> .../gcc-HEAD/gcc/fortran/decl.c:3828:23: error: invalid conversion from 
> 'const char*' to 'char*' [-fpermissive]
> .../gcc-HEAD/gcc/fortran/decl.c: In function 'match 
> gfc_match_bind_c(gfc_symbol*, bool)':
> .../gcc-HEAD/gcc/fortran/decl.c:5820:23: error: invalid conversion from 
> 'const char*' to 'char*' [-fpermissive]
> gmake[3]: *** [fortran/decl.o] Error 1
>

Have you tried r183679, which should fix this?

> How and where was this patch tested?

While I can speak only for myself, regtesting on
x86_64-unknown-linux-gnu. For some reason this was/is flagged as a
warning for me, not an error, so I missed it among all the other
warnings. Perhaps something to do with me using --disable-bootstrap,
and my host compiler (GCC 4.4) not flagging this as an error while 4.7
does?

Cheers,

-- 
Janne Blomqvist

Re: [Patch, fortran] PR 51808 Heap allocate binding labels

[Tobias Burnus]

Gerald Pfeifer wrote:

On Sun, 29 Jan 2012, Janne Blomqvist wrote:

Taking into account the suggestions by Tobias and Mikael, attached is
the patch I just committed. Thanks for the reviews!

I am now seeing the following bootstrap error on all my FreeBSD testers,
and this does not appear to be operating system-specific:

How and where was this patch tested?


I cannot comment on how Janne tested the patch, but I just did an update 
with a rebuild, and it survived building on x86-64-linux. While it was 
an incremental build (three stages, C++ compiler in stage 2/3), it 
worked - and, thus, assume that it should also survive a boot strap on 
that system.


Did you use a C++ compiler (default setting) or a C compiler (as often 
with cross build or with--disable-build-poststage1-with-cxx)?


I also wonder about the line numbers:

.../gcc-HEAD/gcc/fortran/decl.c:3828:23: error: invalid conversion from 
'const char*' to 'char*' [-fpermissive]


On my system, that's:

  3828if (sym_name != NULL && has_name_equals == 0)
  3829  *dest_label = IDENTIFIER_POINTER (get_identifier 
(sym_name));


Thus, having the line number 3828 is odd.

I have to think about line 3829 to understand whether there is an issue 
or not; one has "const char *sym_name" and "const char **dest_label", 
IDENTIFIER_POINTER returns (cast) a "const char*" and get_identifier 
takes a "const char *" as argument.


Tobias

[wwwdocs] Add section on diagnostics conventions

[Diego Novillo]

This is the first of a few patches to update GCC's documentation with 
the proposed conventions in the GCC Development Conventions document 
that Joseph and I published last year 
(https://docs.google.com/a/google.com/document/pub?id=10LO8y0YhjlKHya_PKM3jEGrJu0rllv-Nc9qP5LXqH_I#h.qpg2rjcas9fw)


I am just starting to get back to these documents, so I will start with 
the "easy" parts.  Joseph, Gabriel, I'm sending this patch to you since 
you folks maintain these areas.  Other changes to the documentation may 
need global reviewers.


OK for wwwdocs?


Diego.


Index: codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.63
diff -u -d -u -p -r1.63 codingconventions.html
--- codingconventions.html  12 Feb 2011 15:49:51 -  1.63
+++ codingconventions.html  29 Jan 2012 21:51:56 -
@@ -157,6 +157,45 @@ regression-checkers distinguish a true r
 to the test suite.


+Diagnostics Conventions
+
+
+Use of the input_location global, and of the
+diagnostic functions that implicitly use input_location,
+is deprecated; the preferred technique is to pass around locations
+ultimately derived from the location of some explicitly chosen source
+code token.
+
+Diagnostics using the GCC diagnostic functions should generally
+use the GCC-specific formats such as %qs or
+%< and %> for quoting and
+%m for errno numbers.
+
+Identifiers should generally be formatted with %E or
+%qE; use of identifier_to_locale is needed
+if the identifier text is used directly.
+
+Formats such as %wd should be used with types such as
+HOST_WIDE_INT (HOST_WIDE_INT_PRINT_DEC is a
+format for the host printf functions, not for the GCC
+diagnostic functions).
+
+error is for defects in the user's code.
+
+internal_error is used for conditions that should not
+be triggered by any user input whether valid or invalid and including
+invalid asms and LTO binary data (sometimes, as an exception, there is
+a call to error before further information is printed and
+an ICE is triggered).
+
+Assertion failures should not be triggered by invalid input.
+inform is for informative notes accompanying errors and
+warnings. All diagnostics should be full sentences without English
+fragments substituted in them, to facilitate translation.
+
+
+
+
 Miscellaneous Conventions

 Code should use gcc_assert(EXPR) to check invariants.

Re: [Patch, fortran] PR 51808 Heap allocate binding labels

[Tobias Burnus]

Janne Blomqvist wrote:

Have you tried r183679, which should fix this?


Aha, I missed the follow up patch - that explains why I didn't see it.


While I can speak only for myself, regtesting on x86_64-unknown-linux-gnu. For 
some reason this was/is flagged as a warning for me, not an error, so I missed 
it among all the other warnings. Perhaps something to do with me using 
--disable-bootstrap,


Yes. I think the logic of having no -Werror with --disable-bootstrap is 
the following: The compiler is the system compiler and it might have 
different - and completely bogus - warnings. Thus, as the basis (the 
system compiler) is not known, it is better to not stop the build with 
an error. While for bootstrapping, one knows that Stage 2 and Stage 3 
are the current GCC. Thus, the compiler is well defined and thus 
compiling with -Werror is possible without causing any breakage.


Thus: Better to do a full bootstrap - or at least watch for warnings. 
(Side note: The libgfortran library does not use -Werror. Thus, one 
should occasionally manually check for warnings.)


Tobias

New German PO file for 'cpplib' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-4.7-b20120128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New German PO file for 'cpplib' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-4.7-b20120128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

New German PO file for 'gcc' (version 4.7-b20120128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators.  The file is available at:

http://translationproject.org/latest/gcc/de.po

(This file, 'gcc-4.7-b20120128.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [Patch,wwwdocs,AVR]: AVR release notes

[Gerald Pfeifer]

On Fri, 20 Jan 2012, Georg-Johann Lay wrote:
> Adding AVR-specific release notes to wwwdocs/htdocs/gcc-4.7/changes.html

Index: changes.html
===
+The AVR port's libgcc has been improved and its multilib structure
+  has been enhanced.  As a result, all objects contributing to an
+  application must either be compiled with GCC versions up to 4.6.x or
+  with GCC versions ≥ 4.7.

How about "...compiled with older versions of GCC, up to GCC 4.6.x,
or GCC 4.7.0 and later" ?

And I'd omit the   just ≥4.7.0 should work?

+Support has beed added for instrinsic named address spaces

"Support for...has been added" (also typo: beed -> been)

+__pgm, __pgm1, …, __pgm5

How about omitting   here?

+and __pgmx.  These address spaces locate read-only data in
+flash memory and allow reading from flash memory by means of vanilla
+C instructions, i.e. without the need of (inline) assembler code.

What's a C instruction?  C builtins?

+Support for AVR-specific built-in functions has beed added.

Which ones?

+New command-line options -maccumulate-args,
+  -mbranch-cost=cost and -mstrict-X
+  were added to allow better fine-tuning of code optimization.

Should X be put under ... here, to?

+Many optimizations to:
+  
+   64-bit integer arithmetic
+   Widening multiplication
+   Integer divide-by-constant

"division by a constant"

+ Generic built-in functions + like __builtin_ffs*, 
__builtin_clz*, etc.

I don't think we need   here.  Breaing the lines here is something
a web browser should avoid, but it is not verboten, technically.

+   Merging of data in .progmem

What is ".progmen"?  Perhaps paraphrase this briefly?

The update is fine assuming you look into my suggestions.

Thanks you,

Gerald

[committed] Skip gfortran.dg/guality/pr41558.f90 on 32-bit hppa*-*-hpux*

[John David Anglin]

See PR.  Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

2012-01-29  John David Anglin  

PR testsuite/51875
* gfortran.dg/guality/pr41558.f90: Skip on 32-bit hppa*-*-hpux*.

Index: gfortran.dg/guality/pr41558.f90
===
--- gfortran.dg/guality/pr41558.f90 (revision 183677)
+++ gfortran.dg/guality/pr41558.f90 (working copy)
@@ -1,5 +1,6 @@
 ! PR debug/41558
 ! { dg-do run }
+! { dg-skip-if "PR testsuite/51875" { { hppa*-*-hpux* } && { ! hppa*64*-*-* } 
} { "*" } { "" } }
 ! { dg-options "-g" }
 
 subroutine f (s)

[committed] Fix typo in g++.dg/ext/visibility/template10.C

[John David Anglin]

dg-require-visibility needs an argument.  Tested on hppa2.0w-hp-hpux11.11
and hppa64-hp-hpux11.11.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

2012-01-29  John David Anglin  

* g++.dg/ext/visibility/template10.C: Fix typo.

Index: g++.dg/ext/visibility/template10.C
===
--- g++.dg/ext/visibility/template10.C  (revision 183677)
+++ g++.dg/ext/visibility/template10.C  (working copy)
@@ -1,5 +1,5 @@
 // PR c++/51930
-// { dg-require-visibility }
+// { dg-require-visibility "" }
 // { dg-options -fvisibility=hidden }
 // { dg-final { scan-not-hidden "_Z8testfuncI3fooEvv" } }
 

[committed] Add -fno-common option on hppa-*-hpux* in gcc.dg/tm/pr51472.c

[John David Anglin]

Work around limited common alignment.  Tested on hppa2.0w-hp-hpux11.11
and hppa64-hp-hpux11.11.

Dave
-- 
J. David Anglin  dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

2012-01-29  John David Anglin  

* gcc.dg/tm/pr51472.c: Add -fno-common option on hppa-*-hpux*.

Index: gcc.dg/tm/pr51472.c
===
--- gcc.dg/tm/pr51472.c (revision 183677)
+++ gcc.dg/tm/pr51472.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-fgnu-tm -O  --param tm-max-aggregate-size=32" } */
+/* { dg-options "-fgnu-tm -fno-common -O  --param tm-max-aggregate-size=32" { 
target hppa*-*-hpux* } } */
 
 typedef int __attribute__ ((vector_size (16))) vectype;
 vectype v;

Re: [PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw

[Paul Brook]

> On 01/29/2012 07:57 AM, Tom de Vries wrote:
> > Richard,
> > 
> > [now cc-ing gcc-patches]
> > 
> > this patch fixes PR50283 in a target-independent way.
> > 
> > it asserts on frame-related insns in the delay slot of insns that can
> > throw, and prevents the assert by testing for the same condition in
> > eligible_for_{delay,annul_true,annul_false}.
> > 
> > build and reg-tested on mips64el.
> > 
> > I don't know of any tests currently failing on this, so I think it's not
> > appropriate for stage4. OK for stage1 ?
> 
> If we can't tell one unwinder (eh) what to do with this, how do we
> expect to be able to tell another unwinder (gdb)?  Thus I'm not sure
> how "throwing" has anything to do with it.

If you need a reliable backtrace from any point then I guess you shouldn't 
allow frame related insns in delay slots at all.

However this is a issue of debug experiance rather than code correctness.  My 
guess is most architectures don't allow you to singlestep into delay slots, so 
any use of delay slots may cause lossage[1], not just frame related ones.  
Debugging optimized code is always a compromise.

It's worth noting that -fasync-unwind-tables does not guarantee 
backtrace/unwind from arbitrary points.  Only from those instructions that may 
result in a synchronous trap (which matches the semantics of this patch).

I'd guess that putting frame related insns in delay slots of libcalls is 
probably a worthwhile optimization.

Paul

[1] If the insns come from different source lines.

[PATCH] Fix PR 51910, -frepo/linker demangling interaction

[Sandra Loosemore]

As discussed in PR c++/51910, my patch from last summer

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html

to make HAVE_LD_DEMANGLE the default when using GNU ld exposed a bug in 
collect2's link-time -frepo handling -- it depends on the linker passing 
back mangled names of undefined symbols to collect2.  This patch fixes 
that by explicitly adding --no-demangle to the options passed to the 
linker in the repository-processing loop.  Then the original settings 
are restored for the final link, so that (for instance) if the user 
requested a map file or if there are messages for real link errors, they 
respect the user-specified demangling options.  This patch therefore 
adds two extra link steps to the case where HAVE_LD_DEMANGLE is defined, 
there is repository information, and recompilation is necessary to 
resolve undefined symbols from the repository.  In other cases it adds 
no overhead.


Bootstrapped and regression-tested on i636 linux.  OK to check in?

-Sandra


2012-01-29  Sandra Loosemore 
Jason Merrill 
Jakub Jelinek 

PR c++/51910
gcc/
* tlink.c (do_tlink): Explicitly pass --no-demangle to linker
for repo processing when HAVE_LD_DEMANGLE is defined.

gcc/testsuite/
* g++.dg/torture/pr51910.C: New testcase.

Re: [PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw

[Richard Henderson]

On 01/30/2012 11:07 AM, Paul Brook wrote:
> However this is a issue of debug experiance rather than code correctness.  My 
> guess is most architectures don't allow you to singlestep into delay slots, 
> so 
> any use of delay slots may cause lossage[1], not just frame related ones.  

Certainly Sparc can single-step delay slots.  I assumed others do as well.


r~

[PATCH] Fix PR 51910, -frepo/linker demangling interaction

[Sandra Loosemore]

[Ooops, resending to include the attachment, this time]

As discussed in PR c++/51910, my patch from last summer

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html

to make HAVE_LD_DEMANGLE the default when using GNU ld exposed a bug in 
collect2's link-time -frepo handling -- it depends on the linker passing 
back mangled names of undefined symbols to collect2.  This patch fixes 
that by explicitly adding --no-demangle to the options passed to the 
linker in the repository-processing loop.  Then the original settings 
are restored for the final link, so that (for instance) if the user 
requested a map file or if there are messages for real link errors, they 
respect the user-specified demangling options.  This patch therefore 
adds two extra link steps to the case where HAVE_LD_DEMANGLE is defined, 
there is repository information, and recompilation is necessary to 
resolve undefined symbols from the repository.  In other cases it adds 
no overhead.


Bootstrapped and regression-tested on i636 linux.  OK to check in?

-Sandra


2012-01-29  Sandra Loosemore 
Jason Merrill 
Jakub Jelinek 

PR c++/51910
gcc/
* tlink.c (do_tlink): Explicitly pass --no-demangle to linker
for repo processing when HAVE_LD_DEMANGLE is defined.

gcc/testsuite/
* g++.dg/torture/pr51910.C: New testcase.


Index: gcc/tlink.c
===
--- gcc/tlink.c	(revision 183674)
+++ gcc/tlink.c	(working copy)
@@ -777,23 +777,53 @@ do_tlink (char **ld_argv, char **object_
   /* Until collect does a better job of figuring out which are object
 	 files, assume that everything on the command line could be.  */
   if (read_repo_files (ld_argv))
-	while (exit && i++ < MAX_ITERATIONS)
-	  {
-	if (tlink_verbose >= 3)
-	  {
-		dump_file (ldout, stdout);
-		dump_file (lderrout, stderr);
-	  }
-	demangle_new_symbols ();
-	if (! scan_linker_output (ldout)
-		&& ! scan_linker_output (lderrout))
-	  break;
-	if (! recompile_files ())
-	  break;
-	if (tlink_verbose)
-	  fprintf (stderr, _("collect: relinking\n"));
-	exit = tlink_execute ("ld", ld_argv, ldout, lderrout);
-	  }
+	{
+	  char **ld1_argv = ld_argv;
+
+#ifdef HAVE_LD_DEMANGLE
+	  /* We must explicitly tell the linker not to demangle names
+	 and re-do the initial link attempt, since repository processing
+	 requires demangled error output from the linker.  */
+	  int argc = 0;
+	  while (ld_argv[argc])
+	++argc;
+	  ld1_argv = XNEWVEC (char *, argc + 2);
+	  memcpy (ld1_argv, ld_argv, sizeof (ld_argv[0]) * argc);
+	  ld1_argv[argc] = CONST_CAST (char *, "--no-demangle");
+	  ld1_argv[argc + 1] = NULL;
+	  if (tlink_verbose)
+	fprintf (stderr, _("collect: relinking\n"));
+	  exit = tlink_execute ("ld", ld1_argv, ldout, lderrout);
+#endif
+
+	  while (exit && i++ < MAX_ITERATIONS)
+	{
+	  if (tlink_verbose >= 3)
+		{
+		  dump_file (ldout, stdout);
+		  dump_file (lderrout, stderr);
+		}
+	  demangle_new_symbols ();
+	  if (! scan_linker_output (ldout)
+		  && ! scan_linker_output (lderrout))
+		break;
+	  if (! recompile_files ())
+		break;
+	  if (tlink_verbose)
+		fprintf (stderr, _("collect: relinking\n"));
+	  exit = tlink_execute ("ld", ld1_argv, ldout, lderrout);
+	}
+
+#ifdef HAVE_LD_DEMANGLE
+	  /* Now redo the final link with the original options so that
+	 any remaining errors, the link map, etc are presented to
+	 the user with the original mangling options.*/
+	  XDELETEVEC (ld1_argv);
+	  if (tlink_verbose)
+	fprintf (stderr, _("collect: relinking\n"));
+	  exit = tlink_execute ("ld", ld_argv, ldout, lderrout);
+#endif
+	}
 }
 
   dump_file (ldout, stdout);
Index: gcc/testsuite/g++.dg/torture/pr51910.C
===
--- gcc/testsuite/g++.dg/torture/pr51910.C	(revision 0)
+++ gcc/testsuite/g++.dg/torture/pr51910.C	(revision 0)
@@ -0,0 +1,19 @@
+// PR c++/51910 
+// Check that -frepo works in the presence of linker symbol demangling.
+//
+// { dg-options "-frepo -Wl,--demangle" }
+// { dg-require-host-local "" }
+// { dg-skip-if "dkms are not final links" { vxworks_kernel } }
+
+template
+struct Foo
+{
+  virtual ~Foo() { }
+};
+
+int main( int, char*[] )
+{
+  Foo test;
+}
+
+// { dg-final { cleanup-repo-files } }

Re: [PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw

[Richard Henderson]

On 01/30/2012 11:07 AM, Paul Brook wrote:
> It's worth noting that -fasync-unwind-tables does not guarantee 
> backtrace/unwind from arbitrary points.  Only from those instructions that 
> may 
> result in a synchronous trap (which matches the semantics of this patch).

... and we're not talking about arbitrary points.  We're talking about call 
sites.
Whether or not the call itself is marked nothrow.


r~

Re: [PATCH, alpha]: Default to full IEEE compliance mode for Go language.

[Robert Dewar]

On 1/29/2012 3:40 PM, Richard Henderson wrote:

On 01/30/2012 05:22 AM, Uros Bizjak wrote:

2012-01-29  Uros Bizjak

* config/alpha/alpha.c (alpha_option_overrride): Default to
full IEEE compliance mode for Go language.


I'm not keen on this, but I also don't have an alternative to suggest.

Ok.


It's always worrisome for gcc based languages to default to horrible
performance, it means that many benchmarks will be run only with this
horrible performance.

We have seen instances in which GNAT performs poorly in benchmarks
because it is run with -O0, and competing compilers default to
something more similar to -O1. In one case, when we pointed this
out, the response was that company mandated policies insisted on
all benchmarks being run with default options.

[wwwdocs] Re: [PATCH] invoke.texi: "compile time", "run time" cleanup

[Sandra Loosemore]

On 01/29/2012 07:31 AM, Joseph S. Myers wrote:

On Sat, 28 Jan 2012, Sandra Loosemore wrote:


2012-01-28  Sandra Loosemore

gcc/
* doc/invoke.texi: Make usage of "compile time" and
"run time"/"runtime" consistent throughout the file.


OK.  Could you post a patch to codingconventions.html to document the
conventions you described in your message?


Like this?  The table formatting encourages brevity, but I can twiddle 
it somehow if more detail is necessary.


-Sandra

? htdocs/codingconventions.html.~1.63.~
Index: htdocs/codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.63
diff -u -r1.63 codingconventions.html
--- htdocs/codingconventions.html	12 Feb 2011 15:49:51 -	1.63
+++ htdocs/codingconventions.html	30 Jan 2012 01:05:29 -
@@ -280,6 +280,18 @@
 
   
   
+"compilation time" (noun);
+  how long it takes to compile the program
+"compile time"
+
+  
+  
+"compile time" (noun), "compile-time" (adjective);
+  the time at which the program is compiled
+
+
+  
+  
 "dependent" (adjective), "dependence", "dependency"
 "dependant", "dependance", "dependancy"
 
@@ -295,6 +307,12 @@
 Established convention
   
   
+"execution time" (noun);
+  how long it takes the program to run
+"run time" or "runtime"
+
+  
+  
 "free software" or just "free"
 "Open Source" or "OpenSource"
   
@@ -314,6 +332,12 @@
 
   
   
+"link time" (noun), "link-time" (adjective);
+  the time at which the program is linked
+
+
+  
+  
 "lowercase"
 "lower case" or "lower-case"
 
@@ -357,6 +381,18 @@
 
   
   
+"run time" (noun), "run-time" (adjective);
+  the time at which the program is run
+"runtime"
+
+  
+  
+"runtime" (both noun and adjective);
+  libraries and system support present at run time
+"run time", "run-time"
+
+  
+  
 "SPARC"
 "Sparc" or "sparc"
   

Re: [PATCH] Prevent frame-related insn from occurring in delay slots of insns that throw

[Paul Brook]

> On 01/30/2012 11:07 AM, Paul Brook wrote:
> > It's worth noting that -fasync-unwind-tables does not guarantee
> > backtrace/unwind from arbitrary points.  Only from those instructions
> > that may result in a synchronous trap (which matches the semantics of
> > this patch).
> 
> ... and we're not talking about arbitrary points.  We're talking about call
> sites. Whether or not the call itself is marked nothrow.

What about backtracing from a signal handler?

Paul

Re: [PATCH] Fix PR 51505

[Paolo Bonzini]

On 01/29/2012 04:09 PM, Eric Botcazou wrote:

As discussed in Bugzilla, this is the patch implementing Paolo's
suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes.  The
code assumes there is at most one such note per insn.


That's wrong though and wreaks havoc during reload, e.g.:

(insn 169 60 62 4 (set (reg:TF 158)
 (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
 (const_int -16 [0xfff0])) [3 S16 A64]))
960513-1.c:13 97 {*movtf_insn_sp32}
  (expr_list:REG_EQUIV (mem/c:TF (plus:SI (reg/f:SI 101 %sfp)
 (const_int -16 [0xfff0])) [3 S16 A64])
 (expr_list:REG_EQUAL (mult:TF (reg/v:TF 110 [ d ])
 (reg:TF 154))
 (nil

because the REG_EQUIV note disappears behind reload's back and it isn't
prepared for that.  This is the cause of the following regression on SPARC:

FAIL: gcc.c-torture/execute/960513-1.c execution,  -Os


As well as:

FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O2
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -Os
FAIL: gcc.c-torture/execute/stdarg-2.c
execution,  -O2 -flto -flto-partition=none
FAIL: gcc.c-torture/execute/stdarg-2.c execution,  -O2 -flto

for the exact same reason.


Does this help?

Paolo

2012-01-30  Paolo Bonzini  

	* df-problems.c (df_kill_notes): Check that the use refers
	to the note under examination.

Index: df-problems.c
===
--- df-problems.c	(revision 183693)
+++ df-problems.c	(working copy)
@@ -2814,8 +2814,10 @@ df_kill_notes (rtx insn, bitmap live)
 	  {
 		df_ref use = *use_rec;
 		if (DF_REF_REGNO (use) > FIRST_PSEUDO_REGISTER
+		&& DF_REF_LOC (use)
 		&& (DF_REF_FLAGS (use) & DF_REF_IN_NOTE)
-		&& ! bitmap_bit_p (live, DF_REF_REGNO (use)))
+		&& ! bitmap_bit_p (live, DF_REF_REGNO (use))
+		&& loc_mentioned_in_p (DF_REF_LOC (use), XEXP (link, 0)))
 		  {
 		deleted = true;
 		break;