[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[jakub at gcc dot gnu.org]

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

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

I've bootstrapped/regtested this version of the patch (feel free to rewrite the
ChangeLog entry), attaching just to show the testcase added on
{s390,s390x,powerpc,powerpc64}-linux (--enable-checking=yes), no regressions.

[Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

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

Bug ID: 60606
   Summary: ICE [ARM] error: insn does not satisfy its constraints
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.salikhov at samsung dot com

Created attachment 32414
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32414&action=edit
Code sample reproducing the bug

Reproduced on 4.8.0+ and on trunk.

*How to reproduce:*
Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"

*Compiler output:*
ice.c: In function 'alpha':
ice.c:5:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 5 2 6 (set (reg:SI 3 r3 [orig:110 pc.0 ] [110])
(reg/v:SI 15 pc [ pc ])) ice.c:4 641 {*arm_movsi_vfp}
 (nil))
ice.c:5:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:13693
0x83e1907 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:109
0x83e1945 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:120
0x85e4b49 note_invalid_constants
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:13693
0x85e4b49 arm_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:14031
0x83e17b8 rest_of_handle_machine_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/reorg.c:3939
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



*Commit introducing the bug:*
git hash: bffbb863ff0f267b5111bfa95b42c99cd0474424
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189350
138bc75d-0d04-0410-961f-82ee72b054a4



arm-v7a9-linux-gnueabi-gcc -v output:

Using built-in specs.
COLLECT_GCC=../../toolchain_repos/ta_sdk/cortex-cross-tools_exp/bin/arm-v7a9-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/libexec/gcc/arm-v7a9-linux-gnueabi/4.8.3/lto-wrapper
Target: arm-v7a9-linux-gnueabi
Configured with:
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-v7a9-linux-gnueabi --disable-libmudflap --disable-libssp
--with-gnu-as --with-gnu-ld --disable-lto --disable-nls
--prefix=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-shared --disable-threads --disable-libssp --disable-libquadmath
--without-headers --with-newlib --disable-decimal-float --disable-libffi
--enable-languages=c
--with-sysroot=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/arm-v7a9-linux-gnueabi/sys-root/
--with-gmp=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpfr=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpc=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-libgomp --disable-libatomic --with-interwork --with-cpu=cortex-a9
--with-arch=armv7-a --with-mode=arm --with-tune=cortex-a9 --with-fpu=vfpv3
--with-float=softfp
Thread model: single
gcc version 4.8.3 20140321 (prerelease) (GCC)

[Bug lto/60607] New: Missing lto command line option handling causes build failures

[trippels at gcc dot gnu.org]

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

Bug ID: 60607
   Summary: Missing lto command line option handling causes build
failures
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org

Consider (-march=native is amdfam10):

markus@x4 tmp % cat foo.ii
markus@x4 tmp % cat bar.ii
typedef int __m128i __attribute__ ((__vector_size__ (16)));
__m128i a, b, c;
void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
markus@x4 tmp % g++ -flto -fPIC -march=native -O2 -c foo.ii
markus@x4 tmp % g++ -flto -fPIC -march=native -O2 -msse4.1 -c bar.ii
markus@x4 tmp % g++ -flto -march=native -O2 -shared foo.o bar.o
bar.ii: In function ‘dequant_scaling’:
bar.ii:3:61: error: ‘__builtin_ia32_pmulld128’ needs isa option -m32 -msse4.1
 void dequant_scaling () { c = __builtin_ia32_pmulld128 (a, b); }
 ^
lto-wrapper: /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0/g++ returned 1 exit status

Adding -msse4.1 to the final link step would fix the issue.
This causes e.g. media-libs/x265 build failures see: PR60568 comment13.

[Bug tree-optimization/45932] execute/pr37573.c fails after Neon misaligned patch.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Ramana Radhakrishnan  ---
updating based on c#3 and a recent set of testresults.

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0

[Bug target/37436] arm-cross-g++. internal compiler error: in extract_insn, at recog.c:1990

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #13 from Ramana Radhakrishnan  ---
4.3 branch is closed and looks like my backport never made it. Closing this out
as it got fixed in a 4.4.0 release I suspect

