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

[doko at gcc dot gnu.org]

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

--- Comment #3 from Matthias Klose  ---
Created attachment 32265
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32265&action=edit
preprocessed source (armv7)

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  5 08:46:31 2014
New Revision: 208340

URL: http://gcc.gnu.org/viewcvs?rev=208340&root=gcc&view=rev
Log:
PR lto/60404
* cfgexpand.c (expand_used_vars): Do not assume all SSA_NAMEs
of PARM/RESULT_DECLs must be coalesced with optimize && in_lto_p.
* tree-ssa-coalesce.c (coalesce_ssa_name): Use MUST_COALESCE_COST - 1
cost for in_lto_p.

* gcc.dg/lto/pr60404_0.c: New test.
* gcc.dg/lto/pr60404_1.c: New file.
* gcc.dg/lto/pr60404_2.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr60404_0.c
trunk/gcc/testsuite/gcc.dg/lto/pr60404_1.c
trunk/gcc/testsuite/gcc.dg/lto/pr60404_2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-coalesce.c

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Note I've posted a patch in the mean time:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed, thanks for reporting this.

[Bug target/58595] internal compiler error: in gen_movsi when compiling on arm some files of lttng-tools with -fPIE

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
This patch bootstrapped on a Chromebook and passed regtest fine for me.

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

[y.gribov at samsung dot com]

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

--- Comment #4 from Yury Gribov  ---
This might have been fixed in trunk already, at least I can't repro for
arm-v7a15. My fresh gcc is configured with
 ~/src/gcc-master/configure --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=arm-v7a15-linux-gnueabi
--prefix=/home/ygribov/install/gcc-master-arm-full
--with-sysroot=/home/ygribov/install/gcc-master-arm-full/arm-v7a15-linux-gnueabi/sys-root/
--disable-libmudflap --disable-libssp --disable-nls --disable-libstdcxx-pch
--with-interwork --with-mode=arm --with-fpu=vfpv3 --with-cpu=cortex-a15
--with-tune=cortex-a15 --with-float=softfp --enable-libgomp
--enable-poison-system-directories --enable-long-long --enable-threads
--enable-languages=c,c++ --enable-shared --with-gnu-as --with-gnu-ld
--with-build-time-tools=/home/ygribov/install/gcc-master-arm-full
--enable-checking CFLAGS='-g -O0' CXXFLAGS='-g -O0'

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I think Daniel's question is tangential because the testcase can be modified
like so:

  B b{};

Or like so:

struct A { explicit A(int = 0); };
struct B { int i; A a; };

int main()
{
  B b = { 1 };
}

Now whether B has an explicit default ctor is irrelevant. This bug is about
whether the missing initializer-clause for b.a is equivalent to {} or A{}, and
as I said in PR 60416, [dcl.init.aggr]/7 has an example indicating that the
answer is A{}, so I think the testcase is clearly valid, whatever the
resolution of DR 1518 or Daniel's question.

[Bug libstdc++/60421] New: std::this_thread::sleep_for doesn't sleep for all arguments

[jaak at ristioja dot ee]

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

Bug ID: 60421
   Summary: std::this_thread::sleep_for doesn't sleep for all
arguments
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaak at ristioja dot ee

#include 
  #include 
  #include 
  int main() {
   
std::this_thread::sleep_for(std::chrono::duration(std::numeric_limits::max()));
return 0;
  }

This doesn't even sleep a millisecond. Relevant strace output:

  nanosleep({18446744073709551615, 0}, NULL) = -1 EINVAL (Invalid argument)

Hence the §30.3.2.7 of the C++11 standard is violated as sleep_for does not
sleep by the relative amount of time specified by its argument. Bug may be run
into during testing.

Also happens with 4.7.3.

[Bug libstdc++/60422] New: headers should give a diagnostic when included directly

[redi at gcc dot gnu.org]

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

Bug ID: 60422
   Summary:  headers should give a diagnostic when
included directly
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org

Some users do dumb things like:

#include 
#include 
#include 
#include 

and expect to be able to use std::shared_ptr.  This happens to work with GCC
4.8, but not with 4.9 because we re-arranged some headers to allow the library
to use shared_ptr internally.

In order to stop this nonsense we should add preprocessor checks to the
headers:

#ifndef _MEMORY
#error Do not include this header directly, use  instead
#else
...
#endif

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.3

[Bug lto/60405] ICE in lto1 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x32
   Target Milestone|--- |4.9.0

--- Comment #2 from Richard Biener  ---
Hmm, what's the target triplet of a x32-only target?(In reply to H.J. Lu from
comment #0)
> Since r208165, 435.gromacs in SPEC CPU 2006 is miscompiled on x32 with
> 
> -mx32 -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
> -fuse-linker-plugin
> 
> The failure is
> 
>   Running 435.gromacs ref peak lto default
> 
> *** Miscompare of gromacs.out; for details see
>
> /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.grom
> acs/run/run_peak_ref_lto./gromacs.out.mis
> 
> cat
> /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.
> gromacs/run/run_peak_ref_lto./gromacs.out.mis
> 0002:  3.07684e+02
>3.03594e+02
> 
> The result of 3.03594e+02 is outside of tolerance for 3.07684e+02.
> I added a static counter in tree_forwarder_block_p for the number of
> times returned true above and return false if it is between getenv("from")
> and getenv("to").  I noticed that as more basic blocks get removed,
> the deviation is getting bigger. One removed basic block has
> 
> ;; basic block 3, loop depth 0, count 0, freq 225, maybe hot 
> ;;  prev block 2, next block 4, flags: (NEW, REACHABLE)
> ;;  pred:   2
> ;; 
> ;;  succ:   4
> 
> and its successor has
> 
> ;; basic block 4, loop depth 1, count 0, freq 2500, maybe hot 
> ;;  prev block 3, next block 5, flags: (NEW)
> ;;  pred:   3
> ;;  6
> ;; starting at line 722 
> # gimple_phi 
> 
> Is is safe to remove basic block 3?

Sure it is.  This is a loop pre-header.

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to H.J. Lu from comment #1)
> Do we need to verify that basic block DEST has a single predecessor?

No, that's not necessary.  In fact that disables all pre-header
removal (because the loop header always has the loop entry and at least
one latch)

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |---

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to H.J. Lu from comment #0)
> Since r208165, 435.gromacs in SPEC CPU 2006 is miscompiled on x32 with
> 
> -mx32 -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
> -fuse-linker-plugin
> 
> The failure is
> 
>   Running 435.gromacs ref peak lto default
> 
> *** Miscompare of gromacs.out; for details see
>
> /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.grom
> acs/run/run_peak_ref_lto./gromacs.out.mis
> 
> cat
> /export/project/git/gcc-regression/spec/2006/spec/benchspec/CPU2006/435.
> gromacs/run/run_peak_ref_lto./gromacs.out.mis
> 0002:  3.07684e+02
>3.03594e+02
> 
> The result of 3.03594e+02 is outside of tolerance for 3.07684e+02.
> I added a static counter in tree_forwarder_block_p for the number of
> times returned true above and return false if it is between getenv("from")
> and getenv("to").  I noticed that as more basic blocks get removed,
> the deviation is getting bigger. One removed basic block has

That's odd.  What's the code generation difference in the end
for the minimal range {to, from} that still shows a difference
of the result?

[Bug libstdc++/60422] headers should give a diagnostic when included directly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
#ifndef _GLIBCXX_MEMORY probably (but, as bits/shared_ptr.h is used also in
other headers as implementation detail, you'd probably also need to list those
guards in the preprocessor conditional).

[Bug plugins/59335] Plugin doesn't build on trunk

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  5 09:52:18 2014
New Revision: 208344

