[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 9 Jan 2014, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723
> 
> --- Comment #7 from Dominique d'Humieres  ---
> > ... which implies that the GCC testsuite needs to be improved with regards 
> > to LTO testing as there was no new failure with the patch.

Maybe ... but if you modify LTO code for a feature I'd expect you
try LTO on a simple example using that feature ;)

> Not GCC, but gfortran. I stumbled on this pr with
> 
> make -k check-gfortran
> RUNTESTFLAGS="--target_board=unix'{-m32/-flto,-m64/-flto}'"
> 
> One may consider to add something '-Ofast -flto' to the set of options in
> gfortran.dg.

One always has to weight in testing time of course.

[Bug sanitizer/59748] New: ptrace isn't instrumented on at least arm-linux-gnueabihf and powerpc-linux.gnu

[doko at gcc dot gnu.org]

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

Bug ID: 59748
   Summary: ptrace isn't instrumented on at least
arm-linux-gnueabihf and powerpc-linux.gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

seen with trunk 20140109, at least the shared libasan.so.1 doesn't have these
two symbols on arm-linux-gnueabihf and powerpc-linux-gnu:

  __interceptor_ptrace@Base
  ptrace@Base

is this expected?

[Bug tree-optimization/59715] [4.7/4.8 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 10 08:37:07 2014
New Revision: 206511

URL: http://gcc.gnu.org/viewcvs?rev=206511&root=gcc&view=rev
Log:
2014-01-10  Richard Biener  

PR tree-optimization/59715
* tree-flow.h (split_critical_edges): Declare.
* tree-cfg.c (split_critical_edges): Export.
* tree-ssa-sink.c (execute_sink_code): Split critical edges.

* gcc.dg/torture/pr59715.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59715.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/tree-cfg.c
branches/gcc-4_8-branch/gcc/tree-flow.h
branches/gcc-4_8-branch/gcc/tree-ssa-sink.c

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-10
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|wrong code at -Os and above |[4.9 Regression] wrong code
   |on x86_64-linux-gnu in  |at -Os and above on
   |64-bit mode |x86_64-linux-gnu in 64-bit
   ||mode
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/59745] [4.9 Regression] internal compiler error: tree check: expected tree that contains 'typed' structure, have '' in operand_equal_p, at fold-const.c:2492

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 31792
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31792&action=edit
gcc49-pr59745.patch

Totally untested fix.  As this is only reproduceable in bootstrapped build, -O0
built stage1 doesn't fail, this is just a guess what the problem is, will try
to verify later on with bootstrap (but, because of that I think adding a
reduced testcase is not really useful either).  If that is the case, it would
be a latent bug before, as determine_offset has been called before for
read/read and could put items into the affine cache.

[Bug c/59749] New: unused warning not emited for unused static struct unles -save-temps is used

[martin at netbsd dot org]

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

Bug ID: 59749
   Summary: unused warning not emited for unused static struct
unles -save-temps is used
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org

Created attachment 31793
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31793&action=edit
original source file exhibiting the problem

I have a program (for the atf testing framework) that is supposed to warn about
an unused variable and (due to -Werror) fail compilation. This works fine with
gcc 4.5.4.

But with 4.8.2 I get:

$ /usr/pkg/gcc48/bin/cc -O2 -c -Wall -Werror /usr/tests/atf/atf-c/unused_test.c
$

The code (after macro expansion) declares a struct and initialize it:

static atfu_this_is_unused_tc_pack = { .m_ident =  };

and there is no reference to this struct anywhere in the file.

Interestingly when preparing for this ticket I did:

$ /usr/pkg/gcc48/bin/cc -O2 -save-temps -c -Wall -Werror
/usr/tests/atf/atf-c/unused_test.c
/usr/tests/atf/atf-c/unused_test.c:41:123: error: 'atfu_this_is_unused_tc'
defined but not used [-Werror=unused-variable]
 ATF_TC(this_is_unused);
   
   ^
cc1: all warnings being treated as errors
$   /usr/pkg/gcc48/bin/cc -v Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc48/bin/cc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc48/libexec/gcc/sparc64--netbsd/4.8.2/lto-wrapper
Target: sparc64--netbsd
Configured with: ../gcc-4.8.2/configure --enable-languages='c c++'
--enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc48
--enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib ' --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --disable-nls --with-gmp=/usr/pkg
--with-mpc=/usr/pkg --with-mpfr=/usr/pkg --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc48/include/c++/ --prefix=/usr/pkg/gcc48
--build=sparc64--netbsd --host=sparc64--netbsd --infodir=/usr/pkg/gcc48/info
--mandir=/usr/pkg/gcc48/man
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used

[martin at netbsd dot org]

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

--- Comment #1 from Martin Husemann  ---
Created attachment 31794
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31794&action=edit
unused_test.i file from -save-temps

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Author: hubicka
Date: Fri Jan 10 09:33:24 2014
New Revision: 206516

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

PR ipa/58252
PR ipa/59226
* ipa-devirt.c record_target_from_binfo): Take as argument
stack of binfos and lookup matching one for virtual inheritance.
(possible_polymorphic_call_targets_1): Update.

* g++.dg/ipa/devirt-20.C: New testcase.
* g++.dg/torture/pr58252.C: Likewise.
* g++.dg/torture/pr59226.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-20.C
trunk/gcc/testsuite/g++.dg/torture/pr58252.C
trunk/gcc/testsuite/g++.dg/torture/pr59226.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/59374] [4.7/4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work|4.7.3, 4.9.0|4.3.6, 4.4.7
Summary|[4.8 Regression]|[4.7/4.8/4.9 Regression]
   |-ftree-slp-vectorize breaks |-ftree-slp-vectorize breaks
   |unique_ptr's move   |unique_ptr's move
   |constructor |constructor
  Known to fail||4.6.4, 4.7.3, 4.9.0

--- Comment #7 from Richard Biener  ---
Backporting this fix is hard as it depends on some of the re-org done on trunk,
in particular doing dataref group analysis before dependence analysis, and then
especially marking those stmts as not vectorizable that do not participate in
a group.  Also looking closer this isn't fixed on trunk fully either because
if you trick group analysis to succeed but in the end vectorization not
because you let SLP build fail then we still miscompile it:

extern void abort (void);

static struct X { void *a; void *b; } a, b;

void __attribute__((noinline)) foo (void)
{
  void *tem = a.b;
  a.b = (void *)0;
  b.b = tem;
  b.a = a.a;
  a.a = tem;
}

int main()
{
  a.b = &a;
  foo ();
  if (b.b != &a)
abort ();
  return 0;
}


t.c:7:9: note: === vect_analyze_slp ===
t.c:7:9: note: Build SLP for a.a = tem_2;

t.c:7:9: note: Build SLP for a.b = 0B;

t.c:7:9: note: Build SLP failed: different operation in stmt a.b = 0B;

in this case a missed optimization, of course.


Btw, 4.7.3 and 4.6.4 don't work for me for either testcase (they may work
for the original C++ testcase).  Wasn't able to check 4.5 right now
(but it has SLP vectorization, too).