[Bug target/54051] [4.7 Regression] Invalid alignment specifier generated for vld3_lane_* and vld3_dup_* intrinsics.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #8 from Ramana Radhakrishnan  ---
Not working on this.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *__s, int __c, size_t __n) __attribute__
((__nothrow__)) __attribute__ ((__nonnull__ (1)));
extern void __warn_memset_zero_len (void) __attribute__((__warning__ ("memset
used with constant zero length parameter; this could be due to transposed
parameters")));
extern __inline __attribute__((__always_inline__))
__attribute__((__artificial__))
void * __attribute__ ((__nothrow__))
memset (void *__dest, int __ch, size_t __len)
{
  if (__builtin_constant_p (__len) && __len == 0
  && (!__builtin_constant_p (__ch) || __ch != 0))
{
  __warn_memset_zero_len ();
  return __dest;
}
  return __builtin___memset_chk (__dest, __ch, __len, 
 __builtin_object_size (__dest, 0));
}

void
main (int argc, char **argv)
{
  char buf[5000];

  memset (buf, 0xFF, argc);
}


This breaks a lot of applications if you build them with LTO and
-D_FORTIFY_SOURCE=2.  The reason this happens is that when LTO bytecode
is output we still have

  :
  _2 = (long unsigned int) argc_1(D);
  _6 = __builtin_constant_p (_2);
  if (_6 != 0)
goto ;
  else
goto ;

  :
  if (_2 == 0)
goto ;
  else
goto ;

  :
  __warn_memset_zero_len ();
  goto ;

  :
  __memset_chk (&buf, 255, _2, 5000);

  :
  buf ={v} {CLOBBER};

thus __builtin_constant_p is not yet forced to be evaluated.  This means that
we put __warn_memset_zero_len into the LTO symbol table which is queried
by the linker and this causes it to warn at the "beginning" of link-time.
Also (as can be seen with the cases where we introduce a call late) the
linker wants to see a final set of symbols at this time, thus it won't drop
the reference to __warn_memset_zero_len even if during LTRANS phase we
optimize it away.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
It also (sadly) means this "works" with -fno-use-linker-plugin.  It also means
that not outputting the UNDEF into the LTO symbol table for this case doesn't
work as the executable will not link (we optimize the symbol away) if we don't
fold away the reference to it later.

I see no better way than either forcing the linker to re-scan needed symbols
and warn at a "second" stage only or to fold __builtin_constant_p earlier.

[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||4.7.3, 4.8.3, 4.9.0
   Severity|normal  |major

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #1 from Yury Gribov  ---
(In reply to D.Salikhov from comment #0)
> Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"

For my 4.9 with --enable-checking this fails earlier during LRA:

tmp.c: In function 'alpha':
tmp.c:5:1: internal compiler error: in check_rtl, at lra.c:2070
 }
 ^
0x9a3545 check_rtl
/home/ygribov/src/gcc-master/gcc/lra.c:2070
0x9a3fc7 lra(_IO_FILE*)
/home/ygribov/src/gcc-master/gcc/lra.c:2449
0x952374 do_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5457
0x9526c2 rest_of_handle_reload
/home/ygribov/src/gcc-master/gcc/ira.c:5598
0x95270c execute
/home/ygribov/src/gcc-master/gcc/ira.c:5627

The problematic RTL seems to be

 (insn 5 2 6 2 (set (reg:SI 3 r3 [orig:110 D.4140 ] [110])
(reg/v:SI 15 pc [ pc ])) tmp.c:4 663 {*arm_movsi_vfp}
 (nil))

Indeed movsi patterns in arm.md does not allow pc in RHS:

 (define_insn "*arm_movsi_insn"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,r,rk,m")
(match_operand:SI 1 "general_operand"  "rk, I,K,j,mi,rk"))]

I'm not sure whether this is a bug or a feature. As a workaround you could
simply do

 register unsigned long pc;
 asm("mov %0, pc" : "=r"(pc));

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

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

--- Comment #2 from D.Salikhov  ---
I suppose it is a bug as according to ARM Architecture Reference Manual,
A8.8.13 AND (immediate), pc is valid register for using in 'AND' instruction as
an input.

[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Seems to happen quite often when building packages with LTO (see PR51744 for
another major annoyance there).

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.3
   Keywords||lto
   Last reconfirmed|2014-03-19 00:00:00 |2014-03-21
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|lto1 ICE in |[4.9 Regression] lto1 ICE
   |add_symbol_to_partition, at |in add_symbol_to_partition,
   |lto/lto-partition.c:233 -   |at lto/lto-partition.c:233
   |when no -fresolution= is|with -fno-use-linker-plugin
   |available   |
   Target Milestone|--- |4.9.0

--- Comment #8 from Richard Biener  ---
.res data is produced by the linker-plugin thus this bug boils down to an ICE
that can be reproduced with -fno-use-linker-plugin.

The non-linker-plugin path doesn't get much attention these days.  4.8 works
for me.

Confirmed.

[Bug lto/60567] [4.9 Regression] lto1 ICE in add_symbol_to_partition, at lto/lto-partition.c:233 with -fno-use-linker-plugin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||miles at gnu dot org

--- Comment #9 from Richard Biener  ---
*** Bug 56775 has been marked as a duplicate of this bug. ***

[Bug lto/56775] -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition")

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Biener  ---
Same spot of the ICE as 60567.

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

[Bug target/60607] -march=native command line option handling breaks LTO option machinery

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Keywords||lto
   Last reconfirmed||2014-03-21
  Component|lto |target
 Ever confirmed|0   |1
Summary|Missing lto command line|-march=native command line
   |option handling causes  |option handling breaks LTO
   |build failures  |option machinery
   Severity|enhancement |normal

--- Comment #1 from Richard Biener  ---
The issue is that -march=native "explodes" to explicit set options, including
negative ones such as -mno-sse4.1.  That's bad, as we now have conflicting
options for bar.o and foo.o which we merge like

  /* Do what the old LTO code did - collect exactly one option
 setting per OPT code, we pick the first we encounter.
 ???  This doesn't make too much sense, but when it doesn't
 then we should complain.  */

I think this option exploding done by -march=native is simply broken.

At least exploding to full positive _and_ negative lists is.  Either we
have a separate option for each target feature - then we don't need the
-mno-xxx stuff, or we don't - then we need to fix that.

Note that the plan for the future is to no longer "merge" any target options
for link-time but use target attributes more aggressively.  The current code
merely tries to make the link-step succeed somehow, not follow what the
user intended with setting specific target options on specific TUs.

[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #34 from Dominique d'Humieres  ---
>> I ran the test on Solaris 9 and 11 and looked at the resulting .sum
>> files.  Seeing the Unsupported rounding entries on Solaris 11 (any
>> platform without the rounding issue actually) seemed strange/backwards
>> at first (double negation) until I understood how it's done.
>
> I agree that direct logic is better than double negation. With the following
> patch
[...]
> the gfortran.sum contains
>
> ...
> PASS: gfortran.dg/fmt_en.f90  -O0   scan-file All kinds rounded to nearest
> ...

Even better.  Tested again on i386-pc-solaris2.9 and i386-pc-solaris2.11.

Thanks.
Rainer

[Bug debug/60603] [4.7/4.8/4.9 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #54 from Jakub Jelinek  ---
Agreed.

[Bug c++/60608] New: Template argument problem

[volumedriverteam at cloudfounders dot com]

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

Bug ID: 60608
   Summary: Template argument problem
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volumedriverteam at cloudfounders dot com

#include 
template
void
wrapper(void (*f)(Args...),
Args... args)
{
f(std::forward(args...));
}

void
myfun(int)
{}

void
myfun2(const int)
{}

void
test()
{
int a = 0;
wrapper(myfun, a);

wrapper(myfun, a);

wrapper(myfun2, a);

const int b = 0;
wrapper(myfun2, b);

wrapper(myfun2, b);
}
It's not clear why the last line doesn't compile. It doesn't give any problem
on clang. The compiler seems to get the type of myfun2 wrong.

[Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code

[rguenth at gcc dot gnu.org]

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

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]
   |inefficient FDO |inefficient FDO
   |instrumentation code|instrumentation code

--- Comment #7 from Richard Biener  ---
Fixed on trunk.

[Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 21 11:52:50 2014
New Revision: 208746

URL: http://gcc.gnu.org/viewcvs?rev=208746&root=gcc&view=rev
Log:
2014-03-21  Richard Biener  

PR tree-optimization/60577
* tree-core.h (struct tree_base): Document nothrow_flag use
in VAR_DECL_NONALIASED.
* tree.h (VAR_DECL_NONALIASED): New.
(may_be_aliased): Adjust.
* coverage.c (build_var): Set VAR_DECL_NONALIASED.

* gcc.dg/tree-ssa/ssa-lim-11.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-lim-11.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree.h

[Bug c++/60608] Template argument problem

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to volumedriverteam from comment #0)
> void
> myfun2(const int)

Top-level const is removed from function parameters, so this function is
equivalent to:

  void myfun2(int);

And the instantiation wrapper is equivalent to:

  template<> void wrapper(void (*)(int), int);

G++ gets confused trying to match const int to int somewhere.


f.cc: In function ‘void test()’:
f.cc:31:33: error: no matching function for call to ‘wrapper(void (&)(int),
const int&)’
 wrapper(myfun2, b);
 ^
f.cc:31:33: note: candidate is:
f.cc:4:1: note: template void wrapper(void (*)(Args ...), Args
...)
 wrapper(void (*f)(Args...),
 ^
f.cc:4:1: note:   template argument deduction/substitution failed:
f.cc:31:33: note:   mismatched types ‘const int’ and ‘int’
 wrapper(myfun2, b);
 ^

[Bug target/60609] New: [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[doko at gcc dot gnu.org]

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

Bug ID: 60609
   Summary: [4.8/4.9 Regression] Error: value of 256 too large for
field of 1 bytes at 68242
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

originall reported as a gas issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=16735

seen when building the ppl 1.1 bindings for SWI Prolog, using binutils from the
2.24 branch on arm-linux-gnueabihf with a compiler defaulting to thumb mode.

seen with current 4.8 branch and at least trunk 20140306.

$ g++ -c -g -O2 ppl_prolog_common.ii
/tmp/ccuRxr3p.s: Assembler messages:
/tmp/ccuRxr3p.s:126688: Error: value of 256 too large for field of 1 bytes at
68242

$ g++ -marm -c -g -O2 ppl_prolog_common.ii


$ as -v -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o
ppl_prolog_common.o ppl_prolog_common.s
GNU assembler version 2.24 (arm-linux-gnueabihf) using BFD version (GNU
Binutils for Debian) 2.24
ppl_prolog_common.s: Assembler messages:
ppl_prolog_common.s:130339: Error: value of 256 too large for field of 1 bytes
at 70430

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.8/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.8.2 (Debian 4.8.2-16)

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Hi Rainer,

  Given that the 2.9 target is deprecated, do we really care about this problem
?

  Also - when I tried to assemble the file you uploaded I had no problems. 
This was using gas built from today's FSF mainline binutils sources, but I also
tried a version built from the 2.24 sources and the 2.23 sources - they all
worked.

Cheers
  Nick

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
Confirmed - reducing.

[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #18 from Martin Jambor  ---
Author: jamborm
Date: Fri Mar 21 12:48:02 2014
New Revision: 208747

URL: http://gcc.gnu.org/viewcvs?rev=208747&root=gcc&view=rev
Log:
2014-03-21  Martin Jambor  

PR ipa/60419
* ipa.c (symtab_remove_unreachable_nodes): Clear thunk flag of nodes
in the border.

testsuite/
* g++.dg/ipa/pr60419.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr60419.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Nick Clifton  ---
> Hi Rainer,
>
>   Given that the 2.9 target is deprecated, do we really care about this 
> problem
> ?

Not too much.  Given that is was a new failure, I still reported it to
check if we can do something about it short of XFAILing the test.

>   Also - when I tried to assemble the file you uploaded I had no problems. 
> This was using gas built from today's FSF mainline binutils sources, but I 
> also
> tried a version built from the 2.24 sources and the 2.23 sources - they all
> worked.

Sorry, I forgot: the failure only happens with the native as, not with gas.

Rainer

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|c++ |ipa

[Bug rtl-optimization/60601] [4.9 Regression] profiledbootstrap fails with Ada

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
 Target||x86_64-*-*, i?86-*-*
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed by Jakub.  Works for release checking.

[Bug debug/60603] [4.7/4.8/4.9 Regression] .debug_macinfo/.debug_macro has wrong line numbers for built-in macros

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |4.9.0

[Bug ipa/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  ---
Author: jamborm
Date: Fri Mar 21 12:59:35 2014
New Revision: 208748

URL: http://gcc.gnu.org/viewcvs?rev=208748&root=gcc&view=rev
Log:
2014-03-21  Martin Jambor  

PR ipa/59176
* cgraph.h (symtab_node): New flag body_removed.
* ipa.c (symtab_remove_unreachable_nodes): Set body_removed flag
when removing bodies.
* symtab.c (dump_symtab_base): Dump body_removed flag.
* cgraph.c (verify_edge_corresponds_to_fndecl): Skip nodes which
had their bodies removed.

testsuite/
* g++.dg/torture/pr59176.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr59176.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/ipa.c
trunk/gcc/symtab.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Jambor  ---
Fixed.

[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #5)
> But the function doesn't inline itself, that is why it uses the asm alias
> and GCC shouldn't be looking through that and merging the two decls because
> of that.
> 
> Breaking this breaks pretty much all of glibc -D_FORTIFY_SOURCE, and there
> really isn't any other way how to write it.
> 
> To show the reason for the inline:
> __fortify_function __nonnull ((1, 2)) __wur ssize_t
> __NTH (readlink (const char *__restrict __path, char *__restrict __buf,
>  size_t __len))
> {
>   if (__bos (__buf) != (size_t) -1)
> {
>   if (!__builtin_constant_p (__len))
> return __readlink_chk (__path, __buf, __len, __bos (__buf));
> 
>   if ( __len > __bos (__buf))
> return __readlink_chk_warn (__path, __buf, __len, __bos (__buf));
> }
>   return __readlink_alias (__path, __buf, __len);
> }
> 
> The inline must be always_inline, because it is a security matter if it is
> inlined or not, and we want it to expand as a call to __readlink_chk if
> it needs runtime verification, otherwise as a call to the original function,
> not inlined.  So, this is really a LTO/IPA bug.

Note that __readlink_alias was _not_ declared always-inline and thus at least
the call edge (even if eventually re-directing to readlink itself) should
not be considered always-inline.  But we always check the always-inline flag
on the callee decl, even if it was substituted from an alias.  As we throw
away the callgraph edges it's also hard to maintain this edge property there.

[Bug target/60610] New: [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[rguenth at gcc dot gnu.org]

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

Bug ID: 60610
   Summary: [4.9 Regression] ICE in convert_regs_1, at
reg-stack.c:3064
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Host: i586-linux-gnu
Target: x86_64-*-*

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

/usr/lib/gcc/i586-suse-linux/4.9/cc1 -fpreprocessed efiemu.i -quiet -dumpbase
efiemu.c -m64 -mcmodel=large -mno-red-zone -mtune=generic -march=x86-64
-auxbase-strip efiemu64_c.o -O2 -Wall -Werror -version -o efiemu.s
../../grub-core/efiemu/runtime/efiemu.c: In function 'efiemu_get_time':
../../grub-core/efiemu/runtime/efiemu.c:247:1: internal compiler error: in
convert_regs_1, at reg-stack.c:3064
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #1 from Richard Biener  ---
Note that the weird thing is that with 4.8 I get

[  127s] GRUB2 will be compiled with following components:
...
[  127s] efiemu runtime: No (cannot compile with -m64 -mcmodel=large
-mno-red-zone -nostdlib)

but appearantly with 4.9 that succeeds (the compiler wasn't built with
multilibs)

[  153s] efiemu runtime: Yes

so maybe this isn't a "true" regression.  It's at least odd.

[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  ---
Created attachment 32418
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32418&action=edit
Reduced testcase

Reduced testcase. Looks prima-facie like lengths are messed up somewhere which
needs careful digging.


-march=armv7-a -mthumb -c -O2 -mfpu=vfpv3-d16 on trunk.

Ramana

[Bug lto/59626] [4.8/4.9 Regression] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Better patch - simply kill all bodies of extern always_inline functions before
LTO streaming...  (we should be able to do that anyway)

Index: gcc/ipa.c
===
--- gcc/ipa.c   (revision 208745)
+++ gcc/ipa.c   (working copy)
@@ -1218,6 +1218,29 @@ static unsigned
 free_inline_summary (void)
 {
   inline_free_summary ();
+  /* If we create LTO bytecode then drop bodies of extern always_inline
+ functions now.  */
+  if (flag_lto)
+{
+  cgraph_node *node;
+  FOR_EACH_DEFINED_FUNCTION (node)
+   if (DECL_EXTERNAL (node->decl)
+   && lookup_attribute ("always_inline",
+DECL_ATTRIBUTES (node->decl)) != NULL)
+ {
+   cgraph_release_function_body (node);
+   /* ???  The above doesn't do what I like it to do ;)  */
+   node->analyzed = false;
+   node->definition = false;
+   /* ???  Shouldn't be necessary but the diagnostic code doesn't
+  verify if there is a definition at all.
+  ???  Note attribute lists are possibly shared and
+  remove_attribute doesn't honor that.  */
+   DECL_ATTRIBUTES (node->decl)
+ = remove_attribute ("always_inline",
+ DECL_ATTRIBUTES (node->decl));
+ }
+}
   return 0;
 }

[Bug driver/27354] Memory leak in make_relative_prefix

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Jerry DeLisle  ---
No apparent interest for a long time.

[Bug c++/60611] New: friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration

[nicolas.bertolotti at mathworks dot fr]

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

Bug ID: 60611
   Summary: friend function declaration rejected when the
namespace in which it is declared is not explicitely
specified in the declaration
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.bertolotti at mathworks dot fr

Created attachment 32419
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32419&action=edit
Source file to reproduce the issue

If you compile the following piece of code using g++ (4.7.2):
"
class class1; 

namespace ns1 { 

class class2; 
class class3; 
}

ns1::class3 *func(ns1::class2 * cfg, const class1 * def); 

namespace ns1 { 

class class4 { 
#ifdef WORKAROUND
friend ns1::class3 *(::func)(ns1::class2 * cfg, const class1 * def);
#else
friend class3 *(::func)(class2 * cfg, const class1 * def); 
#endif
}; 
}
" (also attached)
you get the following:
$ g++ -c test.cpp
test.cpp:17:25: error: ‘func’ is neither function nor member function; cannot
be declared friend
test.cpp:17:23: error: expected ‘;’ at end of member declaration
test.cpp:17:32: error: expected ‘)’ before ‘*’ token

Now, if you explicitely add the namespaces as they appear in the initial
declaration (add -DWORKAROUND), the compilation succeeds.

[Bug c++/60612] New: Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[tasptz at gmail dot com]

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

Bug ID: 60612
   Summary: Throwing exception, catching and rethrowing
(std::exception_ptr) in destructor leads to segfault
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tasptz at gmail dot com

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

See attached sample.
Compiled with gcc 4.7 (g++-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3) the
program runs and exits normally. Compiled with gcc 4.8 a segfault occurs.

#0  0x in ?? ()
#1  0x77b34c76 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x77b33d39 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x77b348ea in __gxx_personality_v0 () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x775d3803 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#5  0x775d3b9b in _Unwind_RaiseException () from
/lib/x86_64-linux-gnu/libgcc_s.so.1
#6  0x77b34c5a in
std::rethrow_exception(std::__exception_ptr::exception_ptr) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00400cb1 in A::~A() ()
#8  0x00400bc4 in main ()

version:
g++ (GCC) 4.8.2

system:
Linux gpustation 3.5.0-21-generic #32~precise1-Ubuntu SMP Thu Dec 13 20:26:47
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

gcc configure:
--enable-languages=c,c++

example compilation:
g++ -std=c++11 -o main main.cpp

[Bug middle-end/60419] [4.8 Regression] ICE Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE
   |Segmentation fault  |Segmentation fault

--- Comment #19 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Well, this is ICE on code with undefined behavior.  Function test
calls itself with a parameter which is a reference to an object of
type child2 and then static_casts it to a reference to child1.  These
are non-PODs, neither of these types is an ancestor of the other and
thus the use of static_cast is not allowed by the C++ standard.

ipa-prop based devirtualization does not see the cast, it thinks the
object is of type child2, and therefore the virtual method it looks up
is intermediate::topf.  Then it does a consistency check to see
whether type hierarchy based devirtualization has that function among
its possible targets.  However, this devirtualization starts with
child1 as its outer type and thus it concludes the only possible
target is top::topf.  The consistency check fails and we get an ICE on
assert.

The assert has to go but I wonder whether we want to give up when
possible_polymorphic_call_target_p returns false so that we don't try
to optimize such undefined cases.  We might even give a warning,
although making the warning useful to the user might require some
effort.

[Bug sanitizer/60613] New: Invalid signed subtraction ubsan diagnostics

[jakub at gcc dot gnu.org]

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

Bug ID: 60613
   Summary: Invalid signed subtraction ubsan diagnostics
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub 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

On x86_64-linux with -O2 -m32 -fsanitize=undefined on:
__attribute__((noinline, noclone)) long long
foo (long long y)
{
  asm ("");
  return 8LL - y;
}

int
main ()
{
  foo (1);
  return 0;
}

we get invalid diagnostics:
runtime error: signed integer overflow: 8 - 1 cannot be represented in type
'long long int'

[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

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

Václav Zeman  changed:

   What|Removed |Added

 CC||vhaisman at gmail dot com

--- Comment #3 from Václav Zeman  ---
Created attachment 32421
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32421&action=edit
preprocessed source

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

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

--- Comment #4 from Václav Zeman  ---
(In reply to Tobias Burnus from comment #2)
> This PR might have the same reason as PR60567.
> 
> Namely, your GCC has not been compiled on a system with working linker
> plugin - and thus, lto1 is not invoked with -fresolution=.
> 
> Try compiling with "-fuse-linker-plugin" - if that gives an error, try a GCC
> which has been configured with --with-plugin-ld= pointing to a newer
> Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.

I was able to (manually) reduce the test to 

g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
.libs/cyglog4cplus-1-2-2.dll

The preprocessed file is attached compressed.

> 
> If it doesn't help: Create a reduced test case as described at
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

[Bug lto/57715] lto1.exe: internal compiler error: in add_symbol_to_partition

[vhaisman at gmail dot com]

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

--- Comment #5 from Václav Zeman  ---
(In reply to Václav Zeman from comment #4)
> (In reply to Tobias Burnus from comment #2)
> > This PR might have the same reason as PR60567.
> > 
> > Namely, your GCC has not been compiled on a system with working linker
> > plugin - and thus, lto1 is not invoked with -fresolution=.
> > 
> > Try compiling with "-fuse-linker-plugin" - if that gives an error, try a GCC
> > which has been configured with --with-plugin-ld= pointing to a newer
> > Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.
> 
> I was able to (manually) reduce the test to 
> 
> g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
> .libs/cyglog4cplus-1-2-2.dll
> 
> The preprocessed file is attached compressed.
> 
> > 
> > If it doesn't help: Create a reduced test case as described at
> > http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

Oops! All of this should have gone to PR 56963 instead.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Or we might produce a call to __builtin_unreachable (we already do
that in ipa_get_indirect_edge_target_1 in similar cases) or
__builtin_abort.  Tough decision, although I'll probably go for
__builtin_unreachable, for the sake of consistency.

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

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

--- Comment #7 from Václav Zeman  ---
Created attachment 32422
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32422&action=edit
preprocessed source

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

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

--- Comment #6 from Václav Zeman  ---
(In reply to Tobias Burnus from comment #5)
> This PR might have the same reason as PR60567.
> 
> Namely, your GCC has not been compiled on a system with working linker
> plugin - and thus, lto1 is not invoked with -fresolution=.
> 
> Try compiling with "-fuse-linker-plugin" - if that gives an error, try a GCC
> which has been configured with --with-plugin-ld= pointing to a newer
> Binutils - 2.21 or newer. If that helps, it is a duplicate of PR60567.

I was able to (manually) reduce the test to 

g++  -r -nostdlib  src/.libs/liblog4cplus_la-rootlogger.ii -flto -o
.libs/cyglog4cplus-1-2-2.dll

The preprocessed file is attached compressed.

> 
> If it doesn't help: Create a reduced test case as described at
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs

[Bug lto/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284

[vhaisman at gmail dot com]

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

--- Comment #8 from Václav Zeman  ---
BTW, the current version with which I have reduced the test case is this:

`--> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.8.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2 --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-arch=i686
--with-tune=generic --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)

[Bug c/60614] New: -Wtype-limits fails to warn on unsigned bitfields

[hjp at liab dot dk]

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

Bug ID: 60614
   Summary: -Wtype-limits fails to warn on unsigned bitfields
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjp at liab dot dk

This is possibly related to #54787, but with a different case.

After finding a bug in code compiled with avr-gcc, I created this test case, as
no warning was issued when I expected it. The following test case is tested on:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20140206/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20140206 (prerelease) (GCC)

Test case:
#include 

struct {
unsigned char field1 :3;
unsigned char field2 :5;
} teststruct;

int main ( void ) {

unsigned char test;

if (teststruct.field1 < 0) //issues no warning
printf("Field1 was negative\n");

if (test < 0) //issues warning
printf("Test was negative\n");

return 0;
}


// Compilation:
$ gcc -Wall -Wextra test.c -o test
test.c: In function ‘main’:
test.c:17:2: warning: comparison is always false due to limited range of data
type [-Wtype-limits]
  if (test < 0)
  ^


==
The warning is not issued on test for negative unsigned bitfield as I expected
it.

[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
This is what I'm about to bootstrap and test and then try with Mozilla
Firefox.

It might be worthwhile to report the error in the library from which
the testcase is derived.  You can even try and build and test the
library with this patch but with BUILT_IN_UNREACHABLE replaced with
BUILT_IN_ABORT to track the issue.

--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1639,11 +1639,18 @@ ipa_get_indirect_edge_target_1 (struct cgraph_edge *ie,
return NULL_TREE;
   target = gimple_get_virt_method_for_binfo (token, binfo);
 }
-#ifdef ENABLE_CHECKING
-  if (target)
-gcc_assert (possible_polymorphic_call_target_p
-(ie, cgraph_get_node (target)));
-#endif
+
+  if (target && !possible_polymorphic_call_target_p (ie,
+cgraph_get_node (target)))
+{
+  if (dump_file)
+   fprintf (dump_file,
+"Type inconsident devirtualization: %s/%i->%s\n",
+ie->caller->name (), ie->caller->order,
+IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (target)));
+  target = builtin_decl_implicit (BUILT_IN_UNREACHABLE);
+  cgraph_get_create_node (target);
+}

   return target;
 }

[Bug sanitizer/60613] Invalid signed subtraction ubsan diagnostics

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  ---
Author: rth
Date: Fri Mar 21 15:31:25 2014
New Revision: 208749

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

* ifcvt.c (dead_or_predicable): Return FALSE if there are any frame
related insns after epilogue_completed.
* gcc.dg/pr60598.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr60598.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60598] [4.9 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

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

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
In C++11 destructors have an implicit noexcept, so the 4.7 behaviour is wrong:
the program should call std::terminate() when the exception leaves ~A()

If you change the program to:

~A() noexcept(false)

then it runs and exits normally.

If you explicitly add:

~A() noexcept(true)

then you get the same behaviour from 4.7 and 4.8, it segfaults in the terminate
handler.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #0)
> Created attachment 32417 [details]
> testcase
> 
> /usr/lib/gcc/i586-suse-linux/4.9/cc1 -fpreprocessed efiemu.i -quiet
> -dumpbase efiemu.c -m64 -mcmodel=large -mno-red-zone -mtune=generic
> -march=x86-64 -auxbase-strip efiemu64_c.o -O2 -Wall -Werror -version -o
> efiemu.s
> ../../grub-core/efiemu/runtime/efiemu.c: In function 'efiemu_get_time':
> ../../grub-core/efiemu/runtime/efiemu.c:247:1: internal compiler error: in
> convert_regs_1, at reg-stack.c:3064
>  }
>  ^
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://bugs.opensuse.org/> for instructions.

I got

[hjl@gnu-6 pr60610]$ /export/build/gnu/gcc-32bit/build-i586-linux/gcc/cc1
-fpreprocessed efiemu.i -quiet -dumpbase efiemu.c -m64 -mcmodel=large
-mno-red-zone -mtune=generic -march=x86-64 -auxbase-strip efiemu64_c.o -O2
-Wall -version -o efiemu.s
GNU C (GCC) version 4.9.0 20140321 (experimental) (i586-linux)
compiled by GNU C version 4.8.2 20140115 (Red Hat 4.8.2-11), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20140321 (experimental) (i586-linux)
compiled by GNU C version 4.8.2 20140115 (Red Hat 4.8.2-11), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1545236744b328e15d09c2404fa0d2e2
../../grub-core/efiemu/runtime/efiemu.c: In function
‘efiemu_set_virtual_address_map’:
../../grub-core/efiemu/runtime/efiemu.c:378:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:381:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:384:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
../../grub-core/efiemu/runtime/efiemu.c:387:6: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
[hjl@gnu-6 pr60610]$

[Bug c++/42328] rejects valid friend

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Clang accepts the code in comment 0, but GCC 4.9 and icc 13.0.1 still give the
same errors as stated here in 2009

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[tasptz at gmail dot com]

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

tasptz at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from tasptz at gmail dot com ---
Thanks, Jonathan.

[Bug c++/60611] friend function declaration rejected when the namespace in which it is declared is not explicitely specified in the declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #3 from Jonathan Wakely  ---
This is not invalid, it's a bug: the terminate handler should terminate, not
segfault

[Bug c++/60615] New: bad location in error from initializer

[tromey at gcc dot gnu.org]

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

Bug ID: 60615
   Summary: bad location in error from initializer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

Consider this source:

struct v
{
  int (*f1) (int);
  int (*f2) ();
  int (*f3) (int);
  int (*f4) (int);
};

int func(int x) { return x; }
int fv() { return 23; }

struct v inst = {
  func,
  func,
  func,
  func
}; // Line 17

Compile it with g++:

barimba. g++ --syntax-only pr.cc
pr.cc:17:1: error: invalid conversion from ‘int (*)(int)’ to ‘int (*)()’
[-fpermissive]
 }; // Line 17
 ^

Note that the error refers to line 17 and does not mention the field name
at all.  This is very inconvenient when one has a large struct of
function pointers -- it can be quite hard to find the actual location
of the problem.

[Bug c++/60616] New: bad location from -Wunused-parameter

[tromey at gcc dot gnu.org]

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

Bug ID: 60616
   Summary: bad location from -Wunused-parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org

Consider this source code:

int whatever (int x,
  int y)
{
  return x;
}


Compile it with g++:

barimba. g++ -c -Wunused-parameter pr.cc
pr.cc:1:5: warning: unused parameter ‘y’ [-Wunused-parameter]
 int whatever (int x,
 ^


Note that the error message refers to the wrong location.
I think it should point to the 'y' on line 2.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
You need 32-bit non-multilib cc1.  I can reproduce this, looking into it now.
4.8 configured the same way would complain:
error: code model ‘large’ not supported in the 32 bit mode
sorry, unimplemented: 64-bit mode not compiled in
but 4.9 doesn't for some reason.

[Bug target/60617] New: [4.8 Regression]

[doko at gcc dot gnu.org]

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

Bug ID: 60617
   Summary: [4.8 Regression]
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

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

seen with the 4.8 branch on arm-linux-gnueabihf, configured with
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb 

omitting the -fno-tree-dce works around the issue.  not seen with the 4.7
branch and trunk 20140306.

$ g++ -std=c++11 -fPIC -fno-tree-dce -fno-exceptions -fno-omit-frame-pointer -c
-g -O2 JITArithmetic32_64.ii
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp: In member function 'void
JSC::JIT::emit_op_add(JSC::Instruction*)':
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526:1: error: unable to
find a register to spill in class 'LO_REGS'
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526:1: error: this is the
insn:
(insn 335 334 336 20 (parallel [
(set (reg:SI 3 r3)
(ior:SI (eq:SI (reg/v:SI 112 [ op ])
(reg/v:SI 110 [ dst ]))
(eq:SI (reg/v:SI 111 [ op ])
(reg/v:SI 110 [ dst ]
(clobber (reg:CC 100 cc))
]) ../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:514 295
{*ior_scc_scc}
 (expr_list:REG_UNUSED (reg:CC 100 cc)
(nil)))
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:526: confused by earlier
errors, bailing out
Preprocessed source stored into /tmp/ccb0Osgc.out file, please attach this to
your bugreport.

[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Mar 21 16:35:26 2014
New Revision: 208752

URL: http://gcc.gnu.org/viewcvs?rev=208752&root=gcc&view=rev
Log:
/cp
2014-03-21  Paolo Carlini  

PR c++/60384
* name-lookup.c (push_class_level_binding_1): Check identifier_p
on the name argument.

/testsuite
2014-03-21  Paolo Carlini  

PR c++/60384
* g++.dg/cpp1y/pr60384.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr60384.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/60384] [4.9 Regression] [c++1y] ICE with invalid typedef

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #4 from Paolo Carlini  ---
Fixed.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
This got broken with r203634.
203634   tmsriram   if ((TARGET_64BIT_P (opts->x_ix86_isa_flags) != 0)
203634   tmsriram   != ((opts->x_ix86_isa_flags & OPTION_MASK_ISA_64BIT) !=
0))
is always false, no matter how the compiler has been configured:
i386.h:#define TARGET_64BIT_P(x) TARGET_ISA_64BIT_P(x)
#define TARGET_ISA_64BIT_P(ix86_isa_flags) ((ix86_isa_flags &
OPTION_MASK_ISA_64BIT) != 0)

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

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

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

Completely untested patch.

[Bug target/60618] New: ICE when building openssh on hppa w/-ftrapv in gcse.c

[vapier at gentoo dot org]

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

Bug ID: 60618
   Summary: ICE when building openssh on hppa w/-ftrapv in gcse.c
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vapier at gentoo dot org
CC: toolchain at gentoo dot org
  Host: hppa2.0-linux-gnu
Target: hppa2.0-linux-gnu
 Build: hppa2.0-linux-gnu

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

building the latest version of openssh on hppa ICEs when using -ftrapv (which
upstream adds themselves)

$ hppa2.0-unknown-linux-gnu-gcc-4.6.4 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_fingerprint’:
ssh-keygen.i:9188:1: internal compiler error: in hoist_code, at gcse.c:4631

$ hppa2.0-unknown-linux-gnu-gcc-4.7.3 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_known_hosts’:
ssh-keygen.i:9499:1: internal compiler error: in hoist_code, at gcse.c:3123

$ hppa2.0-unknown-linux-gnu-gcc-4.8.2 -c ssh-keygen.i -O2 -ftrapv
ssh-keygen.i: In function ‘do_fingerprint’:
ssh-keygen.i:9188:1: internal compiler error: in get_pressure_class_and_nregs,
at gcse.c:3438

[Bug target/60520] stack adjustment are not merged anymore

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #32399|0   |1
is obsolete||

--- Comment #13 from H.J. Lu  ---
Created attachment 32427
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32427&action=edit
A patch with a target hook

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
When I step through std::rethrow_exception() in gdb it goes from line 215 to
line 223, so skips over the call to get_terminate(), so dep->terminateHandler
is null and so is dep->unwindHeader.exception_cleanup

(gdb) bt
#0  std::rethrow_exception (ep=...) at
/home/jwakely/src/gcc/gcc/libstdc++-v3/libsupc++/eh_ptr.cc:223
#1  0x00400d39 in A::~A (this=0x7fffd9df, __in_chrg=) at ep.cc:19
#2  0x00400c4c in main () at ep.cc:28
(gdb) p *dep
$17 = {primaryException = 0x603090, unexpectedHandler = 0x77d3a7c0
, terminateHandler = 0x0, nextException = 0x0, handlerCount =
0, handlerSwitchValue = 0, actionRecord = 0x0, languageSpecificData = 0x0, 
  catchTemp = 0, adjustedPtr = 0x0, unwindHeader = {exception_class = 0,
exception_cleanup = 0x0, private_1 = 0, private_2 = 0}}

[Bug c++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
*Sigh* -- ignore that. After line 223 it jumps back to 216 then continues back
to 223 again with the right values in *dep. I thought I was debugging an
unoptimised libstdc++.so but apparently not.

[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar 21 18:54:06 2014
New Revision: 208755

URL: http://gcc.gnu.org/viewcvs?rev=208755&root=gcc&view=rev
Log:
PR libstdc++/60587
* include/debug/functions.h (_Is_contiguous_sequence): Define.
(__foreign_iterator): Accept additional iterator. Do not dispatch on
iterator category.
(__foreign_iterator_aux2): Likewise. Add overload for iterators
from different types of debug container. Use _Is_contiguous_sequence
instead of is_lvalue_reference.
(__foreign_iterator_aux3): Accept additional iterator. Avoid
dereferencing past-the-end iterator.
(__foreign_iterator_aux4): Use const value_type* instead of
potentially user-defined const_pointer type.
* include/debug/macros.h (__glibcxx_check_insert_range): Fix comment
and pass end iterator to __gnu_debug::__foreign_iterator.
(__glibcxx_check_insert_range_after): Likewise.
(__glibcxx_check_max_load_factor): Fix comment.
* include/debug/vector (_Is_contiguous_sequence): Define partial
specializations.
* testsuite/23_containers/vector/debug/57779_neg.cc: Remove
-std=gnu++11 option and unused header.
* testsuite/23_containers/vector/debug/60587.cc: New.
* testsuite/23_containers/vector/debug/60587_neg.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/60587.cc
  - copied, changed from r208753,
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/60587_neg.cc
  - copied, changed from r208753,
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/functions.h
trunk/libstdc++-v3/include/debug/macros.h
trunk/libstdc++-v3/include/debug/vector
trunk/libstdc++-v3/testsuite/23_containers/vector/debug/57779_neg.cc

[Bug libstdc++/60587] [4.9 Regression] debug-mode -std=c++11 vector::insert(pos, begin, end) dereferences begin too eagerly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed (with a rather more complicated patch!)

[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Running the test compiled with -fsanitize=address gives

=
==70806==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff58110428 at pc 0x107b115d8 bp 0x7fff58110240 sp 0x7fff58110218
READ of size 168 at 0x7fff58110428 thread T0
#0 0x107b115d7 (/opt/gcc/gcc4.9w/lib/libasan.1.dylib+0x1a5d7)
#1 0x107af0340
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x11340)
#2 0x107af18ad
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x128ad)
#3 0x7fff9184e5fc (/usr/lib/system/libdyld.dylib+0x35fc)
#4 0x0

Address 0x7fff58110428 is located in stack of thread T0 at offset 104 in frame
#0 0x107af000d
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1100d)

  This frame has 1 object(s):
[32, 104) 'at' <== Memory access at offset 104 overflows this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
  0x1fffeb022030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb022070: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
=>0x1fffeb022080: 00 00 00 00 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00
  0x1fffeb022090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1fffeb0220d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contiguous container OOB:fc
  ASan internal:   fe
==70806==ABORTING

[Bug fortran/60560] Problem allocating character array with assumed length

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-03-21
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I get the error from version 4.3.1 up to 4.9.0 (trunk).

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug target/60610] [4.9 Regression] ICE in convert_regs_1, at reg-stack.c:3064

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 21 21:24:31 2014
New Revision: 208756

URL: http://gcc.gnu.org/viewcvs?rev=208756&root=gcc&view=rev
Log:
PR target/60610
* config/i386/i386.h (TARGET_64BIT_P): If not TARGET_BI_ARCH,
redefine to 1 or 0.
* config/i386/darwin.h (TARGET_64BIT_P): Redefine to
TARGET_ISA_64BIT_P(x).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/config/i386/i386.h

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Mar 21 22:14:36 2014
New Revision: 208757

URL: http://gcc.gnu.org/viewcvs?rev=208757&root=gcc&view=rev
Log:
2014-03-21  Jerry DeLisle  

PR fortran/60148
* gfortran.texi: Add description of namelist DELIM= behavior.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Mar 21 22:19:44 2014
New Revision: 208759

URL: http://gcc.gnu.org/viewcvs?rev=208759&root=gcc&view=rev
Log:
2014-03-21  Jerry DeLisle  

PR libfortran/60148
* io/transfer.c (data_transfer_init): If std= was specified, set
delim status to DELIM_NONE of no other was specified.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug fortran/60148] strings in NAMELIST do not honor DELIM= in open statement

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #16 from Jerry DeLisle  ---
Fixed on trunk.

[Bug target/60604] GCC incorrectly compiles s_csinh function on MIPS

[sje at gcc dot gnu.org]

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

--- Comment #1 from Steve Ellcey  ---
Created attachment 32428
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32428&action=edit
New reduced test case

Here is a new reduced test case that calls no libm functions.  I am pretty sure
that the bug is in the handling of __builtin_fabs and specifically in
expand_absneg_bit where we use the MIPS exp instruction to genreate a floating
point absolute value.  I am not sure exactly what the problem is, but if I have
this routine always return NULL_RTX and use a differentr method of computing a
floating point absolute value then my program works.

I thought it might be a simulator issue since I do most of my testing with qemu
but I ran the executable on hardware and got failures there.

The new reduced test case prints with -O0 or -O1 prints:

x = 0.634964 1.298458
In __csinh(1), 0.634964 1.29846
In __csinh(2), 0.634964 1.29846
x = 0.00 0.00

With -O2 or -O3 it prints:

x = 0.634964 1.298458
In __csinh(1), 0.634964 1.29846
In __csinh(2), 1.00959e+116 1.29846
In if statement
x = 0.00 0.00

[Bug target/60604] GCC incorrectly compiles s_csinh function on MIPS

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Steve Ellcey  ---
Richard and Andrew, I hope you don't mind me adding you to the CC list for this
bug but I am curious if you can reproduce this bug and if you have any ideas on
what could be going wrong.

[Bug libstdc++/60612] Throwing exception, catching and rethrowing (std::exception_ptr) in destructor leads to segfault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |4.8.3

--- Comment #6 from Jonathan Wakely  ---
This is a bug in libsupc++, I have a patch to fix it.

[Bug target/60604] GCC incorrectly compiles s_csinh function on MIPS32 (32bit fp)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|mips*-*-*   |mips*-*-* (o32/eabi32)
Summary|GCC incorrectly compiles|GCC incorrectly compiles
   |s_csinh function on MIPS|s_csinh function on MIPS32
   ||(32bit fp)

--- Comment #3 from Andrew Pinski  ---
The code generation looks incorrect to me:

mfc1$3,$f12
mfc1$2,$f12
move$17,$3
jalmyclassify
ext$16,$2,0,31


Notice how $2/$3 are moving from the same register, one of them should have
been $f13.


The problem is due to paired floating point registers are swapped for
big-endian.
/* Paired FPRs are always ordered little-endian.  */

So when the register allocator is figuring out which register to copy from for
the high subreg of the DF mode:
(insn 23 22 24 (set (subreg:SI (reg:DF 200 [ D.2940 ]) 0)
(and:SI (subreg:SI (reg:DF 194 [ D.2940 ]) 0)
(const_int 2147483647 [0x7fff]))) t77.c:25 -1
 (nil))

It decides that is the same as the register which is incorrect for pair float.

This is what the register allocator produces:

(insn 110 8 23 2 (set (reg:SI 2 $2)
(reg:SI 44 $f12)) t77.c:25 302 {*movsi_internal}
 (nil))
(insn 23 110 111 2 (set (reg:SI 16 $16 [ D.2940 ])
(and:SI (reg:SI 2 $2)
(const_int 2147483647 [0x7fff]))) t77.c:25 157 {*andsi3}
 (nil))

This is incorrect as we should be using $f13 or the full DI mode instead.

[Bug c/60619] New: new -solve-sign-conflicts at -Wsign-compare cases (easy work)

[aleks at physik dot tu-berlin.de]

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

Bug ID: 60619
   Summary: new -solve-sign-conflicts at -Wsign-compare cases
(easy work)
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aleks at physik dot tu-berlin.de

GCC detects sign problems (-Wconversion -Wsign-compare -Wsign-conversion).

int i; unsigned u; if (u == i) // warning sign ..

my gcc feature suggestion: new -solve-sign-conflicts
==> some problems could be solved by gcc alone (if switch).

I could provide compare functions, that are used by gcc in case of above
warning and the new switch.

// e.g. 3 compare functions, handle signs
inline int cmp_su32_equal(int s, uint32 u) { /* == */
const int o = s | (int) u;
if (s != (int) u) return 0;
if (o < 0) return 0; // (s<0) || (u>INT_MAX)
return 1;
}
inline int cmp_su32_lt(int s, uint32 u) { /* < */
const int o = s | (int) u;
if (o < 0) return 1; // (s<0) || (u>INT_MAX)
if (s < (int) u) return 1;
return 0; // return (s < (int) u);
}
inline int cmp_su32_gt(int s, uint32 u) { /* > */
const int o = s | (int) u;
if (o < 0) return 0; // (s<0) || (u>INT_MAX)
if (s > (int) u) return 1;
return 0; // return (s > (int) u);
}

[Bug c/60619] new -solve-sign-conflicts at -Wsign-compare cases (easy work)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Well your option violates C promotion rules.  Basically the warning is there as
some folks don't understand how promotion works in C when it comes to comparing
unsigned and signed integers against each other.

For equals, most of the time you want bytewise comparison; that is the
implicate cast does not change the bits.  While your switch does change the
bits.

[Bug c/60619] new -solve-sign-conflicts at -Wsign-compare cases (easy work)

[aleks at physik dot tu-berlin.de]

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

--- Comment #2 from Alexander Kleinsorge  ---
(In reply to Andrew Pinski from comment #1)
> Well your option violates C promotion rules.  Basically the warning is there
> as some folks don't understand how promotion works in C when it comes to
> comparing unsigned and signed integers against each other.
> 
> For equals, most of the time you want bytewise comparison; that is the
> implicate cast does not change the bits.  While your switch does change the
> bits.

I understand the promotion rules. Nobody is forced to used this new switch.
It gives the fast possibility to see the code as it is written from math
perspective. e.g. (-1 != 0xffFFffFFu) even if both bit representation is ~0

What happens in reallity (not enough programming time):
(s != u) ==> ((unsigned)s != u) , the typecast is inserted to avoid the
warning, not because it is really meant!

This could fasten some cases. The sign-warning could still be there (as without
new switch).

Alex