[Bug libstdc++/57421] Error when linking static libstc++ due to missing future classes

[juergen.reuter at desy dot de]

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

--- Comment #10 from Jürgen Reuter  ---
After I completely recompiled the trunk version (r199585) the problem is gone.
So most probably it resulted from an incomplete update and recompilation of the
code,
or was in an intermediate step of the development, which seems to be gone by
now.

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 11 06:03:46 2013
New Revision: 199934

URL: http://gcc.gnu.org/viewcvs?rev=199934&root=gcc&view=rev
Log:
PR target/56564
* varasm.c (get_variable_align): Move #endif to the right place.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/varasm.c

[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Self contained reduced test

module m_xfunit_assertion_character
  implicit none
  private
  public t_string, character, t_xfunit_assertion, t_xfunit_assertion_character

  type t_string
private
character, dimension(:), allocatable :: string  ! String buffer
integer  :: length = 0  ! String length
integer  :: size   = 0  ! Total buffer size
  end type t_string

  type, abstract :: t_xfunit_assertion
  end type t_xfunit_assertion

  type, extends(t_xfunit_assertion) :: t_xfunit_assertion_character
private
contains
  procedure :: get_expected
  end type t_xfunit_assertion_character

  interface character
module procedure string_to_char
  end interface character

contains

elemental function string_to_char( s ) result(res)
  type(t_string),intent(in) :: s
  character(len=size(s%string)) :: res
end function string_to_char

pure function get_expected( ast ) result(res)
  class(t_xfunit_assertion_character), intent(in) :: ast
  type(t_string) :: res
end function get_expected

end module m_xfunit_assertion_character

module m_xfunit_assertion_array_character
  use m_xfunit_assertion_character
  implicit none
  private
  public t_xfunit_assertion_array_character

  type, extends(t_xfunit_assertion) :: t_xfunit_assertion_array_character
private
  type(t_xfunit_assertion_character), dimension(:), allocatable :: rast
contains
  procedure :: get_expected
  end type t_xfunit_assertion_array_character

contains

pure function get_expected( ast ) result(res)
  class(t_xfunit_assertion_array_character), intent(in) :: ast
  character, dimension(size(ast%rast)) :: res
  integer :: i
  res = (/ (character(ast%rast(i)%get_expected()), i=1, size(ast%rast)) /)
end function get_expected

end module m_xfunit_assertion_array_character

[Bug c++/57581] abi_tag vs. demangler

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Try using a newer demangler.

$ ./cxxfilt
_ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_
std::set, std::allocator
>::erase[abi:cxx11](std::_Rb_tree_const_iterator,
std::_Rb_tree_const_iterator)

[Bug c++/57581] New: abi_tag vs. demangler

[bkoz at gcc dot gnu.org]

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

Bug ID: 57581
   Summary: abi_tag vs. demangler
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bkoz at gcc dot gnu.org

Some member functions in libstdc++ have been decorated with the "abi_tag"
attribute.

Any abi_tag attribution renders these names unable to be demangled.

For instance:

  iterator
  erase(const_iterator __first, const_iterator __last)
  { return _M_t.erase(__first, __last); }

For set turns from:
_ZNSt3setIiSt4lessIiESaIiEE5eraseESt23_Rb_tree_const_iteratorIiES5_

into:
 _ZNSt3setIiSt4lessIiESaIiEE5eraseB5cxx11ESt23_Rb_tree_const_iteratorIiES5_


The first can be de-mangled into:
std::set, std::allocator
>::erase(std::_Rb_tree_const_iterator, std::_Rb_tree_const_iterator)

The second, not so much.

[Bug debug/37132] Debug: No DW_TAG_namelist emitted for NAMELISTS

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
New draft patch: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00534.html

[Bug tree-optimization/57579] Problem with vectorization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|federico.carminati at cern dot ch  |
  Component|c++ |tree-optimization

--- Comment #1 from Paolo Carlini  ---
In any case, doesn't look like a C++ front end issue

[Bug regression/57551] [4.9 Regression]: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|jason at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #5 from Jason Merrill  ---
Reassigning since Honza has been working on this.

[Bug preprocessor/57580] New: Repeated _Pragma message directives in macro causes problems

[drussel at gmail dot com]

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

Bug ID: 57580
   Summary: Repeated _Pragma message directives in macro causes
problems
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drussel at gmail dot com

Input:
#define BROKEN\
  _Pragma("message(\"message0\")")   \
  _Pragma("message(\"message1\")")

BROKEN


Output:
gcc -c test.cpp
test.cpp:5:2: error: stray ‘#’ in program
test.cpp:5:27: note: #pragma message: message0
test.cpp:5:3: error: ‘pragma’ does not name a type

gcc 4.6.3 and clang are both happy with the code.

[Bug c++/57575] lvalue function accepted as an rvalue

[anass.lasram at gmail dot com]

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

Anass Lasram  changed:

   What|Removed |Added

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

--- Comment #2 from Anass Lasram  ---
(In reply to Daniel Krügler from comment #1)
> Your assumptions are mistaken. In C++ it is valid to bind a function value
> to an rvalue reference of that function type. It is only so, that binding to
> an lvalue reference is preferred.
> 
> In other words, the following is valid as well:
> 
> float f() { return 0.f; }
> float (&&r)(void) = f;
> 
> See for example [over.ics.ref] p3 (emphasis mine):
> 
> "Except for an implicit object parameter, for which see 13.3.1, a standard
> conversion sequence cannot be formed if it requires [..] binding an rvalue
> reference to an lvalue **other than a function lvalue**."


Thanks Daniel for the rectification.

[Bug target/57379] [4.9 Regression]: Segfault in invalidate_any_buried_refs (x=0x0) at ../../gcc-svn/trunk/gcc/gcse.c:3850

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|4.9.0   |4.7.4

--- Comment #2 from Uroš Bizjak  ---
Fixed in mainline and backported to 4.8.1 and 4.7.4 branches.

[Bug c++/57579] New: Problem with vectorization

[federico.carminati at cern dot ch]

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

Bug ID: 57579
   Summary: Problem with vectorization
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.carminati at cern dot ch

Good evening,
   all my apologises if this is a stupid question, however I have a terribly
simple loop


include 

typedef struct
{
   double x,y,z;
   double dummy;
} P;


void foo(const P * __restrict__ points, double * __restrict__ d)
{
   for(int i=0;i<100;++i) {
  d[i]=points[i].x*points[i].x*points[i].x*points[i].x+
 points[i].y*points[i].y*points[i].y+
 points[i].z*points[i].z*points[i].z;
   }
}

if I compile with

/opt/gcc-4.8.1/bin/g++ -c -std=c++0x -O3 -msse4.1 -Wall -Wstrict-aliasing=2
-ftree-vectorizer-verbose=2

I obtain the diagnostic at the bottom of the page. Is there a place where I can
find an explanation for the g++ vectorizer diagnostic messages? I frankly do
not understand what it is talking about and google does not seem to be willing
to help me this time. Any help in deciphering these messages would be greatly
appreciated. Thanks and sorry for the bother

Analyzing loop at testvec1.cxx:12

testvec1.cxx:12: note: Data access with gaps requires scalar epilogue loop
testvec1.cxx:12: note: vector alignment may not be reachable
testvec1.cxx:12: note: virtual phi. skip.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: not ssa-name.
testvec1.cxx:12: note: use not simple.
testvec1.cxx:12: note: no array mode for V2DF[4]

Vectorizing loop at testvec1.cxx:12

testvec1.cxx:12: note: virtual phi. skip.
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:12: note: no array mode for V2DF[4]
testvec1.cxx:10: note: vectorized 1 loops in function.

testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.

testvec1.cxx:13: note: not vectorized: no vectype for stmt: vect_var_.10_29 =
MEM[(const struct P *)vect_ppoints.6_31];
 scalar_type: const vector(2) double
testvec1.cxx:13: note: Failed to SLP the basic block.
testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
basic block.

testvec1.cxx:13: note: Build SLP failed: grouped loads have gaps _59 = _60->x;

testvec1.cxx:13: note: Failed to SLP the basic block.
testvec1.cxx:13: note: not vectorized: failed to find SLP opportunities in
basic block.

testvec1.cxx:10: note: not vectorized: not enough data-refs in basic block.

[Bug debug/48163] [4.7 Regression]: ICEs for cris-elf, like gcc.c-torture/compile/calls.c gcc.c-torture/execute/complex-1.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
vt_add_function_parameter needs to be adjusted after the assign_parms change:

  if (!vt_get_decl_and_offset (incoming, &decl, &offset))
{
  if (REG_P (incoming) || MEM_P (incoming))
{
  /* This means argument is passed by invisible reference.  */
  offset = 0;
  decl = parm;
  incoming = gen_rtx_MEM (GET_MODE (decl_rtl), incoming);
}
  else
{
  if (!vt_get_decl_and_offset (decl_rtl, &decl, &offset))
return;
  offset += byte_lowpart_offset (GET_MODE (incoming),
 GET_MODE (decl_rtl));
}
}

This generates MEM of MEM incoming locations.

[Bug tree-optimization/57539] [4.9 Regression] ice in ipa_edge_duplication_hook

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Created attachment 30286
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30286&action=edit
Proposed fix

I'm currently bootstrapping and testing this patch to fix the issue.  I'll give
one more thought to creating a testcase for the testsuite but constructing one
is not entirely trivial.

[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler

[prop_design at yahoo dot com]

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

--- Comment #13 from Anthony Falzone  ---
My previous post needs a correction.  Comparing gfortran O3 to Intel Fortran O3
I see a 60% speed improvement in favor of the Intel Fortran compiler.  There is
a 40% improvement over past releases of PROP_DESIGN, which used gfortran Ofast.
 There is not much difference between Intel Fortran O3 and Ofast, so I am using
O3 to ensure accurate calculations.

[Bug fortran/47680] [OOP] ICE with polymorphic array elements as dummy

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #4)
> Per comment #3, this PR should probably be closed.

Let's do it then.

[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 199873.

[Bug fortran/49397] [F03] ICE with proc pointer assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Still present at revision 199873.

[Bug fortran/48939] ICE in code involving procedure pointers

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Dominique d'Humieres  ---
Works for me with revisions 4.6.4, 4.7.3, 4.8.1, and trunk. Closing as fixed.

[Bug fortran/47680] [OOP] ICE with polymorphic array elements as dummy

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Per comment #3, this PR should probably be closed.

[Bug target/57578] New: SPE detection broken on Linux (bits/predefs.h: No such file or directory)

[stigge at antcom dot de]

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

Bug ID: 57578
   Summary: SPE detection broken on Linux (bits/predefs.h: No such
file or directory)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stigge at antcom dot de

SPE detection broken on Linux (bits/predefs.h: No such file or directory)

The build of powerpc spe on Linux aborts like this:

[...]
/«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/bin/
-B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/include -isystem
/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/sys-include-g -O2 -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC
-mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I.
-I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/.
-I../../../src/libgcc/../gcc -I../../../src/libgcc/../include
-I../../../src/libgcc/../libdecnumber/dpd -I../../../src/libgcc/../libdecnumber
-DHAVE_CC_TLS  -o _gcov_merge_single.o -MT _gcov_merge_single.o -MD -MP -MF
_gcov_merge_single.dep -DL_gcov_merge_single -c ../../../src/libgcc/libgcov.c
In file included from /usr/include/stdio.h:28:0,
 from ../../../src/libgcc/../gcc/tsystem.h:87,
 from ../../../src/libgcc/libgcov.c:27:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or
directory
 #include 
  ^
compilation terminated.
[...]

Turns out that the detection of the SPE case is done via
rs6000/e500-double.h in $(tm_file_list), but e500-double.h was removed
recently, and hence not added anymore to $(tm_file_list). However, in
the SPE (i.e. e500v2) case, with_cpu is set exactly to 8548 in
config.gcc.

I solved this in gcc/config/rs6000/t-linux by replacing the line

MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h,
$(tm_file_list)),,v1)

with

MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
8548,$(with_cpu)),,v1)

