[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #50 from Iain Sandoe  2011-08-14 08:10:32 
UTC ---
(In reply to comment #42)
>   I have no clue about what to do for Ada.

Ada is unaffected on i686-darwin9 ... 
... it won't bootstrap on powerpc-darwin9 for 4.6 or trunk (investigating).

have to see what can be done to bootstrap on darwin10.

===

powerpc-darwin9-X-darwin8 using cctools 622 is also unaffected.

(native bootstrap on darwin8 will have to wait until the investigation of ada
bootstrap issue is complete).

[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  2011-08-14 
09:10:20 UTC ---
Author: gjl
Date: Sun Aug 14 09:10:13 2011
New Revision: 177744

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177744
Log:

* PR target/49903
* config/avr/avr.md (UNSPEC_IDENTITY): New c_enum.
(branch_unspec): New insn.
(branch): Beauty farm.
* config/avr/avr.c (compare_condition): Use JUMP_P.  Test SET_SRC
to be IF_THEN_ELSE.
(avr_compare_pattern, avr_reorg_remove_redundant_compare):
New static functions.
(avr_reorg): Use them.  Use next_real_insn instead of NEXT_INSN.
Use CONST_INT_P.  Beauty.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md

[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Georg-Johann Lay  2011-08-14 
09:11:26 UTC ---
Closed with this patch.

[Bug c/50078] [4.6.1+ SVN 2011-08-13] ARM wrong code: volatile accesses optimized out

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2011-08-14 
09:22:01 UTC ---
Not ARM-specific, also happens on i686-linux.

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2011-08-14 
09:24:31 UTC ---
You need a _compiler_ barrier before the store in _unlock().

[Bug c/50078] [4.6.1+ SVN 2011-08-13] ARM wrong code: volatile accesses optimized out

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-14
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-08-14 
09:37:26 UTC ---
Mine.

  /* If the statement is a scalar store, see if the expression
 has the same value number as its rhs.  If so, the store is
 dead.  */
  else if (gimple_assign_single_p (stmt)
   && !is_gimple_reg (gimple_assign_lhs (stmt))
   && (TREE_CODE (gimple_assign_rhs1 (stmt)) == SSA_NAME
   || is_gimple_min_invariant (gimple_assign_rhs1 (stmt

needs a && !gimple_has_volatile_ops (stmt).

[Bug fortran/50073] gfortran must not accept function name when result name is present

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2011-08-14 09:37:28 UTC ---
Author: janus
Date: Sun Aug 14 09:37:25 2011
New Revision: 177745

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177745
Log:
2011-08-14  Janus Weil  

PR fortran/50073
* decl.c (check_function_name): New function, separated off from
'variable_decl' and slightly extended.
(variable_decl,attr_decl1): Call it.


2011-08-14  Janus Weil  

PR fortran/50073
* gfortran.dg/func_result_7.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/func_result_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/50073] gfortran must not accept function name when result name is present

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from janus at gcc dot gnu.org 2011-08-14 09:43:22 UTC ---
Fixed with r177745. Closing.

Thanks for the report!

[Bug rtl-optimization/50068] Invalid memory access in incr_ticks_for_insn

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-08-14 
09:44:40 UTC ---
last_basic_block should never be 0, it should at least be NUM_FIXED_BLOCKS.

[Bug tree-optimization/50067] [4.7 Regression] Wrong code with -fpredictive-commoning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|Wrong code with |[4.7 Regression] Wrong code
   |-fpredictive-commoning  |with -fpredictive-commoning

--- Comment #1 from Richard Guenther  2011-08-14 
09:45:37 UTC ---
Probably caused by allowing invariant DRs.

[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Target Milestone|--- |4.7.0

--- Comment #16 from Richard Guenther  2011-08-14 
09:49:01 UTC ---
Invalid.

[Bug rtl-optimization/50063] [4.6/4.7 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Summary|[avr]: DSE: wrong code for  |[4.6/4.7 Regression] DSE:
   |gcc.dg/torture/pta-ptrarith |wrong code for
   |-3.c|gcc.dg/torture/pta-ptrarith
   ||-3.c

--- Comment #5 from Richard Guenther  2011-08-14 
09:52:28 UTC ---
Sounds like some of the latent RTL alias issues we have with regarding to
find_base_value and friends (see some i?86 bugreport I fail to remember right
now).

[Bug middle-end/50061] [4.7 regression] emit_library_call_value_1 change broke SF->TI conversion on MIPS

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |4.7.0

[Bug c/50032] Bad optimization with sin/cos

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-08-14 
09:58:01 UTC ---
(In reply to comment #2)
> > if your math library implementation has a slower cosf than cos it's
> > definitely broken ;)
> 
> So it is at least for fedora (see
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997
> http://sourceware.org/bugzilla/show_bug.cgi?id=5781
> https://bugzilla.redhat.com/show_bug.cgi?id=521190 and pr34128).
> 
> I suspect it is for most (all?) linux libraries (I am not in position to check
> it, but the above pointer will allow anyone interested to see by
> her/himself;-).

Sure some vendors patch their libm.

[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org 2011-08-14 12:02:57 UTC ---
(In reply to comment #3)
> The relevant quote from the F08 std is probably:
> 
> "C417 (R422) A type-param-value in a char-length shall be a colon, asterisk, 
> or
> specification-expr."
> 
> together with chapter 7.1.11 ("Specification expression").


Based on chapter 7.1.11, I would say that g95's error message is wrong: z does
not have to have constant length.

"A specification-expr shall be a constant expression unless it is in an
interface body (12.4.3.2), the specification part of a subprogram or BLOCK
construct, a derived type definition, or the declaration-type-spec of a FUNCTION
statement (12.6.2.2)."

Since z is in the specification part of a subprogram, there is no need for to
have constant length.

[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2011-08-14 12:07:55 UTC ---
(In reply to comment #2)
> ifort rejects the original test case with:
> 
> error #6756: A COMMON block data object must not be an automatic object.   [Z]
>   common n,z
> ---^

ifort's error message is apparently based on this restriction in the F08
standard:

"C5100 (R569) A common-block-object shall not be a dummy argument, a result
variable, an allocatable variable, a derived-type object with an ultimate
component that is allocatable, a procedure pointer, an automatic object, a
variable with the BIND attribute, an unlimited polymorphic pointer, or a
coarray."

This is what really makes the original test case invalid.

[Bug c++/50012] [4.5/4.6/4.7 Regression] C++ front end misses -Wsign-compare warnings when extraneous parentheses are present

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2011-08-14 
12:25:12 UTC ---
The warning is lost due to this fragment of r148952 (with the rest of r148952
disabled):

--- gcc/cp/typeck.c(revision 148951)
+++ gcc/cp/typeck.c(revision 148952)
@@ -4018,6 +4018,8 @@ cp_build_binary_op (location_t location,

   if ((short_compare || code == MIN_EXPR || code == MAX_EXPR)
   && warn_sign_compare
+  && !TREE_NO_WARNING (orig_op0)
+  && !TREE_NO_WARNING (orig_op1)
   /* Do not warn until the template is instantiated; we cannot
  bound the ranges of the arguments until that point.  */
   && !processing_template_decl

In this test case (the foo() function) the LHS is a parenthesized expression,
and cp/semantics.c:finish_parenthesized_expr() contains the following gem:

tree
finish_parenthesized_expr (tree expr)
{
  if (EXPR_P (expr))
/* This inhibits warnings in c_common_truthvalue_conversion.  */
TREE_NO_WARNING (expr) = 1;

Disabling either the setting of TREE_NO_WARNING in finish_parenthesized_expr or
the && !TREE_NO_WARNING check in cp_build_binary_op restores the warning for
this test case.  Alas I'm sure something else will break in that case ...

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2011-08-14 
12:42:47 UTC ---
> The code is equivalent to
> 
> volatile unsigned char lock;
> int remap_barrier;
> 
> while (atomic_test_and_set(lock)) {
>while (lock) {
>  ;
>}
> }
> remap_barrier++;
> lock = 0;
> 
> Eric: could you let me know you you think the code inside function  
> spinlock_lock(&remap_lock) is a NOP?

I don't, you simply misquoted, I wrote "the end of the code".  The first part
of the spinlock implementation is correct, in particular you have the required
memory barrier in spinlock_is_locked.  The second part is not correct, as you
don't have the memory barrier in spinlock_unlock.

> Also, the arch_write_lock/unlock in the SPARC port of Linux uses a very 
> similar implementation.

No, it precisely doesn't, it has the memory barrier in spinlock_unlock.

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2011-08-14 
13:00:06 UTC ---
> I don't think this is an valid optimization.
> 
> There are only two memory models in SPARC32, TSO and PSO (not RMO in the 
> 64-bit
> v9). Both don't allow relaxing the read->write order, i.e.  'LD remap_barrier'
> should always be executed before 'ST lock'.
> 
> This optimization violates the memory model, therefore should be prohibited.

You're apparently confusing 2 different concepts:

  1. What an optimizing C compiler is permitted to do.  This is defined by the
ISO Standard in terms of an abstract machine that is somewhat simplistic.  In
particular, there is no concept of concurrency or memory model, and the whole
thing is essentially target-independent.  The kind of reordering we have here
is allowed by the Standard as it doesn't change the "external state" of the
abstract machine.

  2. The memory model implemented by the SPARC processor, under which loads and
stores can be reordered, even though the compiler itself doesn't reorder them.

A proper implementation of spinlocks needs to take them both into account.

For the first part, you need a compiler memory barrier, i.e.:

__asm__ __volatile__ ("" : : : "memory");

For the second part, you need a processor memory barrier, i.e. to put a stbar
instruction if you're running PSO, plus an atomic instruction that is the only
memory barrier available in V8 for TSO.

[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-14
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #6 from janus at gcc dot gnu.org 2011-08-14 13:10:57 UTC ---
Here is a preliminary patch which rejects the original test case:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 177744)
+++ gcc/fortran/resolve.c(working copy)
@@ -858,6 +858,12 @@ resolve_common_vars (gfc_symbol *sym, bool named_c
 &csym->declared_at);
 }

+  /* F08:C5100.  */
+  if (csym->ts.type == BT_CHARACTER
+  && !gfc_is_constant_expr (csym->ts.u.cl->length))
+gfc_error_now ("Automatic object %s at %L may not be in a COMMON block",
+   csym->name, &csym->declared_at);
+
   if (csym->ts.type != BT_DERIVED)
 continue;

[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  2011-08-14 
13:20:27 UTC ---
(In reply to comment #5)
For the record, F95 and F2003 have a similar constraint, respectively:

Constraint: A common-block-object shall not be a dummy argument, an allocatable
array, an automatic
object, a function name, an entry name, or a result name.

C588 (R558) A common-block-object shall not be a dummy argument, an allocatable
variable, a
derived-type object with an ultimate component that is allocatable, an
automatic object, a
function name, an entry name, a variable with the BIND attribute, or a result
name.

[Bug driver/31316] driver specifies output file twice when compiling header with -S

[yashik_pochty at mail dot ru]

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

yashik_poc...@mail.ru  changed:

   What|Removed |Added

 CC||yashik_pochty at mail dot
   ||ru

--- Comment #2 from yashik_pochty at mail dot ru  
2011-08-14 14:10:36 UTC ---
Confirmed, 4.6.1, ArchLinux

[Bug tree-optimization/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org

--- Comment #1 from Dominique d'Humieres  2011-08-14 
16:41:47 UTC ---
This is due to revision 176042.  I'll attach the working and failing assembly
files.

[Bug tree-optimization/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-08-14 
16:42:48 UTC ---
Created attachment 25008
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25008
working assembly

[Bug tree-optimization/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-08-14 
16:43:22 UTC ---
Created attachment 25009
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25009
failing assembly

[Bug testsuite/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite

--- Comment #4 from H.J. Lu  2011-08-14 17:13:12 
UTC ---
It also failed with -fPIC on Linux/x86-64. It should be disabled
if PIC is enabled by default.

[Bug testsuite/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-08-14 
17:22:32 UTC ---
> It also failed with -fPIC on Linux/x86-64. It should be disabled
> if PIC is enabled by default.

Well, the test succeeds at revision 176041 and I don't see why it should be
disabled after revision 176042.

[Bug middle-end/50079] New: [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test

[danglin at gcc dot gnu.org]

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

 Bug #: 50079
   Summary: [4.7 Regression] FAIL: g++.dg/init/copy7.C execution
test
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/init/copy7.C  -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0   -ansi
-pedantic-errors -Wno-long-long   
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs 
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs 
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs  -lm   -o
./copy7.exe(timeout = 300)
PASS: g++.dg/init/copy7.C (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs:/test/gnu/gcc/objdir/gcc
FAIL: g++.dg/init/copy7.C execution test

[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  2011-08-14 
19:16:06 UTC ---
Breakpoint 1, memcpy (dest=0x40001ab0, src=0x40001ab0, n=81) at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/init/copy7.C:9
9  if (dest == src)
(gdb) p/x $r26
$1 = 0x40001ab0
(gdb) p/x $r25
$2 = 0x40001ab0
(gdb) bt
#0  memcpy (dest=0x40001ab0, src=0x40001ab0, n=81) at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/init/copy7.C:9
#1  0x31ac in f (a1=0x40001ab0, a2=0x40001ab0) at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/init/copy7.C:33
#2  0x320c in main () at
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/init/copy7.C:38

Maybe this is c++ bug.

[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||powerpc-apple-darwin9
   ||arm-unknown-eabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-14
 CC||rguenther at suse dot de
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||powerpc-apple-darwin9
   ||arm-unknown-eabi
 Ever Confirmed|0   |1
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11
   ||powerpc-apple-darwin9
   ||arm-unknown-eabi

--- Comment #2 from Dominique d'Humieres  2011-08-14 
20:50:59 UTC ---
I also see the failure on powerpc-apple-darwin9 at revision 177733, see also
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01103.html for arm-unknown-eabi
(likely revision 177625).

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[tanzhangxi at gmail dot com]

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

--- Comment #8 from Zhangxi Tan  2011-08-14 
21:00:40 UTC ---
Thanks for the clear explanation.
I agree that a memory barrier would solve this issue.

Regarding the spinlock_unlock in linux, the regular arch_spin_unlock is
implemented with a single inline assembly. That will prevent the memory
reordering in C. However, for the 32-bit port the arch_write_unlock is still
defined as the following without a memory barrier in
arch/sparc/include/asm/spinlock_32.h

#define arch_write_unlock(rw)   do { (rw)->lock = 0; } while(0)

OTH, the 64-bit implemention is ok. Or did I miss something here.
Anyway, I think this is a separated issue from this thread.

(In reply to comment #6)
> > The code is equivalent to
> > 
> > volatile unsigned char lock;
> > int remap_barrier;
> > 
> > while (atomic_test_and_set(lock)) {
> >while (lock) {
> >  ;
> >}
> > }
> > remap_barrier++;
> > lock = 0;
> > 
> > Eric: could you let me know you you think the code inside function  
> > spinlock_lock(&remap_lock) is a NOP?
> 
> I don't, you simply misquoted, I wrote "the end of the code".  The first part
> of the spinlock implementation is correct, in particular you have the required
> memory barrier in spinlock_is_locked.  The second part is not correct, as you
> don't have the memory barrier in spinlock_unlock.
> 
> > Also, the arch_write_lock/unlock in the SPARC port of Linux uses a very 
> > similar implementation.
> 
> No, it precisely doesn't, it has the memory barrier in spinlock_unlock.

[Bug c++/50080] New: error: 'template' (as a disambiguator) is only allowed within templates

[solodon at mail dot com]

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

 Bug #: 50080
   Summary: error: 'template' (as a disambiguator) is only allowed
within templates
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: solo...@mail.com


Hi,

Consider the following code snippet compiled as:

g++ -std=c++0x test.cpp

In particular the two instantiations of B: one in the template context and the
other one in non-dependent scope.

template 
struct A
{
template 
struct B {};
};

template 
void test()
{
typename A::template B b;
}

int main()
{
typename A::template B b;
}

My GCC complains about the second instantiation saying: 

error: 'template' (as a disambiguator) is only allowed within templates

and surely enough removing template there fixes the problem. The keyword
typename used for a similar purpose of disambiguating a type in a non-template
context is accepted even though redundant. Allowing typename seems to be in
line with the relaxed rule of C++0x. I think, however, that the template
keyword should similarly be allowed in non-dependent context accordingly to the
C++0x standard (and not allowed accordingly to C++03).

Here is a snippet from C++0x standard draft (FDIS n3291, section 14.2[5]) I
could get a hold of:

``A name prefixed by the keyword template shall be a template-id or the name
shall refer to a class template.
[ Note: The keyword template may not be applied to non-template members of
class templates. -end
note ] [ Note: As is the case with the typename prefix, the template prefix is
allowed in cases where it is
not strictly necessary; i.e., when the nested-name-specifier or the expression
on the left of the -> or . is not
dependent on a template-parameter, or the use does not appear in the scope of a
template. -end note ]''

I think that the second note implies that template keyword should have been
allowed in the example above in much the same way the typename is, please
correct me if I'm wrong.

The practical reason I need this behavior for is that I have a code snippet
that is generated by a macro. With template being allowed in non-dependent
context I can have a single macro that can be used in dependent and
non-dependent contexts, while without this behavior (as well as in C++03) I
will need to have 2 separate (largely duplicated) macros for each of the uses.

Thanks,
Yuriy

[Bug c/45941] Failed compile on Loongson2f

[mattst88 at gmail dot com]

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

--- Comment #1 from Matt Turner  2011-08-15 04:33:57 
UTC ---
Created attachment 25010
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25010
lto-streamer-in.i.bz2

Test case (preprocessed lto-streamer-in.c from gcc-4.5.3 sources).

$ mips64el-unknown-linux-gnu-gcc -O2 -mabi=64 -c lto-streamer-in.i 
mips64el-unknown-linux-gnu-gcc: Internal error: Segmentation fault (program
cc1)
Please submit a full bug report.
See  for instructions.

Notes:
 - The segfault is reproducible with mips64el-unknown-linux-gnu-4.5.x
   (tested 4.5.2 and 4.5.3)
 - The segfault is not reproducible with 4.6.1.
 - The segfault only occurs with -O2 and -mabi=64. Other -O levels or -mabi=...
   flags do not trigger the crash, including '-O3 -mabi=64'
 - The segfault is not reproducible with [big endian] mips64-unknown-linux-gnu
  (tried 4.5.2, 4.5.3, and 4.6.1)

Filed as Gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=378375

[Bug c/50081] New: Wrong code (wrong order) generated with -O2 or -Os while function return a struct

[lingyouz...@arimacomm-hz.cn]

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

 Bug #: 50081
   Summary: Wrong code (wrong order) generated with -O2 or -Os
while function return a struct
Classification: Unclassified
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lingyouz...@arimacomm-hz.cn


The code like:
typedef struct {
  struct umdb_list_head_st *list_head;
  struct umdb_list_node_st *current;
} umdb_util_it_t;
typedef umdb_util_it_t umdb_dbms_hl_oper_list_iterator_t;

umdb_dbms_hl_oper_list_iterator_t 
umdb_dbms_oper_list_find_element (umdb_dbms_hl_oper_list_handle_t *list, 
  MSF_UINT8 src_mod_id,
  MSF_UINT16 transaction_id)
{
  umdb_dbms_hl_oper_list_iterator_t it;
  umdb_dbms_oper_list_elem_t *elem;

  it = umdb_dbms_oper_list_get_iterator (list);

  while (!umdb_dbms_oper_list_equals_end (&it)) {
elem = (umdb_dbms_oper_list_elem_t*)it.current;

if (elem->ml_transaction_id == transaction_id &&
elem->src_mod_id == src_mod_id) {
  break;
}

umdb_dbms_oper_list_iterator_next (&it);
  }

  return it;
}

The asm code like:
 :
   0:b5f0  push{r4, r5, r6, r7, lr}
   2:b087  subsp, #28
   4:ac02  addr4, sp, #8
   6:1c05  addsr5, r0, #0
   8:ae04  addr6, sp, #16
   a:1c20  addsr0, r4, #0
   c:1c17  addsr7, r2, #0
   e:9301  strr3, [sp, #4]
  10:f7ff fffe bl0 
  14:cc03  ldmiar4!, {r0, r1}
  16:c603  stmiar6!, {r0, r1}
  18:e00a  b.n30 
  1a:6863  ldrr3, [r4, #4]
  1c:9801  ldrr0, [sp, #4]
  1e:8a1a  ldrhr2, [r3, #16]
  20:4282  cmpr2, r0
  22:d102  bne.n2a 
  24:7a1b  ldrbr3, [r3, #8]
  26:42bb  cmpr3, r7
  28:d008  beq.n3c 
  2a:a804  addr0, sp, #16
  2c:f7ff fffe bl0 
  30:ac04  addr4, sp, #16
  32:1c20  addsr0, r4, #0
  34:f7ff fffe bl0 
  38:2800  cmpr0, #0
  3a:d0ee  beq.n1a 
  3c:1c2a  addsr2, r5, #0
  3e:ab04  addr3, sp, #16
  40:b007  addsp, #28
  42:cb03  ldmiar3!, {r0, r1}
  44:c203  stmiar2!, {r0, r1}
  46:1c28  addsr0, r5, #0
  48:bdf0  pop{r4, r5, r6, r7, pc}
  4a:46c0  nop; (mov r8, r8)

It show the return struct is not safe here, it still use the stack after
sp+0x28.
  40:b007  addsp, #28
  42:cb03  ldmiar3!, {r0, r1}
  44:c203  stmiar2!, {r0, r1}