[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
Thanks.

The simplify pattern probably needs an extra test that the types of @0 and @1
are compatible, so we don't try to produce unord(float,double). In that case,
it isn't as obvious that converting the first argument to double then using
unord would be better than 2 isnan, but it may still be worth it.

Now we have to wait until the branch that handles those patterns gets merged.

[Bug target/50302] inefficient float->double conversion in AVX with -mtune=generic

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #6 from Andi Kleen  ---
Seems to be fixed now in 

gcc version 5.0.0 20140926 (experimental) (GCC) 


The double conversion is only generated for -mtune=amdfam10, but not for
mtune=generic

[Bug other/63387] New: Optimize pairs of isnan() calls into a single isunordered()

[jzwinck at gmail dot com]

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

Bug ID: 63387
   Summary: Optimize pairs of isnan() calls into a single
isunordered()
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jzwinck at gmail dot com

Whenever a program does (isnan(x) || isnan(y)), GCC 4.7 and 4.9 in the best
case emits code like this on x86-64:

  ucomisd %xmm0, %xmm0 ; set parity flag if x is NAN
  setp%dl  ; copy parity flag to %edx
  ucomisd %xmm1, %xmm1 ; set parity flag if y is NAN
  setp%al  ; copy parity flag to %eax
  orl %edx, %eax   ; OR one byte of each result into a full-width register

This is suboptimal because ucomisd already has the effect of checking if
*either* of its operands is NAN, so this code is equivalent:

  xorl%eax, %eax
  ucomisd %xmm1, %xmm0
  setp%al

And indeed that's what you get if you help GCC along by calling isunordered(x,
y) instead.  But no one thinks to do that, because isnan() is much more widely
used and it isn't an obvious thing at the source level to change pairs of
isnan() calls to isunordered().  So the optimizer should do it.

Someone already suggested that in GCC 5 it might be as simple as this (which
seems correct and safe to me):

  (simplify (or (unordered @0 @0) (unordered @1 @1)) (unordered @0 @1))

A discussion of this issue is here:
http://stackoverflow.com/questions/26053934/is-it-feasible-to-add-this-optimization-to-gcc

[Bug middle-end/35545] tracer pass is run too late

[hubicka at ucw dot cz]

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

--- Comment #18 from Jan Hubicka  ---
> WE can try some internal benchmarks with this change too.

That would be very welcome.  Tracer used to be quite useful pass in old days,
doing 1.6% on -O3+FDO SPECint (for 1.4% code size cost) that put it very close
to the inliner (1.8%) that however needed 12.9% of code size.

http://www.ucw.cz/~hubicka/papers/amd64/node4.html (see aggressive optimization
table)

I do not think it was ever resonably returned for GIMPLE. Martin, do you have
any current scores? Part of benefits came from lack of global optimizers, but
I think tail duplication has a potential in modern compiler, too.

Perhaps we should try to do that and given that we now have tail merging pass,
consider getting it useful without FDO, too.

Honza

[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-27
 CC||jason at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
The sections for COMDAT functions are used to drive code unification.  I
wonder, do we want to support something like this (and expect that user knows
what he is doing and he won't, for example, drop multiple COMDATs into one
section) or just reject the attribute?

[Bug middle-end/35545] tracer pass is run too late

[xinliangli at gmail dot com]

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

--- Comment #17 from davidxl  ---
(In reply to Jan Hubicka from comment #16)
> I have moved tracer before the late cleanups that seems to be rather obbious
> thing to do. This lets us to optimize the testcase (with -O2):
> int main() ()
> {
>   struct A * ap;
>   int i;
>   int _6;
> 
>   :
> 
>   :
>   # i_29 = PHI 
>   _6 = i_29 % 7;
>   if (_6 == 0)
> goto ;
>   else
> goto ;
> 
>   :
>   ap_8 = operator new (16);
>   ap_8->i = 0;
>   ap_8->_vptr.A = &MEM[(void *)&_ZTV1A + 16B];
>   goto ;
> 
>   :
>   ap_13 = operator new (16);
>   MEM[(struct B *)ap_13].D.2244.i = 0;
>   MEM[(struct B *)ap_13].b = 0;
>   MEM[(struct B *)ap_13].D.2244._vptr.A = &MEM[(void *)&_ZTV1B + 16B];
> 
>   :
>   # ap_4 = PHI 
>   operator delete (ap_4);
>   i_22 = i_29 + 1;
>   if (i_22 != 1)
> goto ;
>   else
> goto ;
> 
>   :
>   return 0;
> 
> }
> 
> Martin, I do not have SPEC setup, do you think you can benchmark the
> attached patch with SPEC and profile feedback and also non-FDO -O3 -ftracer
> compared to -O3, please?
> It would be nice to know code size impact, too.
> Index: passes.def
> ===
> --- passes.def  (revision 215651)
> +++ passes.def  (working copy)
> @@ -155,6 +155,7 @@ along with GCC; see the file COPYING3.
>NEXT_PASS (pass_dce);
>NEXT_PASS (pass_call_cdce);
>NEXT_PASS (pass_cselim);
> +  NEXT_PASS (pass_tracer);
>NEXT_PASS (pass_copy_prop);
>NEXT_PASS (pass_tree_ifcombine);
>NEXT_PASS (pass_phiopt);
> @@ -252,7 +253,6 @@ along with GCC; see the file COPYING3.
>NEXT_PASS (pass_cse_reciprocals);
>NEXT_PASS (pass_reassoc);
>NEXT_PASS (pass_strength_reduction);
> -  NEXT_PASS (pass_tracer);
>NEXT_PASS (pass_dominator);
>NEXT_PASS (pass_strlen);
>NEXT_PASS (pass_vrp);
> 
> Doing it at same approximately the same place as loop header copying seems
> to make most sense to me.  It benefits from early cleanups and DCE definitly
> and it should enable more fun with the later scalar passes that are almost
> all rerun then.


WE can try some internal benchmarks with this change too.

David

[Bug ipa/60665] gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer' is used uninitialized whenever '?:' condition is false

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Sat Sep 27 00:21:33 2014
New Revision: 215656

URL: https://gcc.gnu.org/viewcvs?rev=215656&root=gcc&view=rev
Log:

PR ipa/60665
* ipa-devirt.c (possible_polymorphic_call_targets): Silence clang warning.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug ipa/60665] gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer' is used uninitialized whenever '?:' condition is false

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

[Bug ipa/62121] [4.9 Regression] ICE: Segmentation fault in ipa-devirt.c:997

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Sat Sep 27 00:19:06 2014
New Revision: 215655

URL: https://gcc.gnu.org/viewcvs?rev=215655&root=gcc&view=rev
Log:

PR ipa/62121
* ipa-polymorphic-call.c
(ipa_polymorphic_call_context::restrict_to_inner_class):
fix pasto in checking array size.

* g++.dg/torture/pr62121.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr62121.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Yep, the problem with dealing arbitrarily long sequences is something we need
to solve.  Also memcpy/memset ought to use vector moves by itself in these
cases..

[Bug middle-end/35545] tracer pass is run too late

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mliska at suse dot cz
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #16 from Jan Hubicka  ---
I have moved tracer before the late cleanups that seems to be rather obbious
thing to do. This lets us to optimize the testcase (with -O2):
int main() ()
{
  struct A * ap;
  int i;
  int _6;

  :

  :
  # i_29 = PHI 
  _6 = i_29 % 7;
  if (_6 == 0)
goto ;
  else
goto ;

  :
  ap_8 = operator new (16);
  ap_8->i = 0;
  ap_8->_vptr.A = &MEM[(void *)&_ZTV1A + 16B];
  goto ;

  :
  ap_13 = operator new (16);
  MEM[(struct B *)ap_13].D.2244.i = 0;
  MEM[(struct B *)ap_13].b = 0;
  MEM[(struct B *)ap_13].D.2244._vptr.A = &MEM[(void *)&_ZTV1B + 16B];

  :
  # ap_4 = PHI 
  operator delete (ap_4);
  i_22 = i_29 + 1;
  if (i_22 != 1)
goto ;
  else
goto ;

  :
  return 0;

}

Martin, I do not have SPEC setup, do you think you can benchmark the attached
patch with SPEC and profile feedback and also non-FDO -O3 -ftracer compared to
-O3, please?
It would be nice to know code size impact, too.
Index: passes.def
===
--- passes.def  (revision 215651)
+++ passes.def  (working copy)
@@ -155,6 +155,7 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_dce);
   NEXT_PASS (pass_call_cdce);
   NEXT_PASS (pass_cselim);