[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
Fixed.

[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2

[hubicka at gcc dot gnu.org]

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

--- Comment #13 from Jan Hubicka  ---
Author: hubicka
Date: Fri Jan 10 09:33:24 2014
New Revision: 206516

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

PR ipa/58252
PR ipa/59226
* ipa-devirt.c record_target_from_binfo): Take as argument
stack of binfos and lookup matching one for virtual inheritance.
(possible_polymorphic_call_targets_1): Update.

* g++.dg/ipa/devirt-20.C: New testcase.
* g++.dg/torture/pr58252.C: Likewise.
* g++.dg/torture/pr59226.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/ipa/devirt-20.C
trunk/gcc/testsuite/g++.dg/torture/pr58252.C
trunk/gcc/testsuite/g++.dg/torture/pr59226.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #20 from Jan Hubicka  ---
Fixed, finally!

[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka  ---
Fixed ;)

[Bug c/59750] New: stack protector does not catch 1 byte overwrite of char[10] array

[martin at netbsd dot org]

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

Bug ID: 59750
   Summary: stack protector does not catch 1 byte overwrite of
char[10] array
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org

This test program correctly dies when compiled with gcc 4.5.4:

#include 
int main(int argc, char **argv)
{
char b[10];
strcpy(b, "1");
strcat(b, "012345678");
return 0;
}

but when compiled with gcc 4.8.2 it does not cause an abort on sparc64:

$ /usr/pkg/gcc48/bin/cc -fstack-protector -O0 test.c
$ ./a.out
$

Using a few more chars ("0123456789ABCDE") in the strcat make ssp catch it.

$ /usr/pkg/gcc48/bin/cc -v
Using built-in specs.
COLLECT_GCC=/usr/pkg/gcc48/bin/cc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc48/libexec/gcc/sparc64--netbsd/4.8.2/lto-wrapper
Target: sparc64--netbsd
Configured with: ../gcc-4.8.2/configure --enable-languages='c c++'
--enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc48
--enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib ' --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --disable-nls --with-gmp=/usr/pkg
--with-mpc=/usr/pkg --with-mpfr=/usr/pkg --enable-__cxa_atexit
--with-gxx-include-dir=/usr/pkg/gcc48/include/c++/ --prefix=/usr/pkg/gcc48
--build=sparc64--netbsd --host=sparc64--netbsd --infodir=/usr/pkg/gcc48/info
--mandir=/usr/pkg/gcc48/man
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Fix for PR58252 and PR59226 fixed first two problems contributing to the ICE on
the testcase.  The last remaining problem is that our type inheritance graph is
incomplete, it misses the class C.

The reason is that I build the graph by looking for virtual methods and adding
their types.  C has no virtual methods per se, but it does use thunk of A's
constructor. This thunk is considered, but it does not have type of C that I
think is a frontend bug.

The patch I attached fixes it by considering also non-virtual methods to build
the graph. This matches the constructor of C and gets testcase working, but I
think it is symptomatic fix and may break if ctor is optimized out with LTO.
I am looking into a safer way to discover existence of C.

[Bug go/59431] [4.9 regression] runtime FAILs on Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I thought so myself when I saw the patch and fired off an
i386-pc-solaris2.10 bootstrap.  Unfortunately, the failures remain.

Rainer

[Bug libstdc++/59751] New: Hash tables don't use allocator_traits

[martinho.fernandes at gmail dot com]

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

Bug ID: 59751
   Summary: Hash tables don't use allocator_traits
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martinho.fernandes at gmail dot com

Take the following program:

---

#include 
#include 
#include 
#include 

template 
struct my_allocator {
using value_type = T;

T* allocate(std::size_t) { return nullptr; }
void deallocate(T*, std::size_t) {}
};

int main() {
using map_type = std::unordered_map,
std::equal_to, my_allocator>>;

map_type m { { 1, 1. } , { 2, 2. } };
}

---

As far as I understand the allocator used is a minimally complete.
std::allocator_traits can fill in all the rest, so the program is well-formed.

However, attempting compilation with GCC 4.8.1 results in:

---

In file included from /usr/include/c++/4.8/unordered_map:47:0,

 from main.cpp:1:

/usr/include/c++/4.8/bits/hashtable.h: In instantiation of ‘class
std::_Hashtable, my_allocator >, std::__detail::_Select1st, std::equal_to, std::hash,
std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash,
std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >’:

/usr/include/c++/4.8/bits/unordered_map.h:100:18:   required from ‘class
std::unordered_map, std::equal_to,
my_allocator > >’

main.cpp:17:14:   required from here

/usr/include/c++/4.8/bits/hashtable.h:194:47: error: no type named ‘pointer’ in
‘struct my_allocator >’

   typedef typename _Alloc::pointerpointer;

   ^

/usr/include/c++/4.8/bits/hashtable.h:195:55: error: no type named
‘const_pointer’ in ‘struct my_allocator >’

   typedef typename _Alloc::const_pointer  const_pointer;

   ^

/usr/include/c++/4.8/bits/hashtable.h:196:55: error: no type named ‘reference’
in ‘struct my_allocator >’

   typedef typename _Alloc::reference  reference;

   ^

/usr/include/c++/4.8/bits/hashtable.h:197:55: error: no type named
‘const_reference’ in ‘struct my_allocator >’

   typedef typename _Alloc::const_referenceconst_reference;

   ^

/usr/include/c++/4.8/bits/hashtable.h:317:8: error: no class template named
‘rebind’ in ‘struct my_allocator >’

_Node_allocator_type;

^

/usr/include/c++/4.8/bits/hashtable.h:319:8: error: no class template named
‘rebind’ in ‘struct my_allocator >’

_Bucket_allocator_type;

^

/usr/include/c++/4.8/bits/hashtable.h:321:75: error: no class template named
‘rebind’ in ‘struct my_allocator >’

   using __before_begin = __detail::_Before_begin<_Node_allocator_type>

   ^

In file included from /usr/include/c++/4.8/unordered_map:48:0,

 from main.cpp:1:

/usr/include/c++/4.8/bits/unordered_map.h: In instantiation of ‘class
std::unordered_map, std::equal_to,
my_allocator > >’:

main.cpp:17:14:   required from here

/usr/include/c++/4.8/bits/unordered_map.h:116:49: error: no type named
‘pointer’ in ‘std::unordered_map,
std::equal_to, my_allocator >
>::allocator_type {aka struct my_allocator >}’

   typedef typename allocator_type::pointer  pointer;

 ^

/usr/include/c++/4.8/bits/unordered_map.h:117:54: error: no type named
‘const_pointer’ in ‘std::unordered_map,
std::equal_to, my_allocator >
>::allocator_type {aka struct my_allocator >}’

   typedef typename allocator_type::const_pointer const_pointer;

  ^

/usr/include/c++/4.8/bits/unordered_map.h:118:50: error: no type named
‘reference’ in ‘std::unordered_map,
std::equal_to, my_allocator >
>::allocator_type {aka struct my_allocator >}’

   typedef typename allocator_type::reference reference;

  ^

/usr/include/c++/4.8/bits/unordered_map.h:119:56: error: no type named
‘const_reference’ in ‘std::unordered_map,
std::equal_to, my_allocator >
>::allocator_type {aka struct my_allocator >}’

   typedef typename allocator_type::const_reference const_reference;

^

In file included from /usr/include/c++/4.8/unordered_map:47:0,

 from main.cpp:1:

/usr/include/c++/4.8/bits/hashtable.h: In instantiation of
‘std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash,
_RehashPolicy, _Traits>::_Hashtable(_InputIterator, _InputIterator,
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _H1, _H2, _Hash,
_RehashPolicy, _Traits>::size_type, const _H1&, const _H2&, const _Hash&

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at ucw dot cz]

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

--- Comment #29 from Jan Hubicka  ---
> 
> That optimization seems invalid. There is a explicit template instantiation
> definition, so it is valid for other dsos to have an undefined reference.

Can I see the cgraph dump of the unreduced source file containing the explicit
instantiation?

In this case C++ FE should set forced_by_abi flag and that should
prevent us from bringing comdat local in:
/* A helper for comdat_can_be_unshared_p.  */

static bool
comdat_can_be_unshared_p_1 (symtab_node *node)
{ 
  /* When address is taken, we don't know if equality comparison won't
 break eventually. Exception are virutal functions, C++
 constructors/destructors and vtables, where this is not possible by
 language standard.  */
  if (!DECL_VIRTUAL_P (node->decl)
  && (TREE_CODE (node->decl) != FUNCTION_DECL
  || (!DECL_CXX_CONSTRUCTOR_P (node->decl)
  && !DECL_CXX_DESTRUCTOR_P (node->decl)))
  && address_taken_from_non_vtable_p (node))
return false;

  /* If the symbol is used in some weird way, better to not touch it.  */
  if (node->force_output)
return false;

  /* Explicit instantiations needs to be output when possibly
 used externally.  */
  if (node->forced_by_abi
  && TREE_PUBLIC (node->decl)
  && (node->resolution != LDPR_PREVAILING_DEF_IRONLY
  && !flag_whole_program))
return false;

Perhaps we forget about the flag, or perhaps the symbol is hidden by the
default
visibility overrride?

Honza

[Bug middle-end/59752] New: Stack overflow on simple testcase

[trippels at gcc dot gnu.org]

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

Bug ID: 59752
   Summary: Stack overflow on simple testcase
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

Jakub's testcase from PR59659 comment 7 with an array size of 10
overflows the stack:

markus@x4 tmp % cat test.ii
struct S { S (); S (int); ~S (); int i; };
struct A { S s[10]; };

void
foo ()
{
A a = {{}};
}

markus@x4 tmp % g++ -O2 -c test.ii
g++: internal compiler error: Segmentation fault (program cc1plus)
0x40ccef execute
../../gcc/gcc/gcc.c:2841
0x40cf57 do_spec_1
../../gcc/gcc/gcc.c:4641
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
0x40d6e2 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
0x40d6e2 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40d2de do_spec_1
../../gcc/gcc/gcc.c:5410
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
0x40d6e2 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
0x40d6e2 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
0x40d6e2 do_spec_1
../../gcc/gcc/gcc.c:5295
0x40fccd process_brace_body
../../gcc/gcc/gcc.c:5924
0x40fccd handle_braces
../../gcc/gcc/gcc.c:5838
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 26558]
0x0073c6bf in cp_gimplify_expr (expr_p=0x74f5ae28,
pre_p=0x7bfff7f8, post_p=0x7bfff460) at
../../gcc/gcc/cp/cp-gimplify.c:532
532 {
(gdb) bt
#0  0x0073c6bf in cp_gimplify_expr (expr_p=0x74f5ae28,
pre_p=0x7bfff7f8, post_p=0x7bfff460) at
../../gcc/gcc/cp/cp-gimplify.c:532
#1  0x009a085c in gimplify_expr (expr_p=expr_p@entry=0x74f5ae28,
pre_p=pre_p@entry=0x7bfff7f8, post_p=,
post_p@entry=0x7bfff460, 
gimple_test_f=0x9819e0 ,
fallback=fallback@entry=3) at ../../gcc/gcc/gimplify.c:7350
#2  0x009a83fc in gimplify_compound_lval
(expr_p=expr_p@entry=0x754d0ab8, pre_p=pre_p@entry=0x7bfff7f8,
post_p=post_p@entry=0x7bfff460, 
fallback=fallback@entry=3) at ../../gcc/gcc/gimplify.c:1976
#3  0x009a0ea7 in gimplify_expr (expr_p=expr_p@entry=0x754d0ab8,
pre_p=pre_p@entry=0x7bfff7f8, post_p=, 
gimple_test_f=gimple_test_f@entry=0x9986d0 ,
fallback=fallback@entry=3) at ../../gcc/gcc/gimplify.c:7393
#4  0x009ac5e2 in gimplify_addr_expr
(expr_p=expr_p@entry=0x7fffee5c11f0, pre_p=pre_p@entry=0x7bfff7f8,
post_p=post_p@entry=0x7bfff460)
at ../../gcc/gcc/gimplify.c:4794
#5  0x009a2ac2 in gimplify_expr (expr_p=0x7fffee5c11f0,
pre_p=pre_p@entry=0x7bfff7f8, post_p=, post_p@entry=0x0, 
gimple_test_f=0x9815e0 , fallback=) at ../../gcc/gcc/gimplify.c:7487
#6  0x009acc5c in gimplify_arg (arg_p=,
pre_p=pre_p@entry=0x7bfff7f8, call_location=) at
../../gcc/gcc/gimplify.c:2184
#7  0x009ae09a in gimplify_call_expr
(expr_p=expr_p@entry=0x7fffef5b4a58, pre_p=pre_p@entry=0x7bfff7f8,
want_value=)
at ../../gcc/gcc/gimplify.c:2354
#8  0x009a1c35 in gimplify_expr (expr_p=0x7fffef5b4a58,
pre_p=pre_p@entry=0x7bfff7f8, post_p=, post_p@entry=0x0, 
gimple_test_f=gimple_test_f@entry=0x99a6e0 ,
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:7412
#9  0x009a59a7 in gimplify_stmt (stmt_p=,
seq_p=seq_p@entry=0x7bfff7f8) at ../../gcc/gcc/gimplify.c:5334
#10 0x009a1cdb in gimplify_cleanup_point_expr (pre_p=0x7bfffad8,
expr_p=0x7fffef5aef40) at ../../gcc/gcc/gimplify.c:5110
#11 gimplify_expr (expr_p=0x7fffef5aef40, pre_p=pre_p@entry=0x7bfffad8,
post_p=, post_p@entry=0x0, 
gimple_test_f=gimple_test_f@entry=0x99a6e0 ,
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:7797
#12 0x009a59a7 in gimplify_stmt (stmt_p=,
seq_p=seq_p@entry=0x7bfffad8) at ../../gcc/gcc/gimplify.c:5334
#13 0x009a1a5c in gimplify_statement_list (pre_p=0x7bfffad8,
expr_p=0x7bfffac0) at ../../gcc/gcc/gimplify.c:1405
#14 gimplify_expr (expr_p=0x7bfffac0, pre_p=pre_p@entry=0x7bfffad8,
post_p=, post_p@entry=0x0, 
gimple_test_f=gimple_test_f@entry=0x99a6e0 ,
fallback=fallback@entry=0) at ../../gcc/gcc/gimplify.c:7849
#15 0x009a59a7 in gimplify_stmt (stmt_p=stmt_p@entry=0x7bfffac0,
seq_p=seq_p@entry=0x7bfffad8) at ../../gcc/gcc/gimplify.c:5334
#16 0x009