Thanks!

[Bug c++/52440] [C++11] Wrong template argument deduction/substitution failures

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.3, 4.8.0, 4.9.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.3

--- Comment #2 from Paolo Carlini  ---
Done.

[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|SUSPENDED
 Resolution|INVALID |---

--- Comment #6 from Jason Merrill  ---
(In reply to Jason Merrill from comment #5)
> DR 62 clarified that G++ is correct here.
> 
> http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#62

Actually, it didn't really; this case is still unclear in the new wording for
DR 62.

[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jason Merrill  ---
DR 62 clarified that G++ is correct here.

http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#62

[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jun 10 15:41:52 2013
New Revision: 199898

URL: http://gcc.gnu.org/viewcvs?rev=199898&root=gcc&view=rev
Log:
PR target/56564
* varasm.c (align_variable): Don't use DATA_ALIGNMENT or
CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl).
Use DATA_ABI_ALIGNMENT for that case instead if defined.
(get_variable_align): New function.
(get_variable_section, emit_bss, emit_common,
assemble_variable_contents, place_block_symbol): Use
get_variable_align instead of DECL_ALIGN.
(assemble_noswitch_variable): Add align argument, use it
instead of DECL_ALIGN.
(assemble_variable): Adjust caller.  Use get_variable_align
instead of DECL_ALIGN.
* config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment
caller.
(DATA_ABI_ALIGNMENT): Define.
* config/i386/i386-protos.h (x86_data_alignment): Adjust prototype.
* config/i386/i386.c (x86_data_alignment): Add opt argument.  If
opt is false, only return the psABI mandated alignment increase.
* config/c6x/c6x.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.c (mmix_data_alignment): Adjust function comment.
* config/s390/s390.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document.
* doc/tm.texi: Regenerated.

* gcc.target/i386/pr56564-1.c: New test.
* gcc.target/i386/pr56564-2.c: New test.
* gcc.target/i386/pr56564-3.c: New test.
* gcc.target/i386/pr56564-4.c: New test.
* gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/vect-sizes-1.c: Likewise.
* gcc.target/i386/memcpy-1.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr56564-1.c
trunk/gcc/testsuite/gcc.target/i386/pr56564-2.c
trunk/gcc/testsuite/gcc.target/i386/pr56564-3.c
trunk/gcc/testsuite/gcc.target/i386/pr56564-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/c6x/c6x.h
trunk/gcc/config/i386/i386-protos.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/mmix/mmix.c
trunk/gcc/config/mmix/mmix.h
trunk/gcc/config/s390/s390.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-4.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-1.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-3.c
trunk/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-4.c
trunk/gcc/testsuite/gcc.target/i386/memcpy-1.c
trunk/gcc/testsuite/gcc.target/i386/vect-sizes-1.c
trunk/gcc/varasm.c

[Bug c++/52440] [C++11] Wrong template argument deduction/substitution failures

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
Fixed in 4.7.3. I'm adding the testcase and closing the bug.

[Bug c++/52371] [C++11] ICE in noexcept with constexpr conversion function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Paolo Carlini  ---
Dup.

*** This bug has been marked as a duplicate of bug 54207 ***

[Bug c++/54207] [4.7 Regression][C++0x] ICE in build_noexcept_spec when bool is #defined/typedef'd

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||ai.azuma at gmail dot com

--- Comment #9 from Paolo Carlini  ---
*** Bug 52371 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/57569] [4.8/4.9 Regression] wrong code for struct copy at -O3 on x86_64-linux

[matz at gcc dot gnu.org]

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

--- Comment #2 from Michael Matz  ---
My guess is that it's again somewhere using the wrong predicate
to test directed rw/wr/ww dependencies.

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

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

--- Comment #9 from Anna  ---
Issue that is very alike to issue mentioned in Comment 7:

int A[10];

int main () {
  int a;
  a = __sec_reduce (1);
}

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:6:1: internal compiler error: tree check: accessed operand 6 of call_expr
with 4 operands in fix_builtin_array_notation_fn, at c/c-array-notation.c:145
 }
 ^
0xaf30d7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
/home/anna/trunk/gcc/tree.c:9258
0x531b89 tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/anna/trunk/gcc/tree.h:4125
0x54a9e7 fix_builtin_array_notation_fn
/home/anna/trunk/gcc/c/c-array-notation.c:145
0x5511ec build_array_notation_expr(unsigned int, tree_node*, tree_node*,
tree_code, unsigned int, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:731
0x555218 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2311
0x554e50 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2299
0x543d43 c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4098
0x544bfa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x5499db c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x54a446 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x54a446 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
0x59c024 c_common_parse_file()
/home/anna/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

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

--- Comment #8 from Anna  ---
Thing from Comment 1 is still reproducible with this case:
int A[10];

int main () {
  int a;
  a = __sec_reduce_add (1);
}

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:5:5: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:2042
   a = __sec_reduce_add (1);
 ^
0x78b57b gimplify_var_or_parm_decl
/home/anna/trunk/gcc/gimplify.c:2042
0x78d24b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7565
0x798883 gimplify_modify_expr
/home/anna/trunk/gcc/gimplify.c:4851
0x78d213 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7160
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x78cafb gimplify_statement_list
/home/anna/trunk/gcc/gimplify.c:1521
0x78cafb gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
/home/anna/trunk/gcc/gimplify.c:7549
0x790836 gimplify_stmt(tree_node**, gimple_statement_d**)
/home/anna/trunk/gcc/gimplify.c:5692
0x791ec1 gimplify_body(tree_node*, bool)
/home/anna/trunk/gcc/gimplify.c:8193
0x792376 gimplify_function_tree(tree_node*)
/home/anna/trunk/gcc/gimplify.c:8325
0x62951f analyze_function
/home/anna/trunk/gcc/cgraphunit.c:629
0x62c514 analyze_functions
/home/anna/trunk/gcc/cgraphunit.c:913
0x62d9c5 finalize_compilation_unit()
/home/anna/trunk/gcc/cgraphunit.c:2097
0x50a333 c_write_global_declarations()
/home/anna/trunk/gcc/c/c-decl.c:10118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

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

--- Comment #7 from Anna  ---
(In reply to Anna from comment #6)
> Created attachment 30285 [details]
> Another test case reproducing the original thing

And another issue in slightly changed test case from this attachment:
int A[10];

int main () {
  int a;
  a = __sec_reduce_add ();
}

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:6:1: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in fix_builtin_array_notation_fn, at c/c-array-notation.c:158
 }
 ^
0xaf30d7 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
/home/anna/trunk/gcc/tree.c:9258
0x54a7e6 tree_operand_check
/home/anna/trunk/gcc/tree.h:4125
0x54a7e6 fix_builtin_array_notation_fn
/home/anna/trunk/gcc/c/c-array-notation.c:158
0x5511ec build_array_notation_expr(unsigned int, tree_node*, tree_node*,
tree_code, unsigned int, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:731
0x555218 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2311
0x554e50 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2299
0x543d43 c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4098
0x544bfa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x5499db c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x54a446 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x54a446 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
0x59c024 c_common_parse_file()
/home/anna/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler used to get Comment-5, Comment-6 and this issue is:
Target: x86_64-unknown-linux-gnu
Configured with: /home/anna/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 4.9.0 20130608 (experimental) (GCC)

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

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

--- Comment #6 from Anna  ---
Created attachment 30285
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30285&action=edit
Another test case reproducing the original thing

[Bug middle-end/57541] [Cilkplus]: internal compiler error: in gimplify_expr, at gimplify.c:7809

[anna.m.tikhonova at gmail dot com]

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

--- Comment #5 from Anna  ---
(In reply to Balaji V. Iyer from comment #4)
> Hello,
> This issue should be fixed in trunk revision 199837. Please let me know
> otherwise.
> 
> Thanks,
> 
> Balaji V. Iyer.

Hi Balaji,
I still can reproduce segfault mentioned in Comment 2.

[Bug middle-end/57577] internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123

[anna.m.tikhonova at gmail dot com]

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

--- Comment #1 from Anna  ---
Also, when I change "A[:] = foo (B[:][:]);" to "A[0] = foo (B[:][:]);"
compilation hangs.

[Bug middle-end/57577] New: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in tree_operand_check, at tree.h:4123

[anna.m.tikhonova at gmail dot com]

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

Bug ID: 57577
   Summary: internal compiler error: tree check: expected class
'expression', have 'constant' (integer_cst) in
tree_operand_check, at tree.h:4123
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anna.m.tikhonova at gmail dot com

Created attachment 30284
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30284&action=edit
Reproducer

Hi,
attached test case fails with ICE:

$ gcc -fcilkplus 1.c
1.c: In function 'main':
1.c:7:1: internal compiler error: tree check: expected class 'expression', have
'constant' (integer_cst) in tree_operand_check, at tree.h:4123
 }
 ^
0xae7d99 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/anna/trunk/gcc/tree.c:9110
0x4c3cef expr_check
/home/anna/trunk/gcc/tree.h:3859
0x4c3cef tree_operand_check
/home/anna/trunk/gcc/tree.h:4123
0x531755 tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/anna/trunk/gcc/tree.h:4111
0x55255d build_array_notation_expr(unsigned int, tree_node*, tree_node*,
tree_code, unsigned int, tree_node*, tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:1264
0x555cf8 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2777
0x555b90 expand_array_notation_exprs(tree_node*)
/home/anna/trunk/gcc/c/c-array-notation.c:2765
0x5438f3 c_parser_compound_statement
/home/anna/trunk/gcc/c/c-parser.c:4098
0x5447aa c_parser_declaration_or_fndef
/home/anna/trunk/gcc/c/c-parser.c:1758
0x54958b c_parser_external_declaration
/home/anna/trunk/gcc/c/c-parser.c:1363
0x549ff6 c_parser_translation_unit
/home/anna/trunk/gcc/c/c-parser.c:1251
0x549ff6 c_parse_file()
/home/anna/trunk/gcc/c/c-parser.c:11000
0x59c954 c_common_parse_file()
/home/anna/trunk/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler used is:
Target: x86_64-unknown-linux-gnu
Configured with: /home/anna/trunk/configure --with-arch=corei7
--with-cpu=corei7 --enable-clocale=gnu --with-system-zlib --enable-shared
--with-demangler-in-ld --enable-cloog-backend=isl --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 4.9.0 20130608 (experimental) (GCC)

[Bug c++/57524] internal compiler error on dump translation unit

[JamesMikeDuPont at googlemail dot com]

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

--- Comment #10 from James Michael DuPont  ---
I have reported the problem in the code to boost, they have fixed it.
https://svn.boost.org/trac/boost/ticket/8651#comment:1

The problem is having to do with underspecifed namespace selection. They
changed the code to remove the crash.

mike

[Bug other/57482] [4.7.3][AVR] --help=optimizers reports a wrong list

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Christophe from comment #3)
> Reading target.def is really instructive, but I still do not understand
> (yet) how the optimizations list is built, and how options are
> overwritten... All this is very confusing.

How options are set is a bit of a mess. For fshort-enums, there is the main
definition in the c.opt file, there is the dummy value that denotes
uninitialized in ./opts.c, and toplev.c that calls the target hook if
short_enums is uninitialized. The options help list is built before calling the
target hook, so it probably uses "2" and understands that as "enabled". The way
to fix this is to call process_options before print_specific_help (In fact,
print_specific_help is called too early, --help=optimizers ignores everything
that appears after it in the command-line).

Ideally, the fact that fshort-enums requires a target hook to set its value if
uninitialized should be encoded in the .opt files. And it should not use a
magic uninitialized value "2", but opts_set to test whether the solution was
set.

[Bug c++/57575] lvalue function accepted as an rvalue

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Your assumptions are mistaken. In C++ it is valid to bind a function value to
an rvalue reference of that function type. It is only so, that binding to an
lvalue reference is preferred.

In other words, the following is valid as well:

float f() { return 0.f; }
float (&&r)(void) = f;

See for example [over.ics.ref] p3 (emphasis mine):

"Except for an implicit object parameter, for which see 13.3.1, a standard
conversion sequence cannot be formed if it requires [..] binding an rvalue
reference to an lvalue **other than a function lvalue**."

[Bug c++/57576] Using declaration hides template for purposes of explicit instantiation

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Ah!

[Bug c++/57576] New: Using declaration hides template for purposes of explicit instantiation

[redi at gcc dot gnu.org]

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

Bug ID: 57576
   Summary: Using declaration hides template for purposes of
explicit instantiation
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

The following is incorrectly rejected by all active releases:

namespace std
{
  template
void remove(T, U)
{ }
}

int remove(char);

namespace std
{
  using ::remove;
}

namespace std
{
  template void remove(int, long);
}


r.cc:17:33: error: ‘void std::remove(int, long int)’ is not declared in ‘std’

Reversing the order of the two declarations of std::remove makes it compile. 
Using remove<> for the explicit instantiation makes it compile.

This causes
libstdc++-v3/testsuite/25_algorithms/remove/requirements/explicit_instantiation/2.cc
to fail in C++11 mode.

[Bug target/56987] gcc/config/avr/avr.opt:80: "change" -> "changed"?

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P5
 Status|UNCONFIRMED |ASSIGNED
   Keywords||documentation
   Last reconfirmed||2013-06-10
  Component|translation |target
 CC||gjl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |gjl at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |trivial

[Bug target/57501] [avr] generated collect2 crttn24a.o missing path with -mmcu=attiny24a

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target|attiny24a   |avr
 Status|UNCONFIRMED |RESOLVED
 CC||gjl at gcc dot gnu.org
   Host|Linux 3.9.2-1-ARCH x86_64   |x86_64-linux-gnu
 Resolution|--- |INVALID

--- Comment #1 from Georg-Johann Lay  ---
This looks like an artifact of missing feature AVR-LibC #35407, cf.
http://savannah.nongnu.org/bugs/?35407

In your installation there must be a directory avr/lib/avr25/tiny-stack and
therein -- amongst others -- the object file crttn24a.

[Bug c++/57390] Fixed point types on AVR are not available in C++ mode

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 CC||gjl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Georg-Johann Lay  ---
It's not about "enabling", it's about extending the C++ language and front end
in GCC and maintaining such extension.

[Bug c++/41725] g++ accepts compounded unnamed type in template (violates 14.3.1-2)

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
Do we have DR # for this issue?

[Bug tree-optimization/57558] Issue with number of iterations calculation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947

--- Comment #1 from Richard Biener  ---
That's because the first variant can loop infinitely for n == ULONG_MAX
and that "infinite" cannot be represented using new induction variable
as the vectorizer wants to.  Well, not easily at least.

[Bug rtl-optimization/57559] [4.9 Regression] S/390: ICE with lra

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
Summary|S/390: ICE with lra |[4.9 Regression] S/390: ICE
   ||with lra

[Bug tree-optimization/57567] Missed optimisation: compare + or

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  ISTR Jakub did some work in this area.

[Bug target/57571] linux kernel function memcpy() execute with low efficiency on Intel Ivybridge platform

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-06-10
 Ever confirmed|0   |1

[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode

[kai.koehne at digia dot com]

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

--- Comment #6 from Kai Koehne  ---
The issue is still there with 4.8.1 . It understand that the discussion on Kai
Tietz' original patch has stalled ... Any suggestion on how we can move this
forward?

[Bug other/57482] [4.7.3][AVR] --help=optimizers reports a wrong list

[christophe.beausoleil at sogeti dot com]

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

--- Comment #3 from Christophe  ---
> 2) -f[no-]short-enums is not an optimization option;

Hum, I do not really agree although it is strongly related to ABI, no doubt.
Anyway, it is a very special option as I can see in opts.c :
  /* Set this to a special "uninitialized" value.  The actual default
 is set after target options have been processed.  */
  opts->x_flag_short_enums = 2;

A few specific options are also treated here, but it seems to me that
-fshort-enum is the only optimization option concerned. Am I wrong ? Could it
be the only option which is not reported correctly by --help=optimizers ?

Reading target.def is really instructive, but I still do not understand (yet)
how the optimizations list is built, and how options are overwritten... All
this is very confusing.

[Bug middle-end/55308] /usr/ports/lang/gcc48/work/build/sparc64-portbld-freebsd10.0/libstdc++-v3/src/.libs/libstdc++.so.6: Undefined symbol "__emutls_v._ThreadRuneLocale"

[mexas at bristol dot ac.uk]

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

Anton Shterenlikht  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Anton Shterenlikht  ---
Fixed by a binutils patch in the latest version, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53964

[Bug regression/53964] regression: sparc64 FreeBSD: /usr/ports/lang/gcc46/work/build/./prev-gcc/include/stddef.h:150:26: error: two or more data types n declaration specifiers

[mexas at bristol dot ac.uk]

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

Anton Shterenlikht  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Anton Shterenlikht  ---
Fixes 4.7 and 4.8 too, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308