+  NEXT_PASS (pass_tracer);
   NEXT_PASS (pass_copy_prop);
   NEXT_PASS (pass_tree_ifcombine);
   NEXT_PASS (pass_phiopt);
@@ -252,7 +253,6 @@ along with GCC; see the file COPYING3.
   NEXT_PASS (pass_cse_reciprocals);
   NEXT_PASS (pass_reassoc);
   NEXT_PASS (pass_strength_reduction);
-  NEXT_PASS (pass_tracer);
   NEXT_PASS (pass_dominator);
   NEXT_PASS (pass_strlen);
   NEXT_PASS (pass_vrp);

Doing it at same approximately the same place as loop header copying seems to
make most sense to me.  It benefits from early cleanups and DCE definitly and
it should enable more fun with the later scalar passes that are almost all
rerun then.

[Bug middle-end/35545] tracer pass is run too late

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  ---
Author: hubicka
Date: Sat Sep 27 00:03:23 2014
New Revision: 215651

URL: https://gcc.gnu.org/viewcvs?rev=215651&root=gcc&view=rev
Log:

PR middle-end/35545
* passes.def (pass_tracer): Move before last dominator pass.
* g++.dg/tree-prof/pr35545.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-prof/pr35545.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 26-Sep-14, at 3:46 PM, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
>
> --- Comment #4 from Jeffrey A. Law  ---
> Have you tried with the current 4.9.2 bits?  I get the following  
> with a 32bit
> host cross to hppa64-unknown-linux-gnu:


The wrong code is actually generated by the native 32-bit hppa-unknown- 
linux-gnu compiler.

This results in the hppa64-unknown-linux-gnu cross compiler being  
miscompiled and incorrect
ldil instructions in its output.  The hppa64-unknown-linux-gnu cross  
compiler correctly compiles
the test case.

In my regression search, I got wrong code with r215536 from the 4.9  
branch.  Then,
I switched to checking trunk.  I just checked r215649 from 4.9 branch  
and still get the following
incorrect code for the testcase:

 extru %r26,31,11,%r28
 comiclr,<> 0,%r28,%r28
 ldi 1,%r28
 bv,n %r0(%r2)

Note that this is 32-bit code.

Dave
--
John David Anglindave.ang...@bell.net

[Bug c++/63386] Release version of CB wont compile Bullet (-o2)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-09-26
 Ever confirmed|0   |1
   Severity|blocker |normal

--- Comment #3 from Jonathan Wakely  ---
This bug database has nothing to do with CodeBlocks (I had absoutely no idea
what "CB" was supposed to mean after reading the summary).

Please specify the exact compiler version, not just "latests MinGW & TDM"

See https://gcc.gnu.org/bugs/

[Bug middle-end/36757] __builtin_signbit should be type-generic

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #2 from Francois-Xavier Coudert  ---
That would be interesting indeed.