[Bug libstdc++/59751] Hash tables don't use allocator_traits

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Already fixed, see http://gcc.gnu.org/gcc-4.9/changes.html#cxx

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #30 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #29)
> > 
> > That optimization seems invalid. There is a explicit template instantiation
> > definition, so it is valid for other dsos to have an undefined reference.
> 
> Can I see the cgraph dump of the unreduced source file containing the
> explicit
> instantiation?

It's in the first bziped attachment: Function.ii line 71217.

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
I think the problem is in setting the value of e.  With -O in .gimple we have:
e.2 = e;
e.3 = e.2;   
e.4 = e.3 + -1;
e = e.4;
while with -O2:
e.2 = e;
e.3 = e.2;
e.4 = (unsigned short) e.3;
D.1762 = e.4 + 65535;
e.5 = (short int) D.1762;
e = e.5;

Wrt the weirdo shift: -1 >> 56 is implementation-defined behavior.

[Bug c/59753] New: Missing -Woverflow warning with signed constant conversion between T_MAX+1 and UT_MAX

[vincent-gcc at vinc17 dot net]

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

Bug ID: 59753
   Summary: Missing -Woverflow warning with signed constant
conversion between T_MAX+1 and UT_MAX
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net

When writing "int d = some_signed_constant;", one expects a -Woverflow warning
if some_signed_constant > INT_MAX, but one actually gets a warning only if
some_signed_constant > UINT_MAX. Similarly for other types, such as char and
short.

For instance, with the following program, one expects 6 warnings, but one only
gets 2.

#include 
int main (void)
{
  short a = 32768;
  short b = 65535;
  short c = 65536;
  int d = 2147483648;
  int e = 4294967295;
  int f = 4294967296;
  printf ("%d %d %d %d %d %d\n", a, b, c, d, e, f);
  return 0;
}

$ gcc-snapshot tst.c -o tst
tst.c: In function 'main':
tst.c:6:3: warning: overflow in implicit constant conversion [-Woverflow]
   short c = 65536;
   ^
tst.c:9:3: warning: overflow in implicit constant conversion [-Woverflow]
   int f = 4294967296;
   ^

This occurs with:
gcc (Debian 20131201-1) 4.9.0 20131201 (experimental) [trunk revision 205573]
and older versions (4.7 and 4.8 at least).

[Bug fortran/54221] [4.8/4.9 Regression] Explicit private access specifier signals "unexpected defined but not used [-Wunused-function]" warning

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Andrew Benson from comment #11)
> This was fixed in PR54884 if I remember correctly.

Ok, thanks.

Then I'm closing this one ...

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #31 from Jan Hubicka  ---
OK, the visibility is:
_ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodesFromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
(transferNodesFromList) @0x7fd527d7ee18
  Type: function definition analyzed
  Visibility: externally_visible prevailing_def_ironly_exp public weak comdat 

