[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.

[Hale.Wang at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123

--- Comment #6 from Hale Wang  ---
Thanks for Zhenqiang Chen's help. This bug is fixed. Refer to the link
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01429.html

[Bug tree-optimization/61569] New: faggressive-loop-optimizations overoptimize loop checks with unpredicted result

[n-gcc at nn dot kiev.ua]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61569

Bug ID: 61569
   Summary: faggressive-loop-optimizations overoptimize loop
checks with unpredicted result
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: n-gcc at nn dot kiev.ua

The following program performs 112 iterations (and stop on x==1) instead of
expected 10 ones.

#include 

int main()
{
int i, x = 27;
for (i = 0; i < 10; ++i)
{
printf("%11d : %11d : %d\n", i, i*10, x);
if (x==1) break;
x = x%2 ? x*3+1 : x/2;
}
return 0;
}

With a small change, it, instead, limits itself to 3 iterations.

#include 

int main()
{
int i, j, x = 27;
for (i = j = 0; i < 10; ++i, ++j)
{
printf("%11d : %11d : %d\n", i, j*10, x);
if (x==1) break;
x = x%2 ? x*3+1 : x/2;
}
return 0;
}

Conditions to represent the issue are:
1. gcc after 4.8.0 (my versions gcc48-4.8.4.s20140605 and gcc49-4.9.1.s20140611
from FreeBSD ports).
2. -O2 or higher, or -Os.

The issue goes after any of the following options added:
* -fno-aggressive-loop-optimizations
* -fno-strict-overflow
* -fwrapv or -ftrapv (obviously)

Stage dump analysis shows that loop exit condition check (i<10 in that code
examples, i<=9 internally after some change) is gone away at 056t.cunrolli.

Adding of -Wstrict-overflow of any level doesn't cause warning emission.

The similar issue was reported in #58143 comment 9, and #53265 seems devoted to
lack of warning, but I'm not sure cases are equal.

Disclaimer: I'm aware of standard's statement "signed integer overflow is UB"
but I'm confident that a respected common-goal compiler should thoroughly limit
this UB to result value of the operator itself and avoid expanding it to any
other program action.

Thanks to: livejournal.com user _winnie for issue finding; user kodt_rsdn
(Nikolay Merkin) for the clear example designing; Serge Ryabchun for diagnosing
-faggressive-loop-optimizations influence.

[Bug testsuite/61567] gfortran.dg/coarray_collectives_{5,6}.f90 failure

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61567

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
FIXED.

Thanks for the report and sorry for the breakage. When testing what became
r211816, I wondered why it didn't require testsuite changes – well, it turned
out it did, but I had looked at the wrong testsuite log file.

[Bug testsuite/61567] gfortran.dg/coarray_collectives_{5,6}.f90 failure

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61567

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Fri Jun 20 05:24:09 2014
New Revision: 211833

URL: https://gcc.gnu.org/viewcvs?rev=211833&root=gcc&view=rev
Log:
2014-06-20  Tobias Burnus  

PR testsuite/61567
* gfortran.dg/coarray_collectives_5.f90: Update
dg-final scan-tree-dump-times.
* gfortran.dg/coarray_collectives_6.f90: Ditto.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_5.f90
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_6.f90

[Bug c++/61568] New: unscoped enums different types differ from __underlying_type

[myriachan at cox dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61568

Bug ID: 61568
   Summary: unscoped enums different types differ from
__underlying_type
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at cox dot net

If you have an unscoped, unfixed-type enum whose members exist solely within
[0...INT_MAX], the enum type is considered "signed int", but the
"__underlying_type" intrinsic operator returns "unsigned int".  As a result,
the following paradoxical C++ code compiles when it should not.  (This also
occurs if you use type_traits and std::underlying type instead of the intrinsic
directly.)

This may be a duplicate of bug 58559.


template  struct type_is_unsigned_int { static const bool value =
false; };
template <> struct type_is_unsigned_int { static const bool value
= true; };

enum unscoped_unfixed_size_enum {
some_enum_name = 0,
};

static_assert(
static_cast(-1) <
static_cast(0),
"This assert doesn't fire, indicating that the enum is signed.");
static_assert(
static_cast<__underlying_type(unscoped_unfixed_size_enum)>(-1) >
static_cast<__underlying_type(unscoped_unfixed_size_enum)>(0),
"But neither does this one!  It's inconsistent.");
static_assert(
   
type_is_unsigned_int<__underlying_type(unscoped_unfixed_size_enum)>::value,
"The exact type in the implementation is, in fact, \"unsigned int\".");

[Bug target/61545] Miscompilation in libcap-ng

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61545

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Henderson  ---
Fixed.

[Bug bootstrap/61565] [4.10 Regression] ICE building libjava/interpret.cc

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-06-20
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Henderson  ---
Which clearly means some sort of latent bug in cmpelim.
Investigating...

[Bug bootstrap/61565] [4.10 Regression] ICE building libjava/interpret.cc

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |4.10.0
Summary|ICE building|[4.10 Regression] ICE
   |libjava/interpret.cc|building
   ||libjava/interpret.cc

[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.

[zqchen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123

--- Comment #5 from zqchen at gcc dot gnu.org ---
Author: zqchen
Date: Fri Jun 20 04:52:11 2014
New Revision: 211832

URL: https://gcc.gnu.org/viewcvs?rev=211832&root=gcc&view=rev
Log:
c-family/ChangeLog
2014-06-20 Hale Wang 

PR lto/61123
* c.opt (fshort-enums): Add to LTO.
* c.opt (fshort-wchar): Likewise.

testsuite/ChangeLog
2014-06-20 Hale Wang 

* gcc.target/arm/lto/: New folder to verify the LTO option.
* gcc.target/arm/lto/pr61123-enum-size_0.c: New test case.
* gcc.target/arm/lto/pr61123-enum-size_1.c: Likewise.
* gcc.target/arm/lto/lto.exp: New exp file used to test LTO option.
* lib/lto.exp (object-readelf): New procedure.

Added:
trunk/gcc/testsuite/gcc.target/arm/lto/
trunk/gcc/testsuite/gcc.target/arm/lto/lto.exp
trunk/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_0.c
trunk/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_1.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/lto.exp

[Bug bootstrap/61565] ICE building libjava/interpret.cc

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565

Richard Henderson  changed:

   What|Removed |Added

 CC||mshawcroft at gcc dot gnu.org

--- Comment #1 from Richard Henderson  ---
git bisect says the offending commit is

commit c0277521db0192171b1275c2b8d7cb5d4be488d9
Author: mshawcroft 
Date:   Tue Apr 22 16:08:33 2014 +

[AArch64] Define TARGET_FLAGS_REGNUM

Ramana noted:

This defines TARGET_FLAGS_REGNUM for AArch64 to be CC_REGNUM. Noticed
this turns on the cmpelim pass after reload and in a few examples and
a couple of benchmarks I noticed a number of comparisons getting
deleted.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@209643
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug target/61550] [4.10 Regression] [SH] build failure with ICE in gen_reg_rtx, at emit-rtl.c:943

[kkojima at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61550

Kazumoto Kojima  changed:

   What|Removed |Added

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

--- Comment #3 from Kazumoto Kojima  ---
Fixed.

[Bug testsuite/61567] gfortran.dg/coarray_collectives_{5,6}.f90 failure

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61567

--- Comment #1 from vries at gcc dot gnu.org ---
configure line:
...
src/configure --prefix=nobootstrap/install --with-cloog=infra --with-ppl=infra
--with-gmp=infra --with-mpfr=infra --with-mpc=infra --disable-bootstrap
--enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++
...

[Bug testsuite/61567] New: gfortran.dg/coarray_collectives_{5,6}.f90 failure

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61567

Bug ID: 61567
   Summary: gfortran.dg/coarray_collectives_{5,6}.f90 failure
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

Created attachment 32978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32978&action=edit
coarray_collectives_5.f90

I see these failures with r211823.

./gcc/testsuite/gfortran/gfortran.sum:
...
FAIL: gfortran.dg/coarray_collectives_5.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_max \\(&desc.., 0B, 0, &stat1, 0B, 0, 0\\);" 1
FAIL: gfortran.dg/coarray_collectives_5.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_min \\(&desc.., 0B, 0, &stat2, 0B, 0, 0\\);" 1
FAIL: gfortran.dg/coarray_collectives_5.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_sum \\(&desc.., 0B, 0, &stat3, 0B, 0\\);" 1
FAIL: gfortran.dg/coarray_collectives_6.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_max \\(&desc.., 0B, 0, &stat1, errmesg1, 0, 6\\);" 1
FAIL: gfortran.dg/coarray_collectives_6.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_sum \\(&val2, 0B, 4, &stat2, errmesg2, 7\\);" 1
FAIL: gfortran.dg/coarray_collectives_6.f90  -O   scan-tree-dump-times original
"_gfortran_caf_co_min \\(&desc.., 0B, res, &stat3, errmesg3, 99, 8\\);" 1
...

The original dump for coarray_collectives_5.f90 contains:
  _gfortran_caf_co_max (&desc.0, 0, &stat1, 0B, 0, 0);
and the scan for this pattern fails:
  _gfortran_caf_co_max \\(&desc.., 0B, 0, &stat1, 0B, 0, 0\\);

I tentatively marked this as a testsuite problem.

[Bug fortran/60718] [4.8 / 4.9 / 4.10 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm-none-linux-gnueabihf
 Status|UNCONFIRMED |NEW
  Known to work||4.7.2
   Keywords||wrong-code
   Last reconfirmed||2014-06-19
 CC||ramana at gcc dot gnu.org
   Host||arm-none-linux-gnueabihf
 Ever confirmed|0   |1
Summary|Test case   |[4.8 / 4.9 / 4.10
   |gfortran.dg/select_type_4.f |regression] Test case
   |90 fails on ARM |gfortran.dg/select_type_4.f
   ||90 fails on ARM
  Known to fail||4.8.0, 4.8.1, 4.8.2, 4.9.0

--- Comment #15 from Ramana Radhakrishnan  ---
This looks very similar to PR57297 and might even be a dup of that. I found
atleast one test result for 4.7.2 which shows it worked there. Therefore
technically a regression.

[Bug c++/61566] New: [4.9/4.10 Regression] ICE in write_unscoped_name

[ppluzhnikov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566

Bug ID: 61566
   Summary: [4.9/4.10 Regression] ICE in write_unscoped_name
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

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

Google ref: b/15734838

Test case compiles fine with Clang and current gcc-4_8-branch (@r211826).

Broken on trunk (and gcc-4_9) since not later than r195189.

Using current trunk @r211826:

gcc-svn-install/bin/g++ -c -std=c++11 t.cc
t.cc: In instantiation of 'std::function<_Res(_ArgTypes
...)>::function(_Functor) [with _Functor = C<>::;
 = int; _Res = std::A; _ArgTypes = {}]':

t.cc:24:7: internal compiler error: in write_unscoped_name, at cp/mangle.c:881
   function (_Functor);
   ^
0x727aa1 write_unscoped_name
../../gcc/cp/mangle.c:879
0x72b205 write_unscoped_template_name
../../gcc/cp/mangle.c:897
0x72b205 write_name
../../gcc/cp/mangle.c:810
0x72b0e0 write_local_name
../../gcc/cp/mangle.c:1808
0x72b0e0 write_name
../../gcc/cp/mangle.c:842
0x72bcbe write_class_enum_type
../../gcc/cp/mangle.c:2496
0x72bcbe write_type
../../gcc/cp/mangle.c:1954
0x72acc8 write_template_args
../../gcc/cp/mangle.c:2525
0x72f4ed write_nested_name
../../gcc/cp/mangle.c:941
0x72afa7 write_name
../../gcc/cp/mangle.c:854
0x72fe3b write_encoding
../../gcc/cp/mangle.c:704
0x730609 mangle_decl_string
../../gcc/cp/mangle.c:3383
0x730857 get_mangled_id
../../gcc/cp/mangle.c:3405
0x730857 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3428
0xdb03f0 decl_assembler_name(tree_node*)
../../gcc/tree.c:603
0x83f0d4 insert_to_assembler_name_hash
../../gcc/symtab.c:187
0x83f231 symtab_initialize_asm_name_hash()
../../gcc/symtab.c:366
0x84ea54 analyze_functions
../../gcc/cgraphunit.c:1135
0x84ffa5 finalize_compilation_unit()
../../gcc/cgraphunit.c:2333
0x63e4ae cp_write_global_declarations()
../../gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/61563] better 387 code for float x == (int)x

[jay.foad at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563

--- Comment #2 from Jay Foad  ---
I hadn't considered spurious "invalid" exceptions. I was only thinking about
the result of the whole expression, which I think is the same regardless of
rounding mode even for double and int.

[Bug sanitizer/61547] Invalid sanitization of trailing byte in __builtin_strlen

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61547

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Yeah, GCC is different in this regard.

[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux

[kumba at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538

--- Comment #9 from Joshua Kinard  ---
Rebuilt/upgraded to gcc-4.8.3 against the patched glibc-2.19, and I am still
getting the hang.

[Bug bootstrap/61565] New: ICE building libjava/interpret.cc

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565

Bug ID: 61565
   Summary: ICE building libjava/interpret.cc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org

Created attachment 32976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32976&action=edit
preprocessed file

$ cc1plus -quiet -O2 -fPIC -fnon-call-exceptions interpret.ii 

../../../git-rh/libjava/interpret.cc: In static member function ‘static void
_Jv_InterpMethod::run(void*, ffi_java_raw*, _Jv_InterpMethod*)’:
../../../git-rh/libjava/interpret.cc:991:1: error: missing REG_EH_REGION note
at the end of bb 961
 }
 ^
../../../git-rh/libjava/interpret.cc:991:1: error: missing REG_EH_REGION note
at the end of bb 944
../../../git-rh/libjava/interpret.cc:991:1: internal compiler error:
verify_flow_info failed
0x8282f3 verify_flow_info()
../../git-rh/gcc/cfghooks.c:260
0xac52bb execute_function_todo
../../git-rh/gcc/passes.c:1789
0xac5bcb execute_todo
../../git-rh/gcc/passes.c:1834

[Bug middle-end/61562] Compiler crash when combining -Wstrict-overflow=4 -O2

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61562

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-19
 CC||iant at google dot com,
   ||manu at gcc dot gnu.org
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
Also in trunk.

  if (strict_overflow_p)
fold_overflow_warning (("assuming signed overflow does not "
"occur when simplifying "
"X % (power of two)"),
   WARN_STRICT_OVERFLOW_MISC);

The % should probably be %%.

Everybody (even people that do not need approval) should add testcases when
adding new  warnings and errors.

[Bug c/61564] New: #pragma GCC optimize ("-fno-lto") causes the compiler to crash

[t.poechtrager at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61564

Bug ID: 61564
   Summary: #pragma GCC optimize ("-fno-lto") causes the compiler
to crash
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t.poechtrager at gmail dot com
Target: Linux x86_64, i686-w64-mingw32 and others

$ cat test.cpp
#pragma GCC push_options
#pragma GCC optimize ("-fno-lto")
int main(void){return 0;}
#pragma GCC pop_options

### GCC 4.9.0 ###
$ LC_ALL=C gcc test.cpp -flto 
test.cpp:4:24: internal compiler error: Segmentation fault
 #pragma GCC pop_options
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccpuDCNO.out file, please attach this to
your bugreport.

### GCC 4.6.4 ###
$ LC_ALL=C gcc-4.6 test.cpp -flto # no crash

[Bug target/61563] better 387 code for float x == (int)x

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563

--- Comment #1 from joseph at codesourcery dot com  ---
Note that it's only for certain pairs of floating-point and integer type 
that the rounding mode doesn't matter.  It's true for float and int, 
because the precision of float is small enough, compared to that of int, 
that values that are within range for int when converted rounding towards 
zero, but that might overflow and so cause a spurious "invalid" exception 
if converted in another rounding mode, can't be represented in float.  
But it's not true for double and int, for example (though maybe more cases 
are allowed by -fno-trapping-math).

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718

--- Comment #14 from Bernd Edlinger  ---
FYI: updated patch was posted at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00774.html
but not yet reviewed/approved.

[Bug target/61563] New: better 387 code for float x == (int)x

[jay.foad at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61563

Bug ID: 61563
   Summary: better 387 code for float x == (int)x
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.foad at gmail dot com

I get this with GCC 4.10.0 20140619 (experimental):

$ gcc -mno-sse -O3 -S -o - -x c - <<<"int f(float x) { return x == (int)x; }"
...
f:
fnstcw-2(%rsp)
movzwl-2(%rsp), %eax
flds8(%rsp)
movl$0, %edx
orb$12, %ah
movw%ax, -4(%rsp)
xorl%eax, %eax
fldcw-4(%rsp)
fistl-12(%rsp)
fldcw-2(%rsp)
fildl-12(%rsp)
fucomip%st(1), %st
fstp%st(0)
setnp%al
cmovne%edx, %eax
ret

All the fnstcw and fldcw stuff is unnecessary, because when we convert x to
int, it doesn't matter what rounding mode we use; all that matters is whether
it is already an exact int value or not.

I think the x == (int)x pattern is fairly common, and it would be nice if GCC
generated better 387 code for it.

[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510

--- Comment #3 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 32975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32975&action=edit
Reduced testcase.

Adding a reduced testcase for this bug. 

Honza: To answer your question, if I add gcc_assert (origin_node) before the
dereference, it triggers - so in my case we definitely do have a NULL
origin_node.

If I dump decl, DECL_ABSTRACT_ORIGIN (decl) the results look "sane" (I
think)...

decl:

full-name "std::scoped_allocator_adaptor<_OuterAlloc,
_InnerAllocs>::scoped_allocator_adaptor() [with _OuterAlloc =
std::allocator; _InnerAllocs = {}]"
pending-inline-info 0x7f32a2507ab0 template-info 0x7f32a2362680

DECL_ABSTRACT_ORIGIN:

full-name "std::scoped_allocator_adaptor<_OuterAlloc,
_InnerAllocs>::scoped_allocator_adaptor() [with _OuterAlloc =
std::allocator; _InnerAllocs = {}]"
pending-inline-info 0x7f32a2507990 template-info 0x7f32a2362680

cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl)) == (nil)

[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 Target|cris-axis-elf   |cris-axis-elf,
   ||arm-none-eabi,
   ||aarch64-none-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-19
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Confirmed across bare metal arm/aarch64 targets.

[Bug c++/61562] New: Compiler crash when combining -Wstrict-overflow=4 -O2

[zweije at xs4all dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61562

Bug ID: 61562
   Summary: Compiler crash when combining -Wstrict-overflow=4 -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zweije at xs4all dot nl

Created attachment 32974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32974&action=edit
Test output

gcc-4.9 crashes when combining -Wstrict-overflow=4 and -O2 on the following
code snippet:

void f() {
 unsigned char x = 0;
 (x * 185) % 256;
}

Also crashes when compiled as .cpp.

Test output attached.

[Bug translation/61561] arm gcc internal error

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561

--- Comment #3 from ktkachov at gcc dot gnu.org ---
FWIW On 4.7.4 without LRA the ICE is:
ice.c:9:1: error: insn does not satisfy its constraints:
(insn 25 12 19 2 (set (reg:QI 2 r2)
(reg:QI 13 sp)) ice.c:8 193 {*arm_movqi_insn}
 (nil))

But 4.7 is no loner maintained, so that's more of a trivia at this point

[Bug translation/61561] arm gcc internal error

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.7.4

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Also ICEs on 4.7.4, I guess that's been this way for a while

[Bug translation/61561] arm gcc internal error

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-19
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.10.0, 4.8.3, 4.9.1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed for trunk, 4.9 and 4.8.

Marat, please send the patch to gcc-patc...@gcc.gnu.org with an appropriate
ChangeLog entry and the included testcase for review.

[Bug translation/61561] New: arm gcc internal error

[m.zakirov at samsung dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561

Bug ID: 61561
   Summary: arm gcc internal error
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.zakirov at samsung dot com

Created attachment 32973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32973&action=edit
Proposed patch

To reproduce the issue do:
1) Configure gcc for arm as traget and x86 as host.
$ ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=arm-v7a15v5r2-linux-gnueabi
--prefix=/home/mzakirov/proj/gcc_arm_ref/arm-v7a15v5r2
--with-sysroot=/your_arm/sys-root
2) make -j6
3) make install
4) Compile following:
$ cat ex.c
int dummy(int a);

char a;

void mmm (void)
{
  char dyn[ dummy(3) ];
  a = (char)&dyn[0];
}
$ gcc -O3 ex.c -o ex.o 
ex.c: In function ‘mmm’:
ex.c:8:7: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   a = (char)&dyn[0];
   ^
ex.c:9:1: internal compiler error: in check_rtl, at lra.c:1919
 }
 ^
0x8689e5 check_rtl
   
/home/mzakirov/proj/gcc_arm_ref/build.arm.cortex-a15/sources/gcc_1/gcc/lra.c:1919
0x86bde5 lra(_IO_FILE*)
   
/home/mzakirov/proj/gcc_arm_ref/build.arm.cortex-a15/sources/gcc_1/gcc/lra.c:2309
0x82b02e do_reload
   
/home/mzakirov/proj/gcc_arm_ref/build.arm.cortex-a15/sources/gcc_1/gcc/ira.c:5325
0x82b02e execute
   
/home/mzakirov/proj/gcc_arm_ref/build.arm.cortex-a15/sources/gcc_1/gcc/ira.c:5486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Analysis showed that the problem in instruction like:
(insn 26 12 18 2 (set (reg:QI 2 r2)
(reg:QI 13 sp)) ex.c:8 205 {*arm_movqi_insn}
 (nil))
gcc cse propogates sp register to (char/short) cast from a pointer (32 bit
value) and reload phase fails because gcc do not founds applicable template for
loading a byte or word from sp.
Adding correct template to arm.md fixes the issue. See attached patch.

Note: that issue appeared while translating linux kernel for arm.

[Bug fortran/61454] ICE in simplification of initialization expression with array

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #4 from Francois-Xavier Coudert  ---
Fixed on trunk.

[Bug fortran/31392] [meta-bug] gfortran problems with initialization

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392
Bug 31392 depends on bug 61454, which changed state.

Bug 61454 Summary: ICE in simplification of initialization expression with array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454

   What|Removed |Added

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

[Bug fortran/61454] ICE in simplification of initialization expression with array

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454

--- Comment #3 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Thu Jun 19 11:58:55 2014
New Revision: 211822

URL: https://gcc.gnu.org/viewcvs?rev=211822&root=gcc&view=rev
Log:
PR fortran/61454
* expr.c (scalarize_intrinsic_call): Take care of optional
arguments.
* gfortran.dg/pr61454.f90: New file.

Added:
trunk/gcc/testsuite/gfortran.dg/pr61454.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61454] ICE in simplification of initialization expression with array

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Francois-Xavier Coudert  ---
Patch submitted for review:
https://gcc.gnu.org/ml/fortran/2014-06/msg00169.html

[Bug tree-optimization/61560] FAIL: gcc.dg/tree-ssa/ssa-fre-32.c on arm

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61560

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm-none-eabi
 CC||rguenther at suse dot de
  Known to work||4.9.0
  Known to fail||4.10.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
cc'ing richi as he touched that test and area last.

[Bug tree-optimization/61560] New: FAIL: gcc.dg/tree-ssa/ssa-fre-32.c on arm

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61560

Bug ID: 61560
   Summary: FAIL: gcc.dg/tree-ssa/ssa-fre-32.c on arm
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

Created attachment 32972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32972&action=edit
fre pass diff between bad and good dumps

On arm-none-eabi I see a regression in the aforementioned test:
FAIL: gcc.dg/tree-ssa/ssa-fre-32.c scan-tree-dump-times fre1 "return
x_\\d+\\(D\\);" 2

Curiously this doesn't happen for an aarch64-none-elf target built from the
same revision (r211782)

I'm attaching the diff between the failing (bad) fre dump for arm and the
passing (good) dump from aarch64

[Bug c++/59296] [c++11] ref-qualified member function is ambiguous

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Jun 19 09:36:09 2014
New Revision: 211821

URL: https://gcc.gnu.org/viewcvs?rev=211821&root=gcc&view=rev
Log:
PR c++/59296
* call.c (add_function_candidate): Also set LOOKUP_NO_TEMP_BIND.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/59296] [c++11] ref-qualified member function is ambiguous

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59296

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Jun 19 09:34:57 2014
New Revision: 211820

URL: https://gcc.gnu.org/viewcvs?rev=211820&root=gcc&view=rev
Log:
PR c++/59296
* call.c (add_function_candidate): Set LOOKUP_NO_RVAL_BIND
|LOOKUP_NO_TEMP_BIND for ref-qualifier handling.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual15.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/call.c

[Bug c++/61507] GCC does not compile function with parameter pack.

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61507

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Jun 19 09:34:48 2014
New Revision: 211819

URL: https://gcc.gnu.org/viewcvs?rev=211819&root=gcc&view=rev
Log:
PR c++/61507
* pt.c (resolve_overloaded_unification): Preserve
ARGUMENT_PACK_EXPLICIT_ARGS.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/variadic159.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/pt.c

[Bug fortran/61454] ICE in simplification of initialization expression with array

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61454

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #1 from Francois-Xavier Coudert  ---
In expr.c:scalarize_intrinsic_call(), we don't deal correctly with intrinsics
that have an optional kind argument. I'm testing this simple patch to fix it:


Index: expr.c
===
--- expr.c(revision 211685)
+++ expr.c(working copy)
@@ -1955,7 +1955,7 @@ scalarize_intrinsic_call (gfc_expr *e)
   for (; a; a = a->next)
 {
   n++;
-  if (a->expr->expr_type != EXPR_ARRAY)
+  if (!a->expr || a->expr->expr_type != EXPR_ARRAY)
 continue;
   array_arg = n;
   expr = gfc_copy_expr (a->expr);

[Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559

--- Comment #2 from Uroš Bizjak  ---
On a related note, -march=i386 generates long sequences of rol insns, e.g.:

foo5:
movl4(%esp), %eax
rolw$8, %ax
roll$16, %eax
rolw$8, %ax
movl8(%esp), %edx
rolw$8, %dx
roll$16, %edx
rolw$8, %dx
andl%edx, %eax
rolw$8, %ax
roll$16, %eax
rolw$8, %ax
ret

Please note that this arch doesn't have bswap insn, but this insn isn't
generated for optimized code anyway.

[Bug rtl-optimization/61559] FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559

Uroš Bizjak  changed:

   What|Removed |Added

 CC||thomas.preudhomme at arm dot 
com

--- Comment #1 from Uroš Bizjak  ---
Adding a CC that might be interested in this PR.

[Bug rtl-optimization/61559] New: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559

Bug ID: 61559
   Summary: FAIL: gcc.dg/builtin-bswap-8.c on i686 with -mmovbe
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
Target: i686-pc-linux-gnu

gcc.dg/builtin-bswap-8.c fails on i686 with -mmovbe:

~/gcc-build/gcc/cc1 -O2 -march=corei7 -mmovbe -m32 builtin-bswap-8.c

foo5:
movbe   4(%esp), %eax
movbe   8(%esp), %edx
andl%edx, %eax
bswap   %eax
ret
foo6:
movbe   4(%esp), %eax
movbe   8(%esp), %edx
orl %edx, %eax
bswap   %eax
ret
foo7:
movbe   4(%esp), %eax
movbe   8(%esp), %edx
xorl%edx, %eax
bswap   %eax
ret

It looks that direct swap from memory (movbe) interferes with bswap
elimination. Without -mmovbe, following asm is produced:

foo5:
movl8(%esp), %eax
andl4(%esp), %eax
ret
foo6:
movl8(%esp), %eax
orl 4(%esp), %eax
ret
foo7:
movl8(%esp), %eax
xorl4(%esp), %eax
ret

[Bug middle-end/61558] [4.10 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #2 from Markus Trippelsdorf  ---
Started with r211689.

[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796

--- Comment #5 from vincenzo Innocente  ---
so with latest 4.9 
gcc version 4.10.0 20140611 (experimental) [trunk revision 211467] (GCC) 
situation has not changed much (the scalar version is now faster!):
I think that the cost of gather instructions is still under-estimated

[Bug c++/61558] [4.10 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-06-19
 CC||trippels at gcc dot gnu.org
Version|4.9.0   |4.10.0
   Target Milestone|--- |4.10.0
Summary|ice in  |[4.10 Regression] ICE:
   |insert_to_assembler_name_ha |Segmentation fault
   |sh  |
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat bug2.ii
static __typeof 0 a __attribute__ ((__weakref__ ("")));
template  class A
{
  static __thread int b;
};


Program received signal SIGSEGV, Segmentation fault.
[Switching to process 20878]
decl_assembler_name_hash (asmname=0x0) at ../../gcc/gcc/symtab.c:80
80if (IDENTIFIER_POINTER (asmname)[0] == '*')
(gdb) bt
#0  decl_assembler_name_hash (asmname=0x0) at ../../gcc/gcc/symtab.c:80
#1  0x0083ca10 in insert_to_assembler_name_hash (node=0x773da078,
with_clones=) at ../../gcc/gcc/symtab.c:191
#2  0x0083cb62 in symtab_initialize_asm_name_hash () at
../../gcc/gcc/symtab.c:366
#3  0x0083ccbd in symtab_initialize_asm_name_hash () at
../../gcc/gcc/symtab.c:390
#4  symtab_node_for_asm (asmname=0x773d4420) at ../../gcc/gcc/symtab.c:379
#5  0x00848e91 in handle_alias_pairs () at
../../gcc/gcc/cgraphunit.c:1152
#6  0x0084d8bd in finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:2320
#7  0x0063b2af in cp_write_global_declarations () at
../../gcc/gcc/cp/decl2.c:4647
#8  0x00b85c2d in compile_file () at ../../gcc/gcc/toplev.c:562
#9  0x00b87c75 in do_compile () at ../../gcc/gcc/toplev.c:1918
#10 toplev_main (argc=12, argv=0x7fffdee8) at ../../gcc/gcc/toplev.c:1994
#11 0x775fbfb0 in __libc_start_main () from /lib/libc.so.6
#12 0x0054b841 in _start ()
(gdb) p asmname 
$1 = (const_tree) 0x0

[Bug c++/61558] New: ice in insert_to_assembler_name_hash

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558

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

Created attachment 32971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32971&action=edit
gzipped C++ source code

The attached source code, when compiled by trunk dated 20140618,
does this 

../results/bin/gcc -c bug150.cc
Swift/Controllers/FileTransfer/FileTransferController.cpp:149:1: internal
compiler error: Segmentation fault
0xa9697f crash_signal
../../src/trunk/gcc/toplev.c:337
0x7453b0 insert_to_assembler_name_hash
../../src/trunk/gcc/symtab.c:187
0x745f8b insert_to_assembler_name_hash
../../src/trunk/gcc/symtab.c:181
0x745f8b symtab_initialize_asm_name_hash()
../../src/trunk/gcc/symtab.c:366
0x745f8b symtab_node_for_asm(tree_node const*)
../../src/trunk/gcc/symtab.c:379
0x753320 handle_alias_pairs
../../src/trunk/gcc/cgraphunit.c:1152
0x756a5c finalize_compilation_unit()
../../src/trunk/gcc/cgraphunit.c:2320
0x5b720b cp_write_global_declarations()
../../src/trunk/gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler source code is

  tree name = DECL_ASSEMBLER_NAME (node->decl);

My guess is that node->decl is NULL.