[Bug tree-optimization/57275] [4.9 Regression] Error in data dependence analysis during gather vectorization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed May 15 08:12:49 2013
New Revision: 198918

URL: http://gcc.gnu.org/viewcvs?rev=198918&root=gcc&view=rev
Log:
2013-05-15  Richard Biener  

PR tree-optimization/57275
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Fix
return value for fail to do runtime alias checks for gather loads.

* gcc.target/i386/pr57275.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr57275.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/57278] -fno-if-conversion and -fno-if-conversion2 do not work as intended

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||steven at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Steven Bosscher  ---
(In reply to Andrew Pinski from comment #1)
> I don't think  -fno-if-conversion and -fno-if-conversion2 are designed to
> turn off all predicated instructions.

Correct.  There are instruction patterns that automatically expand to 
predicated instructions, see e.g. some of the define_insn_and_split 
and define_split cases in arm.md like this one:

(define_split
  [(set (match_operand:SI 0 "s_register_operand" "")
(eq:SI (match_operand:SI 1 "s_register_operand" "")
   (const_int 0)))
   (clobber (reg:CC CC_REGNUM))]
  "..."
  [(parallel
[(set (reg:CC CC_REGNUM)
  (compare:CC (const_int 1) (match_dup 1)))
 (set (match_dup 0)
  (minus:SI (const_int 1) (match_dup 1)))])
   (cond_exec (ltu:CC (reg:CC CC_REGNUM) (const_int 0))
  (set (match_dup 0) (const_int 0)))])

There is no option at the moment to disable all predicated instructions.

[Bug rtl-optimization/56833] [4.9 Regression] Valid register is over written by postreload pass

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
Summary|[4.9 Regression] Valid  |[4.9 Regression] Valid
   |register is over written by |register is over written by
   |reload pass |postreload pass
 Ever confirmed|0   |1

[Bug web/55237] Linkify r123456 in comments to point to SVN

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

URL|http://gcc.gnu.org/viewcvs/ |http://gcc.gnu.org/viewcvs/
   |gcc?view=revision&revision= |gcc?view=revision&revision=
   |1234|123456

--- Comment #10 from Steven Bosscher  ---
Is it a good idea to only linkify references for r[0-9]{3,} so that
register names are not linkified? E.g. in bug 56833 all register names
like r26, r31, etc. are turned into SVN revision links (and probably in
this bug report now, too :-)

[Bug c++/56976] using braces to initialize a reference forces copy construction

[akim.demaille at gmail dot com]

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

--- Comment #2 from Akim Demaille  ---
Maybe I don't know, even after having read several times the section you
pointed me to.  In particular I see nothing there which could explain why using
foo() instead of foo{} would give different results.

FWIW, other people fell on this issue, and I didn't see any clear cut answer.

http://stackoverflow.com/questions/12450258/how-generic-is-the-construction-syntax?lq=1

[Bug libstdc++/57283] New: missing typedefs in specialized std::mem_fn for member variables

[record.nctu.cis91 at gmail dot com]

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

Bug ID: 57283
   Summary: missing typedefs in specialized std::mem_fn for member
variables
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: record.nctu.cis91 at gmail dot com

Created attachment 30118
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30118&action=edit
code-reproduce-this-issue.cpp

I found that gcc complain that "no type named ‘argument_type’ in ‘class
std::_Mem_fn’", with the code in attachment.

Then I try to locate the problem and find there is no any typedefs for
argument_type.
So I guess it's missing the required typedefs.

[Bug middle-end/57276] Waste work in cgraph_edge_brings_all_agg_vals_for_node()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
 CC||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug target/57281] x86_64-linux loop fails to terminate at -O3 -m32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  It's loop unswitching triggering this.