if the function is explicitly instantiated and required to be exported from
module by ABI, it needs forced_by_abi flag. In that case it is an FE bug.
Can you point me to that instantiation? It is hard for me to parse the .ii file
:(

Honza

[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[trippels at gcc dot gnu.org]

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

--- Comment #32 from Markus Trippelsdorf  ---
(In reply to Jan Hubicka from comment #31)
> OK, the visibility is:
> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE21transferNodes
> FromListERNS_12ilist_traitsIS1_EENS_14ilist_iteratorIS1_EES8_/3295
> (transferNodesFromList) @0x7fd527d7ee18
>   Type: function definition analyzed
>   Visibility: externally_visible prevailing_def_ironly_exp public weak
> comdat 
> 
> if the function is explicitly instantiated and required to be exported from
> module by ABI, it needs forced_by_abi flag. In that case it is an FE bug.
> Can you point me to that instantiation? It is hard for me to parse the .ii
> file :(

As I wrote above: The instantiation is on line 71217.

[Bug c/59750] stack protector does not catch 1 byte overwrite of char[10] array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Why do you think this should be caught, that is not what -fstack-protector is
meant to protect.  After 10 bytes long buffer there is likely to be padding, so
1 byte overflow will unlikely clobber the stack canary.  SSP only is about
prevention of overwriting function return address and caller's stack frames.
Use -D_FORTIFY_SOURCE=2, -fsanitize=address, -fmudflap etc. if you want this to
be caught.

[Bug c++/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com
  Component|ipa |c++

--- Comment #33 from Jan Hubicka  ---
OK, either the testcase is invalid since ODR forbids you to have function
inline in one unit and not inline in other, or C++ FE should call mark_used on
the explicitly instantiated comdat.  In any case, I am changing component to
C++.

Jason, any chance you can look on this?

[Bug tree-optimization/59374] [4.7/4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.5.4

--- Comment #8 from Richard Biener  ---
Jakub bisected the regression for the testcase in comment #3 to r163757. 
Meanwhile verified that 4.5.4 works.

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r206418.

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Marek Polacek from comment #2)
> I think the problem is in setting the value of e.  With -O in .gimple we
> have:
> e.2 = e;
> e.3 = e.2;   
> e.4 = e.3 + -1;
> e = e.4;
> while with -O2:
> e.2 = e;
> e.3 = e.2;
> e.4 = (unsigned short) e.3;
> D.1762 = e.4 + 65535;
> e.5 = (short int) D.1762;
> e = e.5;

That's -fstrict-overflows effect I think, but not the issue.  "Fixed" by
-fno-ree.

[Bug tree-optimization/59745] [4.9 Regression] internal compiler error: tree check: expected tree that contains 'typed' structure, have '' in operand_equal_p, at fold-const.c:2492

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So, before ree we have:
(insn 13 12 14 4 (set (reg:HI 0 ax [orig:88 D.1782 ] [88])
(mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2
A16])) pr59747.c:18 91 {*movhi_internal}
 (expr_list:REG_EQUIV (mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2 A16])
(nil)))
(insn 14 13 15 4 (set (reg:SI 1 dx [orig:97 D.1782 ] [97])
(sign_extend:SI (reg:HI 0 ax [orig:88 D.1782 ] [88]))) pr59747.c:18 145
{extendhisi2}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI ("d")  ) [2 d+0 S4 A32])
(nil)))
(insn 15 14 17 4 (set (mem/c:SI (symbol_ref:DI ("d")  ) [2 d+0 S4 A32])
(reg:SI 1 dx [orig:97 D.1782 ] [97])) pr59747.c:18 90 {*movsi_internal}
 (nil))
(insn 17 15 18 4 (set (reg:DI 0 ax [orig:99 f ] [99])
(sign_extend:DI (reg:HI 0 ax [orig:88 D.1782 ] [88]))) pr59747.c:19 144
{extendhidi2}
 (nil))

Before Jeff's ree changes, we'd transform it into:
(insn 13 12 14 4 (set (reg:DI 0 ax)
(sign_extend:DI (mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2 A16]))) pr59747.c:18 144 {extendhidi2}
 (expr_list:REG_EQUIV (mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2 A16])
(nil)))
(insn 14 13 15 4 (set (reg:SI 1 dx [orig:97 D.1782 ] [97])
(sign_extend:SI (reg:HI 0 ax [orig:88 D.1782 ] [88]))) pr59747.c:18 145
{extendhisi2}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI ("d")  ) [2 d+0 S4 A32])
(nil)))
(insn 15 14 18 4 (set (mem/c:SI (symbol_ref:DI ("d")  ) [2 d+0 S4 A32])
(reg:SI 1 dx [orig:97 D.1782 ] [97])) pr59747.c:18 90 {*movsi_internal}
 (nil))

which is of course suboptimal, now we transform it into:
(insn 13 12 39 4 (set (reg:DI 1 dx)
(sign_extend:DI (mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2 A16]))) pr59747.c:18 144 {extendhidi2}
 (expr_list:REG_EQUIV (mem/c:HI (symbol_ref:DI ("e")  ) [3 e+0 S2 A16])
(nil)))
(insn 39 13 15 4 (set (reg:SI 0 ax)
(reg:SI 1 dx [orig:97 D.1782 ] [97])) pr59747.c:18 -1
 (nil))
(insn 15 39 18 4 (set (mem/c:SI (symbol_ref:DI ("d")  ) [2 d+0 S4 A32])
(reg:SI 1 dx [orig:97 D.1782 ] [97])) pr59747.c:18 90 {*movsi_internal}
 (nil))

which is wrong, insn 39 move would need to be performed in DImode rather than
SImode.  Or alternatively in this case if insn 13 set DImode %rax as it used to
do, it would be sufficient to do a SImode %edx = %eax move in insn 39.

Jeff, can you please have a look?

[Bug rtl-optimization/59754] New: [ree.c] Incorrect merge while working with vector registers

[kirill.yukhin at intel dot com]

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

Bug ID: 59754
   Summary: [ree.c] Incorrect merge while working with vector
registers
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirill.yukhin at intel dot com

Hello,
It seems that this revision:
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206418
138bc75d-0d04-0410-961f-82ee72b054a4

made bunch of AVX-512F tests failing (at runtime):

The difference in assembler is as following.

For good (prev. rev., testname: gcc.target/i386/avx512f-vpmovzxwd-2.c):
...
vmovdqa 160(%esp), %ymm0
movl$-22854, %eax
leal384(%esp), %ebx
kmovw   %eax, %k1
xorl%edx, %edx
vpmovzxwd   %ymm0, %zmm1
vmovdqa64   %zmm1, 192(%esp)
vmovdqa64   256(%esp), %zmm1
vpmovzxwd   %ymm0, %zmm1{%k1}
vpmovzxwd   %ymm0, %zmm0{%k1}{z}
vmovdqa64   %zmm1, 256(%esp)
vmovdqa64   %zmm0, 320(%esp)
...

For broken:
...
vpmovzxwd   160(%esp), %zmm1
movl$-22854, %eax
leal384(%esp), %ebx
kmovw   %eax, %k1
xorl%edx, %edx
vmovdqa64   %zmm1, %zmm0
vmovdqa64   %zmm1, 192(%esp)
vmovdqa64   256(%esp), %zmm1
vpmovzxwd   %ymm0, %zmm1{%k1}
vpmovzxwd   %ymm0, %zmm0{%k1}{z}
vmovdqa64   %zmm1, 256(%esp)
vmovdqa64   %zmm0, 320(%esp)
...


So it seems that it is allowed to convert:
  (set r0 [mem])
  (set r1 sign_extend (r0))

to:
  (set r1 sign_extend ([mem]))
  (set r0 r1)

IMHO this should work with scalar, but not with vectors.
I suspect eliminating such extends for vector types were
prohibited initially.

[Bug rtl-optimization/59754] [ree.c] Incorrect merge while working with vector registers

[kirill.yukhin at intel dot com]

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

--- Comment #1 from Yukhin Kirill  ---
> made bunch of AVX-512F tests failing (at runtime):
FAIL: gcc.target/i386/avx512f-vpmovsxdq-2.c execution test
FAIL: gcc.target/i386/avx512f-vpmovsxwd-2.c execution test
FAIL: gcc.target/i386/avx512f-vpmovzxdq-2.c execution test
FAIL: gcc.target/i386/avx512f-vpmovzxwd-2.c execution test

[Bug c/59755] New: BUG Increment Operator with Accessing Arrays

[octo.nebula at gmail dot com]

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

Bug ID: 59755
   Summary: BUG Increment Operator with Accessing Arrays
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: octo.nebula at gmail dot com

Guys,

The increment operator is not working right. The post ++ should increment value
of the index after the array expression. But in this case, it acts like the pre
++ version.