URL: http://gcc.gnu.org/viewcvs?rev=208344&root=gcc&view=rev
Log:
PR plugins/59335
* config/i386/t-i386 (OPTIONS_H_EXTRA): Add stringop.def.
(TM_H): Add x86-tune.def.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/t-i386

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[plasmahh at gmx dot net]

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

Dennis Lubert  changed:

   What|Removed |Added

 CC||plasmahh at gmx dot net

--- Comment #1 from Dennis Lubert  ---
Note that for me to reproduce this, _GLIBCXX_USE_NANOSLEEP must be defined. In
that case it uses directly the nanosleep call, casting the uint64max value to
time_t which is signed (which is unfortunately not visible in strace), gets
negative and this is what the nonsleep manpage says for glibc:

   EINVAL The value in the tv_nsec field was not in the range 0 to
9 or tv_sec was negative.

[Bug c++/60423] New: g++ can treat a dynamic POD variable as an array without warning/error

[peter.bocan at azet dot sk]

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

Bug ID: 60423
   Summary: g++ can treat a dynamic POD variable as an array
without warning/error
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.bocan at azet dot sk

Hello guys, we had at university this issue: compiling the code below, throws
no error messages whatsoever, but the code is, as you know, not working. It's,
at least for me, that compiler would recognize this type of mistakes and so it
would be kinda nice to have some type checking upon POD types.

The code is:

int main()
{ 
   int* pod_type = new int(23);

   for (int i = 0; i < 1; i++)
 pot_type[i] = 0xDEADC0DE;

   delete pod_type; 
   return 0;
}

Thank you.

[Bug c++/60423] g++ can treat a dynamic POD variable as an array without warning/error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
gcc detects this with -fsanitize=address, or -fmudflap, or if you run the
program under valgrind.