[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix

[gregory.0xf0 at gmail dot com]

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

--- Comment #32 from gregory.0xf0 at gmail dot com ---
(In reply to cbaylis from comment #31)
> I intend to backport to 4.8 and 4.9, once this change has had a week of
> testing on trunk.

Hi Charles, just a gentle reminder that you were planning this.

[Bug target/61397] [5 regression] FAIL: gcc.target/powerpc/p8vector-ldst.c scan-assembler lxsdx

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #1 from Maciej W. Rozycki  ---
Also in 4.9.1, regressed from 4.9.0.

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
I agree with the analysis in bug 28865 that .size should reflect the 
presence of the initializer.  That bug was marked FIXED, but I'm not clear 
if the issue described in its summary - "Structures with a flexible arrray 
member have wrong .size" - did in fact get fixed for some configurations 
(but not all? or became unfixed?) or only some related issue that was 
sufficient for the testcases added to pass.

I think this code should be considered valid GNU C.

[Bug c++/63386] Release version of CB wont compile Bullet (-o2)

[root at borealis dot su]

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

--- Comment #2 from TechoMan  ---
-O2 causes that , -O1 doesnt.

[Bug c++/63386] Release version of CB wont compile Bullet (-o2)

[root at borealis dot su]

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

--- Comment #1 from TechoMan  ---
Using latests MinGW & TDM.

[Bug c++/63386] New: Release version of CB wont compile Bullet (-o2)

[root at borealis dot su]

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

Bug ID: 63386
   Summary: Release version of CB wont compile Bullet (-o2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: root at borealis dot su

mingw32-g++.exe -Wall -fexceptions -O2 -I..\Bullet\src -c
C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp
-o
obj\Release\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.o
C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp:
In member function 'virtual void
btConnectivityProcessor::processTriangle(btVector3*, int, int)':
C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp:310:2:
internal compiler error: Segmentation fault
  }
  ^
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
C:\CProj\Bullet\src\BulletCollision\CollisionDispatch\btInternalEdgeUtility.cpp:310:2:
internal compiler error: Aborted
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
mingw32-g++.exe: internal compiler error: Aborted (program cc1plus)
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Report for v2.x , same for v3.x . Using codeblocks & MinGW. Same error with
TDM. Using CodeBlocks to compile , release version. In debug version that
doesnt happen. That does happen with -O2 i think ( didnt try , but that is all
diffrence betwen my Debug & Release , beside Wall)

Sources can be found at bullet off. site

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Related to PR57180?

[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #2)
> This got fixed with r197211.  Whether it is safely backportable will leave
> to Jason.

Looks safe, testing now.

[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
Have you tried with the current 4.9.2 bits?  I get the following with a 32bit
host cross to hppa64-unknown-linux-gnu:



   depdi 0,52,20,%r26
depdi,z 1,32,4,%r28
add,l %r26,%r28,%r28
depdi 0,32,1,%r28
or,*>= %r0,%r28,%r28
subi 0,%r28,%r28
ldo -1(%r28),%r28
bve (%r2)
extrd,u %r28,0,1,%r28


Which is identical to what I get on the trunk.

[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-26
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
This got fixed with r197211.  Whether it is safely backportable will leave to
Jason.

[Bug inline-asm/63282] [4.8/4.9/5 Regression] ICE in redirect_jump_1

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 33587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33587&action=edit
gcc5-pr63282-2.patch

Or we can just give up in redirect_jump_1 for asm gotos with > 1 label.
Or both.

I guess I'll try to bootstrap/regtest the first patch with some logging on when
is that new goto cancel hit to see how often does that trigger.

[Bug inline-asm/63282] [4.8/4.9/5 Regression] ICE in redirect_jump_1

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 33586
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33586&action=edit
gcc5-pr63282.patch

Untested fix.  Calling redirect_jump_1/indirect_jump_1 on something that isn't
a normal conditional jump, is, weird.

[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

  Known to work||4.9.0, 4.9.1, 4.9.2
  Known to fail||4.8.0, 4.8.1, 4.8.2, 4.8.3

--- Comment #1 from Matthias Kretz  ---
It is important that the variable is called 'closure'. If I change the name the
code compiles.

[Bug c++/63385] New: internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure

[kretz at kde dot org]

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

Bug ID: 63385
   Summary: internal compiler error: in pop_binding, at
cp/name-lookup.c for implicitly captured variable
called closure
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org

Testcase:

template  void f(F closure) { auto g = [&]() { return closure; }; }

Compile with 'g++ -std=c++11'. Output with gcc 4.8.3:
internal compiler error: in pop_binding, at cp/name-lookup.c:382
 template  void f(F closure) { auto g = [=]() { return closure; };
}
^
0x5fadd9 pop_binding(tree_node*, tree_node*)
../.././gcc/cp/name-lookup.c:382
0x52e92b poplevel(int, int, int)
../.././gcc/cp/decl.c:731
0x538cf8 finish_function(int)
../.././gcc/cp/decl.c:13845
0x58b167 cp_parser_lambda_body
../.././gcc/cp/parser.c:8766
0x58b167 cp_parser_lambda_expression
../.././gcc/cp/parser.c:8295
0x58b167 cp_parser_primary_expression
../.././gcc/cp/parser.c:4104
0x592e10 cp_parser_postfix_expression
../.././gcc/cp/parser.c:5667
0x5916fd cp_parser_unary_expression
../.././gcc/cp/parser.c:6732
0x59684f cp_parser_binary_expression
../.././gcc/cp/parser.c:7424
0x596cff cp_parser_assignment_expression
../.././gcc/cp/parser.c:7660
0x597134 cp_parser_assignment_expression
../.././gcc/cp/parser.c:7710
0x597134 cp_parser_constant_expression
../.././gcc/cp/parser.c:7920
0x5a5afc cp_parser_init_declarator
../.././gcc/cp/parser.c:16079
0x5a601e cp_parser_simple_declaration
../.././gcc/cp/parser.c:10670
0x5a1920 cp_parser_block_declaration
../.././gcc/cp/parser.c:10551
0x5a2940 cp_parser_declaration_statement
../.././gcc/cp/parser.c:10195
0x5a2fe7 cp_parser_statement
../.././gcc/cp/parser.c:8969
0x5a41de cp_parser_statement_seq_opt
../.././gcc/cp/parser.c:9241
0x5a42fe cp_parser_compound_statement
../.././gcc/cp/parser.c:9195
0x5a4448 cp_parser_function_body
../.././gcc/cp/parser.c:17816

4.9.x compiles the code fine.

[Bug target/63347] m68k misoptimisation with -fschedule-insns

[jifl-bugzilla at jifvik dot org]

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

Jonathan Larmour  changed:

   What|Removed |Added

  Known to fail||4.8.3

--- Comment #2 from Jonathan Larmour  ---
(In reply to Andreas Schwab from comment #1)
> GCC 4.7 is no longer maintained.  Please try to reproduce it with a newer
> version.

I can now confirm that it also reproduces equally with gcc 4.8.3. I haven't
tried 4.9 (it was enough of a job getting 4.8 built!).

[Bug target/50302] inefficient float->double conversion in AVX with -mtune=generic

[andi-gcc at firstfloor dot org]

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

--- Comment #5 from Andi Kleen  ---
Problem is still there on 

gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

[Bug target/45475] target attribute use in libcpp breaks LTO bootstrap

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #17 from Andi Kleen  ---
LTO bootstrap works, so I think we can close this now.

[Bug middle-end/60469] simple cilk plus program ICEs

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #16 from Andi Kleen  ---
Fixed since some time

[Bug middle-end/25957] -fstack-protector code on i386/x86_64 can be improved.

[andi-gcc at firstfloor dot org]

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

--- Comment #12 from Andi Kleen  ---
Problem is still there in 

gcc50 (GCC) 4.9.0 20130617 (experimental)


The stack protector edge should be cold and alignment disabled.

[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #4 from Andi Kleen  ---
I think this were broken profile feedback files.

I'll reopen if it happens again.

[Bug rtl-optimization/63384] New: ICE in moveup_expr_chached->sel_bb_head->bb_node with special options

[andi-gcc at firstfloor dot org]

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

Bug ID: 63384
   Summary: ICE in moveup_expr_chached->sel_bb_head->bb_node with
special options
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

Created attachment 33585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33585&action=edit
test case (non minimized)

The following combination of options causes an ICE with the attached test case:

g++50 matrix.i -o outfile -O2  -fsel-sched-pipelining-outer-loops
-fsel-sched-reschedule-pipelined -fvar-tracking-assignments-toggle
-ftree-vectorize -fselective-scheduling2

gcc version 4.9.0 20130617 (experimental) (GCC) 

apps/matrixmultiply.cpp: In function 'T** make_test_matrix() [with T = float]':
apps/matrixmultiply.cpp:22:1: internal compiler error: Segmentation fault
 }
 ^
0x8cde37 crash_signal
../../gcc/gcc/toplev.c:333
0x6764e1 bb_note(basic_block_def*)
../../gcc/gcc/cfgrtl.c:647
0x89c1a1 sel_bb_head(basic_block_def*)
../../gcc/gcc/sel-sched-ir.c:4536
0x8a6fa5 moveup_expr_cached
../../gcc/gcc/sel-sched.c:2563
0x8ac506 move_op_ascend
../../gcc/gcc/sel-sched.c:6217
0x8aabc7 code_motion_path_driver
../../gcc/gcc/sel-sched.c:6706
0x8aca54 move_op
../../gcc/gcc/sel-sched.c:6758
0x8aca54 move_exprs_to_boundary
../../gcc/gcc/sel-sched.c:5292
0x8aca54 schedule_expr_on_boundary
../../gcc/gcc/sel-sched.c:5504
0x8af552 fill_insns
../../gcc/gcc/sel-sched.c:5646
0x8af552 schedule_on_fences
../../gcc/gcc/sel-sched.c:7410
0x8af552 sel_sched_region_2
../../gcc/gcc/sel-sched.c:7544
0x8b14bf sel_sched_region_1
../../gcc/gcc/sel-sched.c:7583
0x8b14bf sel_sched_region(int)
../../gcc/gcc/sel-sched.c:7684
0x8b1fc1 run_selective_scheduling()
../../gcc/gcc/sel-sched.c:7760
0x895b56 rest_of_handle_sched2
../../gcc/gcc/sched-rgn.c:3606

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

[Bug tree-optimization/47413] Constant Propagation and Virtual Function Tables

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
Current mainline gets pretty close:
;; Function int f1337(obj*) (_ZL5f1337P3obj, funcdef_no=19, decl_uid=3418,
cgraph_uid=19, symbol_order=19)

int f1337(obj*) (struct obj * obj)
{
  :
  return 1337;

}



;; Function int main() (main, funcdef_no=22, decl_uid=3427, cgraph_uid=22,
symbol_order=22) (executed once)

Removing basic block 5
int main() ()
{
  struct obj * obj;
  int _1;
  int _10;

  :
  obj_7 = malloc (8);
  if (obj_7 == 0B)
goto ;
  else
goto ;

  :
  obj_7->vtab = &vtab1337;
  _10 = f1337 (obj_7);
  printf ("%d\n", _10);

  :
  # _1 = PHI <0(2), 1(3)>
  return _1;

}

So we are down to one missing inline. After FRE we get:

  :
  obj_13 = malloc (8);
  if (obj_13 == 0B)
goto ;
  else
goto ;

  :
  obj_13->vtab = &vtab1337;

  :
  # _14 = PHI <0B(2), obj_13(3)>
  if (_14 == 0B)
goto ;
  else
goto ;

  :
  _4 = _14->vtab;
  _15 = _4->f;
  _16 = _15 (_14);
  printf ("%d\n", _16);


So purely local problem. I suppose FRE could propagate through by knowing that
on the other path program with segfault?

[Bug ipa/59948] Optimize std::function

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #6 from Jan Hubicka  ---
The nonzero check rewrite is already in tree, so .optimized dump is now better:

int m() ()
{
  struct function h;
  int _23;

  :
  MEM[(int (*) (int) *)&h] = f;
  h._M_invoker = _M_invoke;
  h.D.26130._M_manager = _M_manager;
  _23 = f (1);
  std::_Function_base::_Base_manager::_M_manager (&MEM[(struct
_Function_base *)&h]._M_functor, &MEM[(struct _Function_base *)&h]._M_functor,
3);
  h ={v} {CLOBBER};
  return _23;
}

We fail to inline f because at .release_ssa time it is still passed via memory:

int m() ()
{
  struct function h;
  bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) _2;
  int _4;
  bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) _5;

  :
  MEM[(struct _Function_base *)&h]._M_manager = 0B;
  MEM[(int (*) (int) *)&h] = f;
  h._M_invoker = _M_invoke;
  h.D.26130._M_manager = _M_manager;
  _4 = std::function::operator() (&h, 1);

Where operator () is:

_Res std::function<_Res(_ArgTypes ...)>::operator()(_ArgTypes ...) const [with
_Res = int; _ArgTypes = {int}] (const struct function * const this, int
__args#0)
{
  bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) _3;
  int (*) (const union _Any_data &, int) _4;
  const union _Any_data * _5;
  int _7;

  :
  _3 = MEM[(bool (*) (union _Any_data &, const union _Any_data &,
_Manager_operation) *)this_1(D) + 16B];
...

We have

  Jump functions of caller  int m()/290:
callsite  int m()/290 -> _Res std::function<_Res(_ArgTypes
...)>::operator()(_ArgTypes ...) const [with _Res = int; _ArgTypes = {int}]/361
:
   param 0: UNKNOWN
 Aggregate passed by reference:
   offset: 0, cst: f
   offset: 128, cst: _M_manager
   offset: 192, cst: _M_invoke
   param 1: CONST: 1

So we know that f is passed in the aggregate.

We also know operator () is using it:

  Jump functions of caller  _Res std::function<_Res(_ArgTypes
...)>::operator()(_ArgTypes ...) const [with _Res = int; _ArgTypes =
{int}]/361:
callsite  _Res std::function<_Res(_ArgTypes ...)>::operator()(_ArgTypes
...) const [with _Res = int; _ArgTypes = {int}]/361 -> void
std::__throw_bad_function_call()/539 :
indirect aggregate callsite, calling param 0, offset 192, by reference, for
stmt _7 = _4 (_5, __args#0_9(D));
   param 0: UNKNOWN
   param 1: PASS THROUGH: 1, op nop_expr

Later we propagate this call into _M_invoke and we lost track of f() that is
invoked by it.  We do have jump functoin here too:

  Jump functions of caller  static _Res std::_Function_handler<_Res(_ArgTypes
...), _Functor>::_M_invoke(const std::_Any_data&, _ArgTypes ...) [with _Res =
int; _Functor = int (*)(int); _A
indirect aggregate callsite, calling param 0, offset 0, by reference, for
stmt _5 = _3 (__args#0_6(D));
   param 0: PASS THROUGH: 1, op nop_expr

Martin, what is going wrong here?

[Bug c++/55992] constexpr static member function not recognised in templated using statement

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
An alias declaration seems necessary to trigger the bug, eg doesn't affect:

  template
  struct my_array : A { };

[Bug lto/44463] whopr does not work with weak functions

[andi-gcc at firstfloor dot org]

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

--- Comment #15 from Andi Kleen  ---
I don't have any aliasing problems currently, but I haven't tried to take out
the workarounds. But it's ok for me to close.

[Bug middle-end/45307] Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

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

[Bug lto/44463] whopr does not work with weak functions

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #14 from Jan Hubicka  ---
Andi, I suppose this is long fixed?

[Bug c++/63383] internal compiler error: in expand_expr_real_1, at expr.c:9389

[brandon at rioja dot us]

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

--- Comment #3 from Brandon Rioja  ---
Created attachment 33584
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33584&action=edit
preprocessed file (zipped)

[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Ugh.  Clearly merging the wide-int back to 4.9 wouldn't make sense.

[Bug c++/63383] internal compiler error: in expand_expr_real_1, at expr.c:9389

[brandon at rioja dot us]

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

--- Comment #1 from Brandon Rioja  ---

version: gcc (GCC) 4.8.3
system type: cygwin running in windows 7
command line to build:
g++ -ggdb -O0 -std=c++11 BigOEasy.cpp

[Bug c++/63383] internal compiler error: in expand_expr_real_1, at expr.c:9389

[brandon at rioja dot us]

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

--- Comment #2 from Brandon Rioja  ---
Created attachment 33583
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33583&action=edit
stack dump

[Bug c++/63383] New: internal compiler error: in expand_expr_real_1, at expr.c:9389

[brandon at rioja dot us]

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

Bug ID: 63383
   Summary: internal compiler error: in expand_expr_real_1, at
expr.c:9389
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brandon at rioja dot us

Created attachment 33582
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33582&action=edit
The file to compile

When compiling the attached file, the following error is printed.

-*- mode: compilation; default-directory: "~/topcoder/srm/" -*-
Compilation started at Fri Sep 26 12:07:34

g++ -ggdb -O0 -std=c++11 BigOEasy.cpp && nice.exe ./a.exe
BigOEasy.cpp: In lambda function:
BigOEasy.cpp:319:30: internal compiler error: in expand_expr_real_1, at
expr.c:9389
 if ((adj[n][i]) && (adj[i][n]))
  ^

BigOEasy.cpp:319:30: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compilation exited abnormally with code 4 at Fri Sep 26 12:07:34

[Bug tree-optimization/50021] -Wsuggest-attribute=pure makes obviously-incorrect suggestion

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Yep, fixed in 4.7+

[Bug middle-end/35545] tracer pass is run too late

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
This feels like the kind of situation where I've always wanted a pass to be
able to say something like "I've done some set of transformations", schedule
the appropriate cleanup passes to run".

It's heavyweight, but making  the tracer imply a later DOM or VRP pass might
make sense.

Jeff

[Bug bootstrap/63253] [5 Regression] LTO boot strap failure due to ODR warnings

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
Bootstrap works for me with -Werror again.

[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
SRA is indeed quite guilty, the following patch fixes it:

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 8259dba..fb24114 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -1064,6 +1064,11 @@ build_access_from_expr_1 (tree expr, gimple stmt, bool
write)
   "component.");
   return NULL;
 }
+  if (TREE_THIS_VOLATILE (expr))
+{
+  disqualify_base_of_expr (expr, "part of a volatile reference.");
+  return NULL;
+}

   switch (TREE_CODE (expr))
 {

Nevertheless, it is apparently not the only culprit.  Even on trunk
with -fno-tree-sra we produce exactly the same assembly output.  From
a brief look at the dumps it seems that RTL fwprop1 is the pass moving
the load, however I have not had a look if it is its fault or if
expansion looses the volatility information somehow.

[Bug target/63382] gcc 5 breaks linux early bootup in QEMU

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

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

--- Comment #2 from Andi Kleen  ---
Yes, Alan's patch fixes it. So it's a dup.

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

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-09-26
 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |4.8.4
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.1, 5.0

--- Comment #7 from Markus Trippelsdorf  ---
markus@x4 tmp % cat test3.ii
namespace std {
template 
struct B {
  static constexpr _Tp value = 0;
};
typedef B false_type;
struct C : false_type {};
template 
struct is_integral : C {};
template 
struct enable_if {
  typedef _Tp type;
};
}
enum class enabled;
constexpr enabled dummy{};
template ::value,
  enabled>::type = dummy>
class A;
template 
void f(A*) {
  A* map;
  f(map);
}

markus@x4 tmp % g++ -c -std=c++11 test3.ii
test3.ii: In substitution of ‘template void f(A*) [with T =
]’:
test3.ii:23:8:   required from here
test3.ii:23:8: internal compiler error: in unify, at cp/pt.c:18392
   f(map);
^
0x606105 unify
../../gcc/gcc/cp/pt.c:18392
0x6067a4 unify
../../gcc/gcc/cp/pt.c:18234
0x51d9b8 try_class_unification
../../gcc/gcc/cp/pt.c:17248
0x605b77 unify
../../gcc/gcc/cp/pt.c:18271
0x605d5c unify
../../gcc/gcc/cp/pt.c:18138
0x6093f4 unify_one_argument
../../gcc/gcc/cp/pt.c:16657
0x60baea type_unification_real
../../gcc/gcc/cp/pt.c:16728
0x614aac fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16164
0x5843e9 add_template_candidate_real
../../gcc/gcc/cp/call.c:3025
0x584e5c add_template_candidate
../../gcc/gcc/cp/call.c:3122
0x584e5c add_candidates
../../gcc/gcc/cp/call.c:5253
0x587413 perform_overload_resolution
../../gcc/gcc/cp/call.c:3971
0x5897da build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4048
0x7032ac finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2366
0x688c55 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6232
0x68bb09 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7293
0x68c744 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8035
0x68ccd9 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8278
0x68f4c4 cp_parser_expression
../../gcc/gcc/cp/parser.c:8440
0x68fcfc cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9828
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/61848] [5 Regression] a previous declaration causes the section attribute to be lost

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #15 from Andi Kleen  ---
*** Bug 63382 has been marked as a duplicate of this bug. ***

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

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

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

--- Comment #6 from Gereon Kremer  ---
Any news here?

The problem persists with version g++ (GCC) 4.9.1 20140903 (prerelease).

[Bug target/63382] gcc 5 breaks linux early bootup in QEMU

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Probably a dup of PR61848. Could you try Alan's patch?

[Bug target/63382] New: gcc 5 breaks linux early bootup in QEMU

[andi-gcc at firstfloor dot org]

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

Bug ID: 63382
   Summary: gcc 5 breaks linux early bootup in QEMU
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andi-gcc at firstfloor dot org

No debug so far. But a gcc 5 compiled x86 Linux kernel cannot boot in qemu/KVM
with -kernel bzImage. qemu always resets and loops directly after starting to
execute the kernel image. The same kernel compiled with an older compiler works
fine.

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.4
  Known to fail||4.8.3, 4.9.1, 5.0

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #10 from Markus Trippelsdorf  ---
markus@x4 tmp % cat finish.ii
template 
struct B;
template 
struct B<_Tp &> {
  typedef _Tp type;
};
template 
typename B::type foo(L &&);
int a;
struct A {
  typedef int TA __attribute__((__may_alias__));
};
void d() { foo(a); }
int main() { B b; }

markus@x4 tmp % g++ -std=c++11 finish.ii
finish.ii: In instantiation of ‘struct B’:
finish.ii:15:25:   required from here
finish.ii:4:17: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2844

[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from John David Anglin  ---
Introduced in r203627:

2013-10-15  Zhenqiang Chen  

* tree-ssa-reassoc.c: Include rtl.h and tm_p.h.
(optimize_range_tests_1): New function,
extracted from optimize_range_tests.
(optimize_range_tests_xor): Similarly.
(optimize_range_tests_diff): New function.
(optimize_range_tests): Use optimize_range_tests_1.

It was fixed on trunk in wide-int merge but it still is present on 4.9
branch.

[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute

[kretz at kde dot org]

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

Matthias Kretz  changed:

   What|Removed |Added

 CC||kretz at kde dot org

--- Comment #9 from Matthias Kretz  ---
I assume I hit the same issue. I got the testcase down to a few lines:

#include 
template  typename std::remove_reference::type foo(L &&lhs, int
rhs);
template  T d(T i)
{
  enum { Size = sizeof(int) };
  return foo(i, Size);
}
template  struct A {
  typedef int TA __attribute__((__may_alias__));
};
int main()
{
  typedef A V;
  typedef typename std::remove_reference::type T;
  return d(1);
}

It only needs the -std=c++11 flag. Tested to fail: 4.8.0/1/2/3 and 4.9.0/1/2
(4.9.2 is 20140924).

Backtrace from 4.9.2 snapshot:
/opt/gcc-4.9-snapshot/include/c++/4.9.2/type_traits:1488:5: internal compiler
error: in finish_member_declaration, at cp/semantics.c:2827
 { typedef _Tp   type; };
 ^
0x6395c0 finish_member_declaration(tree_node*)
../.././gcc/cp/semantics.c:2827
0x5b975d instantiate_class_template_1
../.././gcc/cp/pt.c:9244
0x5b975d instantiate_class_template(tree_node*)
../.././gcc/cp/pt.c:9445
0x61039d complete_type(tree_node*)
../.././gcc/cp/typeck.c:134
0x5a8531 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:12163
0x5acac7 tsubst_function_type
../.././gcc/cp/pt.c:11344
0x5a7e7f tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:12081
0x5ae8fe tsubst_decl
../.././gcc/cp/pt.c:10596
0x5a822f tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.c:11543
0x5b09fb instantiate_template_1
../.././gcc/cp/pt.c:15580
0x5b09fb instantiate_template(tree_node*, tree_node*, int)
../.././gcc/cp/pt.c:15630
0x5b6c2e fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../.././gcc/cp/pt.c:15979
0x574031 add_template_candidate_real
../.././gcc/cp/call.c:2998
0x571984 add_template_candidate
../.././gcc/cp/call.c:3095
0x571984 add_candidates
../.././gcc/cp/call.c:5169
0x5755d9 perform_overload_resolution
../.././gcc/cp/call.c:3904
0x5770ea build_new_function_call(tree_node*, vec**, bool, int)
../.././gcc/cp/call.c:3981
0x639891 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../.././gcc/cp/semantics.c:2358
0x5a1b34 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:14861
0x5a519c tsubst_expr
../.././gcc/cp/pt.c:14048

[Bug ipa/61283] [5 regression] SEGV in pass_ipa_comdats::execute

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Jan Hubicka  ---
> Does this still reproduce?

It does on i386-pc-solaris2.11 as of 20140924 (r215597).

Rainer

[Bug lto/63333] lto, 1to1 segmentation fault

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Fri, 26 Sep 2014, a...@cloudius-systems.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
> 
> --- Comment #5 from Avi Kivity  ---
> Richard, may I send you the test case privately?

Sure - but why not attach it here?

[Bug middle-end/63247] fortran array alignment in omp target map

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
Patch works fine in my testing, thanks!  Cesar, any further comments, as you
have originally diagnosed this issue?

[Bug lto/63333] lto, 1to1 segmentation fault

[a...@cloudius-systems.com]

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

--- Comment #5 from Avi Kivity  ---
Richard, may I send you the test case privately?

[Bug preprocessor/58893] [4.8/4.9/5 Regression] :0:0: internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Bernd Edlinger from comment #10)
> Created attachment 33546 [details]
> possible fix
> 
> Hi,
> 
> I have looked at this issue, and think this is the right fix.
> 
> Regarding the hunk in cpp_diagnostic, which is not directly involved
> in this bug, but still obviously wrong:
> 
> The line "src_loc = pfile->cur_run->prev->limit->src_loc"
> is probably unreachable, but will crash it is ever executed.
> 
> see:
> 
> _cpp_init_tokenrun (tokenrun *run, unsigned int count)
> {
>   run->base = XNEWVEC (cpp_token, count);
>   run->limit = run->base + count;
>   run->next = NULL;
> }
> 
> limit points at the end of the run, prev is uninitialized.
> 
> Comments?

Looks good to me, but please post it to the gcc-patches mailing list.

[Bug middle-end/63247] fortran array alignment in omp target map

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 33581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33581&action=edit
gcc5-pr63247.patch

Untested fix.  I believe it is only this particular case
(OMP_CLAUSE_MAP_POINTER for array with non-zero bias) that needs fixing, for
zero base array bias we emit mapping for the decl just with perhaps shortened
length, and for non-array pointer assign the decl should be a pointer already. 
Thanks for reporting this.

[Bug middle-end/63247] fortran array alignment in omp target map

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-09-26
  Component|fortran |middle-end
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/63381] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 63381
   Summary: Wrong constant folding
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp

GCC 5.0.0 for x86_64 miscompiles the following code.

   $ cat test.c

int a = 0, b = 0, c = 0, d, e;
int
main (void)
{
d = ((20 % (1 != b)) && c) + 2147483647;
e = 20 % (a >= 0);
return 0;
}

   $ x86_64-unknown-linux-gnu-gcc-5.0.0 test.c -Os
   $ ./a.out
   Floating point exception (core dumped)

   $ x86_64-unknown-linux-gnu-gcc-5.0.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-
5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/orange3/gcc-master/configure --
prefix=/usr/local/x86_64-tools/gcc-5.0.0/ --with-gmp=/usr/local/gmp-
5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/ --with-mpc=/usr/local/mpc-
1.0.1/ --disable-multilib --disable-nls --enable-languages=c
Thread model: posix
gcc version 5.0.0 20140922 (experimental) (GCC)

[Bug tree-optimization/63380] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 63380
   Summary: Wrong constant folding
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp

GCC 5.0.0 for x86_64 miscompiles the following code.

   $ cat test.c

int a = 0, b = 1, c = 0, d = 1, e, f, g, h;
int
main ()
{
  e = 1 >> d;
  f = ((31 / (1 > e)) || c) / 2;
  g = b || a;
  h = 31 / g;
  if (!h)
__builtin_abort();
  return 0;
}

   $ x86_64-unknown-linux-gnu-gcc-5.0.0 test.c -O2
   $ ./a.out
   Floating point exception (core dumped)

   $ x86_64-unknown-linux-gnu-gcc-5.0.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-
5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/orange3/gcc-master/configure --
prefix=/usr/local/x86_64-tools/gcc-5.0.0/ --with-gmp=/usr/local/gmp-
5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/ --with-mpc=/usr/local/mpc-
1.0.1/ --disable-multilib --disable-nls --enable-languages=c
Thread model: posix
gcc version 5.0.0 20140922 (experimental) (GCC)

[Bug tree-optimization/63379] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[jwyatt at feralinteractive dot com]

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

--- Comment #1 from Jason Wyatt  ---
Created attachment 33580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33580&action=edit
Test case

Compiling this code and running it gives the following output:
Point 0,1000
Point 1,1001
Point 2,1002
Point 3,1003
Point 4,1004
Point 5,1005
Point 6,1006
Point 7,1007
Point 8,1008
Point 9,1009
Point 10,1010
Point 11,1011
Point 12,1012
Point 13,1013
Point 14,1014
Point 15,1015
Point 16,1016
Point 17,1017
Point 18,1018
Point 19,1019
Point 20,1020
Point 21,1021
Point 22,1022
Point 23,1023
Point 24,1024
Size: 25
25, 0, 0 <---This value should be 1000 (minimum y value)
Point 0,1000
Point 1,1001
Point 2,1002
Point 3,1003
Point 4,1004
Point 5,1005
Point 6,1006
Point 7,1007
Point 8,1008
Point 9,1009
Point 10,1010
Point 11,1011
Point 12,1012
Point 13,1013
Point 14,1014
Point 15,1015
Point 16,1016
Point 17,1017
Point 18,1018
Point 19,1019
Point 20,1020
Point 21,1021
Point 22,1022
Point 23,1023
Point 24,1024

[Bug tree-optimization/63379] New: Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value

[jwyatt at feralinteractive dot com]

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

Bug ID: 63379
   Summary: Incorrect vectorization when enabling SSE and O3,
initialises loop with wrong value
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwyatt at feralinteractive dot com

Created attachment 33579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33579&action=edit
.i file for simple test case

Enabling SSE and 03 causes gcc to vectorize the following for loop:

Point min_pt = pt_array[0];
for (Point *ptr = pt_array+1, *ptr_end = pt_array+size; ptr != ptr_end; ++ptr)
{
min_pt.x = (min_pt.x < ptr->x) ? min_pt.x : ptr->x;
min_pt.y = (min_pt.y < ptr->y) ? min_pt.y : ptr->y;
}

where pt_array is an array of:

struct Point {
int x;
int y;
};

This sets the min_pt.y value to an x value if the y values are greater than the
x values.

Looking at the assembly, the vectorization splits this into two. It looks like
for one of these, it initialises the first min y value as the min x value.

Compiled with g++ -msse --std=c++11 -O3 -Wall -Wextra test.cpp, which gives no
warnings.

Version info:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)

[Bug middle-end/63325] [5.0 regression] ICE fold check: original tree changed by fold

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
(In reply to Dmitry G. Dyachenko from comment #1)
> start FAIL r215409

I get something similar with revision 215557.

../../../../src/trunk/libgcc/crtstuff.c:382:3: internal compiler error: fold
check: original tree changed by fold
   if (__cxa_finalize)
   ^

[Bug target/60410] [4.8/4.9/5 Regression] -fshort-double ICEs x86_64

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
IMHO -fshort-double should be made a target specific option and generally not
supported.

[Bug middle-end/63373] ELF symbol sizes for variable-length objects are too small

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org
  Component|target  |middle-end

--- Comment #1 from Richard Biener  ---
This is also a question if it is valid (GNU) C.  The types in both units are
definitely not the same.

Joseph?

[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jamborm at gcc dot gnu.org
  Known to work||4.3.4
   Target Milestone|--- |4.8.4
Summary|reordering of reads across  |[4.8/4.9/5 Regression]
   |fences  |reordering of reads across
   ||fences
  Known to fail||4.8.3, 4.9.1, 5.0

--- Comment #3 from Richard Biener  ---
Confirmed the SRA issue.  Martin, can you have a look please?

4.3 works (because we keep the variable addressable due to the lack of
MEM_REFs)

[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug middle-end/35545] tracer pass is run too late

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Well - ideally you'd want to do some CSE, not only VRP (constant propagation in
this case).  So I'd move it even earlier, after pass_lower_vector_ssa?  I
can't see what tracing would break (some odd cases can destroy loop info, but
I think I have disabled all those).

[Bug debug/63300] 'const volatile' sometimes stripped in debug info

[arnez at linux dot vnet.ibm.com]

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

Andreas Arnez  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Andreas Arnez  ---
Closing per comment #5.

[Bug debug/63300] 'const volatile' sometimes stripped in debug info

[arnez at linux dot vnet.ibm.com]

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

Andreas Arnez  changed:

   What|Removed |Added

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

--- Comment #5 from Andreas Arnez  ---
The fix works and I didn't find any regressions.

[Bug c++/63378] decltype and access control issues

[roger.ferrer at bsc dot es]

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

--- Comment #1 from Roger Ferrer Ibanez  ---
Created attachment 33578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33578&action=edit
Testcase

[Bug c++/63378] New: decltype and access control issues

[roger.ferrer at bsc dot es]

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

Bug ID: 63378
   Summary: decltype and access control issues
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roger.ferrer at bsc dot es

Hi,

the following testcase fails to compile with g++ 4.9.1 and 5.0.0 (20140925).

-- test.cc
template 
struct B { };

template 
struct A
{
private:
template 
static B bar();

public:
template 
auto foo1() -> decltype(bar());
};

// (*)
template<>
template<>
auto A::foo1() -> B;
-- end of test.cc

$ g++ --version
g++ (GCC) 5.0.0 20140925 (experimental)
$ g++ -c -std=c++11 -c test.cc
test.cc:18:6: error: template-id ‘foo1’ for ‘B
A::foo1()’ does not match any template declaration
 auto A::foo1() -> B;
  ^

but making 'A::bar' public or using '-fno-access-control' g++ accepts the
code OK.

Explicitly using a manually substituted decltype gives a clue of what is going
on

-- test.cc
// Declarations of B and A above

// (*)
template<>
template<>
auto A::foo1() -> decltype(A::bar());
-- end of test.cc

$ g++ -c -std=c++11 -c test.cc
test.cc:22:6: error: template-id ‘foo1’ for ‘B
A::foo1()’ does not match any template declaration
 auto A::foo1() -> decltype(A::bar());
  ^
test.cc:9:26: error: ‘static B A::bar() [with T2 = int; S2 = float;
T1 = int]’ is private
 static B bar();
  ^
test.cc:22:64: error: within this context
 auto A::foo1() -> decltype(A::bar());

Both clang-3.5 and icc 14.0.2 accept this code.

Kind regards,