See code below:

#include 

int main()
{
int A[2][2] = { { 5, 7}, {9, 10} };

int m = 0, B[] = { 0, 0 };
int C = 0, D = 0;

C = A[m][B[m]];
D = A[m][B[m++]];

if  (C != D) {
  fprintf (stderr, "Error: C /= D\n");
  return 1;
}

 return 0;
}


[sunny@localhost trash]$ gcc test.c
[sunny@localhost trash]$ ./a.out
Error: C /= D
[sunny@localhost trash]$ 


GCC version is 4.8.2

[Bug c/59755] BUG Increment Operator with Accessing Arrays

[octo.nebula at gmail dot com]

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

Arjun  changed:

   What|Removed |Added

 CC||octo.nebula at gmail dot com

--- Comment #1 from Arjun  ---
In the example given above, C = 5 which is A[0][0] and D = 9 which is A[1][0].

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent-gcc at vinc17 dot net]

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

--- Comment #24 from Vincent Lefèvre  ---
(In reply to Nick Maclaren from comment #23)
> If __STDC_IEC_559__ is unset or does not have the value 1, setting
> STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and
> Annex F), unless the implementation explicitly chooses to extend the
> language to support it.

You're wrong. The C standard doesn't say that.

6.10.8.3 says: "__STDC_IEC_559__ The integer constant 1, intended to indicate
conformance to the specifications in annex F (IEC 60559 floating-point
arithmetic)." and nothing about STDC FENV_ACCESS.

In 7.6, only 7.6.1 is specifically about the FENV_ACCESS pragma, and it
specifies under which conditions the behavior is undefined, but nothing related
to __STDC_IEC_559__ and Annex F.

Annex F doesn't apply in the case __STDC_IEC_559__ is unset.

[Bug c/59755] BUG Increment Operator with Accessing Arrays

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
With -Wall one gets:
test.c: In function ‘main’:
test.c:12:14: warning: operation on ‘m’ may be undefined [-Wsequence-point]
  D = A[m][B[m++]];
  ^

Thus your testcase is invalid because of unsequenced modification
and access to m.

[Bug middle-end/59743] [4.9 Regression] ICE: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Ah, there is:
  /* If the df_live problem is not defined, such as at -O0 and -O1, we
 still need to keep the luids up to date.  This is normally done
 in the df_live problem since this problem has a forwards
 scan.  */
  if (!df_live)
df_recompute_luids (bb);
in df_lr_bb_local_compute, so I think luids are fine even at -O0/-O1.

[Bug libstdc++/59756] New: off-by-one error in regex

[Nikolay.Bozhenov at gmail dot com]

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

Bug ID: 59756
   Summary: off-by-one error in regex
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Nikolay.Bozhenov at gmail dot com

example:

$ cat case.cpp
#include 
#include 
#include 

int main() {
std::string re_s("abc(def)ghi");
std::regex re(re_s);
std::smatch mch;
std::regex_match(std::string("abcdefghi"), mch, re);
std::cout << mch[1].str() << std::endl;
}


compilation:

$ g++-4.8.2 case.cpp -std=c++11 -o case


actual result:

$ ./case
cdef


expected result:

$ ./case
def

[Bug rtl-optimization/59754] [ree.c] Incorrect merge while working with vector registers

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 31795
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31795&action=edit
gcc49-pr59754.patch

Untested fix.  Tried to think if the other (older) REE transformations aren't
wrong for vector modes, but haven't found anything yet.

[Bug tree-optimization/59374] [4.7/4.8/4.9 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 10 13:07:42 2014
New Revision: 206523

URL: http://gcc.gnu.org/viewcvs?rev=206523&root=gcc&view=rev
Log:
2014-01-10  Richard Biener  

PR tree-optimization/59374
* tree-vect-slp.c (vect_slp_analyze_bb_1): Move dependence
checking after SLP discovery.  Mark stmts not participating
in any SLP instance properly.

* gcc.dg/torture/pr59374-3.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr59374-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/59374] [4.7/4.8 Regression] -ftree-slp-vectorize breaks unique_ptr's move constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression]
   |-ftree-slp-vectorize breaks |-ftree-slp-vectorize breaks
   |unique_ptr's move   |unique_ptr's move
   |constructor |constructor
  Known to fail|4.9.0   |

--- Comment #10 from Richard Biener  ---
Now hopefully really fixed on trunk ;)

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
The actual REGNO != REGNO transformation is correct, the problem is that the
second extension is to a wider mode and while handling that we change the
destination mode on the def_insn to an even wider mode.  The code just assumes
that the def insn sets the right REGNO rather than some other.  So, I think it
shouldn't be hard to detect that case.  Then we either need to ensure the
corresponding copy insn from the first extension will be adjusted to the wider
mode, or for this case swap back the registers (revert to the original REGNO
for the def insn and put the swap insn the other way around), or do it the
other way around always (then no special casing would be needed; Jeff, what was
the reason why you haven't handled
(set (reg1) (expression))
(set (reg2) (any_extend (reg1))
as
(set (reg1) (any_extend (expression)))
(set (reg2) (reg1))
but instead
(set (reg2) (any_extend (expression)))
(set (reg1) (reg2))
?).

[Bug c/59755] BUG Increment Operator with Accessing Arrays

[octo.nebula at gmail dot com]

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

Arjun  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #3 from Arjun  ---
Why is that so?

Shouldn't the value of m increment after the array indexing? Could you please
explain?

[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance

[hubicka at gcc dot gnu.org]

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

--- Comment #20 from Jan Hubicka  ---
Looking even deeper, there are two problems.  The first is that we miss C in
type hiearchy graph.

C however may be defined in other unit. We do mistake already while walking B. 
There are two variants of B::foo.  One when base A is non-virtual and other
when it is virtual.

B's vtable is:
_ZTV1C: 
.quad   0
.quad   8
.quad   8
.quad   0
.quad   _ZTI1C
.quad   _ZTv0_n24_N1B3fooEv
.quad   -8
.quad   0
.quad   -8
.quad   _ZTI1C
.quad   _ZN1B3fooEv

Our walking logic misses the fact that descendands of B may use the thunk
instead of FOO based on presence of virtual inheritance.

I suppose for complete correctness I would have to add code associating methods
with their virtual thunks and lookup the thunks when walking B and knowng that
I am interested in the derived types.

Simpler solution solving both problems practically is probably to simply walk
known vtables and insert their types to the type hiearchy: all internal
devirtualizations will be correct and all the missed calls to thunk from vtable
of type defined externally are harmless: the visibility code already makes all
the assumption that the call can happen.

[Bug c/59755] BUG Increment Operator with Accessing Arrays

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Please read the section on -Wsequence-point:
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

[Bug c/59755] BUG Increment Operator with Accessing Arrays

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|WONTFIX |INVALID

[Bug tree-optimization/59757] New: Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

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

Bug ID: 59757
   Summary: Unexpected VN_TOP in SSCVN
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye at arm dot com

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

target: arm-none-eabi
host: Only Windows (crossbuild with i586-mingw32msvc). The same revision
doesn't fail on Linux
GCC revision: trunk 20141009 and 4.8
Option: -O3

> arm-none-eabi-gcc -O3 foo.c
foo.c: In function 'univision_ug2828gfeff01_init':
foo.c:119:1: internal compiler error: tree check: expected ssa_name, have
var_de
cl in vn_reference_lookup_2, at tree-ssa-sccvn.c:1497
 univision_ug2828gfeff01_init(CTL_GFX_SEP_DRIVER_t *d, int depth)
 ^

foo.c:119:1: internal compiler error: Segmentation fault

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[joey.ye at arm dot com]

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

--- Comment #1 from Joey Ye  ---
foo.c: In function 'univision_ug2828gfeff01_init':
foo.c:119:1: internal compiler error: tree check: expected ssa_name, have
var_de
cl in vn_reference_compute_hash, at tree-ssa-sccvn.c:631
 univision_ug2828gfeff01_init(CTL_GFX_SEP_DRIVER_t *d, int depth)

Traced to SSCVN:
Breakpoint 1, vn_reference_compute_hash (vr1=0x798fa94)
at /xxx/src/gcc/gcc/tree-ssa-sccvn.c:598
598 in /xxx/src/gcc/gcc/tree-ssa-sccvn.c

Backtrace is 
vn_reference_lookup

(gdb) call debug_tree(vr1->vuse)
 >
used ignored VOID file foo.c line 119 col 1
align 8>

(gdb) call debug_tree(VN_TOP)
 >
used ignored VOID file foo.c line 119 col 1
align 8>

For some reason vr1->vuse is VN_TOP, which is unexpected. But I couldn't go
further without understanding SCCVN.

Anyone can help?

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Cannot reproduce with cross from x86_64-linux (as you said ...).  So it's not
easy to help here.

[Bug fortran/57959] [F03] ICE with structure constructor with scalar allocatable components

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from janus at gcc dot gnu.org ---
obviously a duplicate

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

[Bug libstdc++/59756] off-by-one error in regex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|4.8.2   |4.9.0
 Resolution|--- |FIXED

--- Comment #1 from Jonathan Wakely  ---
 doesn't work in 4.8 (it's not an off-by-one it's just a garbage
character followed by the matched group)

Fixed in 4.9

[Bug fortran/55932] [F03] ICE for structure constructor with scalar allocatable component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #8 from janus at gcc dot gnu.org ---
*** Bug 57959 has been marked as a duplicate of this bug. ***

[Bug fortran/57965] Allocation of derived type containing an allocatable character component segfaults

[janus at gcc dot gnu.org]

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

Bug 57965 depends on bug 57959, which changed state.

Bug 57959 Summary: [F03] ICE with structure constructor with scalar allocatable 
components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57959

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug libstdc++/59756] off-by-one error in regex

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
The garbage is because your program has a bug. You match a temporary string, so
the smatch object contains invalid iterators into an object that no longer
exists.