[Bug target/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32, bogus extendsidi2_1 splitter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i?86-*-*
 Status|ASSIGNED|NEW
   Target Milestone|--- |4.9.0
Summary|x86_64-linux loop fails to  |[4.9 Regression]
   |terminate at -O3 -m32   |x86_64-linux loop fails to
   ||terminate at -O3 -m32,
   ||bogus extendsidi2_1
   ||splitter

--- Comment #2 from Richard Biener  ---
But the miscompile happens during RTL opts:

  :
  f.0_13 ={v} f;
  *pretmp_4 = 0;
  b.5_1 = b;
  _23 = (long long int) b.5_1;
  *pretmp_18 = _23;
  *pretmp_4 = 0;
  b.2_27 = b;
  b.3_28 = b.2_27 + -1;
  b = b.3_28;
  if (b.3_28 != -20)
goto ;
  else
goto ;

  :
  goto ;

is ok, while

.L4:
movlf, %eax
movlf+4, %edx
movl$0, (%ecx)
movlb, %eax
movl%eax, (%ebx)
sarl$31, %eax
movl%eax, 4(%ebx)
subl$1, %eax
cmpl$-20, %eax
movl%eax, b
jne .L4

messes up the IV value - the store of the upper half of the long long
extended b into *pretmp_18 invalidates b (%eax) but that value is then
still used for the IV.

Ok pre-IRA/LRA:

(insn 19 18 20 4 (parallel [
(set (mem:DI (reg/f:SI 68 [ D.1736 ]) [4 *_18+0 S8 A64])
(sign_extend:DI (reg:SI 75 [ b ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) t.c:9 137 {extendsidi2_1}
 (expr_list:REG_DEAD (reg:SI 75 [ b ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
...
(insn 21 20 22 4 (set (reg:SI 76 [ b ])
(mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])) t.c:17 85 {*movsi_internal}
 (nil))
(insn 22 21 23 4 (parallel [
(set (reg:SI 72 [ b.3 ])
(plus:SI (reg:SI 76 [ b ])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))

and after:

(insn 19 78 20 4 (parallel [
(set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
A64])
(sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
(clobber (reg:CC 17 flags))
(clobber (reg:SI 1 dx [80]))
]) t.c:9 137 {extendsidi2_1}
 (expr_list:REG_UNUSED (reg:SI 1 dx [80])
(expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
(nil
(insn 20 19 21 4 (set (mem:SI (reg/f:SI 2 cx [orig:61 D.1734 ] [61]) [2 *_4+0
S4 A32])
(const_int 0 [0])) t.c:21 85 {*movsi_internal}
 (nil))
(note 21 20 80 4 NOTE_INSN_DELETED)
(insn 80 21 22 4 (set (reg:SI 0 ax [82])
(mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])) t.c:17 85 {*movsi_internal}
 (nil))

and postreload optimizes it to

(insn 78 18 19 4 (set (reg:SI 0 ax [orig:75 b ] [75])
(mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])) t.c:9 85 {*movsi_internal}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])
(nil)))
(insn 19 78 21 4 (parallel [
(set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
A64])
(sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
(clobber (reg:CC 17 flags))
(clobber (reg:SI 1 dx [80]))
]) t.c:9 137 {extendsidi2_1}
 (expr_list:REG_UNUSED (reg:SI 1 dx [80])
(expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
(nil
(note 21 19 80 4 NOTE_INSN_DELETED)
(insn 80 21 22 4 (set (reg:SI 0 ax [82])
(reg:SI 0 ax [orig:75 b ] [75])) t.c:17 85 {*movsi_internal}
 (nil))
(insn 22 80 23 4 (parallel [
(set (reg:SI 0 ax [orig:72 b.3 ] [72])
(plus:SI (reg:SI 0 ax [82])
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))

but broken by split, which clobbers ax:

(insn 78 18 89 4 (set (reg:SI 0 ax [orig:75 b ] [75])
(mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])) t.c:9 85 {*movsi_internal}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:SI ("b") [flags 0x2]  ) [2 b+0 S4 A32])
(nil)))
(insn 89 78 90 4 (set (mem:SI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0
S4 A64])
(reg:SI 0 ax [orig:75 b ] [75])) t.c:9 85 {*movsi_internal}
 (nil))
(insn 90 89 91 4 (parallel [
(set (reg:SI 0 ax [orig:75 b ] [75])
(ashiftrt:SI (reg:SI 0 ax [orig:75 b ] [75])
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) t.c:9 529 {ashrsi3_cvt}
 (nil))
(insn 91 90 21 4 (set (mem:SI (plus:SI (reg/f:SI 3 bx [orig:68 D.1736 ] [68

[Bug target/57260] Generated R_MIPS_GOT_MIPS relocation for direct function call while compiling with -O2 on MIPS N64

[lee.duhem at gmail dot com]

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

--- Comment #12 from Lee Duhem  ---
(In reply to rsand...@gcc.gnu.org from comment #11)
> Created attachment 30116 [details]
> Candidate patch
> 
> Here's the patch I'm testing.  Lee, could you check that it
> fixes the original libglx problem?

The libglx.so problem has been fixed by your patch, thank you.

But the regression tests are not finished yet, the MIPS machine
I am using quiet slow.

Thanks for your time.

[Bug libstdc++/57283] missing typedefs in specialized std::mem_fn for member variables

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
The standard is clear, the typedef is not required when wrapping a pointer to
member data, see [func.memfn]

You can use a lambda expression in C++11:

[](const cls& c) { return !c.value; };

In C++14 you will be able to write a generic lambda to negate arbitrary
function objects, replacing std::not1 completely:

[](auto f) { return !f(); };

[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
Summary|[4.9 Regression]|[4.9 Regression]
   |x86_64-linux loop fails to  |x86_64-linux loop fails to
   |terminate at -O3 -m32,  |terminate at -O3 -m32
   |bogus extendsidi2_1 |
   |splitter|

--- Comment #3 from Richard Biener  ---
postreload leaves a REG_DEAD note on the

(insn 19 78 21 4 (parallel [
(set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
A64])
(sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
(clobber (reg:CC 17 flags))
(clobber (reg:SI 1 dx [80]))
]) t.c:9 137 {extendsidi2_1}
 (expr_list:REG_UNUSED (reg:SI 1 dx [80])
(expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
(nil

which is bogus.

[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher  ---
(In reply to Richard Biener from comment #2)
> messes up the IV value - the store of the upper half of the long long
> extended b into *pretmp_18 invalidates b (%eax) but that value is then
> still used for the IV.

Re-emergence of bug 56833?

[Bug fortran/57284] New: ICE with "find_array_spec: unused as (1)" in conjunction with size() intrinsic on class dummy parameter shape

[bugs at stellardeath dot org]

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

Bug ID: 57284
   Summary: ICE with "find_array_spec: unused as (1)" in
conjunction with size() intrinsic on class dummy
parameter shape
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at stellardeath dot org

Created attachment 30119
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30119&action=edit
Minimal test case

I get an ICE for the following (valid?) minimal test-case involving a size()
intrinsic for a class() dummy argument:

> cat minimal.f90
module testmod
  type type_t
  end type type_t
  contains
  function foo(a, b) result(add)
class(type_t), intent(in) :: a(:), b(size(a))
type(type_t) :: add(size(a))
  end function
end module testmod
program p
  use testmod
end program
>
> ~/sys/bin/gfortran minimal.f90 
minimal.f90:10.9:

program p
 1
Internal Error at (1):
find_array_spec(): unused as(1)
>
> ~/sys/bin/gfortran --version
GNU Fortran (GCC) 4.9.0 20130514 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


Here, ~/sys/bin/gfortran is a self-compiled gfortran from yesterday's trunk,
the ICE also happens with the gfortran 4.7.2 supplied with openSUSE:


> gfortran --version
GNU Fortran (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

> gfortran minimal.f90 
minimal.f90:10.9:

program p
 1
Internal Error at (1):
find_array_spec(): unused as(1)

[Bug fortran/57285] New: ICe on invalid: "gfc_array_dimen_size(): Bad dimension" due to size() intrinsic with invalid dim on class() dummy argument

[bugs at stellardeath dot org]

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

Bug ID: 57285
   Summary: ICe on invalid: "gfc_array_dimen_size(): Bad
dimension" due to size() intrinsic with invalid dim on
class() dummy argument
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at stellardeath dot org

The following invalid code produces an internal error. It is invalid as it uses
size() with a dim argument of 2 that is larger than the number of dimensions of
the referred array.

> cat minimal.f90
module testmod
  type type_t
integer :: dummy
  end type type_t
  contains
  subroutine foo(a)
class(type_t), intent(in) :: a(:)
type(type_t) :: c(size(a,dim=2))
  end subroutine
end module testmod
> 
> ~/sys/bin/gfortran minimal.f90 
minimal.f90:10.18:

end module testmod
  1
Internal Error at (1):
gfc_array_dimen_size(): Bad dimension
>
> ~/sys/bin/gfortran --version
GNU Fortran (GCC) 4.9.0 20130514 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING


Here, ~/sys/bin/gfortran is a self-compiled gfortran from yesterday's trunk,
the ICE also happens with the gfortran 4.7.2 supplied with openSUSE:


> gfortran --version
GNU Fortran (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

> gfortran minimal.f90 
minimal.f90:10.18:

end module testmod
  1
Internal Error at (1):
gfc_array_dimen_size(): Bad dimension



This might be related to Bug #57284.

[Bug fortran/57285] ICe on invalid: "gfc_array_dimen_size(): Bad dimension" due to size() intrinsic with invalid dim on class() dummy argument

[bugs at stellardeath dot org]

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

--- Comment #1 from Lorenz Hüdepohl  ---
Created attachment 30120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30120&action=edit
Minimal test case

[Bug fortran/57284] ICE with "find_array_spec: unused as (1)" in conjunction with size() intrinsic on class dummy parameter shape

[bugs at stellardeath dot org]

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

--- Comment #1 from Lorenz Hüdepohl  ---
Might be related to Bug #57285

[Bug libstdc++/57283] missing typedefs in specialized std::mem_fn for member variables

[record.nctu.cis91 at gmail dot com]

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

--- Comment #2 from Lin Yi-Li  ---
Sorry I missed that 'pm is a pointer to member function...'.

I know that C++11 has lambda, but using std::mem_fn is sometimes much clear.
But according to standard, value from std::mem_fn for variable will not be able
to work with std::not1. Even if the usage is similiar to the one for member
function takes no argument.

So is it possible to be an enhancement?

[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Redirecting to builtin_unreachable committed as revision 198926.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[LpSolit at netscape dot net]

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

--- Comment #11 from Frédéric Buclin  ---
What's the max value of a register name? r31?

[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #5 from Eric Botcazou  ---
> postreload leaves a REG_DEAD note on the
> 
> (insn 19 78 21 4 (parallel [
> (set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
> A64])
> (sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
> (clobber (reg:CC 17 flags))
> (clobber (reg:SI 1 dx [80]))
> ]) t.c:9 137 {extendsidi2_1}
>  (expr_list:REG_UNUSED (reg:SI 1 dx [80])
> (expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
> (nil
> 
> which is bogus.

Leaving REG_DEAD/REG_UNUSED notes at the end of a pass is OK, it's up to the
next pass using them to make sure they are valid by invoking DF.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
I think ia64 uses registers up to r127.
As http://gcc.gnu.org/r999 is from mid 1992, it is very unlikely too many
bugzilla comments would like to refer to those commits and can use the URL
syntax in that case, so I think just linkifying only r followed by 4+ digits
would be best.

[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Eric Botcazou from comment #5)
> > postreload leaves a REG_DEAD note on the
> > 
> > (insn 19 78 21 4 (parallel [
> > (set (mem:DI (reg/f:SI 3 bx [orig:68 D.1736 ] [68]) [4 *_18+0 S8
> > A64])
> > (sign_extend:DI (reg:SI 0 ax [orig:75 b ] [75])))
> > (clobber (reg:CC 17 flags))
> > (clobber (reg:SI 1 dx [80]))
> > ]) t.c:9 137 {extendsidi2_1}
> >  (expr_list:REG_UNUSED (reg:SI 1 dx [80])
> > (expr_list:REG_DEAD (reg:SI 0 ax [orig:75 b ] [75])
> > (nil
> > 
> > which is bogus.
> 
> Leaving REG_DEAD/REG_UNUSED notes at the end of a pass is OK, it's up to the
> next pass using them to make sure they are valid by invoking DF.

Which means that split has to do that?  Or that the use of dead_or_set_p ()
in

;; Extend to memory case when source register does die.
(define_split
  [(set (match_operand:DI 0 "memory_operand")
(sign_extend:DI (match_operand:SI 1 "register_operand")))
   (clobber (reg:CC FLAGS_REG))
   (clobber (match_operand:SI 2 "register_operand"))]
  "(reload_completed
&& dead_or_set_p (insn, operands[1])
&& !reg_mentioned_p (operands[1], operands[0]))"
  [(set (match_dup 3) (match_dup 1))
   (parallel [(set (match_dup 1) (ashiftrt:SI (match_dup 1) (const_int 31)))
  (clobber (reg:CC FLAGS_REG))])
   (set (match_dup 4) (match_dup 1))]
  "split_double_mode (DImode, &operands[0], 1, &operands[3], &operands[4]);")

is bogus?

[Bug rtl-optimization/57281] [4.9 Regression] x86_64-linux loop fails to terminate at -O3 -m32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> Which means that split has to do that?

Presumably, yes.  peephole2 already does it.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #13 from Alexander Monakov  ---
What about pseudo registers?  They are also r[0-9]+, and the number can easily
be in the thousands.

http://gcc.gnu.org/r9 is almost 8 years ago, so bumping 4+ to 6+ should be
fine.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[LpSolit at netscape dot net]

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

--- Comment #14 from Frédéric Buclin  ---
On the other hand, you are free to not click on a register name which is
linkified.

[Bug c/57286] New: [4.9 regression] infinite recurison in fold-const.c:10037

[jojelino at gmail dot com]

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

Bug ID: 57286
   Summary: [4.9 regression] infinite recurison in
fold-const.c:10037
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jojelino at gmail dot com

Created attachment 30121
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30121&action=edit
preprocessed source

(gdb) r
Starting program: /usr/libexec/gcc/i686-pc-cygwin/4.9.0/cc1.exe -quiet -v -I .
-I .. -I ../include -MD .libs/libfaac_la-aacquant.d -MF
.deps/libfaac_la-aacquant.Tpo -MP -MT libfaac_la-aacquant.lo -Dunix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/lib/../../include/w32api
-D HAVE_CONFIG_H -D DRM -D DLL_EXPORT -D PIC aacquant.c -march=core2 -mcx16
-msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma
-mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2
-msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase
-mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048
-mtune=core2 -quiet -dumpbase aacquant.c -auxbase-strip
.libs/libfaac_la-aacquant.o -g -O4 -std=gnu11 -version -frename-registers
-fno-strict-overflow -o /tmp/ccEheGnn.s
[New Thread 16040.0x374c]
[New Thread 16040.0x1e20]
GNU C (GCC) version 4.9.0 20130515 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.9.0 20130515 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 ..
 ../include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/include
 /usr/local/include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/include-fixed
 /usr/include
 /usr/lib/gcc/i686-pc-cygwin/4.9.0/../../../../include/w32api
End of search list.
GNU C (GCC) version 4.9.0 20130515 (experimental) (i686-pc-cygwin)
    compiled by GNU C version 4.9.0 20130515 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ebeca84797ce5db4d10946c78482951c

Program received signal SIGSEGV, Segmentation fault.
int_const_binop_1 (code=BIT_IOR_EXPR, arg1=0x7fbdfb40, arg2=0x7fbdfb20,
overflowable=0x1) at ../.././gcc/fold-const.c:934
934   tree type = TREE_TYPE (arg1);
(gdb) bt -50


#25936 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28,
cond=0x7fa71350, arg=0x7fac9e28, cond_first_p=0x1)
at ../.././gcc/fold-const.c:6129
#25937 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28)
---Type  to continue, or q  to quit---
at ../.././gcc/fold-const.c:10037
#25938 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e28)
at ../.././gcc/fold-const.c:14944
#25939 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e10, op2=0x7fac9e28)
at ../.././gcc/fold-const.c:14261
#25940 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9e10, op2=0x7fac9e28)
at ../.././gcc/fold-const.c:15006
#25941 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8,
cond=0x7fa71350, arg=0x7fac9dc8, cond_first_p=0x1)
at ../.././gcc/fold-const.c:6129
#25942 0x007b1963 in fold_binary_loc (loc=0x0, code=BIT_IOR_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8)
at ../.././gcc/fold-const.c:10037
#25943 0x007e618d in fold_build2_stat_loc (loc=0x0, code=BIT_IOR_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9dc8)
at ../.././gcc/fold-const.c:14944
#25944 0x007e3f28 in fold_ternary_loc (loc=0x0, code=VEC_COND_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9db0, op2=0x7fac9dc8)
at ../.././gcc/fold-const.c:14261
---Type  to continue, or q  to quit---
#25945 0x007e6224 in fold_build3_stat_loc (loc=0x0, code=VEC_COND_EXPR,
type=0x7fd5ff60, op0=0x7fa71350, op1=0x7fac9db0, op2=0x7fac9dc8)
at ../.././gcc/fold-const.c:15006
#25946 0x00799b42 in fold_binary_op_with_conditional_arg (loc=0x0,
code=BIT_IOR_EXPR, type=0x7fd5ff60, op0=0x7fa7135

[Bug libstdc++/57283] missing typedefs in specialized std::mem_fn for member variables

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Lin Yi-Li from comment #2)
> Sorry I missed that 'pm is a pointer to member function...'.
> 
> I know that C++11 has lambda, but using std::mem_fn is sometimes much clear.

You can still use std::mem_fn, the problem is with std::not1, which only works
with the C++98 function object protocol.

> But according to standard, value from std::mem_fn for variable will not be
> able to work with std::not1. Even if the usage is similiar to the one for
> member function takes no argument.

It's similar but not the same, for a member function the result_type is the
return type and the argument_type is dictated by the cv-qualifiers of the
member function, i.e. for a const member function the argument_type is 'const
T*', but for a member variable the result_type depends on whether you call it
with a const or non-const argument.

Should mem_fn(&cls::value) have result_type=int& and argument_type=cls*
or result_type=const int& and argument_type=const cls*?
The result of mem_fn(&cls::value) is polymorphic.

> So is it possible to be an enhancement?

It might be possible to generalize std::unary_negate, but that's for the
standard committee not GCC's bugzilla.

[Bug web/55237] Linkify r123456 in comments to point to SVN

[stevenb.gcc at gmail dot com]

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

--- Comment #15 from stevenb.gcc at gmail dot com  ---
> --- Comment #14 from Frédéric Buclin  ---
> On the other hand, you are free to not click on a register name which is
> linkified.

That is true, but it's a bit distracting.
Let's not bike shed over this. It's nothing major, only nice-to-have :-)

[Bug middle-end/57286] [4.9 regression] infinite recurison in fold-const.c:10037

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org
  Component|tree-optimization   |middle-end
   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener  ---
So the comment was correct after all ;)

[Bug middle-end/57286] [4.9 regression] infinite recurison in fold-const.c:10037

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
folding

(gdb) call debug_gimple_stmt (stmt)
vect_patt_667.85_618 = VEC_COND_EXPR ;

cycle via

14256 /* Convert A ? 1 : B into A || B if A and B are truth values.  */
14257 if (code == VEC_COND_EXPR ? integer_all_onesp (arg1) :
integer_onep (arg1)
14258 && truth_value_p (TREE_CODE (arg0))
14259 && truth_value_p (TREE_CODE (op2))
14260 && (code == VEC_COND_EXPR || !VECTOR_TYPE_P (type)))
14261   return fold_build2_loc (loc, code == VEC_COND_EXPR
14262? BIT_IOR_EXPR : TRUTH_ORIF_EXPR,
14263   type, fold_convert_loc (loc, type,
arg0), op2);

and

#2  0x0084f783 in fold_binary_op_with_conditional_arg (loc=0, 
code=BIT_IOR_EXPR, type=0x76c27540, op0=0x76c7e500, 
op1=0x76c7b5c0, cond=0x76c7e500, arg=0x76c7b5c0, 
cond_first_p=1) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:6129
6129  return fold_build3_loc (loc, cond_code, type, test, lhs, rhs);

only one variant should be canonical, obvious for the vector case but
eventually not for the scalar case.

[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
 CC||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Kai Tietz  ---
Yes, this happens for function using eax as input-argument hand using
stack-allocation.  btw it isn't specific to chkstk_ms function.

I will take a look

[Bug c/57287] New: GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[muhammad_bilal at mentor dot com]

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

Bug ID: 57287
   Summary: GCC 4.9.0 fails to build GDB on Ubuntu 12.04
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muhammad_bilal at mentor dot com

While I was building the latest GDB CVS source code with
gcc (GCC) 4.9.0 20130513 (experimental)
with building step
with building step 

$CC="/home/mbilal/gcc-svn/install/bin/gcc" ./../src/configure
--prefix=/home/mbilal/commit-gdb-cvs/install

$ make

I got errors

 -MF .deps/py-framefilter.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv
.././../src/gdb/python/py-framefilter.c
In file included from .././../src/gdb/python/py-framefilter.c:24:0:
.././../src/gdb/python/py-framefilter.c: In function ‘enumerate_locals’:
.././../src/gdb/exceptions.h:152:31: error: ‘buf’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/exceptions.h:152:31: note: ‘buf’ was declared here
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/python/py-framefilter.c:839:7: note: in expansion of macro
‘TRY_CATCH’
   TRY_CATCH (except, RETURN_MASK_ALL)
   ^
.././../src/gdb/exceptions.h:152:31: error: ‘buf’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/exceptions.h:152:31: note: ‘buf’ was declared here
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/python/py-framefilter.c:782:7: note: in expansion of macro
‘TRY_CATCH’
   TRY_CATCH (except, RETURN_MASK_ALL)
   ^
.././../src/gdb/exceptions.h:152:31: error: ‘buf’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/exceptions.h:152:31: note: ‘buf’ was declared here
EXCEPTIONS_SIGJMP_BUF *buf = \
   ^
.././../src/gdb/python/py-framefilter.c:762:4: note: in expansion of macro
‘TRY_CATCH’
TRY_CATCH (except, RETURN_MASK_ALL)
^
.././../src/gdb/python/py-framefilter.c:732:23: error: ‘locals_cleanups’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   struct cleanup *locals_cleanups;
   ^
.././../src/gdb/python/py-framefilter.c:731:11: error: ‘local_indent’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   int local_indent = 8 + (8 * indent);
   ^
cc1: all warnings being treated as errors
make[2]: *** [py-framefilter.o] Error 1
make[2]: Leaving directory `/home/mbilal/commit-gdb-cvs/objdir/gdb'
make[1]: *** [all-gdb] Error 2
make[1]: Leaving directory `/home/mbilal/commit-gdb-cvs/objdir'
make: *** [all] Error 2


But something looks really bogus with errors like

.././../src/gdb/python/py-framefilter.c:731:11: error: ‘local_indent’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   int local_indent = 8 + (8 * indent);

First I reported a bug on GDB bugzilla
http://sourceware.org/bugzilla/show_bug.cgi?id=15463#c4

[Bug libstdc++/57283] missing typedefs in specialized std::mem_fn for member variables

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
N.B. you can also do it with a nested std::bind expression and std::logical_not

std::bind(std::logical_not(),
  std::bind(std::mem_fn(&cls::value), std::placeholders::_1))

in C++14 that means you can provide a working not1 replacement:

template
auto not1(F f)
{
return std::bind(std::logical_not<>(), std::bind(f,
std::placeholders::_1));
}

[Bug c/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[muhammad_bilal at mentor dot com]

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

hmb  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug target/57288] New: cfi_restore should precede cfi_def_cfa_offset

[msharov at users dot sourceforge.net]

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

Bug ID: 57288
   Summary: cfi_restore should precede cfi_def_cfa_offset
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net

Created attachment 30122
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30122&action=edit
The emitted assembly exhibiting the ordering problem

This is on x86_64, compiled with -Os. In the attached assembly, line 89, .L55,
.cfi_restore is emitted for ebx and ebp after .cfi_def_cfa_offset 8 already
invalidated the location where they were stored. cfa_offset should be emitted
after cfi_restores, as it was in the other codepaths like .LEHE0-.L51

[Bug c/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[palves at redhat dot com]

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

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #1 from Pedro Alves  ---
(Repeating my comment on the GDB bugzilla here)

All these warnings are around setjmp/longjmp.

E.g, with:

.././../src/gdb/python/py-framefilter.c:731:11: error: ‘local_indent’ may be
used uninitialized in this function [-Werror=maybe-uninitialized]
   int local_indent = 8 + (8 * indent);

local_indent is only used in a TRY_CATCH block, meaning, after a setjmp.

I suspect this to be related to this recent setjmp gcc change:

 http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00344.html

[Bug middle-end/57286] [4.9 regression] infinite recurison in fold-const.c:10037

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
Intuitively, I'd say:

@@ -10041,7 +10041,7 @@

   if (TREE_CODE (arg1) == COND_EXPR
   || TREE_CODE (arg1) == VEC_COND_EXPR
-  || COMPARISON_CLASS_P (arg1))
+  || (COMPARISON_CLASS_P (arg1) && !VECTOR_TYPE_P (TREE_TYPE (arg1
 {
   tem = fold_binary_op_with_conditional_arg (loc, code, type, op0, op1,
  arg1, arg0,

but I don't really have time to think about it right now (meeting).

[Bug c/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-05-15
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Please attach at least one example as preprocessed source.

[Bug fortran/57284] [OOP] ICE with "find_array_spec for polymorphic arrays

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
Summary|ICE with "find_array_spec:  |[OOP] ICE with
   |unused as (1)" in   |"find_array_spec  for
   |conjunction with size() |polymorphic arrays
   |intrinsic on class dummy|
   |parameter shape |

--- Comment #2 from Tobias Burnus  ---
The problem is that the expression is (internally):
   a->REF_COMPONENT("_data")->REF_ARRAY(full array)

In find_array_spec, the code firsts gets the array as:
   as = CLASS_DATA (e->symtree->n.sym)->as;

And then it walks the refs. Result:
   a->(full array)->_data->(full array)

But having two full arrays is invalid! Hence, it fails.

(find_array_spec doesn't see that the two arrays refs are identical.)

[Bug rtl-optimization/56776] [4.8/4.9 Regression] valgrind errors within ira

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.1

[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.1

[Bug fortran/56852] [4.7/4.8/4.9 Regression] ICE on invalid: "Bad array reference" for an undeclared loop variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug fortran/56919] [4.7/4.8/4.9 Regression] Wrong result for SYSTEM_CLOCK on Cygwin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug fortran/56939] [4.8/4.9 Regression] [OOP] Derived type is being used before it is defined

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.8.1

[Bug fortran/57019] [4.7/4.8/4.9 Regression] Compiler crashes (and make wrong assignments) at some combinations of pointers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug fortran/57042] [4.7/4.8/4.9 Regression] ICE/Segfault with -fdump-parse-tree

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug c++/57101] [4.8/4.9 Regression] -fcompare-debug failure with

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.1

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.1

[Bug fortran/57217] [4.7/4.8/4.9 Regression][OOP] Accepts invalid TBP overriding - lacking arguments check

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.4

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> The following snippet fixes the
> cls_unit_va.c failure for me: ...

Confirmed on powerpc-apple-darwin9. Thanks for the fix.

> I've included the complete patch in i386-pc-solaris2.* bootstraps, too,
> and saw no regressions, so I suggest you post the complete patch to
> gcc-patches, and Cc: Anthony Green.

\begin{rant}

I won't have the time to go through the gcc-patches hooplas before at least one
month (in top of that I don't have write access). If someone really wants these
fixes to be committed to 4.8.1, (s)he will have to do the work.

After all powerpc64-unknown-linux-gnu is supposed to be a primary platform with
several maintainers, not powerpc-apple-darwin9.

\end{rant}

[Bug libgcc/57221] [4.8/4.9 regression] libgcc symbol visibility changes break Android blobs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arm-bionic-eabi
   Target Milestone|--- |4.8.1

[Bug lto/57289] New: ICE during 454.calculix compilation with -O3 -flto

[izamyatin at gmail dot com]

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

Bug ID: 57289
   Summary: ICE during 454.calculix compilation with -O3 -flto
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: mjambor at suse dot cz
Target: x86

Happens due to r198821.

Fail:
lto1: internal compiler error: in propagate_controlled_uses, at ipa-prop.c:2552
0x71753f propagate_controlled_uses
../../gcc/ipa-prop.c:2551
0x71753f ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
../../gcc/ipa-prop.c:2659
0x70fe24 inline_call(cgraph_edge*, bool, vec*,
int*, bool)
../../gcc/ipa-inline-transform.c:255
0x7010d7 inline_small_functions
../../gcc/ipa-inline.c:1613
0x7010d7 ipa_inline
../../gcc/ipa-inline.c:1794
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: gfortran returned 1 exit status
/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/56971] [4.9 Regression] GCC claims a friend function to be overloaded, but it isn't

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Dominique d'Humieres  ---
[...]
>> I've included the complete patch in i386-pc-solaris2.* bootstraps, too,
>> and saw no regressions, so I suggest you post the complete patch to
>> gcc-patches, and Cc: Anthony Green.
>
> \begin{rant}
>
> I won't have the time to go through the gcc-patches hooplas before at least 
> one
> month (in top of that I don't have write access). If someone really wants 
> these
> fixes to be committed to 4.8.1, (s)he will have to do the work.

I don't know if we can get the patch into 4.8 at this point, but I
certainly want it for mainline.  I just suggested that you post it since
it's almost completely your work, but am fine with doing it myself.

Rainer

[Bug c++/56966] [4.7 Regression] wrong warning with -Werror (wrong code without Werror?)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
Also this is a glibc issue then.

[Bug c++/56976] using braces to initialize a reference forces copy construction

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  ---
(In reply to Akim Demaille from comment #2)
You are right, I misread your code example in the haste. I agree that this is
not related to CWG 1604 (we have no mixed case) and I think it is clear that
both initializations should be accepted, it should be a direct binding, because
we fall into 8.5.4 p3 b5:

"Otherwise, if the initializer list has a single element of type E and [..] its
referenced type is reference-related to E, the object or reference is
initialized from that element;"

[Bug tree-optimization/57289] [4.9 Regression] ICE during 454.calculix compilation with -O3 -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
  Component|lto |tree-optimization
   Target Milestone|--- |4.9.0
Summary|ICE during 454.calculix |[4.9 Regression] ICE during
   |compilation with -O3 -flto  |454.calculix compilation
   ||with -O3 -flto

--- Comment #1 from Richard Biener  ---
Compile/link options?

[Bug lto/57290] New: [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto

[dominiq at lps dot ens.fr]

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

Bug ID: 57290
   Summary: [4.9 Regression] After r198333 the aermod runtime is
~10% slower when compiled with -fprotect-parens and
-flto
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: rguenth at gcc dot gnu.org

After r198333, the aermod runtime is more than 10% slower when compiled with
-fprotect-parens and -flto:

(1) -Ofast -funroll-loops
(2) -fprotect-parens -Ofast -funroll-loops
(3) -Ofast -funroll-loops -fwhole-program -flto
(4) -fprotect-parens -Ofast -funroll-loops -fwhole-program
(5) -fprotect-parens -Ofast -funroll-loops -fwhole-program -flto

revision:   198332  198333

(1)  18.11   17.74
(2)  17.70   17.61
(3)  17.66   18.34
(4)  18.47   18.49
(5)  17.80   20.70

[Bug rtl-optimization/56776] [4.8/4.9 Regression] valgrind errors within ira

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Jakub Jelinek  ---
This is a non-bug, sparseset intentionally has uninitialized stuff, you need
--enable-checking=valgrind to add valgrind annotations to quiet it up.

[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de  ---
On Wed, 15 May 2013, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57290
> 
> Bug ID: 57290
>Summary: [4.9 Regression] After r198333 the aermod runtime is
> ~10% slower when compiled with -fprotect-parens and
> -flto
>Product: gcc
>Version: 4.9.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: lto
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: dominiq at lps dot ens.fr
> CC: rguenth at gcc dot gnu.org
> 
> After r198333, the aermod runtime is more than 10% slower when compiled with
> -fprotect-parens and -flto:
> 
> (1) -Ofast -funroll-loops
> (2) -fprotect-parens -Ofast -funroll-loops
> (3) -Ofast -funroll-loops -fwhole-program -flto
> (4) -fprotect-parens -Ofast -funroll-loops -fwhole-program
> (5) -fprotect-parens -Ofast -funroll-loops -fwhole-program -flto
> 
> revision:   198332  198333
> 
> (1)  18.11   17.74
> (2)  17.70   17.61
> (3)  17.66   18.34
> (4)  18.47   18.49
> (5)  17.80   20.70

There is a lot of noise in these numbers(?) the patch, apart from

+   * passes.c (init_optimization_passes): Schedule a copy-propagation
+   pass before complete unrolling of inner loops.

should have had no effect on performance (well, in theory, that is).
Can you check whether reverting the above part changes the results?

Also, what's the variance of the numbers?  Are (1) to (4) effectively
the same performance r198332 vs. r198333?  (make sure to disable
address-space randomization for benchmarking)

[Bug fortran/57285] [OOP] ICE on invalid: "gfc_array_dimen_size(): Bad dimension" due to SIZE intrinsic with invalid dim on CLASS dummy

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
 CC||janus at gcc dot gnu.org
Summary|ICe on invalid: |[OOP] ICE on invalid:
   |"gfc_array_dimen_size():|"gfc_array_dimen_size():
   |Bad dimension" due to   |Bad dimension" due to SIZE
   |size() intrinsic with   |intrinsic with invalid dim
   |invalid dim on class()  |on CLASS dummy
   |dummy argument  |
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed. Changing "a" from CLASS to TYPE ...

  type type_t
  end type
contains
  subroutine foo(a)
type(type_t), intent(in) :: a(:)
type(type_t) :: c(size(a,dim=2))
  end subroutine
end  

... one gets the correct error message:

type(type_t) :: c(size(a,dim=2))
 1
Error: 'dim' argument of 'size' intrinsic at (1) is not a valid dimension index

(unfortunately twice!)

[Bug c++/56976] using braces to initialize a reference forces copy construction

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini  ---
Let's add Jason in CC.

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-05/msg00840.htm
   ||l

--- Comment #11 from Rainer Orth  ---
Patch submitted.

[Bug fortran/57284] [OOP] ICE with find_array_spec for polymorphic arrays

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-15
Summary|[OOP] ICE with  |[OOP] ICE with
   |"find_array_spec  for   |find_array_spec for
   |polymorphic arrays  |polymorphic arrays
 Ever confirmed|0   |1

[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/57289] [4.9 Regression] ICE during 454.calculix compilation with -O3 -flto

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-05-15
 CC|mjambor at suse dot cz |jamborm at gcc dot 
gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Jambor  ---
I can reproduce it and will take a look.

[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions

[dodji at gcc dot gnu.org]

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

--- Comment #3 from Dodji Seketeli  ---
A candidate patch was sent to
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00841.html for this.

[Bug rtl-optimization/56833] [4.9 Regression] Valid register is over written by postreload pass

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Jorn Wolfgang Rennecke  ---
The patch has been posted:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00845.html

[Bug bootstrap/57291] New: Failure in build stages 2 and 3 concerning pseudo-op: .balign

[ExtraLeveLInSoftware at ntlworld dot com]

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

Bug ID: 57291
   Summary: Failure in build stages 2 and 3 concerning pseudo-op:
.balign
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ExtraLeveLInSoftware at ntlworld dot com

Failure in build stages 2 and 3 of gcc-4.7.2

To: gcc-bugs

1. Introduction

Trying to build gcc-4.7.2.

Running Mac OS X:

 System Version:Mac OS X 10.5.8 (9L30)
 Kernel Version:Darwin 9.8.0
 >uname -mpv
 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386 i386

This bug report concerns the following points.

  - An error reported by make in stage 2

  - The same error reported by make in stage 3


2. Report from configure

The existing compilation system for stage 1 was obtained as a
ready built version of ada-4.3 in /usr/local/ada-4.3/bin/ (however, it
reports that it is 4.4.0).

bash> gcc --version
gcc (GCC) 4.4.0 20080314 (experimental) [trunk revision 133226]
Copyright (C) 2008 Free Software Foundation, Inc.

Building in /Gnu/gcc/obj.  Sources in /Gnu/gcc/src/gcc-4.7.2/.

The configure command was
../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ 

This completed OK.


3. An error reported by make in stage2

Ran make &> ../logs/make-4.log  This redirects error stream too.

The make failed, in stage2, last few lines of make-4.log:
../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign
../../src/gcc-4.7.2/libcpp/lex.c:463:Rest of line ignored. 1st junk character
valued 49 (1).
make[3]: *** [lex.o] Error 1
make[2]: *** [all-stage2-libcpp] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

It seems that the first build using the older C and Ada compilers has
completed OK, but the next bootstrap stage has failed.

Help was sought from the gcc-help mailing list (see:
29 April 2013, Ongoing Error in make stage2 building gcc-4.7.2)

Response on gcc-help from Ian Lance Taylor with suggestion for how to
get round it: in libcpp/config.h "change HAVE_SSE4 to 0".

The version of the assembler is a possible problem:
as -v
Apple Computer, Inc. version cctools-667.3~21, GNU assembler version 1.38

From its 'man' page:
-
  The program /usr/bin/as is actually a driver that  executes  assemblers
  for specific target architectures.  If no target architecture is speci-
  fied, it defaults to the architecture of the host it is running on.

...

  -v Display  the version of the assembler (both the Mac OS X version
 and the GNU version it is based on).

-


4. An error reported by make in stage3

Modified libcpp/config.h to change HAVE_SSE4 to 0.  Reran make.
Failed as before (but without redoing most of stage 1).  Last few lines:
../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign
etc as before ...

Modified prev-libcpp/config.h as well - failed with the same last few
lines.

Confirmed the test at the point of failure.

The test in lex.c affecting line 463 is "#ifdef HAVE_SSE4".
Modified libcpp/config.h and prev-libcpp/config.h to change HAVE_SSE4 to
undef.

With this it completed stage 2, but failed in stage 3 with the same
effect:

../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign
../../src/gcc-4.7.2/libcpp/lex.c:463:Rest of line ignored. 1st junk character
valued 49 (1).
make[3]: *** [lex.o] Error 1
make[2]: *** [all-stage3-libcpp] Error 2
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2

So a new config.h needed to be changed.  The libcpp now matched the
prev-libcpp original:
Files libcpp/config.h and prev-libcpp/config.orig.h are identical

There are also stage1-libcpp, and so on now.

Applied this change; completed stage3:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Comparison successful.


5. Information from the gcc-help mailing list

On 29 Apr 2013, at 16:07, Ian Lance Taylor wrote:

I would describe this as a bug in libcpp, introduced here:

2010-08-21  Richard Henderson  
Andi Kleen 
David S. Miller  

* configure.ac (AC_C_BIGENDIAN, AC_TYPE_UINTPTR_T): New tests.
(ssize_t): Check via AC_TYPE_SSIZE_T instead of AC_CHECK_TYPE.
(ptrdiff_t): Check via AC_CHECK_TYPE.
* config.in, configure: Rebuild.
* system.h: Include stdint.h, if available.
* lex.c (WORDS_BIGENDIAN): Provide default.
(acc_char_mask_misalign, acc_char_replicate, acc_char_cmp,
acc_char_index, search_line_acc_char, repl_chars, search_line_mmx,
search_line_sse2, search_line_sse42, init_vectorized_lexer,
search_line_fast): New.
(_cpp_clean_line): Use search_line_fast.  Restructu

[Bug bootstrap/57292] New: Failure in build after stage 3, concerning libitm.la

[ExtraLeveLInSoftware at ntlworld dot com]

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

Bug ID: 57292
   Summary: Failure in build after stage 3, concerning libitm.la
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ExtraLeveLInSoftware at ntlworld dot com

Failure in build after stage 3 of gcc-4.7.2

To: gcc-bugs

1. Introduction

Trying to build gcc-4.7.2.

Running Mac OS X:

 System Version:Mac OS X 10.5.8 (9L30)
 Kernel Version:Darwin 9.8.0
 >uname -mpv
 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386 i386

This bug report concerns the following point.

  - An error reported by make after stage 3, concerning libitm.la


2. Report from configure

The existing compilation system for stage 1 was obtained as a
ready built version of ada-4.3 in /usr/local/ada-4.3/bin/ (however, it
reports that it is 4.4.0)

bash> gcc --version
gcc (GCC) 4.4.0 20080314 (experimental) [trunk revision 133226]
Copyright (C) 2008 Free Software Foundation, Inc.

Building in /Gnu/gcc/obj.  Sources in /Gnu/gcc/src/gcc-4.7.2/.

The configure command was
../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ 

This completed OK.


3. An error reported by make

Ran make &> ../logs/make-8.log

The make failed, with last few messages described below.

The build has passed stage 3, but failed later.

Completed stage3, got to
"Comparing stages 2 and 3", gave:
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Comparison successful.

It continued after this, but gave final error:
ld: warning in ../../../src/gcc-4.7.2/libitm/clearcap.map, file is not of
required architecture
ld: pointer in read-only segment not allowed in slidable image, used in
_del_opvnt from .libs/alloc_cpp.o
collect2: error: ld returned 1 exit status
make[4]: *** [libitm.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libitm] Error 2
make: *** [all] Error 2

The current situation seems to be that I have built the entire stage 3,
but that the step "Build runtime libraries using the stage3 compiler from the
previous step." has failed.


4. Information from the gcc-help mailing list

Help was sought from the gcc-help mailing list (see:
13 May 2013 , Re: Ongoing Error in make stage2 building gcc-4.7.2)


On 13 May 2013, at 14:43, Ian Lance Taylor wrote:

It looks like the code is trying to use a linker map, which is not going to
work with the Darwin linker.  This looks like a bug in the libitm configury.
I don't see it in the current bug database; please consider filing a bug
report.


On 13 May 2013, at 15:43, Richard Henderson wrote:

That linker map is for Solaris.  I have no idea how that might have come to be
used for Darwin.

r~


5. Other related Information

In order to complete the stages 2 and 3 builds, it was necessary to
modify libcpp/config.h in both stages 2 and 3 to circumvent a problem in
libcpp/lex.c with "Unknown pseudo-op: .balign".  (Subject of a separate bug
report, 57291.)

This is not believed to be connected, but is stated just in case.


6. Summary of Bug

6.1 Error in ld

Following stage three, presumably in the step "Build runtime libraries
using the stage3 compiler from the previous step.", make has failed with
make[4]: *** [libitm.la] Error 1

See also extra messages above.


6.2 If extra information about the matters reported above would be of value
please contact:

ExtraLeveLInSoftware at ntlworld dot com

Ellis N. Thomas/15-May-2013

[Bug middle-end/57276] Waste work in cgraph_edge_brings_all_agg_vals_for_node()

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-05/msg00846.htm
   ||l
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #3 from Martin Jambor  ---
I have tested the patch and submitted it to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00846.html

I do not expect any objects and plan to commit it tomorrow.
Thanks a lot for spotting it.

[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413

[ysrumyan at gmail dot com]

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

Yuri Rumyantsev  changed:

   What|Removed |Added

 CC||ysrumyan at gmail dot com

--- Comment #6 from Yuri Rumyantsev  ---
We prepared a patch for 254.gap which resolves issue. So this bug can be
closed.

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> I just suggested that you post it since
> it's almost completely your work, but am fine with doing it myself.

Well, my work has been only to test the recipe in comment #5 for the trivial
cases. The real work has been done by Andreas Krebbel and you.

> Patch submitted.

Thanks.

[Bug fortran/56919] [4.7/4.8 Regression] Wrong result for SYSTEM_CLOCK on Cygwin

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-05-15
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Wrong
   |Wrong result for|result for SYSTEM_CLOCK on
   |SYSTEM_CLOCK on Cygwin  |Cygwin
 Ever confirmed|0   |1

--- Comment #7 from Janne Blomqvist  ---
Issue is fixed on trunk (4.9). 

The question is whether it's useful to backport to 4.7 and 4.8. The previous
cygwin behavior, while perhaps surprising, isn't wrong per se and while the new
behavior is an improvement (IMHO) it's a (subtle) change in behavior which
might be surprising in the middle of a release series.

Maybe just backport the _POSIX_MONOTONIC_CLOCK part to fix(?) newlib targets,
and leave the windows stuff as is?

[Bug middle-end/57286] [4.9 regression] infinite recurison in fold-const.c:10037

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Shorter testcase:

typedef long vec __attribute__((vector_size(16)));
vec f(vec x){
  return (x<0)|1;
}

[Bug target/57293] New: [4.8/4.9 Regression] not needed frame pointers on IA-32 (performance regression?)

[fanael4 at gmail dot com]

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

Bug ID: 57293
   Summary: [4.8/4.9 Regression] not needed frame pointers on
IA-32 (performance regression?)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fanael4 at gmail dot com

About a week ago GCC started to emit frame pointers even in presence of
-fomit-frame-pointer whenever there's a call to a function with a "callee
cleans up the arguments" calling convention. Normally it wouldn't be a big
deal, but IA-32 is seriously register-starved, and since one of the secondary
platforms (i.e. Windows) uses __thiscall__ for C++ member functions by default,
for some code the availability of ebp can make a noticeable difference. I can
provide a benchmark if one is needed.

The culprit seems to be revisions 198140 and 198555.

Testcase:

/* compile with -O2 -fomit-frame-pointer */
__attribute__((__noinline__, __noclone__, __stdcall__)) void g(int a)
{
  __builtin_printf("in g(): %d\n", a);
}

__attribute__((__noinline__, __noclone__, __thiscall__)) void h(int a, int b)
{
  __builtin_printf("in h(): %d %d\n", a, b);
}

void f()
{
  g(0);
  h(0, 1);
  __builtin_puts("in f()");
}

What GCC 4.7.0 and 4.8.1 20130430 produce for f :

_f:
LFB2:
.cfi_startproc
subl$28, %esp
.cfi_def_cfa_offset 32
movl$0, (%esp)
call_g@4
.cfi_def_cfa_offset 28
xorl%ecx, %ecx
subl$4, %esp
.cfi_def_cfa_offset 32
movl$1, (%esp)
call_h
.cfi_def_cfa_offset 28
subl$4, %esp
.cfi_def_cfa_offset 32
movl$LC2, (%esp)
call_puts
addl$28, %esp
.cfi_def_cfa_offset 4
ret
.cfi_endproc

What 4.8.1 20130510 produces:

_f:
LFB2:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
subl$24, %esp
movl$0, (%esp)
call_g@4
xorl%ecx, %ecx
subl$4, %esp
movl$1, (%esp)
call_h
subl$4, %esp
movl$LC2, (%esp)
call_puts
leave
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc

Target: i686-w64-mingw32
Configured with: ../../src/gcc-svn/configure --build=x86_64-unknown-linux-gnu
--host=i686-w64-mingw32 --target=i686-w64-mingw32 --disable-multilib
--disable-multiarch --disable-nls --enable-languages=c,c++,lto
--disable-win32-registry --enable-openmp --enable-libgomp
--enable-threads=posix --enable-plugins --enable-static --enable-shared
--disable-symvers --enable-fully-dynamic-string --disable-sjlj-exceptions
--disable-libstdcxx-pch --enable-libstdcxx-time --with-arch=i686
--enable-checking=release --disable-werror --with-gnu-as --with-gnu-ld
--disable-rpath --with-gmp=/mingw/i686-final/libs-out-dir
--with-mpfr=/mingw/i686-final/libs-out-dir
--with-mpc=/mingw/i686-final/libs-out-dir
--with-isl=/mingw/i686-final/libs-out-dir
--with-cloog=/mingw/i686-final/libs-out-dir
--with-libiconv-prefix=/mingw/i686-final/libs-out-dir --with-system-zlib
--prefix=/mingw/i686-final/out-dir
Thread model: posix
gcc version 4.8.1 20130510 (prerelease) (GCC)

[Bug c++/31952] parameters may be redeclared in a function try-block

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jason at gcc dot gnu.org   |
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #11 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug c/57294] New: ice in remove_described_reference

[dcb314 at hotmail dot com]

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

Bug ID: 57294
   Summary: ice in remove_described_reference
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

Created attachment 30123
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30123&action=edit
C source code

I just tried to compile the package plymouth-0.8.9-0.2013.03.26.0
on gcc-4.9 trunk dated 20130515 on an AMD x86_64 box.

The compiler said

./script-execute.c: At top level:
./script-execute.c:785:1: internal compiler error: in
remove_described_reference, at ipa-prop.c:2296
 }
 ^
0x7b9afa remove_described_reference
../../src/trunk/gcc/ipa-prop.c:2296
0x7bda6b try_make_edge_direct_simple_call
../../src/trunk/gcc/ipa-prop.c:2347
0x7bda6b update_indirect_edges_after_inlining
../../src/trunk/gcc/ipa-prop.c:2441
0x7bda6b propagate_info_to_inlined_callees
../../src/trunk/gcc/ipa-prop.c:2500
0x7bdf9c ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
../../src/trunk/gcc/ipa-prop.c:2660
0xd5 inline_call(cgraph_edge*, bool, vec*,
int*, bool)
../../src/trunk/gcc/ipa-inline-transform.c:255
0xd5bef5 inline_small_functions
../../src/trunk/gcc/ipa-inline.c:1613
0xd5bef5 ipa_inline
../../src/trunk/gcc/ipa-inline.c:1794
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

Preprocessed source code attached. Flag -O3 required.

[Bug c/57295] New: target c6x-elf // internal compiler error: in extract_insn, at recog.c:2150

[daniel.calcoen at cern dot ch]

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

Bug ID: 57295
   Summary: target c6x-elf // internal compiler error: in
extract_insn, at recog.c:2150
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.calcoen at cern dot ch

Created attachment 30124
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30124&action=edit
ssp.i

try to build my gcc cross compiler (linux - c6x-elf)
at the 2nd phase of gcc build (after build newlib)

libtool: compile:  /home/dcalcoen/ti/bld/linux/gcc/./gcc/xgcc
-B/home/dcalcoen/ti/bld/linux/gcc/./gcc/
-B/home/dcalcoen/ti/pre/linux/c6x-elf/bin/
-B/home/dcalcoen/ti/pre/linux/c6x-elf/lib/ -isystem
/home/dcalcoen/ti/pre/linux/c6x-elf/include -isystem
/home/dcalcoen/ti/pre/linux/c6x-elf/sys-include -DHAVE_CONFIG_H -I.
-I/home/dcalcoen/gitMirror/gcc/libssp -Wall -g -O2 -save-temps -MT ssp.lo -MD
-MP -MF .deps/ssp.Tpo -c /home/dcalcoen/gitMirror/gcc/libssp/ssp.c -o ssp.o
/home/dcalcoen/gitMirror/gcc/libssp/ssp.c: In function ‘fail.isra.0’:
/home/dcalcoen/gitMirror/gcc/libssp/ssp.c:163:1: error: unrecognizable insn:
 }
 ^
(insn 111 110 112 16 (set (mem/v:SI (reg/f:SI 111) [3 MEM[(volatile int
*)-1B]+0 S4 A32])
(unspec:SI [
(reg:SI 112)
] UNSPEC_MISALIGNED_ACCESS))
/home/dcalcoen/gitMirror/gcc/libssp/ssp.c:156 -1
 (nil))
/home/dcalcoen/gitMirror/gcc/libssp/ssp.c:163:1: internal compiler error: in
extract_insn, at recog.c:2150
0x838c23d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/dcalcoen/gitMirror/gcc/gcc/rtl-error.c:109
0x838c293 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/dcalcoen/gitMirror/gcc/gcc/rtl-error.c:117
0x8364239 extract_insn(rtx_def*)
/home/dcalcoen/gitMirror/gcc/gcc/recog.c:2150
0x826b344 instantiate_virtual_regs_in_insn
/home/dcalcoen/gitMirror/gcc/gcc/function.c:1561
0x826b344 instantiate_virtual_regs
/home/dcalcoen/gitMirror/gcc/gcc/function.c:1928
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [ssp.lo] Error 1
make[2]: Leaving directory `/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libssp'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libssp'
make: *** [all-target-libssp] Error 2

[Bug tree-optimization/57294] [4.9 Regression] ice in remove_described_reference

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.1
   Last reconfirmed||2013-05-15
  Component|c   |tree-optimization
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice in  |[4.9 Regression] ice in
   |remove_described_reference  |remove_described_reference
   Target Milestone|--- |4.9.0
  Known to fail||4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.  Will reduce/bisect today/tomorrow unless some beats me to it.

[Bug fortran/57296] New: Infinite loop in do while when using -O2

[antti.pekka.hynninen at nrel dot gov]

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

Bug ID: 57296
   Summary: Infinite loop in do while when using -O2
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antti.pekka.hynninen at nrel dot gov

Created attachment 30125
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30125&action=edit
Source code that produces the infinite loop

Gfortran produces an infinite "do while" loop for a very simple code:

DO I=1,LENIC
   PREF(I)=PIC(I)
   DO WHILE(PREF(I) < -180.0d0)
  PREF(I)=PREF(I)+360.0d0
   ENDDO
ENDDO

This compiles to something like

L10:
movsd(%rbx,%rdx), %xmm0
ucomisd%xmm0, %xmm1
movsd%xmm0, (%rax,%rdx)
jbeL18
L8:
jmpL8
.align 4
L18:
addq$8, %rdx
cmpq$800, %rdx
jneL10


Note that this only happens when pref is allocated using a subroutine:

  subroutine chmalloc(len, p)
integer len
real(kind=8), allocatable, dimension(:) :: p

allocate(p(len))

return
  end subroutine chmalloc

If I instead use "allocate(pref(lenic))" directly, code works again.

I have added the source code as an attachment, compile with "gfortran -O2
test.f90". My system is Mac OSX 10.6.8.

[Bug lto/57290] [4.9 Regression] After r198333 the aermod runtime is ~10% slower when compiled with -fprotect-parens and -flto

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
There is a lot of noise in these numbers(?) 

Well, AFAICT aermod.f90 has a "non-monotonic" behavior for the different
optimizations: when playing with --param max-inline-insns-auto=xx, the
execution time was not decreasing for increasing xx, but went up or down
depending on which routine was inlined.

> the patch, apart from
>
> +   * passes.c (init_optimization_passes): Schedule a copy-propagation
> +   pass before complete unrolling of inner loops.
>
> should have had no effect on performance (well, in theory, that is).
> Can you check whether reverting the above part changes the results?

Nope

> Also, what's the variance of the numbers? 

Below 0.1s. 

> Are (1) to (4) effectively
> the same performance r198332 vs. r198333?  

Yes for (2) and (4). For (1) and (3), I think the performances are slightly
different. What triggered this PR is (5) (can you reproduce it?) versus (3),
i.e., -fprotect-parens versus -fwhole-program -flto.

> (make sure to disable
> address-space randomization for benchmarking)

I don't really know what you are talking about (I am using Darwin).

Profiling the executable obtained with -fprotect-parens -Ofast -funroll-loops
-ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto gives

- 21.8%, iblval_.lto_priv.516, a.out
- 12.7%, sigz_.lto_priv.419, a.out
- 12.7%, powf$fenv_access_off, libSystem.B.dylib
  12.4%, anyavg_.constprop.50, a.out
- 5.6%, plumef_.lto_priv.580, a.out

and with -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer
-fwhole-program -flto:

- 14.7%, powf$fenv_access_off, libSystem.B.dylib
- 14.5%, iblval_.lto_priv.284, a.out
- 13.8%, sigz_.lto_priv.290, a.out
  13.7%, anyavg_.constprop.50, a.out
- 4.8%, refl_ht_.lto_priv.281, a.out
- 4.7%, rmssig_.lto_priv.298, a.out
  3.1%, _gfortran_compare_string, libgfortran.3.dylib

The subroutine takes ~4.5s for the first set of options and ~2.6s for the
second one.

[Bug fortran/57297] New: FAIL: gfortran.dg/select_type_4.f90 -O2 execution test

[gretay at gcc dot gnu.org]

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

Bug ID: 57297
   Summary: FAIL: gfortran.dg/select_type_4.f90 -O2  execution
test
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gretay at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target: arm-none-eabi

Created attachment 30126
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30126&action=edit
reduced test case

I am not sure whether it's target, fortran, or alias analysis problem (or a
combination).

I am attaching a reduced testcase. It allocates a list with three nodes,
traverses it counting the number of nodes, and then deallocates it. The problem
arises from the middle node that has no data (similar to the original test).
The failure manifests itself by finding only one node in the list, instead of
three. 

$ /work/builds/fortran/install/bin/arm-none-eabi-gfortran
reduced_select_type_4.f90 -O2 -o bad.exe

$ qemu-arm bad.exe
   1
 Done counting

The original test fails on qemu arm-none-eabi using a recent trunk compiler,
and it has been failing on trunk since at least September 2012 (and probably
long ago). 
The reduced testcase fails in arm mode, but not in thumb mode. 
It does not fail when compiled with -fno-strict-aliasing. 
It also does not fail when compiled with -fno-schedule-insns
-fno-schedule-insns2. 
It does not fail when inlining is disabled.

$ /work/builds/fortran/install/bin/arm-none-eabi-gfortran
reduced_select_type_4.f90 -O2 -o good.exe -fno-strict-aliasing
greyor01@e103227-lin:/work/tmp/sel/sept$ qemu-arm good.exe
   1
   2
   3
 Done counting

The problem seems to be incorrect aliasing information that gets used by
instruction reordering.
It results in the following code slice (bad):
addr3, sp, #8  @ 94*arm_addsi3/2[length = 4]
ldmiar3, {r0, r1}@ 104*ldm2_ia[length = 4]
strr6, [sp, #8]@ 99*arm_movsi_vfp/6[length = 4]
strr5, [sp, #12]@ 101*arm_movsi_vfp/6[length = 4]
stmiar4, {r0, r1}@ 105*stm2_ia[length = 4]
instead of (good):
addr3, sp, #8  @ 94*arm_addsi3/2[length = 4] 
strr6, [sp, #8]@ 99*arm_movsi_vfp/6[length = 4]
strr5, [sp, #12]@ 101*arm_movsi_vfp/6[length = 4]
ldmiar3, {r0, r1}@ 104*ldm2_ia[length = 4]
stmiar4, {r0, r1}@ 105*stm2_ia[length = 4]

The problem is that the load is moved before stores to the same address.
This happens in MAIN, in the code of append that is inlined in MAIN to append
the second node to the list.
The fact that the second node has a different type (base node, not integer
node) may be playing a role here.

Gimple for this code is (block 11):
  MEM[(struct __class_poly_list_Node_type_p *)&node] = node_17;
  MEM[(struct __class_poly_list_Node_type_p *)&node + 4B] =
&__vtab_poly_list_Node_type;
  MEM[(struct node_type *)integer_node_4].next = VIEW_CONVERT_EXPR(MEM[(struct __class_poly_list_Node_type
&)&node]);

The stores (rtl insns 99, 101) come from the first two GIMPLE statement, and
the load (insn 104) comes from accessing rhs of the third statement. 
Note that the third statement is an object assignment via movmemqi expand
pattern calling arm_gen_movmemqi function in arm.c. (Could be a target problem
if the alias sets are not handled correctly here, but it seems that they copied
as is from Gimple).

In the RTL right after expand, the relevant memory accesses are annotated as
follows:

(insn 99)   [3 MEM[(struct __class_poly_list_Node_type_p *)&node]+0 S4 A64]
(insn 104)  [8 MEM[(struct __class_poly_list_Node_type &)&node]+0 S4 A64]

This is not recognized as aliasing and no dependence edge is created by the
scheduler. 

In comparison, gimple for block 7 (appending the first node in the list, of
type integer) is handled correctly.

  MEM[(struct __class_poly_list_Node_type *)&class.1] = integer_node_4;
  MEM[(struct __class_poly_list_Node_type *)&class.1 + 4B] =
&__vtab_main_Integer_node_type;
  _63->next = VIEW_CONVERT_EXPR(class.1);

And the alias sets are: 
(insn 48)   [8 MEM[(struct __class_poly_list_Node_type *)&class.1]
(insn 54)   [8 class.1+0 S4 A64]

and the scheduler knows about the dependency.

It doesn't seem to be target-related, because the mem annotation is exactly the
same as in gimple, but I don't see this test failing on other targets. The
difference may be that other targets use generic move_mem_by_pieces while arm
has expand for movmemqi.

The complete RTL after expand for block 11 is:

;; MEM[(struct __class_poly_list_Node_type_p *)&node] = node_17;

(insn 99 98 0 (set (mem/f/c:SI (plus:SI (reg/f:SI 105 virtual-stack-vars)
(const_int -376 [0xfe88])) [3 MEM[(struc

[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi

[woodard at redhat dot com]

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

--- Comment #4 from Ben Woodard  ---
Created attachment 30127
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30127&action=edit
Patch from Ariel that prevents the segv

[Bug libgomp/57298] New: GOMP_CPU_AFFINITY will not work when system has >1024 cores

[sp at numascale dot com]

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

Bug ID: 57298
   Summary: GOMP_CPU_AFFINITY will not work when system has >1024
cores
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sp at numascale dot com
CC: jakub at gcc dot gnu.org

Using GOMP_CPU_AFFINITY to set processor affinity on OpenMP threads will not
work if the system has more than 1024 threads.

[root@numa-0 Stream]# OMP_NUM_THREADS=4 GOMP_CPU_AFFINITY=0-3 ./stream.small.x
libgomp: could not get CPU affinity set 


Output from "lscpu" :

[root@numa-0 ~]# lscpu
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):1272
On-line CPU(s) list:   0-1271
Thread(s) per core:1
Core(s) per socket:6
Socket(s): 212
NUMA node(s):  212
Vendor ID: AuthenticAMD
CPU family:16
Model: 9
Stepping:  1
CPU MHz:   2199.900
BogoMIPS:  4406.00
Virtualization:AMD-V
L1d cache: 64K
L1i cache: 64K
L2 cache:  512K
L3 cache:  5118K


The issue is that cpu_set_t as defined in /usr/include/sched.h only has room
for 1024 entries when statically allocated. However, libc has support for
allocating dynamic sizes which allows for more than 1024 by using the
CPU_ALLOC() and CPU_FREE() macros.

These files :

libgomp/config/linux/affinity.c
libgomp/config/linux/proc.c
libgomp/config/linux/proc.h

needs to be modified to support systems with > 1024 cores.

[Bug libgomp/57298] GOMP_CPU_AFFINITY will not work when system has >1024 cores

[sp at numascale dot com]

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

--- Comment #1 from Steffen Persvold  ---
Created attachment 30128
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30128&action=edit
Proposed patch to fix >1024 processor system support

This patch modifies

libgomp/config/linux/affinity.c
libgomp/config/linux/proc.c
libgomp/config/linux/proc.h

to use dynamically allocated (and freed) cpu sets to support affinity on
systems with >1024 processors.

[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi

[woodard at redhat dot com]

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

--- Comment #5 from Ben Woodard  ---
Ariel,

In talking to the engineers regarding this, they would like _builtin_expect
hints to tell the compiler to generate code saying that hitting this is
unlikely. 

http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html

[Bug target/57295] target c6x-elf // internal compiler error: in extract_insn, at recog.c:2150

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Severity|blocker |normal

[Bug inline-asm/57299] New: Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[umbricola at gmail dot com]

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

Bug ID: 57299
   Summary: Inline assembly memory dependencies produce spurious
loads, register pressure, compilation failures
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: umbricola at gmail dot com

Consider this function with an inline assembly statement that takes two pointer
inputs in named registers and declares that it reads and writes the memory they
point to.

void f(char *x, char *y) {
  register char *p asm("edi") = x;
  register char *q asm("esi") = y;
  asm(""
  : "=m" (*x), "=m" (*y)
  : "r" (p), "r" (q), "m" (*x), "m" (*y));
}

This function should compile cleanly, and the disassembly should have only the
two instructions to load edi and esi from the stacked function arguments,
preceded by the prologue of f() and followed by the epilogue of f().

In fact this function is rejected by gcc -m32 -fPIC -c -o f.o f.c:

f.c: In function ‘f’:
f.c:4:3: error: ‘asm’ operand has impossible constraints
   asm(""
   ^

This error is wrong.  I am using only two named registers, neither of which is
ebx (which is reserved for the implementation of PIC).  There are three
general-purpose registers left, not to mention that loading edi and esi from
the stack shouldn't need any scratch registers anyway.

More strangely, removing any one or more of the four memory inputs and outputs
causes the function to compile successfully.  Memory dependencies should not
have any effect on register bindings entering and leaving the inline assembly
statement, only on optimizations in surrounding code.  Removing the -fPIC
option (which frees ebx) also makes the function compile.

If I remove one of the memory dependencies and disassemble the generated object
code, I see the two expected loads to edi and esi from the stack followed by
three unexpected loads to eax, ecx, and edx from the stack.  If I leave all the
memory dependencies and remove -fPIC instead, then all four of eax, ebx, ecx,
and edx get loaded after the asm statement.

It appears that gcc can convert memory dependencies of inline assembly
statements into useless loads into unrelated general-purpose registers.  This
action is always inefficient and sometimes spuriously exhausts the
general-purpose registers, causing valid code to be rejected.

I am running a 64-bit gcc 4.8.0 that I compiled from sources.  gcc -v says:

Using built-in specs.
COLLECT_GCC=/home/cmihelic/gcc-4.8.0/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/cmihelic/gcc-4.8.0/install/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/cmihelic/gcc-4.8.0/install
Thread model: posix
gcc version 4.8.0 (GCC) 

On a different Linux machine I have also tried several 64-bit gcc installations
I did not compile myself: versions 4.7.2, 4.5.0, 4.4.5, 4.4.3, 4.1.2, and
3.3.1.  They fail similarly, although the error message used to be

f.c:4: error: can't find a register in class `GENERAL_REGS' while reloading
`asm'

Thus this behavior is at least ten years old.

[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|blocker |normal

[Bug inline-asm/57299] Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think you are wrong in how many registers that inline-asm uses.  It uses 4
registers, two each to hold y and x which have to be loaded into a register
from the stack.

[Bug fortran/57296] Infinite loop in do while when using -O2

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Works for me on x86_64-apple-darwin10 (OSX 10.6.8) for both 4.8.0 and trunk.
Where did you get your gfortran? Does -fno-aggressive-loop-optimizations help?

[Bug inline-asm/57299] Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[umbricola at gmail dot com]

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

--- Comment #2 from Chris Mihelich  ---
The asm statement uses only two registers.  Of the six inputs and outputs, only
"r" (p) and "r" (q) are registers; the four "=m" and "m" entries only declare
that memory is read or written in the assembly code.  See the part of
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html about memory operands
(search for "If your assembler instructions access memory").

[Bug inline-asm/57299] Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Chris Mihelich from comment #2)
> The asm statement uses only two registers.  Of the six inputs and outputs,
> only "r" (p) and "r" (q) are registers; the four "=m" and "m" entries only
> declare that memory is read or written in the assembly code.  See the part
> of http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html about memory operands
> (search for "If your assembler instructions access memory").

Since the value of y and x are stored on the stack as they are arguments to the
function, their values need to be loaded into a regsiter first before passing
it on to the inline-asm.

[Bug fortran/57297] FAIL: gfortran.dg/select_type_4.f90 -O2 execution test

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin  ---
Thanks for the detailed bug report. It's very informative (even if I don't
understand everything ;-) ).
Here is a "shot in the dark" patch (on the fortran side); does it work for you?

Index: class.c
===
--- class.c(révision 198085)
+++ class.c(copie de travail)
@@ -581,10 +581,14 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
 sprintf (name, "__class_%s_%d_%da", tname, rank, (*as)->corank);
   else if ((*as) && attr->pointer)
 sprintf (name, "__class_%s_%d_%dp", tname, rank, (*as)->corank);
+  else if ((*as) && attr->target)
+sprintf (name, "__class_%s_%d_%dt", tname, rank, (*as)->corank);
   else if ((*as))
 sprintf (name, "__class_%s_%d_%d", tname, rank, (*as)->corank);
   else if (attr->pointer)
 sprintf (name, "__class_%s_p", tname);
+  else if (attr->target)
+sprintf (name, "__class_%s_t", tname);
   else if (attr->allocatable)
 sprintf (name, "__class_%s_a", tname);
   else
@@ -628,6 +632,7 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
   c->attr.class_pointer = attr->pointer;
   c->attr.pointer = attr->pointer || (attr->dummy && !attr->allocatable)
 || attr->select_type_temporary;
+  c->attr.target = attr->target;
   c->attr.allocatable = attr->allocatable;
   c->attr.dimension = attr->dimension;
   c->attr.codimension = attr->codimension;

[Bug fortran/57296] Infinite loop in do while when using -O2

[antti.pekka.hynninen at nrel dot gov]

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

--- Comment #2 from Antti-Pekka Hynninen  
---
(In reply to Dominique d'Humieres from comment #1)
> Works for me on x86_64-apple-darwin10 (OSX 10.6.8) for both 4.8.0 and trunk.
> Where did you get your gfortran? Does -fno-aggressive-loop-optimizations
> help?

Thanks for checking!

I believe I got it from "http://hpc.sourceforge.net/";. The full version is:
GNU Fortran (GCC) 4.8.0 20120603 (experimental)

My version of gfortran does not have that option.

I'll try to compile gfortran from the source and see if the bug goes away.

[Bug inline-asm/57299] Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[umbricola at gmail dot com]

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

--- Comment #4 from Chris Mihelich  ---
Yes indeed, x is loaded from the stack into edi, and y is loaded from the stack
into esi, as the register variable declarations specified.  That's two
registers.  Where are the other two?

[Bug inline-asm/57299] Inline assembly memory dependencies produce spurious loads, register pressure, compilation failures

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Chris Mihelich from comment #4)
> Yes indeed, x is loaded from the stack into edi, and y is loaded from the
> stack into esi, as the register variable declarations specified.  That's two
> registers.  Where are the other two?

Simple, "m"(*x) cannot use either edi or esi.  Likewise for "m"(*y).  You can
change the *y to *q and *x to *p, it will work.