[Bug lto/60424] New: [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

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

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

Bug ID: 60424
   Summary: [4.9 regression] FAIL: gcc.dg/lto/20110201-1
c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link,  -O0
-flto
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org

$ gcc/xgcc -Bgcc/ -O0 -flto -c -o c_lto_20110201-1_0.o
../gcc/testsuite/gcc.dg/lto/20110201-1_0.c 
$ gcc/xgcc -Bgcc/ c_lto_20110201-1_0.o -O0 -flto -ffast-math
-fuse-linker-plugin -o gcc-dg-lto-20110201-1-01.exe
/tmp/ccGQ0Up1.ltrans0.ltrans.o: In function `foo':
ccGQ0Up1.ltrans0.o:(.text+0x3c): undefined reference to `cabs'

[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

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

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

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

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

--- Comment #1 from Andreas Schwab  ---
Started to fail between r208309 and r208316.

[Bug c/60425] New: -fopenmp fails when gcc is compiled to /usr/local

[j-frankish at slb dot com]

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

Bug ID: 60425
   Summary: -fopenmp fails when gcc is compiled to /usr/local
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j-frankish at slb dot com

Using gcc-4.7.2 compiled to /usr/local.

The following fails:

echo "int main(){}" > hello.c
gcc hello.c -fopenmp

..with a message that libgomp.spec cannot be found

editing the output of gcc -dumpspecs:

include(libgomp.spec) -> include(/usr/local/lib/libgomp.spec)
include(libitm.spec) -> include(/usr/local/lib/libitm.spec)

fixes the error, but shouldn't be required.

[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
should probably be fixed along with PR 58038

[Bug middle-end/60426] New: [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 60426
   Summary: [4.9 Regression] ICE near
expand_builtin_int_roundingfn_2
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch

Between r208300 and r208339 LTO compiles of cp2k start failing with the
backtrace below. This happens for several files, all traces lead to a NINT in
the code.

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_scf_post_gpw.F:977:0: internal
compiler error: Segmentation fault
nmoloc(ispin) = NINT(nelectron/occupation(1))
 ^
0x9056cf crash_signal
../../gcc/gcc/toplev.c:337
0x57808b contains_struct_check
../../gcc/gcc/tree.h:2822
0x57808b build_call_nofold_loc
../../gcc/gcc/builtins.c:2695
0x580aa5 expand_builtin_int_roundingfn_2
../../gcc/gcc/builtins.c:2933
0x5a0ae0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:5928
0x68da35 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10341
0x6991df store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/gcc/expr.c:5337
0x69bf69 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5123
0x5bf2ea expand_call_stmt
../../gcc/gcc/cfgexpand.c:2257
0x5bf2ea expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3158
0x5bf2ea expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3310
0x5c0957 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5150
0x5c31f9 gimple_expand_cfg
../../gcc/gcc/cfgexpand.c:5729
0x5c31f9 execute
../../gcc/gcc/cfgexpand.c:5949
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [/tmp/ccvOjlYd.ltrans24.ltrans.o] Error 1

[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Works just fine here.  Can you
strace gcc hello.c -fopenmp 2>&1 | grep libgomp.spec
?

[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
testcase:

> cat test.f90 
SUBROUTINE S1(a,b,N)
  REAL*8 :: a,b
  INTEGER :: N
  N=NINT(a/b)
END SUBROUTINE

CALL S1(1.0D0,2.0D0,i)
END

> gfortran -flto test.f90 
test.f90: In function ‘s1’:
test.f90:4:0: internal compiler error: Segmentation fault
   N=NINT(a/b)
 ^
0x9056cf crash_signal
../../gcc/gcc/toplev.c:337

[Bug lto/60427] New: [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto

[dominiq at lps dot ens.fr]

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

Bug ID: 60427
   Summary: [4.9 Regression] r208312 causes ICE and wrong code for
Fortran with -flto
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: pmatos at gcc dot gnu.org, rguenth at gcc dot gnu.org

After r208312 (+ the fix in r208315) I get

FAIL: gfortran.dg/pr33794.f90  -g -flto  execution test

with both -m32/-m64, and

FAIL: gfortran.dg/nint_2.f90  -g -flto  (internal compiler error)

with -m64 (r208311 + the fix in r208315 is OK).

The ICE occurs for the following reduced test

  real(kind=8) :: a
  integer(kind=8) :: i1

!  a = nearest(0.5_8,-1.0_8)
!  i1 = nint(a)

  a = 0.5_8
  i1 = nint(a)

!  a = nearest(0.5_8,1.0_8)
!  i1 = nint(a)

  end

[Book15] f90/bug% /opt/gcc/gcc4.9p-208312/bin/gfortran -flto nint_2_red.f90
nint_2_red.f90: In function 'MAIN__':
nint_2_red.f90:8:0: internal compiler error: Segmentation fault: 11
   i1 = nint(a)

The wong code is produced with '-O1 -ffast-math -flto' for
gfortran.dg/pr33794.f90 as well as the polyhedron test fatigue.f90.

[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Likely a duplicate of pr60427.

[Bug target/60428] New: non-exception (e.g. C) ARM Linux programs depend on libgcc_s

[ossman at cendio dot se]

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

Bug ID: 60428
   Summary: non-exception (e.g. C) ARM Linux programs depend on
libgcc_s
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ossman at cendio dot se

When compiling a C program for ARM Linux, you can easily end up with
dependencies on libgcc_s. This is very annoying as it is not how other targets
behave and it means extra work to make binaries that work on a lot of system.

I tried to understand the issue, and from what I gather the ARM EABI has a more
advanced stack unwinding system that involves calling functions. This combined
with helpers in libgcc.a for U64 division that can throw exceptions, results in
a dependency on libgcc_s.


First question: Why are these libgcc.a functions being built with unwind
tables? The stated reason is because of CPU exceptions, but AFAIK those result
in signals, not language level exceptions?


Second question: Let's assume libgcc.a truly needs the unwinding, or if nothing
else there will be other C code that is compiled with -fexceptions for
compatibility; can we remove the hard NEEDED for libgcc_s and only use it if
some C++ (or similar) code pulls it in?


I think the answer to the second question is yes. We've applied the attached
patch to our gcc and it seems to do the trick. C code will not have libgcc_s as
NEEDED, yet you can still throw exceptions just fine, even across C code
compiled with -fexceptions.

I am a bit concerned about the interaction of weak symbols in a static library
(libgcc.a) and versioned symbols in a "proper" library (libgcc_s.so). Comments?

[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s

[ossman at cendio dot se]

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

--- Comment #1 from Pierre Ossman  ---
Created attachment 32266
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32266&action=edit
patch to weaken unwind symbols

[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto

[rguenther at suse dot de]

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

--- Comment #1 from rguenther at suse dot de  ---
On Wed, 5 Mar 2014, dominiq at lps dot ens.fr wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427
> 
> Bug ID: 60427
>Summary: [4.9 Regression] r208312 causes ICE and wrong code for
> Fortran with -flto
>Product: gcc
>Version: 4.9.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: lto
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: dominiq at lps dot ens.fr
> CC: pmatos at gcc dot gnu.org, rguenth at gcc dot gnu.org
> 
> After r208312 (+ the fix in r208315) I get
> 
> FAIL: gfortran.dg/pr33794.f90  -g -flto  execution test
> 
> with both -m32/-m64, and
> 
> FAIL: gfortran.dg/nint_2.f90  -g -flto  (internal compiler error)
> 
> with -m64 (r208311 + the fix in r208315 is OK).
> 
> The ICE occurs for the following reduced test
> 
>   real(kind=8) :: a
>   integer(kind=8) :: i1
> 
> !  a = nearest(0.5_8,-1.0_8)
> !  i1 = nint(a)
> 
>   a = 0.5_8
>   i1 = nint(a)
> 
> !  a = nearest(0.5_8,1.0_8)
> !  i1 = nint(a)
> 
>   end
> 
> [Book15] f90/bug% /opt/gcc/gcc4.9p-208312/bin/gfortran -flto nint_2_red.f90
> nint_2_red.f90: In function 'MAIN__':
> nint_2_red.f90:8:0: internal compiler error: Segmentation fault: 11
>i1 = nint(a)
> 
> The wong code is produced with '-O1 -ffast-math -flto' for
> gfortran.dg/pr33794.f90 as well as the polyhedron test fatigue.f90.

Hmm, this is because mathfn_built_in_1 does

  if (TYPE_MAIN_VARIANT (type) == double_type_node)
fcode2 = fcode;
  else if (TYPE_MAIN_VARIANT (type) == float_type_node)
fcode2 = fcodef;
  else if (TYPE_MAIN_VARIANT (type) == long_double_type_node)
fcode2 = fcodel;
  else
return NULL_TREE;

and we now have "two" double_type_nodes (the global tree built
by lto1 and the one that is now streamed literally).

IMHO we want to revert the patch at this point.

[Bug target/60428] non-exception (e.g. C) ARM Linux programs depend on libgcc_s

[ossman at cendio dot se]

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

--- Comment #2 from Pierre Ossman  ---
Created attachment 32267
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32267&action=edit
test case

[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
*** Bug 60426 has been marked as a duplicate of this bug. ***

[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

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

--- Comment #3 from Joost VandeVondele  
---
yes, dup for sure

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

[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local

[j-frankish at slb dot com]

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

--- Comment #2 from j-frankish at slb dot com ---
Ah - I see the problem now.

I'm using gcc packaged into a squashfs package, loop mounted at /tmp/tcloop/gcc
and symlinked to the root file system. The gcc libs are packaged separately and
mounted at /tmp/tcloop/gcc_libs.

As -fopenmp is searching a relative path to libgomp.spec and only looks in
absolute paths to /lib and /usr/lib, it does not find it.

I entered the absolute path /usr/local/lib/libgomp.spec in the root file system
in the specs file, which is what made things work.

..in some respects, if gcc is compiled to /usr/local, shouldn't it search the
absolute path to /usr/local?

--

$ strace gcc hello.c -fopenmp 2>&1 | grep libgomp.spec

strace gcc hello.c -fopenmp 2>&1 | grep libgomp.spec
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/libgomp.spec",
R_OK) = -1 ENOENT (No such file or directory)
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/libgomp.spec", R_OK) = -1
ENOENT (No such file or directory)
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../../i486-pc-linux-gnu/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec",
R_OK) = -1 ENOENT (No such file or directory)
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../../i486-pc-linux-gnu/lib/libgomp.spec",
R_OK) = -1 ENOENT (No such file or directory)
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../i486-pc-linux-gnu/4.7.2/libgomp.spec",
R_OK) = -1 ENOENT (No such file or directory)
access("/tmp/tcloop/gcc/usr/local/bin/../lib/gcc/i486-pc-linux-gnu/4.7.2/../../../libgomp.spec",
R_OK) = -1 ENOENT (No such file or directory)
access("/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec", R_OK) = -1 ENOENT (No such
file or directory)
access("/lib/libgomp.spec", R_OK)   = -1 ENOENT (No such file or directory)
access("/usr/lib/i486-pc-linux-gnu/4.7.2/libgomp.spec", R_OK) = -1 ENOENT (No
such file or directory)
access("/usr/lib/libgomp.spec", R_OK)   = -1 ENOENT (No such file or directory)
open("libgomp.spec", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
write(2, "gcc: error: libgomp.spec: No suc"..., 51gcc: error: libgomp.spec: No
such file or directory) = 51

[Bug c/60425] -fopenmp fails when gcc is compiled to /usr/local

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
User problem then.

[Bug libgcc/60429] New: Miscompilation (aliasing) with -finline-functions

[linux at carewolf dot com]

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

Bug ID: 60429
   Summary: Miscompilation (aliasing) with -finline-functions
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com

After recently trying to build Qt with -O3, I found one of our tests failing.
After investigating I narrowed it down to qregion.cpp and the flag
-finline-functions (using -O2 -finline-functions).

Specificially the inlining of the function loadAET() in "QRegionPrivate
*PolygonRegion()" causes the problem. Adding __attribute__((noinline)) to
loadAET() solves the problem. Interestingly compiling without -finline-function
and just marking the loadAET as inline or always_inline, does not trigger the
issue.

The code is not Qt specific and is used in a other projects, though it is most
places compiled as C code.

Further testing shows the issue is also triggered in GCC 4.6, 4.7, and the
latest version of 4.9 I had. It is however NOT present in GCC 4.4, so this is a
regression.

Looking at the assembler and debug output, I believe the that the variable pAET
that should have been reloaded after loadAET() has been eliminated. This might
be what breaks the aliasing rules.

[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 32268
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32268&action=edit
qregion.cpp intermediate compiled with G++ 4.4 (working)

[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
Created attachment 32269
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32269&action=edit
qregion.cpp intermediate compiled with gcc 4.8

[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions

[linux at carewolf dot com]

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

--- Comment #3 from Allan Jensen  ---
Created attachment 32270
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32270&action=edit
qregion.cpp assembler compiled with gcc 4.8

[Bug libgcc/60429] Miscompilation (aliasing) with -finline-functions

[linux at carewolf dot com]

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

--- Comment #4 from Allan Jensen  ---
Created attachment 32271
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32271&action=edit
qregion.cpp assembler compiled with gcc 4.4

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

[nheghathivhistha at gmail dot com]

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

--- Comment #22 from David Kredba  ---
I got this now with rev. 208241:

/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -O2 -ggdb -pipe -march=native
-mtune=native -mno-3dnow -mno-sse4.2 -mno-avx  -Wnon-virtual-dtor
-Wno-long-long -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith
-Wformat-security -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common
-Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
-fvisibility-inlines-hidden -fexceptions -UQT_NO_EXCEPTIONS
-Wl,--enable-new-dtags -Wl,--no-undefined -lc  -Wl,--as-needed -Wl,-O2 -O2
-ggdb -pipe -march=native -mtune=native -shared
-Wl,-soname,libkorganizer_core.so.4 -o ../lib/libkorganizer_core.so.4.12.3
CMakeFiles/korganizer_core.dir/korganizer_core_automoc.o
CMakeFiles/korganizer_core.dir/koprefs.o
CMakeFiles/korganizer_core.dir/kocore.o
CMakeFiles/korganizer_core.dir/koprefs_base.o 
-L/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3_build/lib 
-L/usr/lib64/qt4 ../lib/libcalendarsupport.so.4.12.3 -leventviews
../lib/libincidenceeditorsng.so.4.12.3 -lkdepim
../lib/libkorganizer_interfaces.so.4.12.3 /usr/lib64/libakonadi-kde.so.4.12.3
/usr/lib64/libkcalcore.so.4.12.3 /usr/lib64/libkcalutils.so.4.12.3
/usr/lib64/libkmime.so.4.12.3 /usr/lib64/libkpimidentities.so.4.12.3
/usr/lib64/libkdecore.so.5.12.3 /usr/lib64/libkio.so.5.12.3
/usr/lib64/qt4/libQtUiTools.a -lz -lkdepim /usr/lib64/libkldap.so.4.12.3
/usr/lib64/libkcmutils.so.4.12.3 -lkdgantt2 -lakonadi_next -lakonadi-calendar
../lib/libcalendarsupport.so.4.12.3 /usr/lib64/libkcalutils.so.4.12.3
/usr/lib64/libkpimidentities.so.4.12.3 /usr/lib64/libkpimtextedit.so.4.12.3
/usr/lib64/libkholidays.so.4.12.3 /usr/lib64/libakonadi-contact.so.4.12.3
/usr/lib64/libkcalcore.so.4.12.3 /usr/lib64/libkabc.so.4.12.3
/usr/lib64/libkresources.so.4.12.3 /usr/lib64/libkpimutils.so.4.12.3
/usr/lib64/libnepomukcore.so.4.12.3 -lphonon /usr/lib64/libkmime.so.4.12.3
/usr/lib64/libakonadi-kde.so.4.12.3
/usr/lib64/libakonadiprotocolinternals.so.1.11.0 /usr/lib64/libkio.so.5.12.3
/usr/lib64/libsolid.so.4.12.3 /usr/lib64/qt4/libQtNetwork.so
/usr/lib64/qt4/libQtXml.so /usr/lib64/libkdeui.so.5.12.3
/usr/lib64/libkdecore.so.5.12.3 /usr/lib64/qt4/libQtCore.so -lpthread
/usr/lib64/qt4/libQtDBus.so /usr/lib64/qt4/libQtGui.so
/usr/lib64/qt4/libQtSvg.so -lsoprano
-Wl,-rpath,/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3_build/lib:/usr/lib64/qt4:
CMakeFiles/korganizer_core.dir/kocore.o: In function `~Part':
/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55:
undefined reference to `KParts::Part::~Part()'
CMakeFiles/korganizer_core.dir/kocore.o: In function `KOrg::Part::~Part()':
/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55:
undefined reference to `KParts::Part::~Part()'
CMakeFiles/korganizer_core.dir/kocore.o: In function `~Part':
/var/tmp/portage/kde-base/korganizer-4.12.3/work/korganizer-4.12.3/korganizer/interfaces/korganizer/part.h:55:
undefined reference to `KParts::Part::~Part()'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTIN4KOrg4PartE[_ZTIN4KOrg4PartE]+0x10):
undefined reference to `typeinfo for KParts::Part'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x10):
undefined reference to `typeinfo for KParts::PartBase'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x18):
undefined reference to `KParts::PartBase::~PartBase()'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x20):
undefined reference to `KParts::PartBase::~PartBase()'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x28):
undefined reference to `KParts::PartBase::setComponentData(KComponentData
const&)'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0x30):
undefined reference to `KParts::PartBase::setComponentData(KComponentData
const&, bool)'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xb0):
undefined reference to `typeinfo for KParts::PartBase'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xb8):
undefined reference to `virtual thunk to KParts::PartBase::~PartBase()'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xc0):
undefined reference to `virtual thunk to KParts::PartBase::~PartBase()'
CMakeFiles/korganizer_core.dir/kocore.o:(.data.rel.ro._ZTCN4KOrg4PartE16_N6KParts8PartBaseE[_ZTVN4KOrg4PartE]+0xf8):
undefined reference to `virtual thunk to
KParts::PartBase::setComponentData(KComponentData const&)'
CMakeFiles/korganize

[Bug target/57631] Use assembler name for sanity checking of ISR names provided it is set

[mhlavink at redhat dot com]

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

Michal Hlavinka  changed:

   What|Removed |Added

 CC||mhlavink at redhat dot com

--- Comment #14 from Michal Hlavinka  ---
This causes regression:
protocols/pulses_avr.cpp:104:1: warning: '_vector_12' appears to be a
misspelled signal handler [enabled by default]
 ISR(TIMER1_COMPA_vect) //2MHz pulse generation (BLOCKING ISR)
 ^

the "+1" in the fix(gcc/config/avr/avr.c):
 name = DECL_ASSEMBLER_NAME_SET_P (decl)
/* Remove the leading '*' added in set_user_assembler_name.  */
? 1 + IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl))
: IDENTIFIER_POINTER (DECL_NAME (decl));

makes name == _vector_12 instead of __vector_12 and it triggers warning a few
lines later

tested version: gcc-4.8.2

[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r197248.

[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #5 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #3)
> > I guess it's fair to say that the ICE is technically a regression.
> So it is a real regression within 4.9.0.

Well, one can argue whether a bug in a new feature is a real regression ...

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #23 from Markus Trippelsdorf  ---
> Is this a new re-occurence?

Looks likely:

markus@x4 tmp % < test.ii
template  class A
{
public:
  A (T &);
  typename T::const_iterator i;
};

template  class B
{
public:
  class const_iterator
  {
  public:
T &operator*();
  };
};

namespace KParts
{
class PartBase
{
public:
  virtual ~PartBase ();
};
class Part : PartBase
{
};
}
class Part : KParts::Part
{
public:
  typedef B List;
  ~Part () {}
};
void fn1 (Part::List &p1)
{
  for (A<__typeof__ p1> a (p1);;)
for (Part *b = *a.i;;)
  delete b;
}
markus@x4 tmp % g++ -Wall -Wextra -c -O2 test.ii
markus@x4 tmp % nm test.o | c++filt
 T fn1(B&)
 U operator delete(void*)
 U A >::A(B&)
 U B::const_iterator::operator*()
 W Part::~Part()
 W Part::~Part()
 W Part::~Part()
 n Part::~Part()
 W KParts::Part::~Part()
 W KParts::Part::~Part()
 W KParts::Part::~Part()
 n KParts::Part::~Part()
 U KParts::PartBase::~PartBase()
 V typeinfo for KParts::Part
 U typeinfo for KParts::PartBase
 V typeinfo name for KParts::Part
 U vtable for __cxxabiv1::__vmi_class_type_info
 V vtable for KParts::Part

markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/g++ -Wall -Wextra -c -O2
test.ii
markus@x4 tmp % nm test.o | c++filt
 T fn1(B&)
 U A >::A(B&)
 U B::const_iterator::operator*()
markus@x4 tmp %

[Bug plugins/59335] Plugin doesn't build on trunk

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  5 15:06:23 2014
New Revision: 208346

URL: http://gcc.gnu.org/viewcvs?rev=208346&root=gcc&view=rev
Log:
PR plugins/59335
* Makefile.in (PLUGIN_HEADERS): Add tree-phinodes.h, stor-layout.h,
ssa-iterators.h, $(RESOURCE_H) and tree-cfgcleanup.h.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in

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

[trippels at gcc dot gnu.org]

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

--- Comment #24 from Markus Trippelsdorf  ---
Created attachment 32272
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32272&action=edit
Unreduced testcase

Here's the unreduced testcase:

markus@x4 tmp % g++ -Wall -Wextra -c -O2 test.ii
markus@x4 tmp % nm test.o | c++filt | grep KPart
 U KParts::Part::setManager(KParts::PartManager*)
 U KParts::Part::customEvent(QEvent*)
 U KParts::Part::qt_metacall(QMetaObject::Call, int, void**)
 U KParts::Part::qt_metacast(char const*)
 U KParts::Part::setSelectable(bool)
 U KParts::Part::partSelectEvent(KParts::PartSelectEvent*)
 U KParts::Part::guiActivateEvent(KParts::GUIActivateEvent*)
 U KParts::Part::partActivateEvent(KParts::PartActivateEvent*)
 U KParts::Part::embed(QWidget*)
 U KParts::Part::widget()
 U KParts::Part::hitTest(QWidget*, QPoint const&)
 U KParts::Part::setWidget(QWidget*)
 U KParts::Part::~Part()
 U KParts::Part::~Part()
 U KParts::Part::~Part()
 U KParts::PartBase::setComponentData(KComponentData const&)
 U KParts::PartBase::setComponentData(KComponentData const&,
bool)
 U KParts::PartBase::~PartBase()
 U KParts::PartBase::~PartBase()
 U KParts::Part::metaObject() const
 V construction vtable for KParts::Part-in-KOrg::Part
 V construction vtable for KParts::PartBase-in-KOrg::Part
 U non-virtual thunk to KParts::Part::~Part()
 U non-virtual thunk to KParts::Part::~Part()
 U typeinfo for KParts::Part
 U typeinfo for KParts::PartBase
 U virtual thunk to KParts::Part::~Part()
 U virtual thunk to KParts::Part::~Part()
 U virtual thunk to KParts::PartBase::~PartBase()
 U virtual thunk to KParts::PartBase::~PartBase()
 U virtual thunk to
KParts::PartBase::setComponentData(KComponentData const&)

[Bug target/60369] [PATCH] [TIC6X] new compiler intrinsics

[wojtek.golf at interia dot pl]

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

--- Comment #1 from Wojciech Migda  ---
Created attachment 32273
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32273&action=edit
Patch, as specified in the report body.

[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #5)
> Well, one can argue whether a bug in a new feature is a real regression ...

Yeah, but maybe we should rather argue about how to fix it than how to classify
it ;)

[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.9.0

[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #2 from Richard Biener  ---
Which architecture?

[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

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

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

--- Comment #3 from Andreas Schwab  ---
Everywhere.

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

[jason at gcc dot gnu.org]

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

--- Comment #25 from Jason Merrill  ---
OK, this testcase wasn't affected by my earlier patch because ~Part is
user-defined, so it's fair game for devirtualization.

I notice, however, that in the unreduced testcase Part is an abstract class, so
it doesn't make sense to choose its destructor for speculative
devirtualization: that can never be the right answer.  I'll fix that.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 32274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32274&action=edit
WIP patch to start combining useless value removal and table reset, after
reverting the faulty patch

I'd prefer if we kept the preserved table without potentially useless locs. 
I've struggled for several hours this morning trying to combine useless value
removal, preservation of values in the alternate table, detection of constants
and equivalences for preservation and discarding values that should not be
preserved into fewer passes over the hash table, unfortunately without much
success.  In the end, I returned to mostly separate removal and reset passes,
but I've managed to make both passes optional, except at the end of
vt_initialize.  Here's the WIP patch, to be applied after the reversal of the
faulty patch.  Unfortunately, the result is not much faster than the reversal,
probably because it works much harder to release cselib_vals and loc lists as
they get removed from the table, instead of just dropping them on the floor
till the pool is released as a whole.

[Bug lto/60424] [4.9 regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o link, -O0 -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Isn't this the same issue as PR60427?

[Bug c++/60430] New: static_assert and reference to const/constexpr

[florent.hivert at lri dot fr]

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

Bug ID: 60430
   Summary: static_assert and reference to const/constexpr
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florent.hivert at lri dot fr

I think the following should be accepted:


constexpr const int A = 42;
const int &B = A;
static_assert(&A == &B, "Bug");

int main() {return 0;}


Indeed, even if B is not constexpr its address is. On the contrary GCC
complains with


bug2.cpp:3:1: error: non-constant condition for static assertion
 static_assert(&A == &B, "Bug");
 ^
bug2.cpp:3:1: error: the value of ‘B’ is not usable in a constant expression
bug2.cpp:2:12: note: ‘B’ was not declared ‘constexpr’
 const int &B = A;

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I admit I haven't timed the insn-recog.c compilation time with my patch, but I
haven't noticed that the compile time would increase significantly.  I guess I
can benchmark it now.

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[wojtek.golf at interia dot pl]

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

--- Comment #1 from Wojciech Migda  ---
Created attachment 32275
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32275&action=edit
Proposed patch

[Bug target/60431] New: [PATCH] [TIC6X] target description missing abssi2 insn

[wojtek.golf at interia dot pl]

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

Bug ID: 60431
   Summary: [PATCH] [TIC6X] target description missing abssi2 insn
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojtek.golf at interia dot pl
  Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP
Wed Oct 23 17:26:33 UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
 Build: tic6x-none-elf-gcc-4.8.3 (GCC) 4.8.3 20140303
(prerelease)

Target definition has ssabssi2 insn definition, which uses ss_abs operand, but
does not have an insn which uses abs operand. As a result simple code which one
would expect to generate abs insn generates much less efficient set of
expressions.

For the testcase:

# 1 "main.c"
# 1 ""
# 1 "main.c"
int fn_1(int x)
{
  return (x >= 0) ? x : -x;
}

int fn_2(int x)
{
  return (x > 0) ? x : -x;
}

stock gcc generates (-march=c674x -fverbose-asm -O2 -g0 -S -dp main.c
-fdump-final-insns=rtl-dump.rtl):

(insn# 0 0 2 (sequence [
(insn:TI# # # 2 (unspec [
(reg:SI 35 B3)
(const_int 2 [0x2])
] UNSPEC_REAL_JUMP) main.c:4# {real_ret}
 (nil))
(insn# # # 2 (set (reg:SI 3 A3 [77])
(ashiftrt:SI (reg/v:SI 4 A4 [orig:75 x ] [75])
(const_int 31 [0x1f]))) main.c:4# {ashrsi3}
 (nil))
]) main.c:4#
 (nil))
(insn:TI# 0 0 2 (set (reg:SI 4 A4 [orig:76 D.1411 ] [76])
(xor:SI (reg:SI 3 A3 [77])
(reg/v:SI 4 A4 [orig:75 x ] [75]))) main.c:3# {xorsi3}
 (nil))
(insn:TI# 0 0 2 (set (reg/i:SI 4 A4)
(minus:SI (reg:SI 4 A4 [orig:76 D.1411 ] [76])
(reg:SI 3 A3 [77]))) main.c:4# {subsi3}
 (expr_list:REG_DEAD (reg:SI 3 A3 [77])
(nil)))
(insn:TI# 0 0 2 (unspec [
(const_int 3 [0x3])
] UNSPEC_NOP) main.c:4# {nop_count}
 (nil))
(insn# 0 0 2 (use (reg/i:SI 4 A4)) main.c:4#
 (nil))
(jump_insn:TI# 0 0 2 (parallel [
(unspec [
(const_int 0 [0])
] UNSPEC_JUMP_SHADOW)
(return)
]) main.c:4# {return_shadow}
 (expr_list:REG_DEAD (reg:SI 35 B3)
(nil))
 -> return)


In contrast, Texas Instruments compiler produces the machine code below:

_fn_1:
   BNOP.S2   B3,4
   ABS.L1A4,A4
_fn_2:
   BNOP.S2   B3,3
   CMPLT.L1  0,A4,A0
[!A0]  NEG.L1A4,A4

The proposed patch introduces a clone of the ssabssi2 insn which uses abs
instead of ss_abs operand.
When it is applied gcc produces rtl below:

(insn# 0 0 2 (sequence [
(insn:TI# # # 2 (unspec [
(reg:SI 35 B3)
(const_int 2 [0x2])
] UNSPEC_REAL_JUMP) main.c:4# {real_ret}
 (nil))
(insn# # # 2 (set (reg/i:SI 4 A4)
(abs:SI (reg:SI 4 A4 [ x ]))) main.c:4# {abssi2}
 (nil))
]) main.c:4#
 (nil))
(insn:TI# 0 0 2 (unspec [
(const_int 5 [0x5])
] UNSPEC_NOP) main.c:4# {nop_count}
 (nil))