[Bug fortran/55932] [F03] ICE for structure constructor with scalar allocatable component

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> *** Bug 57959 has been marked as a duplicate of this bug. ***

carry-over from the above:

Loosely related: PR 49213.

[Bug sanitizer/59758] New: [4.9 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu

[doko at gcc dot gnu.org]

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

Bug ID: 59758
   Summary: [4.9 Regression] bootstrap failure in
libsanitizer/asan on sparc-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

seen with trunk 20140109:

/bin/bash ../libtool --tag=CXX   --mode=compile /«PKGBUILDDIR»/build/./gcc/xgcc
-shared-libgcc -B/«PKGBUILDDIR»/build/./gcc -nostdinc++
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/src
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/sparc-linux-gnu/bin/ -B/usr/sparc-linux-gnu/lib/ -isystem
/usr/sparc-linux-gnu/include -isystem /usr/sparc-linux-gnu/sys-include -isystem
/«PKGBUILDDIR»/build/sys-include-D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  -I.
-I../../../../src/libsanitizer/sanitizer_common  -I
../../../../src/libsanitizer/include   -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/sparc-linux-gnu
-I../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE
-MT sanitizer_platform_limits_linux.lo -MD -MP -MF
.deps/sanitizer_platform_limits_linux.Tpo -c -o
sanitizer_platform_limits_linux.lo
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
libtool: compile:  /«PKGBUILDDIR»/build/./gcc/xgcc -shared-libgcc
-B/«PKGBUILDDIR»/build/./gcc -nostdinc++
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/src
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/sparc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/sparc-linux-gnu/bin/ -B/usr/sparc-linux-gnu/lib/ -isystem
/usr/sparc-linux-gnu/include -isystem /usr/sparc-linux-gnu/sys-include -isystem
/«PKGBUILDDIR»/build/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I.
-I../../../../src/libsanitizer/sanitizer_common -I
../../../../src/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/sparc-linux-gnu
-I../../../../src/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE
-MT sanitizer_platform_limits_linux.lo -MD -MP -MF
.deps/sanitizer_platform_limits_linux.Tpo -c
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
 -fPIC -DPIC -o .libs/sanitizer_platform_limits_linux.o
In file included from
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:40:0:
/usr/include/sparc-linux-gnu/asm/stat.h:60:2: error: 'time_t' does not name a
type
  time_t  st_atime;
  ^
/usr/include/sparc-linux-gnu/asm/stat.h:62:2: error: 'time_t' does not name a
type
  time_t  st_mtime;
  ^
/usr/include/sparc-linux-gnu/asm/stat.h:64:2: error: 'time_t' does not name a
type
  time_t  st_ctime;
  ^
In file included from
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:20:0:
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:66:16:
error: 'struct___old_kernel_stat_sz' was not declared in this scope
 COMPILER_CHECK(struct___old_kernel_stat_sz == sizeof(struct
__old_kernel_stat));
^
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:257:65:
note: in definition of macro 'IMPL_COMPILER_ASSERT'
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
 ^
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:66:1:
note: in expansion of macro 'COMPILER_CHECK'
 COMPILER_CHECK(struct___old_kernel_stat_sz == sizeof(struct
__old_kernel_stat));
 ^
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:66:78:
error: invalid application of 'sizeof' to incomplete type '__old_kernel_stat'
 COMPILER_CHECK(struct___old_kernel_stat_sz == sizeof(struct
__old_kernel_stat));
  ^
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:257:65:
note: in definition of macro 'IMPL_COMPILER_ASSERT'
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
   

[Bug libstdc++/59687] The description of ios::noreplace is hilarious

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 10 14:30:27 2014
New Revision: 206525

URL: http://gcc.gnu.org/viewcvs?rev=206525&root=gcc&view=rev
Log:
PR libstdc++/59687
* doc/xml/manual/backwards_compatibility.xml
(backwards.third.nocreate_noreplace): Correct and expand.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml

[Bug libstdc++/59687] The description of ios::noreplace is hilarious

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
fixed for 4.9

[Bug libstdc++/59698] The type of NULL is described elsewhere

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 10 14:30:21 2014
New Revision: 206524

URL: http://gcc.gnu.org/viewcvs?rev=206524&root=gcc&view=rev
Log:
PR libstdc++/59698
* doc/xml/manual/status_cxx1998.xml (iso.1998.specific): Markup
and stylistic improvements.
* doc/xml/manual/codecvt.xml (std.localization.facet.codecvt): Likewise
and update for C++11.
* doc/xml/manual/ctype.xml (std.localization.facet.ctype): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/codecvt.xml
trunk/libstdc++-v3/doc/xml/manual/ctype.xml
trunk/libstdc++-v3/doc/xml/manual/status_cxx1998.xml

[Bug libstdc++/59699] Effective C++ has moved

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
fixed for 4.9

[Bug libstdc++/59699] Effective C++ has moved

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 10 14:30:32 2014
New Revision: 206526

URL: http://gcc.gnu.org/viewcvs?rev=206526&root=gcc&view=rev
Log:
PR libstdc++/59699
* doc/xml/manual/support.xml (std.support.types.null): Update links.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/support.xml

[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Started by r192211.

[Bug libstdc++/59698] The type of NULL is described elsewhere

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Jonathan Wakely  ---
fixed for 4.9

[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 31797
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31797&action=edit
gcc49-pr59387.patch

Untested fix.

[Bug c++/9744] Explicit parameterization of templated return value fails within templated function

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri Jan 10 15:12:03 2014
New Revision: 206529

URL: http://gcc.gnu.org/viewcvs?rev=206529&root=gcc&view=rev
Log:
PR target/9744

gcc:
* aarch64-modes.def (CC_Zmode): New flags mode.
* aarch64.c (aarch64_select_cc_mode): Only allow NEG when the condition
represents an equality.
(aarch64_get_condition_code0): Handle CC_Zmode.
* aarch64.md (compare_neg): Restrict to equality operations.

gcc/testsuite:
* gcc.target/aarch64/cmn-neg.c: Use equality comparisons.
* gcc.target/aarch64/cmn-neg2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/cmn-neg2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-modes.def
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/cmn-neg.c

[Bug target/59744] miscompilation of unsigned comparison on aarch64

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #3 from Richard Earnshaw  ---
Fixed on trunk

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
This has been fixed (199971 still ICEs, but 200471 is ok).

[Bug target/59744] miscompilation of unsigned comparison on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri Jan 10 15:21:21 2014
New Revision: 206530

URL: http://gcc.gnu.org/viewcvs?rev=206530&root=gcc&view=rev
Log:
PR target/59744
Fix ChangeLog typos in previous commit (r206529).


Modified:
trunk/gcc/ChangeLog

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[barry.m.tannenbaum at intel dot com]

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

Barry Tannenbaum  changed:

   What|Removed |Added

 CC||barry.m.tannenbaum at intel 
dot co
   ||m

--- Comment #6 from Barry Tannenbaum  ---
Hi.  I'm one of the Cilk runtime developers.  Balaji asked me to help him with
this since it's a Cilk runtime issue.

I don't understand the reluctance to check the defintion of
__cpu_set_t_defined, since it's defined right there in
/usr/include/bits/sched.h on my Ubuntu system.  Is the problem that it's not a
"top-level" include file?

How about if I check the macros defined in /usr/include/sched.h.  I could
easily check for a defintion of CPU_SETSIZE, for example.

- Barry

[Bug c++/16168] -Weffc++ item 14 improvements

[gcc-o...@ben-kiki.org]

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

Oren Ben-Kiki  changed:

   What|Removed |Added

 CC||gcc-o...@ben-kiki.org

--- Comment #6 from Oren Ben-Kiki  ---
This still occurs in 4.8.2, and is an extremely annoying issue; it makes
-Weffc++ very difficult to apply to a code base.

This warning really should be restricted to cases where the base class has a
virtual function. For extra credit, we could keep the warning for cases where
the base class has no virtual functions, but the derived class adds data
members with "non trivial" destructors.

This is unrelated to the question of allowing finer grained control over the
warnings of -Weffc++; emitting this warning for cases like `struct Foo{};
struct Bar : Foo{};` just makes no sense and clearly isn't what was intended by
the effective C++ rule.

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

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Marek Polacek from comment #2)
> This has been fixed (199971 still ICEs, but 200471 is ok).

Shouldn't we add the testcase?

[Bug c/56409] internal compiler error while compiling Python 2.7.3 on Sun

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Marek Polacek  ---
No feedback for almost a year.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
(In reply to H.J. Lu from comment #3)
> Shouldn't we add the testcase?

We already have one: c-c++-common/cilk-plus/AN/pr57577.c

[Bug c++/16168] -Weffc++ item 14 improvements

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Oren Ben-Kiki from comment #6)
> This still occurs in 4.8.2, and is an extremely annoying issue; it makes
> -Weffc++ very difficult to apply to a code base.

So don't use -Weffc++ then. It's flawed in a number of ways.

[Bug other/58996] [4.9 regression] build failure in libcilkrts

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Not everything in glibc headers is meant for use by other packages, some
symbols in there are just implementation details that can change any time.
The affinity support is complicated, as it has changed several times in the
history.  There are glibc 2.3.3 (2003-ish) versions of the APIs without size
parameters and 2.3.4 (2004-ish) versions of the APIs with size parameter, and
the macros changed several times, with the last API changes in glibc 2.7
(2007-ish).
So, ideally you want to grab glibc 2.3.2, glibc 2.3.3, glibc 2.3.4, glibc 2.5,
glibc 2.6, glibc 2.7 headers and test against all those.
You want to support more than 1024 CPUs in the masks too, at least for building
with sufficiently new glibc, handle the case when there is no affinity support
in glibc at all (or there is, but it fails at runtime because e.g. kernel is
too old), and depending on what versions of headers you want to handle (there
are still long time support distros with e.g. glibc 2.5) use either the non-_S
or _S macros.

[Bug c++/16168] -Weffc++ item 14 improvements

[o...@ben-kiki.org]

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

--- Comment #8 from o...@ben-kiki.org ---
Well... it does provide some really useful stuff.

I think it is reasonable to expect that as long as -Weffc++ is in the
compiler, it should make sense, and this specific behavior doesn't. If it
has other flaws, well then, they'd also need to be fixed.

One could argue that having -Weffc++ is the wrong approach in the 1st
place, and what we really need is a "standard" lint++, blessed by the
masters-of-C++ (assuming we can agree on who they are ;-). But that's
another discussion...


On Fri, Jan 10, 2014 at 5:59 PM, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16168
>
> --- Comment #7 from Jonathan Wakely  ---
> (In reply to Oren Ben-Kiki from comment #6)
> > This still occurs in 4.8.2, and is an extremely annoying issue; it makes
> > -Weffc++ very difficult to apply to a code base.
>
> So don't use -Weffc++ then. It's flawed in a number of ways.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes

[gereon.kremer at cs dot rwth-aachen.de]

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

--- Comment #1 from Gereon Kremer  ---
Created attachment 31800
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31800&action=edit
Preprocessed file

[Bug c++/59730] ICE: in type_dependent_expression_p, at cp/pt.c:19969

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Backporting makes sense to me.

[Bug c/58346] ICE with SIGFPE at -O1 and above on x86_64-linux-gnu (affecting trunk, 4.8, 4.7, and 4.6)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #8 from Marek Polacek  ---
I'll to try teach the C FE to give an error when subtracting two pointers to
empty aggregates.

[Bug lto/47889] [4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228

[d.g.gorbachev at gmail dot com]

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

--- Comment #16 from Dmitry Gorbachev  ---
Created attachment 31801
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31801&action=edit
Backtrace from non-checked 4.7.4 build

[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #3 from Eric Botcazou  ---
> Cannot reproduce with cross from x86_64-linux (as you said ...).  So it's not
> easy to help here.

Try from i586-linux with gcc/g++ -m32.

[Bug lto/47889] [4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

  Attachment #23485|0   |1
is obsolete||

--- Comment #15 from Dmitry Gorbachev  ---
Created attachment 31799
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31799&action=edit
Backtrace from checked 4.7.4 build

> 4.7.4, not the prerelease?

The latest 4.7 release is 4.7.3 , 4.7.4 is still
pre.

I just tried the head of the 4.7 branch (r206505). Segmentation fault.

[Bug c++/59759] New: internal compiler error: in unify, using std::enable_if on classes

[gereon.kremer at cs dot rwth-aachen.de]

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

Bug ID: 59759
   Summary: internal compiler error: in unify, using
std::enable_if on classes
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gereon.kremer at cs dot rwth-aachen.de

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

Im using gcc version 4.8.2 20131219 (prerelease) (GCC) on arch linux.
When the attached file is compiled with "g++ Test_GCC.cpp -std=c++11", it
crashes with the following output:

Test_GCC.cpp: In function ‘int main()’:
Test_GCC.cpp:21:7: internal compiler error: in unify, at cp/pt.c:17171
  f(map);
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||law at redhat dot com
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

[Bug c++/16168] -Weffc++ item 14 improvements

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to oren from comment #8)
> I think it is reasonable to expect that as long as -Weffc++ is in the
> compiler, it should make sense, and this specific behavior doesn't. If it
> has other flaws, well then, they'd also need to be fixed.

It's reasonable to expect that, but it doesn't match reality, and reality wins.
So if you find the flaws "extremely annoying" then don't use it.

Or, alternatively, contribute a fix to the compiler, ideally breaking up
-Weffc++ into separate warnings that can be enabled/disabled individually, and
fixing the outdated ones ... see PR 16166

[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
I'd say a dup of PR59115.

[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes

[gereon.kremer at cs dot rwth-aachen.de]

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

--- Comment #3 from Gereon Kremer  ---
(In reply to Marek Polacek from comment #2)
> I'd say a dup of PR59115.

I checked the following code from PR59115 that should also trigger this bug:

template void foo(T, U) {}
void bar()
{
  foo(0, 0);
}

This does not trigger an ICE for me, but produces the following, hence it does
not seem like a duplicate to me...

Test_GCC.cpp:15:30: error: ‘float’ is not a valid type for a template non-type
parameter
 template void foo(T, U) {}
  ^
Test_GCC.cpp:19: confused by earlier errors, bailing out

[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
The following also runs without error.

My initial thought is that the content of the string after the 20th char is
undefined and this results in undefined behavior.  As Steve notes, any junk can
be in there.

C TEST READING FROM CHARACTER STRING
  CHARACTER*144 LINE
C
  LINE(1:20)=' 12,30.0,10.5,0 '
C CRASHES AT RUN-TIME UNLESS THE FOLLOWING LINE IS UNCOMMENTED
C LINE(30:30)=CHAR(10)
  READ (LINE(1:20),*) I1,R1,R2,I2
  WRITE (*,1000) I1,R1,R2,I2
 1000 FORMAT (I4,2F10.2,I4)
  END

I think the original code is invalid because of the undefined string. Prior to
the patch mentioned in Comment 1, the run-time library did not "read" or
interpret an EOF character.

Tracing the error shows that the error occurs in finish_list_read where we do
an eat_line which gives the error.  If we want to accept the behavior, we
probably could have a unique eat_line for internal character units.

I am not sure we want to accept the behavior yet and I don't think we should
call it a regression.

[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size

[nickc at gcc dot gnu.org]

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

--- Comment #15 from Nick Clifton  ---
Created attachment 31802
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31802&action=edit
Fix gcc's emission of assembler directives for a variable length structure

Hi Guys,

  I think that the problem is the output_constant function in varasm.c which is
given a target size, but which can emit more bytes than expected if the
expression is a variable length structure.

  This patch updates output_constant so that it returns the number of bytes
that it really did emit, and it updates a couple of places where
output_constant is used so that this corrected size is taken into account.

  Tested without regressions on an i686-pc-linux-gnu toolchain and an
aarch64-elf toolchain.  Does anyone have any objections to my submitting the
patch to gcc-patches ?

Cheers
  Nick

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

--- Comment #17 from Richard Earnshaw  ---
Author: rearnsha
Date: Fri Jan 10 16:54:43 2014
New Revision: 206533

URL: http://gcc.gnu.org/viewcvs?rev=206533&root=gcc&view=rev
Log:
PR rtl-optimization/54300

gcc:
* regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
outputs in a single-set are killed from the value chains.
gcc/testsuite:
* gcc.target/arm/pr54300.C: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr54300.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/regcprop.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/16168] -Weffc++ item 14 improvements

[gcc-o...@ben-kiki.org]

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

--- Comment #10 from Oren Ben-Kiki  ---
All good points, which you could say about many opened bugs.

The `-Weffc++` flag is a useful tool to keep large code bases working, even
when written by less-than-guru C++ programmers. As someone tending a large
framework used by such developers, this specific bug "has non-trivial impact on
my code base", hence the original comment expressing the need for it to be
fixed.

I assume that the GCC maintainers keep an eye on the bug boards and fix bugs
depending on their impact on people's code. I hope this matched reality :-)

I suppose using the word "annoying", while concise, might have convey
additional unintentional connotations; if so, consider this a clarification of
the original intent.

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Richard Earnshaw  ---
Fixed on all active branches

[Bug c++/59760] New: use_thunk internal error on default destructor declarations

[sshannin at gmail dot com]

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

Bug ID: 59760
   Summary: use_thunk internal error on default destructor
declarations
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sshannin at gmail dot com
  Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul
27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Target: x86_64-unknown-linux-gnu
 Build: ../gcc-4.8.2/configure --disable-multilib
--enable-languages=c++ --program-suffix=-4.8.2

Compile line (sans includes):

g++-4.8.2 -std=c++0x -O0 -g3 -Wall -c \
-MMD -MP -MF"build/./example_dir/example.d"
-MT"build/./example_dir/example.o" \
-o build/./example_dir/example.o example_dir/example.cpp

I'm getting an internal compiler error. Details which are likely of note:
 1. templated class
 2. inherits privately from two other templated classes
 3. all three classes have virtual destructor declarations set to '= default'
 4. changing the destructor declaration in the derived class from '= default'
   to '{}' resolves the issue
 5. changing the destructor declarations in either/both base classes appears to
have no effect

I am not able to generate a condensed example at the moment and as such am
refraining from attaching the preprocessed source (large). I'm hoping that the
gcc backtrace along with point #4 above may be enough. 

internal compiler error: in use_thunk, at cp/method.c:338
 virtual ~twenty_three_char_name_() = default;
 ^
0x599594 use_thunk(tree_node*, bool)
../../gcc-4.8.2/gcc/cp/method.c:338
0x5a44ec emit_associated_thunks(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3774
0x5a47a7 expand_or_defer_fn(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3901
0x5bc0bd maybe_clone_body(tree_node*)
../../gcc-4.8.2/gcc/cp/optimize.c:428
0x5a459d expand_or_defer_fn_1(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3825
0x5a4778 expand_or_defer_fn(tree_node*)
../../gcc-4.8.2/gcc/cp/semantics.c:3895
0x59a70f synthesize_method(tree_node*)
../../gcc-4.8.2/gcc/cp/method.c:809
0x5471ea mark_used(tree_node*)
../../gcc-4.8.2/gcc/cp/decl2.c:4677
0x4f3d4c build_over_call
../../gcc-4.8.2/gcc/cp/call.c:7055
0x4f11f8 build_new_method_call_1
../../gcc-4.8.2/gcc/cp/call.c:7715
0x4f11f8 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc-4.8.2/gcc/cp/call.c:7785
0x4f1a9e build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc-4.8.2/gcc/cp/call.c:7352
0x591dcf expand_cleanup_for_base
../../gcc-4.8.2/gcc/cp/init.c:1217
0x596301 expand_cleanup_for_base
../../gcc-4.8.2/gcc/cp/init.c:1112
0x596301 emit_mem_initializers(tree_node*)
../../gcc-4.8.2/gcc/cp/init.c:1097
0x56e16c cp_parser_mem_initializer_list
../../gcc-4.8.2/gcc/cp/parser.c:11736
0x56e16c cp_parser_ctor_initializer_opt
../../gcc-4.8.2/gcc/cp/parser.c:11647
0x56e16c cp_parser_ctor_initializer_opt_and_function_body
../../gcc-4.8.2/gcc/cp/parser.c:17858
0x56e7bf cp_parser_function_definition_after_declarator
../../gcc-4.8.2/gcc/cp/parser.c:21853
0x56f3c3 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-4.8.2/gcc/cp/parser.c:21774

[Bug go/59431] [4.9 regression] runtime FAILs on Solaris

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Yeah, I didn't think that would fix this problem, I was just hoping for more
consistent error messages--e.g., "out of memory" rather than "caught signal
while mallocing: 10".

[Bug fortran/59700] [4.8/4.9 Regression] Misleading/buggy runtime error message: Bad integer for item 0 in list input

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
The item_count variable serves two purposes.  This was done because we were
trying to preserve dtp space and ABI compatibility. I dont remember all the
details of why.  At any rate, when reading logicals we have to scan ahead to
confirm a valid read, so we created the infamous line_buffer.  The variable
item_count related to the line_buffer is just a pointer into the line_buffer,
it contains the current position in that scan ahead process.  The error
messages just need to change and not refer to the item in the read list.
Instead, they should refer to the location in the line where the error
occurred.

642  dtp->u.p.line_buffer[dtp->u.p.item_count++] = c;

is simply getting the next character in the line.  We probably could have used
some sort of substructure union like u.p.uu.place and u.p.uu.item_count to
avoid the confusion. Unrelated to this PR.

[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
In response to your question in c#6, if you use the most obvious form:

ORIG:
(set (reg1) (expression))
(set (reg2) (any_extend (reg1))
TRANSFORMED:
(set (reg1) (any_extend (expression)))
(set (reg2) (reg1))

Then the copy isn't typically propagated away and we don't actually improve the
code. If we look at the original testcase, the obvious form would look
something like this:

(insn 9 5 24 2 (set (reg:DI 0 ax)
(sign_extend:DI (mem:HI (plus:DI (mult:DI (reg/v:DI 1 dx [orig:91 rdx ]
[91])
(const_int 2 [0x2]))
(symbol_ref:DI ("code")  ))
[2 code S2 A16]))) l.c:13 144 {extendhidi2}
 (nil))
(insn 24 9 12 2 (set (reg/v:DI 1 dx [orig:84 rdx ] [84])
(reg:DI 0 ax)) l.c:13 -1
 (nil))
(note 12 24 13 2 NOTE_INSN_DELETED)
(insn 13 12 14 2 (set (reg:DI 0 ax [orig:95 D.1797 ] [95])
(zero_extend:DI (reg:QI 0 ax [orig:83 D.1796 ] [83]))) l.c:16 133
{zero_extendqidi2}
 (nil))
(insn 14 13 15 2 (parallel [
(set (reg:DI 1 dx [orig:96 rdx ] [96])
(ashiftrt:DI (reg/v:DI 1 dx [orig:84 rdx ] [84])
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) l.c:15 563 {*ashrdi3_1}
 (nil))

To get any improvement we must be able to propagate insn24 away and that's
nontrivial to do in that form.