[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Not even with r202421.
Content of main with that revision for x86_64 -Os is:
.cfi_startproc
pushq%rcx
.cfi_def_cfa_offset 16
movla(%rip), %esi
testl%esi, %esi
je.L4
negl%esi
testl%esi, %esi
jg.L3
jmp.L2
.L4:
xorl%esi, %esi
.L2:
movl$.LC0, %edi
xorl%eax, %eax
callprintf
.L3:
xorl%eax, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

--- Comment #2 from Zhendong Su  ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this, neither with 64-bit nor 32-bit.

Jakub, perhaps fixed in later revisions?  I tested it using 202421.

[Bug middle-end/58387] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce this, neither with 64-bit nor 32-bit.

[Bug tree-optimization/58342] ICE in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

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

Bug 58342 depends on bug 58340, which changed state.

Bug 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler 
error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340

   What|Removed |Added

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

[Bug bootstrap/58340] [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #19 from Jeffrey A. Law  ---
Fixed on trunk by fix for 58380.

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[law at redhat dot com]

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

--- Comment #11 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Wed Sep 11 02:23:48 2013
New Revision: 202489

URL: http://gcc.gnu.org/viewcvs?rev=202489&root=gcc&view=rev
Log:
PR tree-optimization/58380
* tree-ssa-threadupdate.c (thread_block): Recognize another case
of threading through a buried loop header.

* tree-ssa-threadedge.c (thread_around_empty_blocks): Correct
return value for single successor case.

* g++.dg/torture/pr58380.C: New test.

2013-09-10  Jeff Law  

Added:
trunk/gcc/testsuite/g++.dg/torture/pr58380.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c
trunk/gcc/tree-ssa-threadupdate.c

[Bug bootstrap/58386] [4.9 regression] libstdc++.so.6: undefined symbol: htab_hash_pointer

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
Forget to mention: FAIL from c#1 was with make -j5 / 4 CPU

with -enable-checking=release and 'make' FAIL differ

checking for x86_64-unknown-linux-gnu-gcc...
/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/sys-include   
checking for C compiler default output file name... 
configure: error: in
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libsanitizer':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libsanitizer] Error 77

config.log contains

configure:3517: checking for C compiler default output file name
configure:3539: /home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/sys-include-g -O2  
conftest.c  >&5
/home/dimhen/build/gcc_current/./gcc/xgcc: symbol lookup error:
/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
undefined symbol: htab_hash_pointer
configure:3543: $? = 127

[Bug middle-end/58385] [4.7/4.8/4.9 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/58387] New: wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

Bug ID: 58387
   Summary: wrong code at -Os and above on x86_64-linux-gnu (both
32-bit and 64-bit modes)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk produces wrong code for the attached testcase on
x86_64-linux-gnu when compiled at -Os and above in both 32-bit and 64-bit
modes. 

It is a regression from 4.8.x.  

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130910 (experimental) [trunk revision 202421] (GCC) 
$ gcc-trunk -O1 small.c
$ a.out
$ gcc-4.8 -O2 small.c
$ a.out
$ gcc-trunk -Os small.c
$ a.out
0
$ 


-

int printf (const char *, ...);

int a = -1; 

int main ()
{
  int b = a == 0 ? 0 : -a;
  if (b < 1)
printf ("%d\n", 0);
  return 0;
}

[Bug c++/58377] spurious "may be used uninitialized" warning with -Og

[davidxl at google dot com]

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

--- Comment #10 from davidxl at google dot com ---

When an incoming edge to a phi is a critical edge, the 'use BB' for the phi arg
should be in the split BB of the edge. Pushing the use into either the Source
BB  or the dest BB will result in extending the 'use' falsely in more BBs.  In
this case, simply use the PHI's BB won't solve the problem, as there is an
incoming path introduced not guarded by if (iftmp.1_3 != 0)

I don't see a good way to fix it unless splitting the edge.

David


(In reply to davidxl from comment #9)
> (In reply to Richard Biener from comment #5)
> > Confirmed with the C++ FE, works with the C FE.  Does not warn on trunk (for
> > no good reason I think, the reason seems to be presence of loop structure
> > and thus some extra BBs).
> > 
> > Difference:
> > 
> > trunk:
> > 
> > [WORKLIST]: add to initial list: out_2 = PHI 
> > [CHECK]: examining phi: out_2 = PHI 
> > 
> > Use in stmt out_1 = PHI 
> > is guarded by :
> > if (pop_first_bucket.2_10 != 0)
> > 
> > [CHECK] Found def edge 0 in out_1 = PHI 
> > 
> > [CHECK] Found def edge 1 in out_1 = PHI 
> > Operand defs of phi out_2 = PHI 
> > is guarded by :
> > if (out_12 != 0)
> > [CHECK]: Found unguarded use: out_1 = PHI 
> > [WORKLIST]: Update worklist with phi: out_1 = PHI  > out_2(3)>
> > [CHECK]: examining phi: out_1 = PHI 
> > 
> > Use in stmt out_2 = PHI 
> > is guarded by :
> >  (.NOT.) if (iftmp.1_3 != 0)
> > 
> > [CHECK] Found def edge 0 in out_1 = PHI 
> > 
> > [CHECK] Found def edge 1 in out_1 = PHI 
> > Operand defs of phi out_1 = PHI 
> > is guarded by :
> > if (pop_first_bucket.2_10 != 0)
> > (.AND.)
> > if (out_12 != 0)
> > (.OR.)
> > if (pop_first_bucket.2_10 != 0)
> > (.AND.)
> >  (.NOT.) if (out_12 != 0)
> > 
> > Normalized to
> > Operand defs of phi out_1 = PHI 
> > is guarded by :
> > if (pop_first_bucket.2_10 != 0)
> > ...
> > 
> > vs. 4.8 branch:
> > 
> > [WORKLIST]: add to initial list: out_2 = PHI 
> > [CHECK]: examining phi: out_2 = PHI 
> > 
> > Use in stmt out_1 = PHI 
> > is guarded by :
> > if (pop_first_bucket.2_10 != 0)
> > 
> > [CHECK] Found def edge 0 in out_1 = PHI 
> > 
> > [CHECK] Found def edge 1 in out_1 = PHI 
> > Operand defs of phi out_2 = PHI 
> > is guarded by :
> > if (out_12 != 0)
> > [CHECK]: Found unguarded use: out_1 = PHI 
> > [WORKLIST]: Update worklist with phi: out_1 = PHI  > out_2(3)>
> > [CHECK]: examining phi: out_1 = PHI 
> > [CHECK]: Found unguarded use: out_2 = PHI 
> > [CHECK]: Found unguarded use: _4 = PHI 
> > [WORKLIST]: Update worklist with phi: _4 = PHI 
> > [CHECK]: examining phi: _4 = PHI 
> > [CHECK]: Found unguarded use: return _4;
> > 
> > The IL difference is that we have
> > 
> >   :
> >   # out_1 = PHI 
> >   # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
> >   if (iftmp.1_3 != 0)
> > goto ;
> >   else
> > goto ;
> > 
> >   :
> >   out_13 = out_1;
> >   goto ;
> > ...
> >   :
> >   # _4 = PHI 
> >   return _4;
> > 
> > which doesn't warn vs.
> > 
> >   :
> >   # out_1 = PHI 
> >   # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
> >   if (iftmp.1_3 != 0)
> > goto ;
> >   else
> > goto ;
> > ...
> >   :
> >   # _4 = PHI 
> >   return _4;
> > 
> > which does.  The issue seems to be that the analysis doesn't consider
> > the PHI uses in
> > 
> >   if (iftmp.1_3 != 0)
> > goto ;
> >   else
> > goto ;
> > 
> >   :
> >   # out_2 = PHI 
> > 
> > guarded by anything (the out_1 use is guarded by iftmp.1_3 == 0).
> > 
> > David - the code does
> > 
> >   if (gimple_code (use_stmt) == GIMPLE_PHI)
> > use_bb = gimple_phi_arg_edge (use_stmt,
> >   PHI_ARG_INDEX_FROM_USE (use_p))->src;
> >   else
> > use_bb = gimple_bb (use_stmt);
> > 
> >   if (is_use_properly_guarded (use_stmt,
> >use_bb,
> > ...
> > 
> > so it chooses the source block (as approximation?).
> > 
> > Splitting all edges results in us no longer warning here and:
> > 
> > Use in stmt out_2 = PHI 
> > is guarded by :
> >  (.NOT.) if (iftmp.1_3 != 0)
> > 
> > Can you see to fix that please?  Thanks.
> 
> 
> Your analysis is correct -- the use is indeed guarded. I forgot why I chose
> to use the phi arg's source BB. Will take a look.
> 
> David

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[ktietz at gcc dot gnu.org]

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

--- Comment #41 from Kai Tietz  ---
Author: ktietz
Date: Tue Sep 10 16:19:45 2013
New Revision: 202474

URL: http://gcc.gnu.org/viewcvs?rev=202474&root=gcc&view=rev
Log:
Backport from trunk.
PR libstdc++/54314
* config/abi/pre/gnu-versioned-namespace.ver: Add thunk _ZTv0_n12_NS*
like in gnu.ver.

Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_8-branch/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver

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

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
On Tue, 10 Sep 2013, rguenther at suse dot de wrote:

> A similar (runtime) error can be provoked by subtracting pointers
> to array elements of variable size that happen to have zero size
> at runtime.

Yes, that needs to be undefined at runtime.

> This all seems to be a can of worms which I'd rather shield the
> middle-end from.  For example we assume that a[0] and a[1] never
> alias.

As I noted in bug 57725, code using zero-size objects should not care 
about whether their addresses compare equal - and any other consequence of 
a non-aliasing deduction shouldn't matter (given that stores to such 
objects will store zero bytes and reads from them will read zero bytes).

> Can we at least make arrays of zero-sized elements trigger undefined
> behavior in our extension documentation?  We probably can paper
> over the ICEs as they occur (testing coverage is very weak of course).

It's specifically the subtraction of pointers that needs to be undefined.  
I'm doubtful about making such arrays undefined in the absence of such 
subtraction.  Uses of zero-size objects are e.g. for when an object may be 
empty for some configurations of a program but not others (depending on 
whether a lock object is needed in that configuration, say), and it seems 
plausible someone might have an array of such conditionally zero-size 
objects, each corresponding to an element of another array (if there's a 
reason why using a single array of structs isn't appropriate).

[Bug other/58374] Wrong target check in configure.ac in libvtv

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #3 from Marc Glisse  ---
You need to login using your @gcc email address, not the one @google.

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

[tudorb at fb dot com]

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

Tudor Bosman  changed:

   What|Removed |Added

 CC||tudorb at fb dot com

--- Comment #2 from Tudor Bosman  ---
We're encountering the same with huge (16M elements) std::array, I presume the
issue is the same.

[Bug c/58385] New: likely wrong code bug

[regehr at cs dot utah.edu]

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

Bug ID: 58385
   Summary: likely wrong code bug
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: regehr at cs dot utah.edu
CC: chenyang at cs dot utah.edu

regehr@john-home ~/z/reduce/r112 $ gcc -O0 small.c ; ./a.out
0
regehr@john-home ~/z/reduce/r112 $ gcc -O1 small.c ; ./a.out
1
regehr@john-home ~/z/reduce/r112 $ cat small.c
int printf(const char *, ...);
int x0, x1 = 1;
int x2() {
  x1 = 0;
  return 0;
}

int main() {
  ((0 || x0) & x2() >= 0) <= 1 && 1;
  printf("%d\n", x1);
  return 0;
}
regehr@john-home ~/z/reduce/r112 $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r202470-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r202470-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130910 (experimental) (GCC)

[Bug bootstrap/58386] [4.9 regression] libstdc++.so.6: undefined symbol: htab_hash_pointer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #3 from Paolo Carlini  ---
Patch reverted.

[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
Agreed.  Testing fix.

Thanks,
Dave

[Bug c++/58377] spurious "may be used uninitialized" warning with -Og

[davidxl at google dot com]

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

--- Comment #9 from davidxl at google dot com ---
(In reply to Richard Biener from comment #5)
> Confirmed with the C++ FE, works with the C FE.  Does not warn on trunk (for
> no good reason I think, the reason seems to be presence of loop structure
> and thus some extra BBs).
> 
> Difference:
> 
> trunk:
> 
> [WORKLIST]: add to initial list: out_2 = PHI 
> [CHECK]: examining phi: out_2 = PHI 
> 
> Use in stmt out_1 = PHI 
> is guarded by :
> if (pop_first_bucket.2_10 != 0)
> 
> [CHECK] Found def edge 0 in out_1 = PHI 
> 
> [CHECK] Found def edge 1 in out_1 = PHI 
> Operand defs of phi out_2 = PHI 
> is guarded by :
> if (out_12 != 0)
> [CHECK]: Found unguarded use: out_1 = PHI 
> [WORKLIST]: Update worklist with phi: out_1 = PHI  out_2(3)>
> [CHECK]: examining phi: out_1 = PHI 
> 
> Use in stmt out_2 = PHI 
> is guarded by :
>  (.NOT.) if (iftmp.1_3 != 0)
> 
> [CHECK] Found def edge 0 in out_1 = PHI 
> 
> [CHECK] Found def edge 1 in out_1 = PHI 
> Operand defs of phi out_1 = PHI 
> is guarded by :
> if (pop_first_bucket.2_10 != 0)
> (.AND.)
> if (out_12 != 0)
> (.OR.)
> if (pop_first_bucket.2_10 != 0)
> (.AND.)
>  (.NOT.) if (out_12 != 0)
> 
> Normalized to
> Operand defs of phi out_1 = PHI 
> is guarded by :
> if (pop_first_bucket.2_10 != 0)
> ...
> 
> vs. 4.8 branch:
> 
> [WORKLIST]: add to initial list: out_2 = PHI 
> [CHECK]: examining phi: out_2 = PHI 
> 
> Use in stmt out_1 = PHI 
> is guarded by :
> if (pop_first_bucket.2_10 != 0)
> 
> [CHECK] Found def edge 0 in out_1 = PHI 
> 
> [CHECK] Found def edge 1 in out_1 = PHI 
> Operand defs of phi out_2 = PHI 
> is guarded by :
> if (out_12 != 0)
> [CHECK]: Found unguarded use: out_1 = PHI 
> [WORKLIST]: Update worklist with phi: out_1 = PHI  out_2(3)>
> [CHECK]: examining phi: out_1 = PHI 
> [CHECK]: Found unguarded use: out_2 = PHI 
> [CHECK]: Found unguarded use: _4 = PHI 
> [WORKLIST]: Update worklist with phi: _4 = PHI 
> [CHECK]: examining phi: _4 = PHI 
> [CHECK]: Found unguarded use: return _4;
> 
> The IL difference is that we have
> 
>   :
>   # out_1 = PHI 
>   # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
>   if (iftmp.1_3 != 0)
> goto ;
>   else
> goto ;
> 
>   :
>   out_13 = out_1;
>   goto ;
> ...
>   :
>   # _4 = PHI 
>   return _4;
> 
> which doesn't warn vs.
> 
>   :
>   # out_1 = PHI 
>   # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
>   if (iftmp.1_3 != 0)
> goto ;
>   else
> goto ;
> ...
>   :
>   # _4 = PHI 
>   return _4;
> 
> which does.  The issue seems to be that the analysis doesn't consider
> the PHI uses in
> 
>   if (iftmp.1_3 != 0)
> goto ;
>   else
> goto ;
> 
>   :
>   # out_2 = PHI 
> 
> guarded by anything (the out_1 use is guarded by iftmp.1_3 == 0).
> 
> David - the code does
> 
>   if (gimple_code (use_stmt) == GIMPLE_PHI)
> use_bb = gimple_phi_arg_edge (use_stmt,
>   PHI_ARG_INDEX_FROM_USE (use_p))->src;
>   else
> use_bb = gimple_bb (use_stmt);
> 
>   if (is_use_properly_guarded (use_stmt,
>use_bb,
> ...
> 
> so it chooses the source block (as approximation?).
> 
> Splitting all edges results in us no longer warning here and:
> 
> Use in stmt out_2 = PHI 
> is guarded by :
>  (.NOT.) if (iftmp.1_3 != 0)
> 
> Can you see to fix that please?  Thanks.


Your analysis is correct -- the use is indeed guarded. I forgot why I chose to
use the phi arg's source BB. Will take a look.

David

[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
I think this is a target bug.  The backend prologue code has things like:

  addr = gen_rtx_MEM (DFmode, gen_rtx_POST_INC (DFmode, tmpreg));

but {PRE,POST}_{INC,DEC} is an address rtx, so it should have the same mode
as the modified register.

[Bug c++/58377] spurious "may be used uninitialized" warning with -Og

[davidxl at google dot com]

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

--- Comment #8 from davidxl at google dot com ---
(In reply to Neil Vachharajani from comment #7)
> It seems like the whole problem is that the loop early exit goes through
> bb_6 which is the same path the back-edge goes through.

There is also one thing weird about the trunk GCC's IR


Why is constant 0 propagated into the PHI node?

_4 = PHI 

>From the CFG, it should be like

_4 = PHI?

[Bug other/58374] Wrong target check in configure.ac in libvtv

[cmtice at google dot com]

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

--- Comment #2 from Caroline Tice  ---
Even though I logged in to Bugzilla, I can't seem to edit any of the fields
above, but to the best of my knowledge a patch to fix this problem has been
committed to GCC and this bug should be marked as fixed and closed.

[Bug ipa/58367] [4.9 Regression] lto/pgo bootstrap failure

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #2)
> Todays trunk is fine again. I guess r58343 might be the fix.

I meant r202441 is the fix and therefore this bug may be a dup of PR58343.

[Bug target/58361] Wrong floating point code generated for ARM target

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Sep 10 16:53:15 2013
New Revision: 202476

URL: http://gcc.gnu.org/viewcvs?rev=202476&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern to
support conditional execution.
(combine_vcvt_f64_): Likewise.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/arm/vfp.md

[Bug ipa/58367] [4.9 Regression] lto/pgo bootstrap failure

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Todays trunk is fine again. I guess r58343 might be the fix.

[Bug c++/58377] spurious "may be used uninitialized" warning with -Og

[nvachhar at google dot com]

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

Neil Vachharajani  changed:

   What|Removed |Added

 CC||nvachhar at google dot com

--- Comment #7 from Neil Vachharajani  ---
It seems like the whole problem is that the loop early exit goes through bb_6
which is the same path the back-edge goes through.

[Bug bootstrap/58386] New: [4.9 regression] libstdc++.so.6: undefined symbol: htab_hash_pointer

[dimhen at gmail dot com]

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

Bug ID: 58386
   Summary: [4.9 regression] libstdc++.so.6: undefined symbol:
htab_hash_pointer
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com

rev.202478 FAIL
rev.202421 OK
Fedora 19/x86_64

configured as
~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--with-multilib-list=m64 --enable-checking=yes,df,fold,rtl,tree
--enable-languages=c,c++,lto --enable-plugin --with-tune=native
--with-arch=native --enable-version-specific-runtime-libs

$ make
[...]
/bin/sh /home/dimhen/src/gcc_current/libgcc/../mkinstalldirs 
/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-unknown-linux-gnu/sys-include-O2  -g -O2
-DIN_GCC   -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector  -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
-Wl,--version-script=libgcc.map -o /libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o
_addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o
_powidf2_s.o _powixf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divsc3_s.o
_divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o
_fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o
_fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
_udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o
divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o
fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o
floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o
floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o
trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o
_multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o
unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc &&
rm -f /libgcc_s.so && if [ -f /libgcc_s.so.1 ]; then mv -f /libgcc_s.so.1
/libgcc_s.so.1.backup; else true; fi && mv /libgcc_s.so.1.tmp /libgcc_s.so.1 &&
ln -s libgcc_s.so.1 /libgcc_s.so
/home/dimhen/build/gcc_current/./gcc/xgcc: symbol lookup error:
/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6:
undefined symbol: htab_hash_pointer
make[3]: *** [libgcc_s.so] Error 127
make[3]: Leaving directory
`/home/dimhen/build/gcc_current/x86_64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/dimhen/build/gcc_current'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/dimhen/build/gcc_current'
make: *** [all] Error 2

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #4 from R Copley  ---
(In reply to Kai Tietz from comment #1)
> MS' abi doesn't allow this.  So I doubt we will be able to implement that
> for this target.  If we want to re-align stack on function-base we will run
> into troubles with SEH-information.

You might be right, I'm not sure. Are you aware that on 64-bit Windows, SEH is
table-based, not frame-based (see, e.g.,
http://www.osronline.com/article.cfm?article=469)?

> Doesn't it work to align explicit the variable itself?

No (see attachments 2 and 3). If I understand correctly, the alignment
specification is redundant anyway, because the variables are supposed to be
naturally aligned, on their size.

Assembling attachment 3 with "-g" and running it in gdb gives:

Program received signal SIGSEGV, Segmentation fault.
main () at bug1.s:46
46  vmovapd %ymm0, -96(%rbp)

Thanks.

[Bug middle-end/58385] likely wrong code bug

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
Confirmed, already in 4.6. Somewhere in fold_range_test we forget to check for
side effects.

[Bug target/58361] Wrong floating point code generated for ARM target

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.4

--- Comment #5 from Richard Earnshaw  ---
Fixed

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #3 from R Copley  ---
Created attachment 30794
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30794&action=edit
Assembly-language code compiled from attachment 1

Compiled with GCC 4.7.2 from the MinGW-w64 toolchain.
Compile command: "gcc -O0 -m64 -mavx -S bug1.c -o bug1.s".
gcc -v output:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ruben/mingw-w64/src/gcc/configure
--host=x86_64-w64-mingw32 --build=x86_64-linux-gnu --target=x86_64-w64-mingw32
--with-sysroot=/home/ruben/mingw-w64/mingw64mingw64/mingw64
--prefix=/home/ruben/mingw-w64/mingw64mingw64/mingw64
--with-gmp=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-mpfr=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-mpc=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-ppl=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-cloog=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--disable-ppl-version-check --disable-cloog-version-check
--enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm'
--enable-shared --enable-static --enable-threads=win32 --enable-plugins
--disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,fortran,java
--enable-libgomp --enable-fully-dynamic-string --enable-libstdcxx-time
--disable-nls --disable-werror --enable-checking=release --with-gnu-as
--with-gnu-ld --disable-win32-registry --disable-rpath --disable-werror
--with-libiconv-prefix=/home/ruben/mingw-w64/prereq/x86_64-w64-mingw32/install
--with-pkgversion=rubenvb-4.7.2-release
--with-bugurl=mingw-w64-pub...@lists.sourceforge.net CC= CFLAGS='-O2
-march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer'
LDFLAGS=
Thread model: win32
gcc version 4.7.2 (rubenvb-4.7.2-release)

[Bug bootstrap/58386] [4.9 regression] libstdc++.so.6: undefined symbol: htab_hash_pointer

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Sep 10 18:45:29 2013
New Revision: 202480

URL: http://gcc.gnu.org/viewcvs?rev=202480&root=gcc&view=rev
Log:
2013-09-10  Paolo Carlini  

PR bootstrap/58386
Revert:

2013-09-10  Gary Benson  

* cp-demangle.c: Include hashtab.h.
(struct d_print_info): New field saved_scopes.
(d_print_init): Initialize the above.
(d_print_free): New function.
(cplus_demangle_print_callback): Call the above.
(struct d_saved_scope): New structure.
(d_store_scope): New function.
(d_free_scope) Likewise.
(d_restore_scope) Likewise.
(d_hash_saved_scope) Likewise.
(d_equal_saved_scope) Likewise.
(d_print_comp): New variable saved_scope.
[DEMANGLE_COMPONENT_REFERENCE,
DEMANGLE_COMPONENT_RVALUE_REFERENCE]: Capture scope the first
time the component is traversed, and use the captured scope for
subsequent traversals.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug middle-end/58385] [4.7/4.8/4.9 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.7.4
Summary|likely wrong code bug   |[4.7/4.8/4.9 Regression]
   ||likely wrong code bug

--- Comment #2 from Jakub Jelinek  ---
Started with r145254.

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[regehr at cs dot utah.edu]

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

John Regehr  changed:

   What|Removed |Added

 CC||regehr at cs dot utah.edu

--- Comment #34 from John Regehr  ---
Looks like another occurrence of the same issue?

regehr@john-home ~/z/reduce/r114 $ gcc -c -O3 small.c
small.c: In function ‘x4’:
small.c:3:5: error: definition in block 3 follows the use
 int x4() {
 ^
for SSA_NAME: _30 in statement:
x1.2_15 = _30 & pretmp_25;
small.c:3:5: internal compiler error: verify_ssa failed
0xaa1e9d verify_ssa(bool)
/home/regehr/z/compiler-source/gcc/gcc/tree-ssa.c:1046
0x87ea51 execute_function_todo
/home/regehr/z/compiler-source/gcc/gcc/passes.c:1834
0x87f197 execute_todo
/home/regehr/z/compiler-source/gcc/gcc/passes.c:1866
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.
regehr@john-home ~/z/reduce/r114 $ 
regehr@john-home ~/z/reduce/r114 $ cat small.c
int x0, x1, x2;
void x3();
int x4() {
  for (;;) {
x3();
int x5 = x0 = 0;
for (; x0 < 7; ++x0) {
  x5--;
  x1 &= x2 <= x5;
}
  }
}
regehr@john-home ~/z/reduce/r114 $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/compiler-install/gcc-r202470-install/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/regehr/z/compiler-source/gcc/configure
--prefix=/home/regehr/z/compiler-install/gcc-r202470-install
--enable-languages=c,c++ --disable-multilib
Thread model: posix
gcc version 4.9.0 20130910 (experimental) (GCC)

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
The #c34 testcase seems to fail starting r199048 till current HEAD.

[Bug other/58374] Wrong target check in configure.ac in libvtv

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Sep 10 16:00:13 2013
New Revision: 202470

URL: http://gcc.gnu.org/viewcvs?rev=202470&root=gcc&view=rev
Log:
Move VTV_SUPPORTED check after AC_CANONICAL_SYSTEM

PR other/58374
* configure.ac: Move VTV_SUPPORTED check after AC_CANONICAL_SYSTEM.
* configure: Regenerated.

Modified:
trunk/libvtv/ChangeLog
trunk/libvtv/configure
trunk/libvtv/configure.ac

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
This looks like slightly different variant of 58343 where we thread through a
loop header when we really didn't want to.

I haven't tracked it through to the ICE, but from looking at the CFG and the
registered jump thread, it's obvious we're threading through a loop header.

Presumably the code to handle threading through loop headers is (again) not
prepared for this particularly shaped CFG with a thread trough the header and
in the process mucks things up pretty badly.

[Bug other/58375] [4.8 Regression] internal compiler error: in push_reload, at reload.c:1360

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ra
 Status|WAITING |NEW
  Component|target  |other
  Known to work||4.7.2
   Host|MacOS 10.8 (Darwin  |
   |linus.fritz.box 12.4.0  |
   |Darwin Kernel Version   |
   |12.4.0: Wed May  1 17:57:12 |
   |PDT 2013;   |
   |root:xnu-2050.24.15~1/RELEA |
   |SE_X86_64 x86_64)   |
 Blocks||56183
Summary|internal compiler error: in |[4.8 Regression] internal
   |push_reload, at |compiler error: in
   |reload.c:1360   |push_reload, at
   ||reload.c:1360

[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows

[rcopley at gmail dot com]

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

--- Comment #2 from R Copley  ---
Created attachment 30793
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30793&action=edit
As before, but with explicitly 32-byte aligned variables

[Bug target/58375] internal compiler error: in push_reload, at reload.c:1360

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Created attachment 30792
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30792&action=edit
Channel.cpp C++ source

Confirmed with this source, looks like a register allocator issue.

$ avr-g++ Channel.cpp -mmcu=atmega2561 -Os  -c -v

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.8-mingw32 --host=i386-mingw32
--build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared
--with-dwarf2
Thread model: single
gcc version 4.8.0 20130306 (experimental) (GCC) 

GNU C++ (GCC) version 4.8.0 20130306 (experimental) (avr)
compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version
4.3.2, MPFR version 2.4.2, MPC version 0.8.2

Channel.cpp: In member function 'virtual void Screen_Setup_Channel::display()':
Channel.cpp:101:1: internal compiler error: in push_reload, at reload.c:1360
 }
 ^

Channel.cpp:101:1: internal compiler error: Segmentation fault

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
(In reply to Jeffrey A. Law from comment #7)
> Presumably David bootstrapped the trunk, then built k3d?  

Yes, the bootstrap ran fine with the usual -g -O2 on BOOT_CFLAGS.

> If this failure occurs in a stage1 cc1plus, then, well, that's totally
> different (and much easier to track down).

Yes, exactly the same Segmentation fault does occur in a stage1 cc1plus.

Command line was

$ ../results/bin/gcc -c -O2 -B/home/dcb/gcc/working/stage1-gcc/ -v bug118.cc
...
 /home/dcb/gcc/working/stage1-gcc/cc1plus -quiet ...

[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  ---
The ICE occurs because reload is asking for a DFmode (8-byte) subreg of an
XFmode (12-byte) hardreg, but 12 % 8 != 0 so the gcc_assert fails.

[Bug target/58361] Wrong floating point code generated for ARM target

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Sep 10 16:55:44 2013
New Revision: 202477

URL: http://gcc.gnu.org/viewcvs?rev=202477&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern to
support conditional execution.
(combine_vcvt_f64_): Likewise.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/arm/vfp.md

[Bug c++/58377] spurious "may be used uninitialized" warning with -Og

[davidxl at google dot com]

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

davidxl at google dot com changed:

   What|Removed |Added

 CC||davidxl at google dot com

--- Comment #6 from davidxl at google dot com ---
There are some spurious PHIs (for out) with -g.

Bad dot file (-g):

digraph "t.cc.153t.uninit2" {
overlap=false;
subgraph "int my_pop()" {
color="black";
label="int my_pop()";
fn_0_basic_block_1
[shape=Mdiamond,style=filled,fillcolor=white,label="EXIT"];

fn_0_basic_block_2 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:880 |\:\l\
goto\ \;\l\
}"];

fn_0_basic_block_7 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:1 |\:\l\
|#\ out_2\ =\ PHI\ \\l\
|pop_first_bucket.2_10\ =\ pop_first_bucket;\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_3 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:9550 |\:\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_4 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:2769 |\:\l\
|out_12\ =\ pop\ ();\l\
|if\ (out_12\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_5 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:2520 |\:\l\
}"];

fn_0_basic_block_6 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:9550 |\:\l\
|#\ out_1\ =\ PHI\ \\l\
|#\ iftmp.1_3\ =\ PHI\ \<1(4),\ 0(5),\ 0(3)\>\l\
|if\ (iftmp.1_3\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_8 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:880 |\:\l\
|#\ _4\ =\ PHI\ \\l\
|return\ _4;\l\
}"];

fn_0_basic_block_0
[shape=Mdiamond,style=filled,fillcolor=white,label="ENTRY"];

fn_0_basic_block_0:s -> fn_0_basic_block_2:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[100%]"];
fn_0_basic_block_2:s -> fn_0_basic_block_7:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[100%]"];
fn_0_basic_block_3:s -> fn_0_basic_block_4:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[29%]"];
fn_0_basic_block_3:s -> fn_0_basic_block_6:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[71%]"];
fn_0_basic_block_4:s -> fn_0_basic_block_6:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[9%]"];
fn_0_basic_block_4:s -> fn_0_basic_block_5:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[91%]"];
fn_0_basic_block_5:s -> fn_0_basic_block_6:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[100%]"];
fn_0_basic_block_6:s -> fn_0_basic_block_8:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[4%]"];
fn_0_basic_block_6:s -> fn_0_basic_block_7:n
[style="dotted,bold",color=blue,weight=10,constraint=false, label="[95%]"];
fn_0_basic_block_7:s -> fn_0_basic_block_3:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[95%]"];
fn_0_basic_block_7:s -> fn_0_basic_block_8:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[4%]"];
fn_0_basic_block_8:s -> fn_0_basic_block_1:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[100%]"];
fn_0_basic_block_0:s -> fn_0_basic_block_1:n
[style="invis",constraint=true];
}
}


GCC reports unguarded use of out at return statement. return value is defined
by

 _4 = PHI (out_1(6), 0(7))

where

out_1 = PHI (out_12 (4), out_12 (5), out_2 (3))

where

out_2 = PHI (out_8(D)(2), out_1 (6))

This phi introduces uninitialized variable use.


To compare, the good dot file is :

digraph "t.cc.133t.uninit1" {
overlap=false;
subgraph "int my_pop()" {
color="black";
label="int my_pop()";
subgraph cluster_0_1 {
style="filled";
color="darkgreen";
fillcolor="grey88";
label="loop 1";
labeljust=l;
penwidth=2;
fn_0_basic_block_5 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:1 |\:\l\
|pop_first_bucket.2_10\ =\ pop_first_bucket;\l\
|if\ (pop_first_bucket.2_10\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_3 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:2769 |\:\l\
|out_12\ =\ pop\ ();\l\
|if\ (out_12\ !=\ 0)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_0_basic_block_4 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:2520 |\:\l\
}"];

}
fn_0_basic_block_0
[shape=Mdiamond,style=filled,fillcolor=white,label="ENTRY"];

fn_0_basic_block_1
[shape=Mdiamond,style=filled,fillcolor=white,label="EXIT"];

fn_0_basic_block_2 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:880 |\:\l\
goto\ \;\l\
}"];

fn_0_basic_block_6 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:880 |\:\l\
|#\ _4\ =\ PHI\ \\l\
|return\ _4;\l\

[Bug rtl-optimization/58384] [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 30791
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30791&action=edit
test-case to reproduce

This is compile only test which must be compiled with pre-reload scheduler,
i.e.
with '-Ofast -march=corei7 -fschedule-insns --param sched-pressure-algorithm=1
-fsched-pressure' options.

[Bug target/58361] Wrong floating point code generated for ARM target

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Sep 10 16:46:55 2013
New Revision: 202475

URL: http://gcc.gnu.org/viewcvs?rev=202475&root=gcc&view=rev
Log:
PR target/58361
* arm/vfp.md (combine_vcvt_f32_): Fix pattern to
support conditional execution.
(combine_vcvt_f64_): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/vfp.md

[Bug rtl-optimization/58384] New: [4.9 regression] Runfail on spec2000/253.perlbmk if lto and pre-reload scheduler is used on x86 after r200133.

[ysrumyan at gmail dot com]

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

Bug ID: 58384
   Summary: [4.9 regression] Runfail on spec2000/253.perlbmk if
lto and pre-reload scheduler is used on x86 after
r200133.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

We also assume that arm can have the same problem at given benchmark if -flto
is used to compile since pre-reload scheduler is used by default on it.

The issue can be reproduced at attached test-case extracted from 253.perlbmk
sources (function Perl_pp_entersub, file pp_hot.c).

Before r200133 forward propagation (fwprop1 for rtl) performs substitution of
stored value to subsequent load with the same base, but after this fix does
not.
Looking at assembly files for test-case we can see that
  -- before fix --

callrealloc
movq(%rbx), %r8
movq%rax, %r9
movq%rax, %rcx
movq8(%rsp), %rdx
movq%rax, 24(%r8)
movq%rax, (%r8)
jmp.L4
 i.e. return value of 'realloc' is copied to %r9 and %rcx which correspondent
to pre temporaries.

  -- after fix -- (without pre-reload scheduler)

callrealloc
movq(%rbx), %rcx
movq(%rbx), %r8
movq8(%rsp), %rdx
movq%rax, 24(%rcx)
movq%rax, (%rcx)
movq(%r8), %rcx  <--- redundant load
movq%rcx, %rax
jmp.L4

i.w. we can see redundant load from %r8.

But if we turn on pre-reload scheduler, this load will be unlegal hoisted cross
interleaved store (we got RT error on 253.perlbmk) and we can see it in
assembly:

callrealloc
movq(%rbx), %r8
movq8(%rsp), %rdx
movq(%r8), %rcx  <--- non-legal code motion
movq%rax, 24(%r8)
movq%rax, (%r8)
movq%rcx, %rax
jmp.L4
To reproduce compile attached test-case with options
-Ofast -march=corei7 -fschedule-insns --param sched-pressure-algorithm=1
-fsched-pressure

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini  ---
Thanks a lot Chris. Sorry if I bother you for a few minutes more: when you say
"doing away with skipping optimizations altogether", you mean, essentially,
using the algorithm we have got now for forward iterators? Which is also, if I
remember correctly, what we had earlier for random access iterators too? 

In that case, I'm really unsure: I'm tempted by what Mitsuru is proposing, but
I'm not 100% sure, not because of the 10% difference, but more importantly
because we know well what we have got, nobody complained for so many years, and
your change would be only a small tweak of it. Also, I know you are around to
maintain it, which isn't a minor detail! In case, would you be willing to
maintain Mitsuru's code too? Eventually, I think I will send both patches to
the mailing list with my personal opinion, and I will ask.

[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Breakpoint 1, trunc_int_for_mode (c=8, mode=DFmode)
at ../../gcc/gcc/explow.c:55
55gcc_assert (SCALAR_INT_MODE_P (mode));
(gdb) bt
#0  trunc_int_for_mode (c=8, mode=DFmode) at ../../gcc/gcc/explow.c:55
#1  0x406bb254 in gen_int_mode (c=8, mode=DFmode)
at ../../gcc/gcc/emit-rtl.c:420
#2  0x4110e470 in adjust_mems (loc=0x83fffd533100, old_rtx=0x0,
data=0x83fffdff14b8) at ../../gcc/gcc/var-tracking.c:1058
#3  0x40c36a20 in simplify_replace_fn_rtx (x=0x83fffd533100,
old_rtx=0x0, fn=0x402ec440, data=0x83fffdff14b8)
at ../../gcc/gcc/simplify-rtx.c:426
#4  0x4110e168 in adjust_mems (loc=0x83fffd5cc558, old_rtx=0x0,
data=0x83fffdff14b8) at ../../gcc/gcc/var-tracking.c:1035
#5  0x40c36a20 in simplify_replace_fn_rtx (x=0x83fffd5cc558,
old_rtx=0x0, fn=0x402ec440, data=0x83fffdff14b8)
at ../../gcc/gcc/simplify-rtx.c:426
#6  0x4110eb78 in adjust_mem_stores (loc=0x83fffd5cc558,
expr=0x83fffd5cc570, data=0x83fffdff14b8)
at ../../gcc/gcc/var-tracking.c:1157
#7  0x40bc7e98 in note_stores (x=0x83fffd5cc570,
fun=0x402ec450, data=0x83fffdff14b8)
at ../../gcc/gcc/rtlanal.c:1518
#8  0x4110ec64 in adjust_insn (bb=0x83fffda7eb60,
insn=0x83fffdae8798) at ../../gcc/gcc/var-tracking.c:1207
#9  0x41139de8 in vt_initialize ()
at ../../gcc/gcc/var-tracking.c:9973
---Type  to continue, or q  to quit---
#10 0x4113ad54 in variable_tracking_main_1 ()
at ../../gcc/gcc/var-tracking.c:10171
#11 0x4113b074 in variable_tracking_main ()
at ../../gcc/gcc/var-tracking.c:10224
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) frame 8
#8  0x4110ec64 in adjust_insn (bb=0x83fffda7eb60,
insn=0x83fffdae8798) at ../../gcc/gcc/var-tracking.c:1207
1207  note_stores (PATTERN (insn), adjust_mem_stores, &amd);
(gdb) p debug_rtx(insn)
(insn/f:TI 248 240 249 2 (set (mem:DF (post_inc:DF (reg:DI 1 %r1)) [0 S8 A64])
(reg:DF 49 %fr21)) ../../../gcc/libgcc/unwind.inc:83 119 {*pa.md:4025}
 (expr_list:REG_DEAD (reg:DF 49 %fr21)
(expr_list:REG_FRAME_RELATED_EXPR (set (mem:DF (plus:DI (reg/f:DI 30
%r30)
(const_int -200 [0xff38])) [0 S8 A64])
(reg:DF 49 %fr21))
(nil
$1 = void

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

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

--- Comment #1 from Martin Husemann  ---
The global pointer "line_table" is changed to the contents of the precompiled
header file in gt_pch_restore in this loop:

  /* Read in all the global pointers, in 6 easy loops.  */
  for (rt = gt_ggc_rtab; *rt; rt++)
for (rti = *rt; rti->base != NULL; rti++)
  for (i = 0; i < rti->nelt; i++)
if (fread ((char *)rti->base + rti->stride * i,
   sizeof (void *), 1, f) != 1)
  fatal_error ("can%'t read PCH file: %m");

but not reset to the previous values when the compiler decides to not use the
pch contents (for example because the address of the mmap differs).

We probably need to save at least line_table (and maybe input_location) at the
start of this function and restore it before invoking fatal_error.

gcc cc1 seg fault on large file with many function calls

[rpalermo]

I have a generated C code file that contains a very large number of function
calls, all with similar function names (ie ff1, ff2, ff3, ..., ff50). It
compiles using gcc versions 3.4.6 and 4.1.2.

But using version 4.4.7, it gets  gcc: Internal error: Segmentation
fault (program cc1)

The code file is 786Mb, so it's large, but not that large. But there are a
lot of static functions declared, and a lot of calls to these functions.

Any ideas?




--
View this message in context: 
http://gcc.1065356.n5.nabble.com/gcc-cc1-seg-fault-on-large-file-with-many-function-calls-tp967294.html
Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug middle-end/58335] S/390: reload vs lra regression - testcase builtin-in-setjmp

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #1 from Vladimir Makarov  ---
LRA does not update elimination offset on subsequent passes as insns for
previous elimination offset updates are more complicated on s390 than usual.

I guess we need a different elimination approach (without parsing already
generated offset elimination insn) independent on insns generated.  It is
necessary not only for s390 but for better LRA portability in whole.

I hope to finish this until end of the week.

[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream, std::allocator >'

[pluto at agmk dot net]

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

--- Comment #40 from Pawel Sikora  ---
$ grep ZTv0 *
gnu.ver:_ZTv0_n12_NS*;
gnu.ver:_ZTv0_n24_NS*;
gnu-versioned-namespace.ver:_ZTv0_n24_NS*;

versioned namespace doesn't provide *n12* for i686.

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

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

--- Comment #2 from Martin Husemann  ---
Created attachment 30790
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790&action=edit
Restore line_table and input_location before calling fatal_error when failing a
pch load

With this patch, the fatal_error is properly reported:

> $BUILDDIR/stage1-gcc/xg++ -B $BUILDDIR/stage1-gcc -Werror -Winvalid-pch 
> -Wno-deprecated -c conftest.cc
conftest.cc:1:0: fatal error: had to relocate PCH
 #include "conftest.h"
 ^
compilation terminated.

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
202296 doesn't change anything WRT sequencing of operations; it merely allows
the threader to dive a bit deeper into the CFG to determine a final target for
a jump threading opportunity.

Presumably David bootstrapped the trunk, then built k3d?  If so, then it might
be a mis-compilation of GCC itself.  As I mentioned in c#3 I'm looking at one
of those right now.

If this failure occurs in a stage1 cc1plus, then, well, that's totally
different (and much easier to track down).

Either way, it's mine.

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[chris at bubblescope dot net]

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

--- Comment #22 from Chris Jefferson  ---
Her are some comparisons. Just to compare, I also checked doing away with
skipping optimisations altogether. Binary sizes (-O3, stripped)


current head: 11928
my code:  12248
Mitsuru:  11384
No skip:  10904

Timing:

current head: 3.70
my code:  3.70
Mitsuru:  4.04
No skip: 15.37

So we clearly want to do skipping. The tradeoff is between same speed and
bigger executables (my code) or ~10% slower but saving 1K or so binary and some
source (Mitsuru's code). I don't know what gcc/libstdc++'s general direction in
that area is.

I actually would expect Mitsuru's code to be faster (as it tries harder to skip
forwards), but it is hard to predict how these things interact with
optimisers/caches/branch predictors at a low level.

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
The symptom hints at a released SSA name being looked at.  That happens
if cfgcleanup looks at a dead code region (we especially run
TODO_cleanup_cfg before TODO_update_ssa to allow passes to be forgiving
with not removing dead blocks).  Eventually we guarded these foldings
but seem to have removed the guarding again.

[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter

[howarth at nitro dot med.uc.edu]

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

--- Comment #24 from Jack Howarth  ---
(In reply to David Fang from comment #22)
> Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's
> bundled in libgcc_s in darwin8,9,10?
> 
> http://opensource.apple.com/tarballs/libunwind/

No. The libunwind sources are the replacement compact and compatibility
unwinders that Apple introduced in 10.7. You will see that the 0.30 release
first appears at http://www.opensource.apple.com/release/mac-os-x-107/. Note
that if you look at
http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c from 10.6.8, you
will see that the unwinder calls resided in libgcc_s up to 10.5 after which
they were subsumed into libSystem. I am unclear if the subsumed unwinder calls
in 10.6.x were based on the code from libgcc but these certainly aren't based
on libunwind. Since Apple never released the source code for theses files, it
is difficult to know their heritage in 10.6.x. Also see...

http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot de

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

This is what creduce came up with.

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Thanks, the .ii file is huge and after an ~hour of reducing the creduce is
still at original file...

[Bug middle-end/58382] [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Just a note, I'm currently looking at a mis-compilation due to those changes;
it may not be worth your time to try and reduce this test until I've sorted out
this other issue.

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini  ---
Sorry. Take my 1sec and 3.5secs, as, say, 4.5secs and 20secs. You see may
point.

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|minor   |normal

--- Comment #20 from Paolo Carlini  ---
I see, thanks Chris. Don't you have the performance numbers for the baseline,
"naive" code, do you? To put in better perspective 3.74secs vs 4.12secs. Like,
if the baseline is 1 or 3.5 isn't the same!

In fact, I also like Mitsuru' patch, it's simplicity in particular. But again,
I would not choose it if the baseline is 3.5secs.

[Bug tree-optimization/58364] [4.8/4.9 Regression] likely wrong code bug

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #7 from Eric Botcazou  ---
r195642 is an equivalent fix in the folder (make_range_step).

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[chris at bubblescope dot net]

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

--- Comment #19 from Chris Jefferson  ---
(In reply to Mitsuru Kariya from comment #15)
> Created attachment 30775 [details]
> Patch
> 
> For your convenience, I attached a patch for this problem.
> 
> This algorithm is always scanned to reverse order.
> If a scan fails in less than enough, a re-scan is performed from the point
> that advanced necessary elements from the original starting point.
> 
> For example, if __count is 20 and a scan fails after 18 elements succeeded,
> a re-scan is performed from the point that advanced 2 elements.

This patch is good, but takes a different route., trying to always skip as far
forwards as possible. On a small test (compiling the 'search_n/iterator.cc'
test, disabling forward checking and bidirection tests, increasing TEST_DEPTH
to 23, compiling -O3):

Both implementations pass correctness and number of comparison tests.

Mitsuru's code is about 1K smaller.

My code is slightly faster (3.74sec vs 4.12sec)

I think I might choose Mitsuru's code, as his code is smaller in terms of both
source and binary, and the performance difference is not that big, but either
would be fine.

[Bug rtl-optimization/58383] ICE when RTL folds vector operations using constants after gne_int_mode changes

[jgreenhalgh at gcc dot gnu.org]

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

jgreenhalgh at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jgreenhalgh at gcc dot gnu.org

--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30788
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30788&action=edit
Proposed fix

A patch along these lines works for me, covering the case where gen_int_mode is
called to generate a vector integer.

[Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless

[martin at netbsd dot org]

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

--- Comment #2 from Martin Husemann  ---
(In reply to Richard Biener from comment #1)
> If you have a system that randomizes then you have to re-define the hook.

Besides ASLR there are various things out of control of the compiler that do
result in varying mapping adresses (like malloc using mmap instead of brk), so
chances are low in any modern system.

I'm not opposed to create a hook for NetBSD, but I have a hard time seeing a
possible sensible implementation. Look at the #ifdef cascade in
config/host-openbsd.c for a disgusting example of code that should not be in a
compiler (IMHO).

How hard is making the externalized format address neutral?

[Bug rtl-optimization/58383] New: ICE when RTL folds vector operations using constants after gne_int_mode changes

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 58383
   Summary: ICE when RTL folds vector operations using constants
after gne_int_mode changes
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org

The patch set around [1/4] Using gen_int_mode instead of GEN_INT causes a
number of similair regressions when building for AArch64.

To pick one example, when building gcc.target/aarch64/vect-fcm-eq-d.c we can
get in to the situation where simplify_unary_expression_1 is trying to simplify
(V2DI: NOT (NEG X)) and will thus try to generate (V2DI: PLUS (X - 1)).

Now we will call plus_constant, and from there gen_int_mode (-1, v2di). From
here we call trunc_int_for_mode (-1, v2di) and trigger the assert:

   /* You want to truncate to a _what_?  */
   gcc_assert (SCALAR_INT_MODE_P (mode));

The failures eventually look like:

In file included from
../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm-eq-d.c:9:0:
../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm.x: In function 'foo':
../src/gcc/gcc/testsuite/gcc.target/aarch64/vect-fcm.x:25:1: internal compiler
error: in trunc_int_for_mode, at explow.c:55
 }
 ^
0x6abc8e trunc_int_for_mode(long, machine_mode)
/work/gcc-dev/src/gcc/gcc/explow.c:55
0x69bb28 gen_int_mode(long, machine_mode)
/work/gcc-dev/src/gcc/gcc/emit-rtl.c:420
0x6abcf2 plus_constant
/work/gcc-dev/src/gcc/gcc/explow.c:189
0x6abcf2 plus_constant
/work/gcc-dev/src/gcc/gcc/explow.c:79
0x8f107f simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/work/gcc-dev/src/gcc/gcc/simplify-rtx.c:369
0xc55e09 propagate_rtx_1
/work/gcc-dev/src/gcc/gcc/fwprop.c:490
0xc55e6f propagate_rtx_1
/work/gcc-dev/src/gcc/gcc/fwprop.c:497
0xc55e86 propagate_rtx_1
/work/gcc-dev/src/gcc/gcc/fwprop.c:498
0xc56409 propagate_rtx
/work/gcc-dev/src/gcc/gcc/fwprop.c:675
0xc57dff forward_propagate_and_simplify
/work/gcc-dev/src/gcc/gcc/fwprop.c:1337
0xc57dff forward_propagate_into
/work/gcc-dev/src/gcc/gcc/fwprop.c:1394
0xc58593 forward_propagate_into
/work/gcc-dev/src/gcc/gcc/fwprop.c:1359
0xc58593 fwprop
/work/gcc-dev/src/gcc/gcc/fwprop.c:1479
0xc58593 execute
/work/gcc-dev/src/gcc/gcc/fwprop.c:1515
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/58369] [4.8/4.9 regression] ICE in subreg_get_info when compiling boost for m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  ---
Created attachment 30787
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30787&action=edit
hand-reduced test case

This is as small as I can get it without losing the ICE.

[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Thanks Markus -- I was going to look at this once I figure out this IA64
mis-compilation issue.  One less thing to worry about now ;-)

[Bug tree-optimization/58373] [4.9 Regression] g++: internal compiler error: Segmentation fault (program cc1plus)

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
dup of PR58373, fixed by rev202441 .

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

[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot de

--- Comment #6 from Markus Trippelsdorf  ---
*** Bug 58373 has been marked as a duplicate of this bug. ***

[Bug c++/58380] [4.9 Regression] ice in fold_comparison

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Seems to have started with r202296.  I'll try to reduce it.

[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #18 from Paolo Carlini  ---
Chris, I'm going to slightly tweak / test again locally / post to the mailing
list your patch in order to apply it. Please have a look to Comment #15, in the
meanwhile, thanks!

[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug tree-optimization/58343] [4.9 Regression] ICE in dfs_enumerate_from, at cfganal.c:1036

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Tue Sep 10 12:29:58 2013
New Revision: 202441

URL: http://gcc.gnu.org/viewcvs?rev=202441&root=gcc&view=rev
Log:
PR tree-optimization/58343
* tree-ssa-threadupdate.c (thread_block): Identify and disable
jump threading requests through loop headers buried in the middle
of a jump threading path.

* tree-ssa-threadedge.c (thread_around_empty_blocks): Fix thinko
in return value/type.

* gcc.c-torture/compile/pr58343.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr58343.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c
trunk/gcc/tree-ssa-threadupdate.c

[Bug middle-end/58382] New: [4.9 Regression] unwind.inc:136:1: ICE: in trunc_int_for_mode, at explow.c:55

[danglin at gcc dot gnu.org]

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

Bug ID: 58382
   Summary: [4.9 Regression] unwind.inc:136:1: ICE: in
trunc_int_for_mode, at explow.c:55
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
 Build: hppa64-hp-hpux11.11

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

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu64/gcc/g
cc-4.9/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.9/hppa64-hp-hpux11.11/lib
/ -isystem /opt/gnu64/gcc/gcc-4.9/hppa64-hp-hpux11.11/include -isystem
/opt/gnu6
4/gcc/gcc-4.9/hppa64-hp-hpux11.11/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing
-prototypes -Wold-style-definition  -isystem ./include  
-frandom-seed=fixed-see
d -Dpa64=1 -DELF=1 -mlong-calls  -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-pr
otector   -frandom-seed=fixed-seed -Dpa64=1 -DELF=1 -mlong-calls  -I. -I.
-I../.
././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../g
cc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2.o 
-MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
../../../gcc/libgcc/
unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc/libgcc/unwind-dw2.c:1698:0:
../../../gcc/libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../gcc/libgcc/unwind.inc:136:1: internal compiler error: in
trunc_int_for_mode, at explow.c:55
 }
 ^

 /test/gnu/gcc/objdir/./gcc/cc1 -fpreprocessed unwind-dw2.i -quiet -dumpbase
unw
ind-dw2.c -mlong-calls -auxbase-strip unwind-dw2.o -g -g -g -O2 -O2 -O2 -Wextra 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-p
rototypes -Wold-style-definition -version -frandom-seed=fixed-seed
-fbuilding-li
bgcc -fno-stack-protector -frandom-seed=fixed-seed -fexceptions
-fvisibility=hidden -o unwind-dw2.s
GNU C (GCC) version 4.9.0 20130909 (experimental) [trunk revision 202391]
(hppa64-hp-hpux11.11)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2,
MPC version 1.0
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20130909 (experimental) [trunk revision 202391]
(hppa64-hp-hpux11.11)
compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.2,
MPC version 1.0
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 1887fdfaba237bed4d949cbaeffd7a9b
In file included from ../../../gcc/libgcc/unwind-dw2.c:1698:0:
../../../gcc/libgcc/unwind.inc: In function '_Unwind_RaiseException':
../../../gcc/libgcc/unwind.inc:136:1: internal compiler error: in
trunc_int_for_mode, at explow.c:55
 }
 ^

Introduced in r202391:

2013-09-09  Richard Sandiford  

* alias.c (addr_side_effect_eval): Use gen_int_mode with the mode
of the associated gen_rtx_* call.
* caller-save.c (init_caller_save): Likewise.
* combine.c (find_split_point, make_extraction): Likewise.
(make_compound_operation): Likewise.
* dwarf2out.c (mem_loc_descriptor): Likewise.
* explow.c (plus_constant, probe_stack_range): Likewise.
* expmed.c (expand_mult_const): Likewise.
* expr.c (emit_single_push_insn_1, do_tablejump): Likewise.
* reload1.c (init_reload): Likewise.
* valtrack.c (cleanup_auto_inc_dec): Likewise.
* var-tracking.c (adjust_mems): Likewise.
* modulo-sched.c (sms_schedule): Likewise, but use gen_rtx_GT
rather than gen_rtx_fmt_ee.

[Bug c++/58377] spurious "may be unused" warning with -Og

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.0
Version|unknown |4.8.1
   Last reconfirmed||2013-09-10
  Component|middle-end  |c++
 CC||xinliangli at gmail dot com
 Ever confirmed|0   |1
Summary|spurious "may be used   |spurious "may be unused"
   |uninitialized" warning with |warning with -Og
   |-Og |

--- Comment #5 from Richard Biener  ---
Confirmed with the C++ FE, works with the C FE.  Does not warn on trunk (for
no good reason I think, the reason seems to be presence of loop structure
and thus some extra BBs).

Difference:

trunk:

[WORKLIST]: add to initial list: out_2 = PHI 
[CHECK]: examining phi: out_2 = PHI 

Use in stmt out_1 = PHI 
is guarded by :
if (pop_first_bucket.2_10 != 0)

[CHECK] Found def edge 0 in out_1 = PHI 

[CHECK] Found def edge 1 in out_1 = PHI 
Operand defs of phi out_2 = PHI 
is guarded by :
if (out_12 != 0)
[CHECK]: Found unguarded use: out_1 = PHI 
[WORKLIST]: Update worklist with phi: out_1 = PHI 
[CHECK]: examining phi: out_1 = PHI 

Use in stmt out_2 = PHI 
is guarded by :
 (.NOT.) if (iftmp.1_3 != 0)

[CHECK] Found def edge 0 in out_1 = PHI 

[CHECK] Found def edge 1 in out_1 = PHI 
Operand defs of phi out_1 = PHI 
is guarded by :
if (pop_first_bucket.2_10 != 0)
(.AND.)
if (out_12 != 0)
(.OR.)
if (pop_first_bucket.2_10 != 0)
(.AND.)
 (.NOT.) if (out_12 != 0)

Normalized to
Operand defs of phi out_1 = PHI 
is guarded by :
if (pop_first_bucket.2_10 != 0)
...

vs. 4.8 branch:

[WORKLIST]: add to initial list: out_2 = PHI 
[CHECK]: examining phi: out_2 = PHI 

Use in stmt out_1 = PHI 
is guarded by :
if (pop_first_bucket.2_10 != 0)

[CHECK] Found def edge 0 in out_1 = PHI 

[CHECK] Found def edge 1 in out_1 = PHI 
Operand defs of phi out_2 = PHI 
is guarded by :
if (out_12 != 0)
[CHECK]: Found unguarded use: out_1 = PHI 
[WORKLIST]: Update worklist with phi: out_1 = PHI 
[CHECK]: examining phi: out_1 = PHI 
[CHECK]: Found unguarded use: out_2 = PHI 
[CHECK]: Found unguarded use: _4 = PHI 
[WORKLIST]: Update worklist with phi: _4 = PHI 
[CHECK]: examining phi: _4 = PHI 
[CHECK]: Found unguarded use: return _4;

The IL difference is that we have

  :
  # out_1 = PHI 
  # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
  if (iftmp.1_3 != 0)
goto ;
  else
goto ;

  :
  out_13 = out_1;
  goto ;
...
  :
  # _4 = PHI 
  return _4;

which doesn't warn vs.

  :
  # out_1 = PHI 
  # iftmp.1_3 = PHI <1(4), 0(5), 0(3)>
  if (iftmp.1_3 != 0)
goto ;
  else
goto ;
...
  :
  # _4 = PHI 
  return _4;

which does.  The issue seems to be that the analysis doesn't consider
the PHI uses in

  if (iftmp.1_3 != 0)
goto ;
  else
goto ;

  :
  # out_2 = PHI 

guarded by anything (the out_1 use is guarded by iftmp.1_3 == 0).

David - the code does

  if (gimple_code (use_stmt) == GIMPLE_PHI)
use_bb = gimple_phi_arg_edge (use_stmt,
  PHI_ARG_INDEX_FROM_USE (use_p))->src;
  else
use_bb = gimple_bb (use_stmt);

  if (is_use_properly_guarded (use_stmt,
   use_bb,
...

so it chooses the source block (as approximation?).

Splitting all edges results in us no longer warning here and:

Use in stmt out_2 = PHI 
is guarded by :
 (.NOT.) if (iftmp.1_3 != 0)

Can you see to fix that please?  Thanks.

[Bug rtl-optimization/58365] [4.7 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] likely
   |likely wrong code bug   |wrong code bug

--- Comment #11 from Jakub Jelinek  ---
Fixed for 4.8.2+ so far.

[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 10 11:48:30 2013
New Revision: 202435

URL: http://gcc.gnu.org/viewcvs?rev=202435&root=gcc&view=rev
Log:
PR rtl-optimization/58365
* cfgcleanup.c (merge_memattrs): Also clear MEM_READONLY_P
resp. MEM_NOTRAP_P if they differ, or set MEM_VOLATILE_P if
it differs.

* gcc.c-torture/execute/pr58365.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58365.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/cfgcleanup.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/58365] [4.7/4.8/4.9 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 10 11:47:19 2013
New Revision: 202434

URL: http://gcc.gnu.org/viewcvs?rev=202434&root=gcc&view=rev
Log:
PR rtl-optimization/58365
* cfgcleanup.c (merge_memattrs): Also clear MEM_READONLY_P
resp. MEM_NOTRAP_P if they differ, or set MEM_VOLATILE_P if
it differs.

* gcc.c-torture/execute/pr58365.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr58365.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/58377] spurious "may be unused" warning with -Og

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
This one works for me but only with 4.8.x, not with mainline, and -Og didn't
exist in 4.7.x, thus it would not qualify as a regression, I'm afraid.

[Bug preprocessor/58379] default mmap based implementation (mmap_gt_pch_get_address/mmap_gt_pch_use_address) is useless

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Well, it doesn't _rely_ on it - it basically makes systems where that is the
case work out of the box (every system pre address-space-randomization area).

If you have a system that randomizes then you have to re-define the hook.

[Bug target/55491] Segmentation fault

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #8 from Kai Tietz  ---
hmm, can't reproduce this for i686-w64-mingw32 for gcc 4.7, or gcc 4.8 series. 
I was using here cygwin-cross, and native compiler.  So I assume it might be
related to the release of this compiler.

So I close this bug as not reproduce-able for me.

[Bug target/57495] Compiling mingw targets with -mcmodel=large causes assert

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Kai Tietz  ---
Code-models large and medium will be supported beginning with gcc 4.9 version. 
The feature is already present there.  A back-merge of this feature isn't
planned.
So I close this bug as won't fix.

[Bug target/55543] diamond shaped inheritance involving strings leads to crashing executables (MinGW, 32 bit)

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #6 from Kai Tietz  ---
I tested 4.8 and here this issue seems to be solved.
Does the issue still exists for more recent 4.7 version?

[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()

[olivier.grisel at ensta dot org]

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

--- Comment #6 from Olivier Grisel  ---
Alright thanks again. For reference I just discovered that the issue has
recently been fixed in Python 3.4 by adding a new `forkserver` option to
multiprocessing.

  http://bugs.python.org/issue8713

[Bug boehm-gc/52217] [boehm-gc] revision 184100 causes segmentation fault in mingw32

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #2 from Kai Tietz  ---
Wait for OP check.  Still assume it is an issue of static vs. shared.
Set bug as waiting.

[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Having a pthread_atfork child hook that would do freeing of memory, or
pthread_mutex_init etc. would only make invalid any OpenMP program using fork,
even those that use it correctly.

[Bug preprocessor/58381] New: crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

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

Bug ID: 58381
   Summary: crash in diagnostic_report_current_module when a
fatal_error happens during PCH processing on
NetBSD/spa64rc
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin at netbsd dot org

In toplev_main variable line_table is initialized and becomes 0x417dc000,
however, when invoking diagnostic_report_current_module with this backtrace it
is different:

#0  diagnostic_report_current_module (context=0x17b28d0, where=19) at
../../gcc-4.8.1/gcc/diagnostic.c:468
#1  0x003a6368 in cp_diagnostic_starter (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/cp/error.c:2907
#2  0x012d5e44 in diagnostic_report_diagnostic (context=0x17b28d0,
diagnostic=0xa3e8)
at ../../gcc-4.8.1/gcc/diagnostic.c:756
#3  0x012d6b90 in fatal_error (gmsgid=0x13e1230 "had to relocate PCH")
at ../../gcc-4.8.1/gcc/diagnostic.c:1076
#4  0x008e83dc in gt_pch_restore (f=0x424a0738) at
../../gcc-4.8.1/gcc/ggc-common.c:704
#5  0x005c575c in c_common_read_pch (pfile=0x42765800, name=0x4275dbc0
"conftest.h.gch", fd=4, 
orig_name=0x4275dbb0 "conftest.h") at
../../gcc-4.8.1/gcc/c-family/c-pch.c:370
#6  0x012f05f8 in should_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:787
#7  0x012f097c in _cpp_stack_file (pfile=0x42765800, file=0x42788130,
import=false)
at ../../gcc-4.8.1/libcpp/files.c:872
#8  0x012f0fe4 in _cpp_stack_include (pfile=0x42765800,
fname=0x4275db90 "conftest.h", angle_brackets=0, 
type=IT_INCLUDE) at ../../gcc-4.8.1/libcpp/files.c:1008
#9  0x012e1fc4 in do_include_common (pfile=0x42765800, type=IT_INCLUDE)
at ../../gcc-4.8.1/libcpp/directives.c:793
#10 0x012e2024 in do_include (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/directives.c:804
#11 0x012e13dc in _cpp_handle_directive (pfile=0x42765800, indented=0)
at ../../gcc-4.8.1/libcpp/directives.c:492
#12 0x012f9dc4 in _cpp_lex_token (pfile=0x42765800) at
../../gcc-4.8.1/libcpp/lex.c:1990
#13 0x01306cec in cpp_get_token_1 (pfile=0x42765800,
location=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2355
#14 0x01307330 in cpp_get_token_with_location (pfile=0x42765800,
loc=0xb0b8)
at ../../gcc-4.8.1/libcpp/macro.c:2537
#15 0x005b9484 in c_lex_with_flags (value=0xb0c0,
loc=0xb0b8, 
cpp_flags=0xb0b2 "", lex_flags=0) at
../../gcc-4.8.1/gcc/c-family/c-lex.c:300
#16 0x003b225c in cp_lexer_get_preprocessor_token (lexer=0x0,
token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:715
#17 0x003f64e8 in cp_parser_initial_pragma
(first_token=0xb0b0)
at ../../gcc-4.8.1/gcc/cp/parser.c:28139
#18 0x003b1d98 in cp_lexer_new_main () at
../../gcc-4.8.1/gcc/cp/parser.c:585
#19 0x003b6604 in cp_parser_new () at
../../gcc-4.8.1/gcc/cp/parser.c:3253
#20 0x003f6b78 in c_parse_file () at
../../gcc-4.8.1/gcc/cp/parser.c:28335
#21 0x005c30a0 in c_common_parse_file () at
../../gcc-4.8.1/gcc/c-family/c-opts.c:1046
#22 0x00c5f230 in compile_file () at ../../gcc-4.8.1/gcc/toplev.c:543
#23 0x00c62540 in do_compile () at ../../gcc-4.8.1/gcc/toplev.c:1864
#24 0x00c62788 in toplev_main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/toplev.c:1940
#25 0x012bc2c0 in main (argc=24, argv=0xb718) at
../../gcc-4.8.1/gcc/main.c:36

(gdb) print line_table
$6 = (line_maps *) 0x42e7

(gdb) print *line_table
$16 = {info_ordinary = {maps = 0x11400, allocated = 1, used = 1115871712,
cache = 0}, info_macro = {
maps = 0x10500, allocated = 0, used = 1117049688, cache = 0}, depth =
1, trace_includes = 55, 
  highest_location = 3, highest_line = 1117048808, max_column_hint = 0,
reallocator = 0x11500, 
  round_alloc_size = 0, location_adhoc_data_map = {htab = 0x0, curr_loc = 1,
allocated = 335544320, data = 0x24282d9e0}}

The "used" fields look strange. Later in the same call it crashes:

Program received signal SIGSEGV, Segmentation fault.
0x012fff88 in linemap_location_from_macro_expansion_p (set=0x42e7,
location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
948   linemap_assert (location <= MAX_SOURCE_LOCATION
(gdb) bt
#0  0x012fff88 in linemap_location_from_macro_expansion_p
(set=0x42e7, location=19)
at ../../gcc-4.8.1/libcpp/line-map.c:948
#1  0x012ff31c in linemap_lookup (set=0x42e7, line=19) at
../../gcc-4.8.1/libcpp/line-map.c:642
#2  0x0130065c in linemap_macro_loc_to_def_point (set=0x42e7,
location=19, original_map=0xfff

[Bug libgomp/58378] Protect libgomp against child process hanging after a Unix fork()

[olivier.grisel at ensta dot org]

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

--- Comment #4 from Olivier Grisel  ---
Thanks for the explanation. Would you consider a solution that would preserve
the state of the parent process and would just reset the thread pool data on
the child?

Otherwise we will have to consider that the way fork() is used in Python's
multiprocessing module is really an abuse and that there is no way to safely
use both openmp-libraries and Python multiprocessing in the same program
safely.

[Bug target/47596] internal compiler error: in print_reg, at config/i386/i386.c:10894

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #9 from Kai Tietz  ---
Gcc 4.4 isn't anymore maintained by gcc team.  As it works for newer
gcc-versions, I close this bug as won't fix.

[Bug target/53485] gcc -O -mavx generates illegal instruction on win64

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #2 from Kai Tietz  ---
yes, it is an alignment issue.  Try to set explicit alignment for this global.
That it doesn't fail for 32-bit is just by chance.
This seems to me an OP issue.

[Bug c++/58377] spurious "may be unused" warning with -Og

[rbd at debian dot org]

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

--- Comment #3 from Roland Dreier  ---
Even simpler test case for me:

$ cat x.cpp 
// gcc -Og -Wall -Werror -c x.cpp

int pop ();
int pop_first_bucket;

int my_pop ()
{
int out;

while (pop_first_bucket)
if (pop_first_bucket && (out = pop()))
return out;

return 0;
}

$ for o in Og O0 O1 O2 O3 Ofast; do echo === $o ===; gcc -$o -Wall -Werror -c
x.cpp; done
=== Og ===
x.cpp: In function ‘int my_pop()’:
x.cpp:8:9: error: ‘out’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 int out;
 ^
cc1plus: all warnings being treated as errors
=== O0 ===
=== O1 ===
=== O2 ===
=== O3 ===
=== Ofast ===

Does not error when built as x.c:

$ cp x.cpp x.c; for o in Og O0 O1 O2 O3 Ofast; do echo === $o ===; gcc -$o
-Wall -Werror -c x.c; done
=== Og ===
=== O0 ===
=== O1 ===
=== O2 ===
=== O3 ===
=== Ofast ===

[Bug c++/58380] ice in fold_comparison

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-10
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.8.1
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1
  Known to fail||4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed, needs -O2.  Bisecting...

[Bug lto/49922] I try to build libgmp using PGO and lto, but the test will result in "internal compiler error"

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #4 from Kai Tietz  ---
Due issue is solved for gcc 4.7 (and upward), and gcc 4.6 isn't under
maintenance by gcc team any more, I close this bug as won't fix.

[Bug target/52061] compiler internal error in extract_insn

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Kai Tietz  ---
Due this issue is in 4.6 tree, which isn't any longer under maintenance by
gcc's team, I close this bug as won't fix.

[Bug rtl-optimization/38614] ICE at simplify-rtx.c:4956

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktietz at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #4 from Kai Tietz  ---
If this issue occurs with more recent gcc-version, please open an new bug.  gcc
4.4 is no longer maintained (same as gcc 4.5).
So closing this bug

[Bug c++/58377] spurious "may be unused" warning with -Og

[rbd at debian dot org]

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

--- Comment #2 from Roland Dreier  ---
arg, I really apologize.  I copied and pasted from the wrong window and ended
up with a test case that does NOT reproduce the issue, even on my system.  Here
is one I triple checked does fail (and everything is copied from one window, so
the code is definitely what I built):

$ cat x.cpp
// gcc -Og -Wall -Werror -c x.cpp

int * pop ();

struct A
{
void * tasks[0];
};

int pop_first_bucket;

int * my_pop (struct A * t)
{
int * out;

do {
if (t->tasks[0] && (out = pop()))
return out;
} while (pop_first_bucket);
return 0;
}

$ gcc -v -Og -Wall -Werror -c x.cpp

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --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 --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-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE x.cpp -mtune=generic -march=x86-64 -Wall -Werror
-Og -fstack-protector -Wformat -Wformat-security
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.8
 /usr/include/x86_64-linux-gnu/c++/4.8
 /usr/include/c++/4.8/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-E' '-mtune=generic'
'-march=x86-64'
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu1' --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 --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-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-Og' '-Wall' '-Werror' '-c' '-o'
'/home/roland/.ccache/0/5/a073b86e9bd44947a6de1615bfe6ad-3402.o.tmp.roland-t410s.19701'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -fpreprocessed
/home/roland/.c