(insn# 0 0 2 (use (reg/i:SI 4 A4)) main.c:4#
 (nil))
(jump_insn:TI# 0 0 2 (parallel [
(unspec [
(const_int 0 [0])
] UNSPEC_JUMP_SHADOW)
(return)
]) main.c:4# {return_shadow}
 (expr_list:REG_DEAD (reg:SI 35 B3)
(nil))
 -> return)

for both functions fn_1 and fn_2 from the testcase listed above. One can notice
that this time abssi2 will be used and that for fn_2 gcc will properly
recognize that it can generate the same rtl as for fn_1, which will be better
than that produced by the TI compiler. 

ChangeLog
2014-03-05  Wojciech Migda  

* gcc/config/c6x/c6x.md: abssi2 instruction.
* gcc/testsuite/gcc.target/tic6x/abssi2-scan.c: abssi2 testcases.

Bootstrapping and testing
Host: Linux wmigda-desktop 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 17:26:33
UTC 2013 i686 i686 i686 GNU/Linux
Target: tic6x-none-elf
Results for the new testcases (run with make check-gcc
RUNTESTFLAGS="CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET
--sysroot=${CXTOOLS}${TRIPLET}/sysroot' -v -v tic6x.exp")

PASS: gcc.target/tic6x/abssi2-scan.c (test for excess errors)
PASS: gcc.target/tic6x/abssi2-scan.c scan-assembler-times [\\t ]abs[\\t ] 2

Patch attached.

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[wojtek.golf at interia dot pl]

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

--- Comment #2 from Wojciech Migda  ---
Created attachment 32276
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32276&action=edit
patch amendment - previous was incomplete

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

[nheghathivhistha at gmail dot com]

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

--- Comment #26 from David Kredba  ---
Hello Markus,
Could you kindly please write here how are you reducing this?

(So next time I can try to do it myself.)

Thank you in advance.

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

[trippels at gcc dot gnu.org]

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

--- Comment #27 from Markus Trippelsdorf  ---
(In reply to David Kredba from comment #26)
> Hello Markus,
> Could you kindly please write here how are you reducing this?
> 
> (So next time I can try to do it myself.)

Sure.
First thing is to find out which object files contains these
undefined symbols.
 cd /var/tmp/portage/kde-base/korganizer-4.12.3
 for f in **/*.o ; do echo $f && nm $f | c++filt | grep "KParts::Part::~Part()"
; done
This will point to kocore.o. Then lookup how kocore.o was compiled
in the build.log. Add --save-temps to the invocation. Write a check.sh script
for creduce, e.g. something like:

 % cat check.sh
#!/bin/sh
/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/g++ -Wall -Wextra -c -O2 -Werror
-Wfatal-errors -c test.ii -pipe
  if ! test $? = 0; then
exit 1
  fi
nm test.o | grep _ZN6KParts4PartD0Ev 
  if test $? = 0; then
exit 1
  fi
g++ -Wall -Wextra -c -O2 -Werror -Wfatal-errors test.ii -pipe
  if ! test $? = 0; then
exit 1
  fi
nm test.o | grep _ZN6KParts4PartD0Ev 
  if ! test $? = 0; then
exit 1
  fi

And finally run creduce.

[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts "universal installation"

[egall at gwmail dot gwu.edu]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> I am running into this error as well. I attached my relevant logfiles in the
> downstream ticket that the OP linked to.
> 
> (In reply to Dominique d'Humieres from comment #1)
> > 
> > Check 
> > (1) that you have the right versions of this libraries in /opt/local that
> > pass 'make check' without error;
> 
> Local-Admins-MacBook-Pro:~ ericgallager$ port installed gmp mpfr libmpc
> The following ports are currently installed:
>   gmp @5.1.2_0+universal (active)
>   libmpc @1.0.2_0+universal (active)
>   mpfr @3.1.1-p2_0+universal (active)
> 
> I lost my results for their testsuites, but I suppose that I can run them
> again...

So I am back after re-running the testsuites, and it turned out that mpfr was
the culprit, so I opened a separate issue downstream for that:
https://trac.macports.org/ticket/42732

[Bug c++/60432] New: Member pointer resolution within class definition causes segmentation fault

[jpelletier at jumptrading dot com]

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

Bug ID: 60432
   Summary: Member pointer resolution within class definition
causes segmentation fault
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpelletier at jumptrading dot com

[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault

[jpelletier at jumptrading dot com]

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

--- Comment #1 from jpelletier at jumptrading dot com ---
Created attachment 32277
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32277&action=edit
full error output

[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault

[jpelletier at jumptrading dot com]

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

--- Comment #2 from jpelletier at jumptrading dot com ---
The following code causes a segmentation fault:

#include 

struct A
{
 int a;
 static constexpr int A::*p = &A::a;
};

%g++ -std=c++11 -c member.cc
member.cc:6:35: internal compiler error: Segmentation fault
  static constexpr int A::*p = &A::a;
   ^

[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault

[jpelletier at jumptrading dot com]

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

--- Comment #3 from jpelletier at jumptrading dot com ---
Created attachment 32278
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32278&action=edit
preprocessed file

[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts "universal installation"

[egall at gwmail dot gwu.edu]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> > I lost my results for their testsuites, but I suppose that I can run them
> > again...
> 
> So I am back after re-running the testsuites, and it turned out that mpfr
> was the culprit, so I opened a separate issue downstream for that:
> https://trac.macports.org/ticket/42732

Actually libmpc was to blame as well: https://trac.macports.org/ticket/42733

[Bug c++/60361] [4.7/4.8/4.9 Regression] unexpected 'use of parameter outside function body' error

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Mar  5 17:53:28 2014
New Revision: 208351

URL: http://gcc.gnu.org/viewcvs?rev=208351&root=gcc&view=rev
Log:
PR c++/60361
* parser.c (cp_parser_template_id): Don't set up a CPP_TEMPLATE_ID
if re-parsing might succeed.
* semantics.c (finish_id_expression): Use of a parameter outside
the function body is a parse error.

Added:
trunk/gcc/testsuite/g++.dg/parse/ambig7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/g++.dg/parse/parameter-declaration-2.C
trunk/gcc/testsuite/g++.dg/parse/typename7.C

[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/60361] [4.7/4.8 Regression] unexpected 'use of parameter outside function body' error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression]
   |unexpected 'use of  |unexpected 'use of
   |parameter outside function  |parameter outside function
   |body' error |body' error
  Known to fail|4.9.0   |

--- Comment #3 from Jason Merrill  ---
Fixed in 4.9 for now.

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The semantics of the abssi2 insn pattern on the most negative integer are 
that it returns the argument unchanged (RTL operations are generally 
modulo; the semantics don't depend on whether -fwrapv is used).  Thus, a 
saturating abs instruction is unsuitable for implementing that pattern; 
you need to make the machine-independent compiler able to use ssabssi2 to 
expand ABS_EXPR-with-undefined-overflow (i.e. ABS_EXPR without flag_wrapv 
or flag_trapv), when the saturating pattern is present but not the 
non-saturating pattern.

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

[jason at gcc dot gnu.org]

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

--- Comment #28 from Jason Merrill  ---
Created attachment 32279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32279&action=edit
New patch

Does this fix KDE?

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

[trippels at gcc dot gnu.org]

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

--- Comment #29 from Markus Trippelsdorf  ---
(In reply to Jason Merrill from comment #28)
> Created attachment 32279 [details]
> New patch
> 
> Does this fix KDE?

Yes. Thanks Jason.

[Bug debug/60381] [4.9 Regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8245

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I've measured (everything --enable-checking=release bootstrapped) vanilla
trunk, that + my http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00142.html patch,
trunk with 208220 reverted and the same plus your WIP patch on insn-recog.ii
(on a SNB box):
vanilla
real 2m11.855s
user 2m9.917s
sys 0m1.479s

my
real 2m11.760s
user 2m9.823s
sys 0m1.449s

208220revert
real 2m11.632s
user 2m9.847s
sys 0m1.310s

lxo
real 2m12.491s
user 2m10.699s
sys 0m1.304s

so I guess all the changes are pretty much in the noise when the r208221 change
is in, so we might as well just revert r208220 and do nothing else.

[Bug c++/60432] Member pointer resolution within class definition causes segmentation fault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.9.0

--- Comment #4 from Jonathan Wakely  ---
The #include is not required to reproduce the bug.

It is already fixed for GCC 4.9.0

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
Created attachment 32280
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32280&action=edit
The assembly difference of good and bad executables

Here is the assembly difference of good and bad executables due
the removal of the single loop preheader.

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Richard Biener from comment #4)
> 
> That's odd.  What's the code generation difference in the end
> for the minimal range {to, from} that still shows a difference
> of the result?

In this particular case, loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
returns false:

(gdb) bt
#0  tree_forwarder_block_p (bb=0x7f69144186e8, phi_wanted=false)
at ../../../../gcc/gcc/tree-cfgcleanup.c:357
#1  0x00a9a07c in cleanup_tree_cfg_bb (bb=0x7f69144186e8)
at ../../../../gcc/gcc/tree-cfgcleanup.c:666
#2  0x00a9a19c in cleanup_tree_cfg_1 ()
at ../../../../gcc/gcc/tree-cfgcleanup.c:709
#3  0x00a9a2d4 in cleanup_tree_cfg_noloop ()
at ../../../../gcc/gcc/tree-cfgcleanup.c:765
#4  0x00a9a3e0 in cleanup_tree_cfg ()
at ../../../../gcc/gcc/tree-cfgcleanup.c:820
#5  0x00967f20 in execute_function_todo (data=0x834)
at ../../../../gcc/gcc/passes.c:1811
#6  0x0096732a in do_per_function (
callback=0x967ee1 , data=0x834)
at ../../../../gcc/gcc/passes.c:1574
#7  0x00968176 in execute_todo (flags=2100)
at ../../../../gcc/gcc/passes.c:1887
#8  0x00968c05 in execute_one_pass (pass=0x29469b0)
at ../../../../gcc/gcc/passes.c:2243
#9  0x00968d8f in execute_pass_list (pass=0x29469b0)
at ../../../../gcc/gcc/passes.c:2282
#10 0x00968dc0 in execute_pass_list (pass=0x2945ed0)
at ../../../../gcc/gcc/passes.c:2283
---Type  to continue, or q  to quit---q
Quit
(gdb) f 5
#5  0x00967f20 in execute_function_todo (data=0x834)
at ../../../../gcc/gcc/passes.c:1811
1811  cleanup_tree_cfg ();
(gdb) f 6
#6  0x0096732a in do_per_function (
callback=0x967ee1 , data=0x834)
at ../../../../gcc/gcc/passes.c:1574
1574callback (data);
(gdb) f 8
#8  0x00968c05 in execute_one_pass (pass=0x29469b0)
at ../../../../gcc/gcc/passes.c:2243
2243  execute_todo (todo_after | pass->todo_flags_finish);
(gdb) p *pass
$4 = { = {type = GIMPLE_PASS, name = 0x1300470 "phicprop", 
optinfo_flags = 0, has_gate = true, has_execute = true, 
tv_id = TV_TREE_PHI_CPROP, properties_required = 40, 
properties_provided = 0, properties_destroyed = 0, 
todo_flags_start = 524288, todo_flags_finish = 2100}, 
  _vptr.opt_pass = 0x13003d0 , sub = 0x0, next = 0x2946a10,
static_pass_number = 85, 
  graph_dump_initialized = false, m_ctxt = 0x29214e0}

Is this OK for the phicprop pass to remove loop pre-headers when
loop_optimizer_init isn't called?

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[wojtek.golf at interia dot pl]

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

--- Comment #4 from Wojciech Migda  ---
Ok, my bad. I'll work on the testcases so that I can make gcc emit abs when it
is valid. Should this PR be rejected then?

[Bug debug/60433] New: auto-fn24.C:7:8: ICE: in dbxout_type, at dbxout.c:2371

[danglin at gcc dot gnu.org]

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

Bug ID: 60433
   Summary: auto-fn24.C:7:8: ICE: in dbxout_type, at dbxout.c:2371
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/auto-fn24.C
 -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/g
cc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/te
st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc
/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/tes
t/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++1y -g -S
-o
 auto-fn24.s
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/cpp1y/auto-fn24.C:7:8: internal compiler
error: in dbxout_type, at dbxout.c:2371

[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed Mar  5 19:25:37 2014
New Revision: 208352

URL: http://gcc.gnu.org/viewcvs?rev=208352&root=gcc&view=rev
Log:
PR c++/60409
* semantics.c (force_paren_expr): Only add a PAREN_EXPR to a
dependent expression.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/regress1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug c++/60409] [4.9 Regression] [c++1y] ICE on valid with template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
current_loops is setup by

(gdb) bt
#0  set_loops_for_fn (fn=0x715901f8, loops=0x7fffef079e20)
at ../../../../gcc/gcc/function.h:747
#1  0x008fe35e in input_cfg (ib=0x7fffdbc0, data_in=0x1fc4a80, 
fn=0x715901f8, count_materialization_scale=1)
at ../../../../gcc/gcc/lto-streamer-in.c:687
#2  0x008ff088 in input_function (fn_decl=0x71a6d800, 
data_in=0x1fc4a80, ib=0x7fffdbb0, ib_cfg=0x7fffdbc0)
at ../../../../gcc/gcc/lto-streamer-in.c:935
#3  0x008ff7ca in lto_read_body (file_data=0x71866000, 
node=0x710468f8, data=0x2439810 "\003", 
section_type=LTO_section_function_body)
at ../../../../gcc/gcc/lto-streamer-in.c:1081
#4  0x008ffa55 in lto_input_function_body (file_data=0x71866000, 
node=0x710468f8, data=0x2439810 "\003")
at ../../../../gcc/gcc/lto-streamer-in.c:1123
#5  0x0063ea32 in cgraph_get_body (node=0x710468f8)
at ../../../../gcc/gcc/cgraph.c:3012
#6  0x006466ad in expand_function (node=0x710468f8)
at ../../../../gcc/gcc/cgraphunit.c:1746
#7  0x00646d5e in expand_all_functions ()
at ../../../../gcc/gcc/cgraphunit.c:1908
#8  0x0064772a in compile () at ../../../../gcc/gcc/cgraphunit.c:2252
#9  0x0059a615 in lto_main () at ../../../../gcc/gcc/lto/lto.c:3427
---Type  to continue, or q  to quit---
#10 0x00a53c2c in compile_file () at ../../../../gcc/gcc/toplev.c:548
#11 0x00a55dc3 in do_compile () at ../../../../gcc/gcc/toplev.c:1914
#12 0x00a55f2e in toplev_main (argc=22, argv=0x1ac9810)
at ../../../../gcc/gcc/toplev.c:1990
#13 0x011ddec4 in main (argc=22, argv=0x7fffdef8)
at ../../../../gcc/gcc/main.c:36

if (current_loops)
{
}

is entered without calling loop_optimizer_init first.

[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  5 20:07:50 2014
New Revision: 208354

URL: http://gcc.gnu.org/viewcvs?rev=208354&root=gcc&view=rev
Log:
PR testsuite/59308
* gcc.dg/pr46309.c: Don't compile on logical_op_short_circuit targets
other than mips/avr.  Use -mbranch-cost=2 even for i?86/x86_64.
* gcc.dg/tree-ssa/reassoc-32.c: Use -mbranch-cost=2 even for
s390*/i?86/x86_64.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c: Don't compile on
logical_op_short_circuit targets other than avr.  Use -mbranch-cost=2
even for mips*/s390*/i?86/x86_64.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c: Likewise.
* gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr46309.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-32.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-33.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-34.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-36.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-ccmp-6.c

[Bug lto/60404] [4.9 Regression] wrong code by LTO on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #6 from Zhendong Su  ---
(In reply to Jakub Jelinek from comment #5)
> Fixed, thanks for reporting this.

Jakub, thanks for the quick fix! 

I'm intrigued by Eric's earlier comment.  Is it one of the purposes of LTO so
that one could link object files (and shared libraries) compiled separately,
and possibly by others?  In that case, I could certainly imagine linking at
-O0, say for debugging, etc., correct?

[Bug target/58271] ICE in gcc for a MIPS target during compilation with -mpaired-single -ftree-vectorize

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-03-05
 CC||rsandifo at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Thanks for the report and sorry for the slow reply.  I agree we should
disable -mpaired-single here.

[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #3 from Mikael Morin  ---
for both calls (my_mul and my_mul_cont) we create a descriptor for a (with
transposed bounds as expected) and make a call to internal_pack.
After that the calls start to differ.
The pointer returned by internal_pack is passed directly to my_mul.
In the case of my_mul_cont, we have to create a descriptor around the pointer
to pass as argument, and we reuse the one passed to internal_pack, but that one
has the bounds transposed! So we pass the transposed array with transposed
bounds -> we pass the original array.

[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
With LTO, current_loops->state may not be set and
loops_state_satisfies_p () may always be false.

[Bug fortran/60392] Problem with TRANSPOSE and CONTIGUOUS dummy arguments

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
(In reply to Mikael Morin from comment #3)
> So we pass the transposed array with
> transposed bounds -> we pass the original array.

Not exactly in fact:
In my_mul_cont, a.stride[0] == 2 and a.stride[1] == 1.
But a descriptor is created for the matmul call, and that one resets
a.stride[0] to 1, so the descriptor passed to matmul has a.stride[0] == 1 and
a.stride[1] == 1.

[Bug c++/60434] New: False -Wformat warnings about %lld and %Lf are given on Windows

[egor_suvorov at mail dot ru]

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

Bug ID: 60434
   Summary: False -Wformat warnings about %lld and %Lf are given
on Windows
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egor_suvorov at mail dot ru

As you know, C++11 defines %Lf for writing and reading long double and %lf/%f
for double. I can successfully use them in printf in MinGW, but it gives me
false warnings when -Wformat enabled. However, it clearly knows something about
formatting, because if I disable C++11 standard, behavior is changed.

Consider the following example:

#include 

int main() {
  long double x = 123.45;
  printf("%f\n", x);  // Undefined
  printf("%lf\n", x); // Undefined
  printf("%Lf\n", x); // Expected '123.45' in C++11

  double y = x;
  printf("%f\n", y);  // Expected '123.45' in C++11
  printf("%lf\n", y); // Expected '123.45' in C++03/C++11
  printf("%Lf\n", y); // Undefined
  return 0;
}

It works when compiling with C++11 or C++03, but it works exactly is it should
to the corresponding standard. Looks like GCC's warnings system does not know
about 'L' modifier in C++11 and consider it spoiled.

I've already https://sourceforge.net/p/mingw/bugs/2190/";>reported
this to MinGW team and they told me to redirect my report here.

[Bug plugins/59335] Plugin doesn't build on trunk

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #16 from Jakub Jelinek  ---
If you are aware of any further headers not installed, please reopen.

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[wojtek.golf at interia dot pl]

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

--- Comment #5 from Wojciech Migda  ---
So, I'd like to learn some more from this. Suppose I have code like this:

int fn_i1(int x)
{
  x /= 2;
  return (x >= 0) ? x : -x;
}

or

short fn_s1(short x)
{
  return (x >= 0) ? x : -x;
}

In each case the compiler should know that the range of values being subjected
to *abs is such that it won't matter whether it will use the sign saturated
instruction or not. But it doesn't take advantage of that. Or I am still
getting it wrong?

[Bug plugins/59335] Plugin doesn't build on trunk

[pageexec at gmail dot com]

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

--- Comment #17 from PaX Team  ---
sure, thanks for fixing the already mentioned ones, i verified that all works
fine for my plugins at least. as a related question, isn't there a better way
than playing this whack-a-mole game with gcc headers vs. plugin headers? as i
understand it, the testsuite doesn't simulate an installed environment for
plugins but there has to be a way to automatically discover new
headers+dependencies that should be exposed to plugins...

PS: i can't reopen this one as i don't seem to have such rights but i'll
comment anyway if i run across something.

PS2: can the $(RESOURCE_H) hunk be backported to the still maintained versions
at least?

[Bug c/60435] New: GCC failes to apply CSE for va_arg with different types whose representations match

[bugdal at aerifal dot cx]

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

Bug ID: 60435
   Summary: GCC failes to apply CSE for va_arg with different
types whose representations match
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugdal at aerifal dot cx

Consider code of the following form:

long foo;
switch (cmd) {
case CMD1:
case CMD2:
case CMD3:
/* ... */
case CMD99:
foo = va_arg(ap, int);
break;
default:
foo = va_arg(ap, long);
break;
}

On machines where int and long have the same representation (even if just in
calling convention, not in memory), this whole switch should be eliminated. GCC
fails to do so, possibly resulting in large amounts of useless branch code.

[Bug target/60431] [PATCH] [TIC6X] target description missing abssi2 insn

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
That sounds like another case for adding an target-independent feature.  
That is, the target description is accurate here but the 
target-independent parts of the compiler could do with new features to 
optimize better for such targets.

[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.

[john.carter at taitradio dot com]

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

John Carter  changed:

   What|Removed |Added

 CC||john.carter at taitradio dot 
com

--- Comment #5 from John Carter  ---
Seems present in Ubuntu Saucy gcov version 4.8.1

Seems related to / Duplicate of ... 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945

[Bug bootstrap/57486] bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform

[brooks at gcc dot gnu.org]

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

Brooks Moses  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||brooks at gcc dot gnu.org
 Resolution|--- |MOVED

--- Comment #4 from Brooks Moses  ---
This appears to be a local issue with the google/* branches.  It's now been
reported internally at Google, and I'm closing this since it doesn't appear to
be an upstream-GCC issue.

(Matt, Dinar, please reopen if this reproduces on trunk or an FSF branch.)