[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Sorry, the number of clobbers drops at DSE1, not during ehcleanup2, I just
messed up my grep. 

I tried the following patch:

Index: passes.def
===
--- passes.def  (revision 221541)
+++ passes.def  (working copy)
@@ -87,6 +87,7 @@ along with GCC; see the file COPYING3.
  NEXT_PASS (pass_build_ealias);
  NEXT_PASS (pass_fre);
  NEXT_PASS (pass_merge_phi);
+ NEXT_PASS (pass_dse);
  NEXT_PASS (pass_cd_dce);
  NEXT_PASS (pass_early_ipa_sra);
  NEXT_PASS (pass_tail_recursion);

This brings number of CLOBBER statements at release_ssa time down to 7392 (50%
reduction).  A nice effect of this patch is that it tends to simplify
destructors often to empty to make them more inlinable:

 ObserverEvent::~ObserverEvent() (struct ObserverEvent * const this)
 {
   :
-  this_2(D)->_vptr.ObserverEvent = &MEM[(void *)&_ZTV13ObserverEvent + 16B];
   MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
   return;

saves a lot of the clobbers:
 Engine<3, double, ExpressionTag, Vector<3, double, Full>, ViewEngine<3,
IndexFunction >::PositionsFunctor> > > >, Scalar > >
> > >::~Engine() (struct Engine * const this)
 {
   :
-  MEM[(struct  &)this_2(D) + 32] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D) + 32] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D) + 8] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D) + 8] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D) + 8] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
-  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
+  MEM[(struct  &)this_1(D)] ={v} {CLOBBER};
   return;

which is especially nice for LTO streaming.

and saves about 7% of code apparently after inlining:

$ wc -l *copyprop2
200189 tramp3d-v4.ii.085t.copyprop2
$ wc -l ../5/*copyprop2
215060 ../5/tramp3d-v4.ii.084t.copyprop2

Even though the inline decisions does not seem to be changed considerably (at
least on tramp3d).

On unrelated note I noticed PR65502

Still I guess this does not really explain the origin of regression in
statement count relative to 4.9...

[Bug ipa/65502] New: pure-const should play well with clobbers.

[hubicka at gcc dot gnu.org]

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

Bug ID: 65502
   Summary: pure-const should play well with clobbers.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org

I just noticed that C++ destructors are not conisdered const/pure:

 local analysis of Smarts::IterateScheduler::~IterateScheduler()
   scanning: MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
Indirect ref write is not const/pure
  scanning: return;
Smarts::IterateScheduler::~IterateScheduler() (struct
IterateScheduler * const this)
{
  :
  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
  return;

}

This is of course wrong, empty function is const.  One issue however is that we
want to preserve CLOBBER when inlining, so during early passes we may want to
keep clobbers nonpure.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
I can re-confirm the 16% compile time regression.  I went through some compare.

$ wc -l *.ssa
299231 tramp3d-v4.ii.015t.ssa
$ wc -l ../5/*.ssa
331115 ../5/tramp3d-v4.ii.018t.ssa

so as a lame compare, we already have 10% more statements to start with.
Now einline

$ wc -l *.einline
692812 tramp3d-v4.ii.018t.einline
$ wc -l ../5/*.einline
724090 ../5/tramp3d-v4.ii.026t.einline

so after einline we seem to have 4% statements more, we do about the same
number of inlining:

$ grep Inlining tramp3d-v4.ii.*einline | wc -l
28003
$ grep Inlining ../5/tramp3d-v4.ii.*einline | wc -l
28685

but at release_ssa we still have about 4% more.

$ wc -l *release_ssa*
348378 tramp3d-v4.ii.036t.release_ssa
$ wc -l ../5/*release_ssa*
365689 ../5/tramp3d-v4.ii.043t.release_ssa

There is no difference in number of functions in ssa and release_ssa dumps. 
What makes the functions bigger in GCC 5?

$ grep "^  .* = " *.release_ssa | wc -l
65028
$ grep "^  .* = " ../5/*.release_ssa | wc -l
72636

The number of statements is about the same.

During the actual inlining GCC 4.9 reports:
 Unit growth for small function inlining: 88536->114049 (28%)
and
 Unit growth for small function inlining: 87943->97699 (11%)

Statement count seems to remain 7% in .optimized dumps.  So perhaps the
slowdown is not really that much caused by IPA passes as we somehow manage to
produce more code out of C++ FE.

I looked for interesting differences in SSA dump.  Here are few:

-;; Function int __gthread_active_p() (_ZL18__gthread_active_pv,
funcdef_no=312, decl_uid=8436, symbol_order=127)
+;; Function int __gthread_active_p() (_ZL18__gthread_active_pv,
funcdef_no=312, decl_uid=8537, cgraph_uid=127, symbol_order=127)

 int __gthread_active_p() ()
 {
-  bool _1;
-  int _2;
+  static void * const __gthread_active_ptr = (void *) __gthrw_pthread_cancel;
+  void * __gthread_active_ptr.111_2;
+  bool _3;
+  int _4;

   :
-  _1 = __gthrw_pthread_cancel != 0B;
-  _2 = (int) _1;
-  return _2;
+  __gthread_active_ptr.111_2 = __gthread_active_ptr;
+  _3 = __gthread_active_ptr.111_2 != 0B;
+  _4 = (int) _3;
+  return _4;

 }

... this looks like header change, perhaps ...

 ObserverEvent::~ObserverEvent() (struct ObserverEvent * const this)
 {
-  int _6;
+  int (*__vtbl_ptr_type) () * _2;
+  int _7;

   :
-  this_3(D)->_vptr.ObserverEvent = &MEM[(void *)&_ZTV13ObserverEvent + 16B];
-  *this_3(D) ={v} {CLOBBER};
-  _6 = 0;
-  if (_6 != 0)
+  _2 = &_ZTV13ObserverEvent + 16;
+  this_4(D)->_vptr.ObserverEvent = _2;
+  MEM[(struct  &)this_4(D)] ={v} {CLOBBER};
+  _7 = 0;
+  if (_7 != 0)

... extra temporary initializing vtbl pointer. This is repeated many times ...

-;; Function static Unique::Value_t Unique::get() (_ZN6Unique3getEv,
funcdef_no=3030, decl_uid=51649, symbol_order=884)
+;; Function static Unique::Value_t Unique::get() (_ZN6Unique3getEv,
funcdef_no=3030, decl_uid=51730, cgraph_uid=883, symbol_order=884)

 static Unique::Value_t Unique::get() ()
 {
   Value_t retval;
-  long int next_s.83_2;
-  long int next_s.84_3;
-  long int next_s.85_4;
-  Value_t _7;
+  long int next_s.83_3;
+  long int next_s.84_4;
+  long int next_s.85_5;
+  Value_t _9;

   :
-  Pooma::DummyMutex::_ZN5Pooma10DummyMutex4lockEv.isra.26 ();
-  next_s.83_2 = next_s;
-  next_s.84_3 = next_s.83_2;
-  next_s.85_4 = next_s.84_3 + 1;
-  next_s = next_s.85_4;
-  retval_6 = next_s.84_3;
-  Pooma::DummyMutex::_ZN5Pooma10DummyMutex6unlockEv.isra.27 ();
-  _7 = retval_6;
-  return _7;
+  Pooma::DummyMutex::lock (&mutex_s);
+  next_s.83_3 = next_s;
+  next_s.84_4 = next_s.83_3;
+  next_s.85_5 = next_s.84_4 + 1;
+  next_s = next_s.85_5;
+  retval_7 = next_s.84_4;
+  Pooma::DummyMutex::unlock (&mutex_s);
+  _9 = retval_7;
+  return _9;

 }

... here we give up on ISRA

and we have about twice as much EH:

$ grep "resx " tramp3d-v4.ii.*\.ssa | wc -l
4816
$ grep "resx " ../5/tramp3d-v4.ii.*\.ssa | wc -l
8671

which however is optimized out at a time of release_ssa.

Another thing that we may consider to cleanup in next stage1 is to get rid of
dead stores:

-  MEM[(struct new_allocator *)&D.561702] ={v} {CLOBBER};
-  D.561702 ={v} {CLOBBER};
-  D.561702 ={v} {CLOBBER};
-  MEM[(struct new_allocator *)_2] ={v} {CLOBBER};
-  MEM[(struct allocator *)_2] ={v} {CLOBBER};
-  MEM[(struct _Alloc_hider *)_2] ={v} {CLOBBER};
-  MEM[(struct basic_string *)_2] ={v} {CLOBBER};
-  *_2 ={v} {CLOBBER};
-  *this_1(D) ={v} {CLOBBER};
+  MEM[(struct  &)&D.570046] ={v} {CLOBBER};
+  MEM[(struct  &)&D.570046] ={v} {CLOBBER};
+  D.570046 ={v} {CLOBBER};
+  MEM[(struct  &)_2] ={v} {CLOBBER};
+  MEM[(struct  &)_2] ={v} {CLOBBER};
+  MEM[(struct  &)_2] ={v} {CLOBBER};
+  MEM[(struct  &)_2] ={v} {CLOBBER};
+  MEM[(struct  &)_2] ={v} {CLOBBER};
+  MEM[(struct  &)this_1(D)] ={v} {CLOBBER};

Clobbers are dangerously common. There are 18K clobbers in release_ssa dump out
of 65K assignments, that makes them to be 29% of all the code. The number

[Bug inline-asm/65436] Max number of extended asm +output operands currently limited to 15

[gccbugzilla at limegreensocks dot com]

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

--- Comment #7 from David  ---
While I don't yet see a case here to justify making this change generally, it
may be useful to change this for private builds of gcc.  For those cases,
change this line in gcc/genconfig.c:

  max_recog_operands = 29;  /* We will add 1 later.  */

This generates MAX_RECOG_OPERANDS in insn-config.h, which controls the number
of parameters for asm statements.

Like Andrew, I would be interested to see what you are doing that modifies > 15
registers in inline asm on x86.  My gut says there's got to be a cleaner way
than throwing more parameters at it, but maybe not.

[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[dave.anglin at bell dot net]

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

--- Comment #1 from dave.anglin at bell dot net ---
On 2015-03-20, at 5:00 PM, danglin at gcc dot gnu.org wrote:

> FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
> Excess errors:
> /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/shared_mutex:64:34:
> error: narrowing conversion of '35985' from 'int' to 'short int' inside { }
> 
> The define in sys/pthread.h is:
> #define __LWP_RWLOCK_VALID  0x8c91

It looks like this bug was triggered by this change:

2015-03-18  Jonathan Wakely  
Torvald Riegel  

* acinclude.m4 (GLIBCXX_CHECK_GTHREADS): Check for pthread_rwlock_t.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/std/shared_mutex: Check _GLIBCXX_USE_PTHREAD_RWLOCK_T.
(shared_timed_mutex::_M_rwlock): Use PTHREAD_RWLOCK_INITIALIZER.
(shared_timed_mutex::lock_shared()): Retry on EAGAIN.
(shared_timed_mutex::try_lock_shared_until()): Retry on EAGAIN and
EDEADLK.

At one time, GCC was permissive about system header issues, particularly when
they aren't
really a problem.  Is this still the case?

It looks like an include hack would fix but there's probably more issues like
this.

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

[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer

[zoltan at hidvegi dot com]

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

--- Comment #8 from Zoltan Hidvegi  ---
How about using -bkeepfile: for all linked .o objects, that would create a very
similar semantics to other platforms, all .o objects are included, and only
objects that resolve undefined symbols would be included from .a files. This
would be a fix for the current bugreport, since it juse uses two .o files, and
one is collected away, but not completely, only in the first link pass, not in
the second link pass, due to the export file I guess. Certainly using -bexpall
is not a good idea.

[Bug rtl-optimization/64366] Segmentation fault in remove_pseudos

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

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

--- Comment #4 from Kazumoto Kojima  ---
Thanks for fixing this!  I'd like to close this PR.

[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer

[dje at gcc dot gnu.org]

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

--- Comment #7 from David Edelsohn  ---
I had not noticed the lack of a reference to any symbol in the file, so missing
the static constructor.  -bexpfull probably would work around that problem but
likely cause another.

It's a tension between two different use cases and a fundamental problem with
collect2 and AIX.  If collect2 utilizes -bexpfull for the first pass and all
symbols are exported, then every object file and every member of an archive
will be referenced, and every constructor will be run.  But what if the archive
contains otherwise unneeded object files and constructors?  With the proposed
change, the resulting binary or shared object will, at best, only be bloated
with unnecessary symbols and functions, and, at worst, run unnecessary or
damaging constructors.  It essentially is enabling the equivalent of
--whole-archive for every link.

There have been other bug reports about this and collect2 explicitly tries to
strike a balance.

I think this bug report really requires the user to explicitly reference the
file containing the constructor or manually use the equivalent of
--whole-archive.

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
Concerning Comment #7, I do not think the sreal refactoring screwed things up.
sreals are not high on profile and the code generated is not worse (performance
wise). It is not better, but it is not a surprise - we traditionally keep
inline limits high enough to get tramp3d performance good.

GCC 5 currently generates 11% bigger code than GCC 4.9. Not a good thing, but
from POV of the inliner heuristics it is - it is trying to do as much as
posisble of code duplication before it hits the limits.  New badness metrics
performs better on tramp3d - it does all useful inlining at 10% of unit growth,
hile old one needed 25%. It prioritizes more cases where inliner knows DCE will
happen because of propagation across arguments and thus it manages to get later
optimizers more busy.

Still plan to look into this more, but I think it is kind of non-bug (just
showing the fact that inliner is stupid to believe that all inlining is a good
idea, but there is not much to do except getting realistic static program
profiles that it out of current state of art).

[Bug target/63683] m32c-rtems ICE unable to find spill register compiling libgcc

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  ---
Still fails on gcc head today.

[Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling

[linux at carewolf dot com]

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

--- Comment #9 from Allan Jensen  ---
Looking at the assembler, it does indeed appear that the only difference just
loop unrolling and if conversion. 

After testing on another machine (and old PhenomII as opposed to the
Sandybridge), and report that disabling tree-loop-if-convert directly or
indirectly via tree-loop-vectorize -O3 regains all of the speed difference to
-O2 on PhenomII.

My guess is that the small loop-unrolling is conflicting with op-cache Intel
introduced in the SandyBridge and newer architectures which speeds up small
tight loops. On architectures without op-cache the loop-unrolling is probably
still slightly faster.

Unfortunately, using -mtune=sandybridge does not improve the situation, so
maybe there should be some architecture tuning on even trivial loop unrolling,
and possibly discussion on making it part of generic-x64 tuning.

[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 5.

[Bug c++/65398] [5 Regression] [C++11] GCC rejects constexpr variable definitions with valid initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar 20 21:53:40 2015
New Revision: 221544

URL: https://gcc.gnu.org/viewcvs?rev=221544&root=gcc&view=rev
Log:
PR c++/65398
* constexpr.c (cxx_fold_indirect_ref): Transform *(&A[i] p+ j) into
A[i + j].

* g++.dg/cpp0x/pr65398.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr65398.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/65501] New: v850 ICE at c_register_pragma_1, at c-family/c-pragma.c:1317

[joel at gcc dot gnu.org]

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

Bug ID: 65501
   Summary: v850 ICE at c_register_pragma_1, at
c-family/c-pragma.c:1317
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joel at gcc dot gnu.org

This occurs during the exception model probe for libstdc++-v3. This should be
reproducible on v850-elf. I think this is the conftest.c based on the
aclocal.m4 file:

cat > conftest.$ac_ext << EOF
[#]line __oline__ "configure"
struct S { ~S(); };
void bar();
void foo()
{
  S s;
  bar();
}


configure:15092: checking for exception model to use
configure:15133:  /users/joel/test-gcc/b-v850-rtems4.11-gcc/./gcc/xgcc
-shared-libgcc -B/users/joel/test-gcc/b-v850-rtems4.11-gcc/./gcc -nostdinc++
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/src
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/src/.libs
-L/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/libstdc++-v3/libsupc++/.libs
-nostdinc -B/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/newlib/
-isystem
/users/joel/test-gcc/b-v850-rtems4.11-gcc/v850-rtems4.11/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/v850-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/v850-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/v850-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/v850-rtems4.11/sys-include-c -S 
conftest.cpp >&5
: internal compiler error: in c_register_pragma_1, at
c-family/c-pragma.c:1317
0x6a15f7 c_register_pragma_1
../../gcc/gcc/c-family/c-pragma.c:1317
0x6a2fa6 c_register_pragma(char const*, char const*, void (*)(cpp_reader*))
../../gcc/gcc/c-family/c-pragma.c:1335
0x534013 init_cp_pragma
../../gcc/gcc/cp/lex.c:225
0x534013 cxx_init()
../../gcc/gcc/cp/lex.c:276
0x435493 lang_dependent_init
../../gcc/gcc/toplev.c:1845
0x435493 do_compile
../../gcc/gcc/toplev.c:2062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
configure:15136: $? = 1
configure:15165: error: unable to detect exception model

[Bug libstdc++/65499] Missing "using namespace literals::chrono_literals" in std::chrono

[marejde at gmail dot com]

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

--- Comment #1 from Martin Ejdestig  ---
See the end of 20.12.2 ("Header  synopsis").

Maybe it is too late for 5.0?

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
This should be enough to fix it:

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(Revision 221530)
+++ gcc/fortran/interface.c(Arbeitskopie)
@@ -1569,7 +1569,7 @@ check_interface0 (gfc_interface *p, const char *in
  functions or subroutines.  */
   if (((!p->sym->attr.function && !p->sym->attr.subroutine)
|| !p->sym->attr.if_source)
-  && p->sym->attr.flavor != FL_DERIVED)
+  && p->sym->attr.flavor != FL_DERIVED && *p->sym->name)
 {
   if (p->sym->attr.external)
 gfc_error ("Procedure %qs in %s at %L has no explicit interface",

[Bug libstdc++/65147] alignment of std::atomic object is not correct

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||ABI
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-20
 CC||jason at gcc dot gnu.org,
   ||jwakely.gcc at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Jason Merrill  ---
This does seem like a bug.

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[boger at us dot ibm.com]

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

--- Comment #6 from boger at us dot ibm.com ---
I decided that you meant the gofrontend so here it is (just did the hg mail)

https://codereview.appspot.com/213570043/

[Bug libstdc++/65500] New: [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 65500
   Summary: [5 Regression] FAIL:
17_intro/headers/c++2014/all_attributes.cc (test for
excess errors)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-5.0
/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/
-i
system /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/
gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpu
x11.11/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -g -O2
-DLO
CALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v
3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib
stdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc
/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/
test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.
cc -std=gnu++14 -S -o all_attributes.s
In file included from /usr/include/pthread.h:7:0,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/hppa2.0w-hp-hpux11.11/bits/gthr-default.h:35,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/in
clude/hppa2.0w-hp-hpux11.11/bits/gthr.h:148,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/atomicity.h:35,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/ios_base.h:39,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ios:42,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/istream:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/sstream:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/complex:45,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ccomplex:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/stdc++.h:52,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc:34:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/shared_mutex:64:34:
error: narrowing conversion of '35985' from 'int' to 'short int' inside { }
 pthread_rwlock_t _M_rwlock = PTHREAD_RWLOCK_INITIALIZER;
  ^
compiler exited with status 1
output is:
In file included from /usr/include/pthread.h:7:0,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/gthr-default.h:35,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/gthr.h:148,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/atomicity.h:35,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/ios_base.h:39,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ios:42,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/istream:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/sstream:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/complex:45,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ccomplex:38,
 from
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11/bits/stdc++.h:52,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/
c++2014/all_attributes.cc:34:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/shared_mutex:64:34:
error: narrowing conversion of '35985' from 'int' to 'short int' inside { }
 pthread_rwlock_t _M_rwlock = PTHREAD_RWLOCK_INITIALIZER;
  ^

FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
Excess errors:
/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/shared_mutex:64:34:
error: narrowing conversion of '35985' from 'int' to 'short int' inside { }

T

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
The ICE is now fixed. I will leave this open to fix the duplicated ODR warnings
(we probably only want to warn once per type). 

Martin, can you commit the testcase?

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[ian at airs dot com]

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

--- Comment #5 from Ian Lance Taylor  ---
Yes, I did mean for gofrontend-dev.

Or if you want to submit to the master sources, that is even better; guidelines
are at http://golang.org/doc/contribute.html .

[Bug target/43052] [4.8/4.9/5 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #27 from Jan Hubicka  ---
I won't be able to do anything iwth this for 5.0, so I am unassigning myself.
Will try to keep this on my radar for next stage1 though.

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
I suppose proper fix is to make flag_incremental_linking and turn -r from
Driver only.  Then we could revisit individual optimizations that do rely on
the fact that static linking will not be re-done.

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #3 from Daniel Krügler  ---
Removing libraries dependencies leads to:

//--
template 
struct is_same 
{ 
  enum { value = false }; 
  constexpr bool operator()() const noexcept { return value; }
};

template 
struct is_same 
{ 
  enum { value = true }; 
  constexpr bool operator()() const noexcept { return value; }
};

template 
struct enable_if { };

template 
struct enable_if { typedef T type; };

template 
using enable_if_t = typename enable_if::type;

struct T;

template 
struct F { };

template 
struct F{}()>> {
template 
F(MakeDependent) {
auto ICE_HERE = __func__;
(void)ICE_HERE; // avoid -Wunused-variable
}
};

int main() {
F{1};
}
//--

If we remove remove the enable_if_t alias we get to:

//--
template 
struct is_same 
{ 
  enum { value = false }; 
  constexpr bool operator()() const noexcept { return value; }
};

template 
struct is_same 
{ 
  enum { value = true }; 
  constexpr bool operator()() const noexcept { return value; }
};

template 
struct enable_if { };

template 
struct enable_if { typedef T type; };

struct T;

template 
struct F { };

template 
struct F{}()>::type> {
template 
F(MakeDependent) {
auto ICE_HERE = __func__;
(void)ICE_HERE; // avoid -Wunused-variable
}
};

int main() {
F{1};
}
//--

This still leads to an ICE, but with different diagnostics using GCC 5.0.0
20150320 (experimental):

>>>>>>>>>>>
nternal compiler error: Error reporting routines re-entered.
0x6fedc5 cxx_eval_call_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1358
0x6f9beb cxx_eval_constant_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3021
0x6fc330 cxx_eval_outermost_constant_expr
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:3529
0x6283b0 convert_nontype_argument
/home/heads/gcc/gcc-source/gcc/cp/pt.c:5843
0x6283b0 convert_template_argument
/home/heads/gcc/gcc-source/gcc/cp/pt.c:6744
0x628f32 coerce_template_parms
/home/heads/gcc/gcc-source/gcc/cp/pt.c:7171
0x629ea8 lookup_template_class_1
/home/heads/gcc/gcc-source/gcc/cp/pt.c:7780
0x629ea8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:8096
0x62b12c tsubst_aggr_type
/home/heads/gcc/gcc-source/gcc/cp/pt.c:10460
0x623ce9 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:12418
0x655bd0 dump_template_bindings
/home/heads/gcc/gcc-source/gcc/cp/error.c:369
0x655bd0 dump_substitution
/home/heads/gcc/gcc-source/gcc/cp/error.c:1448
0x6570fe decl_as_string_translate(tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/error.c:2821
0x6c1f35 cxx_printable_name_internal
/home/heads/gcc/gcc-source/gcc/cp/tree.c:2028
0x656cb2 cp_print_error_function
/home/heads/gcc/gcc-source/gcc/cp/error.c:3154
0x656cb2 cp_diagnostic_starter
/home/heads/gcc/gcc-source/gcc/cp/error.c:3108
0x102b889 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/heads/gcc/gcc-source/gcc/diagnostic.c:866
0x102c8a2 internal_error(char const*, ...)
/home/heads/gcc/gcc-source/gcc/diagnostic.c:1223
0x102b1e3 fancy_abort(char const*, int, char const*)
/home/heads/gcc/gcc-source/gcc/diagnostic.c:1291
0x6fedc5 cxx_eval_call_expression
/home/heads/gcc/gcc-source/gcc/cp/constexpr.c:1358
<<<<<<<<<<<

[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2

[hubicka at gcc dot gnu.org]

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

--- Comment #36 from Jan Hubicka  ---
This is probably too risky to fix for 5.1
(https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html) though I am having WIP patch
now - we need to introduce transparent alias support and make lto-symtab to
turn incompatible decls into transparent aliases.

I hope to have patch ready in a week for consideration. Chromium is using
fortify, so it would be nice to fix this.

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[boger at us dot ibm.com]

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

--- Comment #4 from boger at us dot ibm.com ---
Do you mean as if submitting to gofrontend-dev?

[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level

[law at redhat dot com]

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

--- Comment #24 from Jeffrey A. Law  ---
Integrating uncprop and out-of-ssa certainly crossed my mind when I wrote that
comment :-)  Or at least arranging to build the life info/conflict stuff once
and have it shared.

A poor man's version is to note the path for the equivalence and see if any of
the blocks on that path define the other PHI arguments.  That ought to be fast
and simple enough to possibly include in gcc5.

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
Can you send the libgo part of this patch through the codereview site?

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[boger at us dot ibm.com]

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

--- Comment #2 from boger at us dot ibm.com ---
Created attachment 35081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35081&action=edit
Updated patch to add unsafe to the list of std package names

[Bug preprocessor/65481] _Pragma GCC dependency broken on powerpc64

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Never mind. It does work correctly. The t.c mtime of

  2015-03-19 19:54:40.448639710 -0400

clearly is before the t.h mtime of

  2015-03-19 19:56:02.508682213 -0400

I reversed the order of the two files in the test case. Doh!

(It would be nice to change the test so as not to depend on the timestamps of
the sources but instead create a couple of headers of its own, one older than
the other, and use those instead. That way it could reliably verify that the
pragma works both ways.)

[Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling

[linux at carewolf dot com]

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

--- Comment #8 from Allan Jensen  ---
You can remove the branches in the inner loop and still reproduce the issue.
There were no branches in the original code, I only added them to the reduced
case because I was using a smaller lookup table.

I appears after removing the branches, the execution time with and without
-fno-tree-vectorize on -O3 is the same. So they also cause some issue, but is
the main one.

[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Any updates on this bug report?

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 35080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35080&action=edit
parloops dump with -ftry

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 35079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35079&action=edit
parloops dump with -fno-try

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35078&action=edit
WIP patch

WIP patch, works on included testcase only.

[Bug ipa/65478] [5 regression] crafty performance regression

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
Thre regression seems to be visible at
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-ai-64/186_crafty_big.png

[Bug target/61977] powerpc-eabi preprocessor breaks on lines that end with "vector"

[drivshin at allworx dot com]

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

David Rivshin  changed:

   What|Removed |Added

 Target||powerpc-eabi
  Known to work||4.9.0
  Known to fail||4.9.1, 4.9.2

--- Comment #1 from David Rivshin  ---
This is still happening in the latest trunk and latest 4.9 branch code.

Simplified steps to reproduce:
../gcc.svn/configure --prefix=${PWD}/../local --enable-languages=c
--with-gnu-as --with-gnu-ld --disable-libstdcxx-pch --target=powerpc-eabi
--disable-shared --with-newlib
make all-gcc
make install-gcc
echo -e "# comment ending in vector" | ../local/bin/powerpc-eabi-cpp -x
assembler-with-cpp


I'm fairly certain this is the same root cause as bug 51654, and changeset
r210055 just exposed some non-altivec powerpc targets to it. In addition to the
workarounds mentioned there (bug 51654, comment 3), removing the call to
init_vector_keywords() in rs6000_cpu_cpp_builtins() also works. 

Since those vector keywords only have effect if TARGET_ALTIVEC (see
rs6000_macro_to_expand()), making their definition conditional upon
TARGET_ALTIVEC resolves the 4.9.1 regression (as best I can tell). Although
that obviously does not resolve the underlying issue, which has existed since
at least 4.6 (according to bug 51654).

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Fri Mar 20 18:19:18 2015
New Revision: 221542

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

PR ipa/65475
* ipa-devirt.c (add_type_duplicate): Prevail polymorphic type over
non-polymorphic
* g++.dg/lto/pr65475_0.C: New testcase.
* g++.dg/lto/pr65475_1.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr65475_0.C
trunk/gcc/testsuite/g++.dg/lto/pr65475_1.C
Modified:
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
Hmm, yeah, in one unit base is virutal and in other it is not.  Perhaps just
dropping
that sanity check or restricting it to non-odr-violation-reported

Honza

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
> 
> --- Comment #4 from Martin Liška  ---
> Unfortunately, there is another problem with applied patch:
> 
> $ cat 1.ii
> namespace std {
> class exception {};
> class runtime_error : exception {
>   virtual char m_fn1();
> } a;
> }
> 
> $ cat 2.ii
> namespace std {
> class exception {
>   virtual char m_fn1();
> };
> class runtime_error : exception {
> } a;
> }
> 
> $ g++ 1.ii 2.ii -flto -O1
> /home/marxin/Programming/bin/gcc/bin/ld: error: /tmp/cc7v39VO.o: multiple
> definition of 'std::a'
> /home/marxin/Programming/bin/gcc/bin/ld: /tmp/ccJ8pPM4.o: previous definition
> here
> 2.ii:2:7: warning: type ???struct exception??? violates one definition rule 
> [-Wodr]
>  class exception {
>^
> 1.ii:2:7: note: a type with different virtual table pointers is defined in
> another translation unit
>  class exception {};
>^
> 2.ii:2:7: warning: type ???struct exception??? violates one definition rule 
> [-Wodr]
>  class exception {
>^
> 1.ii:2:7: note: a type with different bases is defined in another translation
> unit
>  class exception {};
>^
> 1.ii:3:7: warning: type ???struct runtime_error??? violates one definition 
> rule
> [-Wodr]
>  class runtime_error : exception {
>^
> 2.ii:5:7: note: a type with different virtual table pointers is defined in
> another translation unit
>  class runtime_error : exception {
>^
> lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1575
> 0x77c43c add_type_duplicate
> ../../gcc/ipa-devirt.c:1573
> 0x77c43c get_odr_type(tree_node*, bool)
> ../../gcc/ipa-devirt.c:1772
> 0x77d25c register_odr_type(tree_node*)
> ../../gcc/ipa-devirt.c:1848
> 0x5b43d6 lto_read_decls
> ../../gcc/lto/lto.c:1946
> 0x5b4d7b lto_file_finalize
> ../../gcc/lto/lto.c:2236
> 0x5b4d7b lto_create_files_from_ids
> ../../gcc/lto/lto.c:2246
> 0x5b4d7b lto_file_read
> ../../gcc/lto/lto.c:2287
> 0x5b4d7b read_cgraph_and_symbols
> ../../gcc/lto/lto.c:2992
> 0x5b4d7b lto_main()
> ../../gcc/lto/lto.c:3462
> 
> 
> Thanks,
> Martin
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
> 
> Richard Biener  changed:
> 
>What|Removed |Added
> 
>  CC||hubicka at gcc dot gnu.org
> 
> --- Comment #6 from Richard Biener  ---
> --param max-peel-branches default of 32 seems to be quite high.  For this
> loop we have two branches on the hot path and 4 times unrolling.
> 
> Honza - how did you arrive at the default of 32?  Shouldn't that depend
> on the number of other stmts thus rather look at branch density?

In https://gcc.gnu.org/ml/gcc-patches/2012-10/msg02716.html I claim value
around 32 is needed for apply. (not that I would recall that)

I do not have really strong opinion concerning the branch density.

Honza

[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> Testcase?  I suppose you are talking about the loops in the bsNEEDR/W macros?
bzip2 is quite small by itself, but I will take a look later today. Yes, it is
bsNEEDR/W macros
that gets unrolled.

Honza

[Bug ipa/65478] [5 regression] crafty performance regression

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  ---
> Which options (LTO?)?  I can't see the regression on our testers.
-Ofast -flto -funroll-loops

Honza

[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-20
   Target Milestone|--- |5.0
Summary|ICE in  |[5 Regression] ICE in
   |cxx_eval_call_expression|cxx_eval_call_expression
   |when using __func__ inside  |when using __func__ inside
   |dependent context   |dependent context
 Ever confirmed|0   |1

--- Comment #2 from Paolo Carlini  ---
Confirmed.

[Bug c++/65498] ICE in cxx_eval_call_expression when using __func__ inside dependent context

[ldionne.2 at gmail dot com]

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

--- Comment #1 from Louis Dionne  ---
Apologies; the lines of the example run were wrapped and it's unreadable from
here. Here's what it looks like:

https://gist.github.com/ldionne/054e276caf90f16e3223

[Bug libstdc++/65499] New: Missing "using namespace literals::chrono_literals" in std::chrono

[marejde at gmail dot com]

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

Bug ID: 65499
   Summary: Missing "using namespace literals::chrono_literals" in
std::chrono
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marejde at gmail dot com

Reading http://en.cppreference.com/w/cpp/chrono/operator%22%22min (sorry, I do
not have the spec readily available) it says:

"In addition, within the namespace std::chrono, the directive using namespace
literals::chrono_literals; is provided by the standard library, so that if a
programmer uses using namespace std::chrono; to gain access to the duration
classes, the duration literal operators become visible as well."

The following program:

#include 
#include 

int main(void)
{
using namespace std::chrono;
minutes min = 36min;
return 0;
}

Does not compile with GCC 4.9.2 while it does with Clang 3.6.

Looking at GCC trunk as of today I do not see a "using namespace
literals::chrono_literals;" anywhere in libstdc++-v3/include/ . Clang's libc++
has it in the chrono namespace though.

Would be great if this could be fixed before GCC 5.0 is released so I don't
have to sprinkle "using namespace literals::chrono_literals;" in my code to be
able to compile with GCC.

[Bug c++/65498] New: ICE in cxx_eval_call_expression when using __func__ inside dependent context

[ldionne.2 at gmail dot com]

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

Bug ID: 65498
   Summary: ICE in cxx_eval_call_expression when using __func__
inside dependent context
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com

The following code triggers an ICE on GCC trunk:
--
#include 

struct T;

template 
struct F { };

template 
struct F{}()>> {
template 
F(MakeDependent) {
auto ICE_HERE = __func__;
(void)ICE_HERE; // avoid -Wunused-variable
}
};

int main() {
F{1};
}
--


Example run:
--
› ~/code/gcc5/bin/g++ -std=c++1y ~/code/hana/test/worksheet.cpp
/Users/ldionne/code/hana/test/worksheet.cpp: In substitution of ‘template using enable_if_t = typename std::enable_if::type [with bool
_Cond = std::is_same{}(); _Tp = void]’:
/Users/ldionne/code/hana/test/worksheet.cpp:1411:25:   required from here
/Users/ldionne/code/hana/test/worksheet.cpp:1408:50:   in constexpr expansion
of ‘((std::integral_constant*)(& std::is_same()))->std::integral_constant<_Tp, __v>::operator()()’
/Users/ldionne/code/hana/test/worksheet.cpp:1411:25: internal compiler error:
in cxx_eval_call_expression, at cp/constexpr.c:1358
 auto ICE_HERE = __func__;
 ^

/Users/ldionne/code/hana/test/worksheet.cpp:1411:25: internal compiler error:
Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--

Note that using 

std::is_same::value

instead of 

std::is_same{}()

seems to fix the issue.


Regards,
Louis Dionne

[Bug c++/52963] Missing error on pack expansion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
In fact 4.8.0 too works fine for me.

[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
And the problem is that with these weirdo scheduling options the scheduler
schedules the
(insn/f:TI 620 60 37 2 (set (reg:DI 39 r10)
(plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))) pr65496.c:3 214 {*leadi}
 (nil))
instruction before the shrink-wrapping conditional jump:
(jump_insn:TI 38 45 43 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 645)
(pc))) pr65496.c:4 613 {*jcc_1}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 900 (nil)))
 -> 645)
At the end of the function we have:
(insn/f:TI 641 640 645 40 (set (reg/f:DI 7 sp)
(plus:DI (reg:DI 39 r10)
(const_int -8 [0xfff8]))) pr65496.c:6 214 {*leadi}
 (expr_list:REG_DEAD (reg:DI 39 r10)
(expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8]))
(nil
(code_label 645 641 644 41 106 "" [1 uses])
(note 644 645 663 41 [bb 41] NOTE_INSN_BASIC_BLOCK)
(jump_insn 663 644 643 41 (parallel [
(simple_return)
(unspec [
(const_int 0 [0])
] UNSPEC_REP)
]) pr65496.c:6 682 {simple_return_internal_long}
 (nil))
(barrier 643 663 355)

And the problem is that because the r10 = rsp + 8 frame related instruction is
moved before the shrink-wrapping jump we assume CFA is in r10 + 0, but before
fallthru into the return we have a CFA restore note to use r8 + 8 again as CFA
(not really needed in this case, but desirable for the case when the r10 = rsp
+ 8 instruction isn't moved.

Richard, any thoughts what to do about this?  Avoid scheduling frame related
instructions across conditional jumps?  Something else?

[Bug rtl-optimization/64366] Segmentation fault in remove_pseudos

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 20 17:43:48 2015
New Revision: 221541

URL: https://gcc.gnu.org/viewcvs?rev=221541&root=gcc&view=rev
Log:
2015-03-20  Vladimir Makarov  

PR rtl-optimization/64366
* lra.c (lra_update_insn_regno_info): Consider regs in
CALL_INSN_FUNCTION_USAGE memory.

2015-03-20  Vladimir Makarov  

PR rtl-optimization/64366
* gcc.target/sh/pr64366.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr64366.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51817] [C++11] argument deduction fails when A-type parameter-type-list has additional parameters

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  ---
I think this is the expected behavior. Note that current clang and EDG behave
exactly the same, reject the testcase with an error at line 12.

Maybe Jason can help me completing the triage of this?

[Bug target/65496] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-20
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r217331.  Not really a regression, as GCC 4.9 doesn't have
-mavx512dq support.

[Bug c++/48324] [C++0x] constexpr evaluation should respect lifetime rules

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

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

[Bug c++/48324] [C++0x] constexpr evaluation should respect lifetime rules

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Mar 20 17:26:32 2015
New Revision: 221539

URL: https://gcc.gnu.org/viewcvs?rev=221539&root=gcc&view=rev
Log:
2015-03-20  Paolo Carlini  

PR c++/48324
* g++.dg/cpp0x/constexpr-48324.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/65345] ICE with _Generic selection on _Atomic int

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
A note to myself: address the TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementations:
.

[Bug c++/48324] [C++0x] constexpr evaluation should respect lifetime rules

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Please.

[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
vect_build_slp_tree apparently has code to handle (limited number) of
permutations for commutative operands, but even if I bump the && *npermutes < 4
test to && *npermutes < 32, for some reason we still don't handle it (but only
retry 7 times, so don't run into this increased limit).

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #11 from Paolo Carlini  ---
Done.

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Fri Mar 20 17:06:18 2015
New Revision: 221537

URL: https://gcc.gnu.org/viewcvs?rev=221537&root=gcc&view=rev
Log:
2015-03-20  Paolo Carlini  

PR c++/48453
* g++.dg/cpp0x/pr48453.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr48453.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/65497] Call to member function template named the same as class template is rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Same issue, really.

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

[Bug c++/61642] g++ confuses template member template function with template class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||lucdanton at free dot fr

--- Comment #2 from Paolo Carlini  ---
*** Bug 65497 has been marked as a duplicate of this bug. ***

[Bug go/65462] Use of 'go get' with gccgo is not finding dependencies correctly

[boger at us dot ibm.com]

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

--- Comment #1 from boger at us dot ibm.com ---
Created attachment 35077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35077&action=edit
Fix dependencies in go tool for gccgo

The code to determine when to import packages was not quite catching the cases
it should.  It really needs to know what packages are part of the GO standard
packages and not try to load those -- if they aren't then they should be
loaded.

This makes a few changes to the previous:
- change the name of reqPkgSrc to reqStdPkgSrc to indicate when we should
require the source for GO standard packages when loading packages.
- generate the list of standard packages found in libgo and make that available
to build into the go tool
- set the flag Standard in the Package structure correctly for gccgo, based on
the list of expected libgo standard packages
- use the reqStdPkgSrc flag and the package.Standard flag to determine if the
load of the package should be attempted

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[daniel.kruegler at googlemail dot com]

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

--- Comment #9 from Daniel Krügler  ---
(In reply to Paolo Carlini from comment #8)
> This is now in C++14. Time to add the testcase and close the bug.
I agree.

[Bug c++/17729] [4.8/4.9/5 Regression] Duplicate __attribute__((deprecated)) warning

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ktietz at gcc dot gnu.org

--- Comment #32 from Kai Tietz  ---
We call function warn_deprecated_use twice within finish_id_expression.  Once
indirectly via mark_used, and the second time directly.  So by checking if
TREE_USED (t) is false this double-warning should be omitted.

Testing right now following patch:

Index: semantics.c
===
--- semantics.c (Revision 221533)
+++ semantics.c (Arbeitskopie)
@@ -3649,7 +3668,7 @@ finish_id_expression (tree id_expression,

   /* Handle references (c++/56130).  */
   tree t = REFERENCE_REF_P (decl) ? TREE_OPERAND (decl, 0) : decl;
-  if (TREE_DEPRECATED (t))
+  if (TREE_DEPRECATED (t) && !TREE_USED (t))
 warn_deprecated_use (t, NULL_TREE);

   return decl;

[Bug c++/48453] [C++0x] [DR 1287] Invalid reference initialization via explicit conversion

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #8 from Paolo Carlini  ---
This is now in C++14. Time to add the testcase and close the bug.

[Bug c++/48324] [C++0x] constexpr evaluation should respect lifetime rules

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #1 from Paolo Carlini  ---
I suppose we can close this as fixed: we warn about returning a reference to a
temporary at line 9 and then we error out at line 12 about the size not being
an integral constant expression. Likewise clang.

Jason, shall I add the testcase and close the bug?

[Bug c++/47765] [Core/1391] Wrong template deduction

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

[Bug c++/65497] New: Call to member function template named the same as class template is rejected

[lucdanton at free dot fr]

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

Bug ID: 65497
   Summary: Call to member function template named the same as
class template is rejected
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

Created attachment 35076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35076&action=edit
Minimal testcase

$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20150319 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat main.cpp
template struct foo {};

template
struct bar {
template void foo() const {}
};

template
void qux(bar b)
{ b.template foo(); }

int main()
{
bar b;
qux(b);
}
$ g++-trunk -std=c++03 main.cpp
main.cpp: In function 'void qux(bar)':
main.cpp:10:5: error: invalid use of 'struct foo'
 { b.template foo(); }
 ^

-

I would expect the code to compile as-is (in all C++03/11/1y/1z modes). In any
case, Clang does accept it. At the very least the error message seems bogus.

[Bug target/65496] New: ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318 with -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0

[zsojka at seznam dot cz]

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

Bug ID: 65496
   Summary: ICE: in maybe_record_trace_start, at dwarf2cfi.c:2318
with -O3 -fsched2-use-superblocks -mavx512dq
--param=max-pending-list-length=0
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 35075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35075&action=edit
reduced testcase

Compiler output:
$ gcc -O3 -fsched2-use-superblocks -mavx512dq --param=max-pending-list-length=0
testcase.c 
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2318
 }
 ^
0x8843d0 maybe_record_trace_start
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2318
0x885348 scan_trace
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2496
0x885c9a create_cfi_notes
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2650
0x885c9a execute_dwarf2_frame
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:3006
0x885c9a execute
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:3486
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.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 5.0.0 20150320 (experimental) (GCC) 

Tested revisions:
r221530 - ICE

[Bug tree-optimization/65494] [5 Regression] Loop is not vectorized because of operand canonicalization.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[5.0 Regression] Loop is|[5 Regression] Loop is not
   |not vectorized because of   |vectorized because of
   |operand canonicalization.   |operand canonicalization.

[Bug tree-optimization/65494] [5.0 Regression] Loop is not vectorized because of operand canonicalization.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-20
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug target/65495] New: ICE: chkp_make_addressed_object_bounds: Unexpected tree code const_decl with -fcheck-pointer-bounds -mmpx and fortran

[zsojka at seznam dot cz]

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

Bug ID: 65495
   Summary: ICE: chkp_make_addressed_object_bounds: Unexpected
tree code const_decl with -fcheck-pointer-bounds -mmpx
and fortran
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 35074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35074&action=edit
reduced testcase

Compiler output:
$ gcc -fcheck-pointer-bounds -mmpx testcase.f90 
testcase.f90:2:0:

   END
 ^
internal compiler error: chkp_make_addressed_object_bounds: Unexpected tree
code const_decl
0xd6d7c6 chkp_make_addressed_object_bounds
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:3384
0xd6ac4e chkp_find_bounds_1
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:3517
0xd6fae6 chkp_find_bounds
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:3555
0xd6fae6 chkp_add_bounds_to_call_stmt
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:1814
0xd6fae6 chkp_instrument_function
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:4139
0xd6fae6 chkp_execute
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:4323
0xd6fae6 execute
/mnt/svn/gcc-trunk/gcc/tree-chkp.c:4380
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.

It seems almost any fortran code triggers this ICE.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-221530-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 5.0.0 20150320 (experimental) (GCC) 

Tested revisions:
r221530 - ICE

[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 35073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35073&action=edit
WIP patch

So, on top of what you've committed, here is my unfinished attempt to disable
for __bos undesirable transformations.  On the:
int
main ()
{
  struct A { char buf1[9]; char buf2[1]; } a;
  char *p = a.buf1;
  char *q = p + 1;
  char *r = q + 4;
  char *t = r - 1;
  strcpy (t, str1 + 5);
  return 0;
}
main of this PRs testcase, the match.pd snippet doesn't work (genmatch thinks
ADDR_EXPR operand must be a SSA_NAME, where that is not valid gimple), we end
up with
  q_2 = &a.buf1 + 1;
  t_4 = &MEM[(void *)q_2 + 3B];
which would be better expressed as
  t_4 = &a.buf1 + 4;
and then FRE folds that into:
  t_4 = &MEM[(void *)&a + 4B];
so if we went this way, we'd need to change genmatch to handle ADDR_EXPRs
specially, and FRE to avoid forwarding into &MEM if that would lose info.

Or, as discussed on IRC we can consider MEM_REFs where first operand isn't just
SSA_NAME or ADDR_EXPR of a decl, but allow also ADDR_EXPR of
handled_component_p (with base being a decl or MEM_REF with SSA_NAME first
operand).

Or add a new tree code, like OFFSETTED_ADDR_EXPR which would be like ADDR_EXPR,
but with integer offset address to the ADDR_EXPR.

[Bug c++/65072] Segfault when parsing dectlype in trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Fixed.

[Bug c++/65072] Segfault when parsing dectlype in trailing return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar 20 14:56:53 2015
New Revision: 221535

URL: https://gcc.gnu.org/viewcvs?rev=221535&root=gcc&view=rev
Log:
PR c++/65072
* typeck.c (lookup_anon_field): Make sure we're dealing with the main
variant.

* g++.dg/cpp0x/pr65072.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr65072.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/65494] [5.0 Regression] Loop is not vectorized because of operand canonicalization.

[ysrumyan at gmail dot com]

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

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

The following options are used to reproduce:  -Ofast -funroll-loops

[Bug target/65459] SLOW_UNALIGNED_ACCESS unconditionally set to 1 for ARM targets

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to ktkachov from comment #2)
> FWIU ARMv6 and later supports unaligned accesses.
> I guess the performance of unaligned accesses differs between cores.
> The documentation for SLOW_UNALIGNED_ACCESS says:
> "Define this macro to be the value 1 if memory accesses described by the
> @var{mode} and @var{alignment} parameters have a cost many times greater
> than aligned accesses, for example if they are emulated in a trap
> handler."
> 
> It seems to me that on some modern cores even if unaligned access is more
> expensive than normal it wouldn't be 'many times greater' so we should
> definitely investigate setting this in a more intelligent way.

(In reply to ktkachov from comment #2)
> FWIU ARMv6 and later supports unaligned accesses.
> I guess the performance of unaligned accesses differs between cores.
> The documentation for SLOW_UNALIGNED_ACCESS says:
> "Define this macro to be the value 1 if memory accesses described by the
> @var{mode} and @var{alignment} parameters have a cost many times greater
> than aligned accesses, for example if they are emulated in a trap
> handler."
> 
> It seems to me that on some modern cores even if unaligned access is more
> expensive than normal it wouldn't be 'many times greater' so we should
> definitely investigate setting this in a more intelligent way.

It is designed this way for a reason. It's not a bug.

On the ARM architecture only the ldr and vld1.8 instructions can handle
unaligned accesses (not aligned to element size). Most of the other
instructions would trap on unaligned access i.e. vldr / vldm / ldrd / ldm. 

So you could get some "so-called" benefit by turning off alignment checking and
then have the world start trapping left right and centre because you've allowed
a free for all without any alignment checks. So, then you might ask what
happens if SLOW_UNALIGNED_ACCESS was true for FP and Vector style operations
and we disable this for SImode values.

The counter against that is well,

1. It is possible (though very unlikely) for SImode values to be in FP
registers when someone needs to do fp conversions. So you've now got a problem
where a type punned case goes into a vldr instruction and then you've now got
an unaligned access which will trap with the vldr instruction. Getting the
phase ordering right in the compiler to prevent something like this will be
interesting.


2. If we set SLOW_UNALIGNED_ACCESS for SImode values to 0, we'd have a
situation where the mid-end was free to spit out

(set (reg) (mem)) style instructions to deal with this.

and then we have all the other work done in ldm / ldrd generation which start
throwing up alignment faults that need to be trapped in the kernel. So by lying
to the compiler that these aren't slow, we never make them fast ! So, if you
wanted to make this change, you also need to prevent ldm / stm and ldrd / strd
instructions from appearing in the code stream for unaligned access and I'm not
sure if we can achieve that purely on memory alignment information from the
compiler i.e. you need to validate that MEM_ALIGN information is sane and
doesn't cause additional alignment faults in larger programs.

[Bug tree-optimization/65494] New: [5.0 Regression] Loop is not vectorized because of operand canonicalization.

[ysrumyan at gmail dot com]

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

Bug ID: 65494
   Summary: [5.0 Regression] Loop is not vectorized because of
operand canonicalization.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

5.0 compiler is not vectorized simple loop extracted from geekbench but 4.9
compiler does. This is caused by different operand ordering after loop
unrolling (I pointed out essential part of tree):
4.9  5.0
_105=_86+_1  _105=_86+_1
_109=_90+_63 _109=_63+_90
_21=_6+_82   _21=_6+_82

Test-case is attached.

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
--param max-peel-branches default of 32 seems to be quite high.  For this
loop we have two branches on the hot path and 4 times unrolling.

Honza - how did you arrive at the default of 32?  Shouldn't that depend
on the number of other stmts thus rather look at branch density?

Similarly late unrolling should take conditional stmts (COND_EXPR rhs_code)
into account?

Especially as we don't really estimate anything to become constant after
unrolling.

[Bug c/65493] bug with 64/32 division sign related to various factors (-O3)

[ml-gnubugzilla at worldspot dot net]

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

sophana  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from sophana  ---
Thanks for your answer.

I made some tests. You are right, it is the addition overflow that causes the
wrong result on all the next divisions:

Looking deeper, I just learnt that (signed) integer overflow cause undefined
behaviour (and not with unsigned)

The overflow bit is raised in the hardware and changes the behaviour of signed
division, and the division behaviour in case of overflow is also undefined.

I still can't explain why this behaviour disapears when:
- removing the noinline attribute
- change the for loop:
  for(nElem=4;nElem>0;nElem-=1) {
 instead of
  for(;nElem>0;nElem-=1) {
- there are 2 identical blocks in the loop. removing one gives a good result!

I changed the loop arguments which shows that the division is not stateless
(because of the overflow bit)

int main(){
xLoop16(
0x4337d8cLL
,0x233dcbc8LL
,-0x048974b0L
,0x18235a18L
,4
);
}


$ gcc test.c -O1 && ./a.out
>>4337d8c/db768b50 = e291 
>>433a0c9cbc8/fd76e568 = fffe57c9 
>>433c4079790/1f773f80 = 2230 
>>433e7456358/41779998 = 106f 
>>4340a832f20/6377f3b0 = 0ad1 
>>4342dc0fae8/85784dc8 = f738 
>>43450fec6b0/a778a7e0 = f3d8 
>>434743c9278/c97901f8 = ec43 
[skok@power4 ~]$ gcc test.c -O3 && ./a.out
>>4337d8c/db768b50 = e291 
>>433a0c9cbc8/fd76e568 = fffe57c9 
>>433c4079790/1f773f80 = 2230 
>>433e7456358/41779998 = 106f 
>>4340a832f20/6377f3b0 = 0ad1 
>>4342dc0fae8/85784dc8 = 0810 
>>43450fec6b0/a778a7e0 = 066d 
>>434743c9278/c97901f8 = 0557 

Only the last 3 divisions become unsigned after the overflow occurs.

Sorry for the invalid bug

[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
module A

Type T
character(LEN=:), allocatable :: S
end type
character(len=6), parameter :: str = 'string'
Type(T) :: TestObj = T(str)

end module

is rejected with

 Type(T) :: TestObj = T(str)
   1
Error: Invalid initialization expression for ALLOCATABLE component 's' in
structure constructor at (1)

So it seems that

>  (a) an allocatable component is a reference to the intrinsic function 
> NULL,

has to be taken in the most restrictive way.

If nobody objects, I'll close the PR as FIXED again.

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Pish, those adds shouldn't be the least bit relevant.  I'll have a look.

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Unrolling of the inner loop accounts for the rest (both conditional moves
with if-conversion applied and the branchy code if not seems to put a too
heavy load on the branch predictor(?) when inside another loop).

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-20
Version|unknown |5.0
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Part of it is if-conversion enabled at -O3 (-fno-tree-loop-if-convert), but
then -O2 is still ~20% faster.

Confirmed.

Not sure if really caused by intrinsics.

[Bug c/65493] bug with 64/32 division sign related to various factors (-O3)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
In such cases you should compile your testcase with -fsanitize=undefined:

foo.c:23:5: runtime error: signed integer overflow: 2091699912 + 136534552
cannot be represented in type 'int'

[Bug c/65493] bug with 64/32 division sign related to various factors (-O3)

[ml-gnubugzilla at worldspot dot net]

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

--- Comment #1 from sophana  ---
Forgot to say that the result is the same on all tested gcc versions on various
targets. All work with -O1 and not with -O3

[Bug c/65493] New: bug with 64/32 division sign related to various factors (-O3)

[ml-gnubugzilla at worldspot dot net]

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

Bug ID: 65493
   Summary: bug with 64/32 division sign related to various
factors (-O3)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ml-gnubugzilla at worldspot dot net

Hi

Problem with a 64bit/32bit signed division with -O3 and various factors.

I found this weirg bug when using -O3 on various gcc versions.

platform: redhat el6.5 x84_64
tested gcc versions:
4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) target x86: 32 and 64bit (-m32 and -m64)
4.9.0 self compiled, target x86 32 and 64bit
4.8.0 self compiled, target sparc


the code:

#
#include
#include


void __attribute__ ((noinline)) xLoop16(
int64_t h
, int64_t hInc
,int32_t l
,int32_t lInc
,int nElem
){
for(;nElem>0;nElem-=1) {
{
int32_t x=h/l;
printf(">>%08llx/%08x = %08x \n",h,l,x);
h+=hInc;
l+=lInc;
}
{
int32_t x=h/l;
printf(">>%08llx/%08x = %08x \n",h,l,x);
h+=hInc;
l+=lInc;
}
}
}
int main(){
xLoop16(
0x4337d8cLL
,0x233dcbc8LL
,0x748974b0L
,0x08235a18L
,4
);
}


The good result:

$ gcc test.c -O1  && ./a.out
>>4337d8c/748974b0 = 093a 
>>433a0c9cbc8/7caccec8 = 08a0 
>>433c4079790/84d028e0 = f745 
>>433e7456358/8cf382f8 = f6a6 
>>4340a832f20/9516dd10 = f5f0 
>>4342dc0fae8/9d3a3728 = f51b 
>>43450fec6b0/a55d9140 = f420 
>>434743c9278/ad80eb58 = f2f4 

The bad result: the division result is always positive, it has become an
unsigned division:
$ gcc test.c -O3  && ./a.out
>>4337d8c/748974b0 = 093a 
>>433a0c9cbc8/7caccec8 = 08a0 
>>433c4079790/84d028e0 = 0819 
>>433e7456358/8cf382f8 = 07a2 
>>4340a832f20/9516dd10 = 0737 
>>4342dc0fae8/9d3a3728 = 06d8 
>>43450fec6b0/a55d9140 = 0682 
>>434743c9278/ad80eb58 = 0634 


What changes the result to the good one:
- removing the noinline attribute
- change the for loop:
  for(nElem=4;nElem>0;nElem-=1) {
 instead of
  for(;nElem>0;nElem-=1) {
- there are 2 identical blocks in the loop. removing one gives a good result!

[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)

[vehre at gcc dot gnu.org]

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

--- Comment #7 from vehre at gcc dot gnu.org ---
First sentence of F2008, 7.1.12 is:

   A constant expression is an expression with limitations that make it 
   suitable for use as a kind type parameter, *initializer*, or named 
   constant. It is an expression in which each operation is intrinsic,
   and each primary is ...

With Type(T) :: TestObj = T(...) the T after the assign becomes an initializer,
which 7.1.12 states only constant expressions are suitable for. In this
constant expression each structure constructor has to adhere to the conditions
of (3):

   a structure constructor where each component-spec corresponding to
 (a) an allocatable component is a reference to the intrinsic function
NULL,
 (b) ...

Now that S is an allocatable component of T. I think this the only valid
expression for that is NULL() as initializer. This is what gfortran does
currently and this is how I interpret the standard.

Btw, cosmomc compiles fine, so it can't be using this specific construct.

[Bug target/65459] SLOW_UNALIGNED_ACCESS unconditionally set to 1 for ARM targets

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |renlin at gcc dot 
gnu.org

--- Comment #3 from renlin at gcc dot gnu.org ---
confirmed and assign it to myself

[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Mar 20 12:39:32 2015
New Revision: 221532

URL: https://gcc.gnu.org/viewcvs?rev=221532&root=gcc&view=rev
Log:
2015-03-20  Richard Biener  

PR middle-end/64715
* tree-chrec.c (chrec_fold_poly_cst): Use useless_type_conversion_p
for type comparison and gcc_checking_assert.
(chrec_fold_plus_poly_poly): Likewise.
(chrec_fold_multiply_poly_poly): Likewise.
(chrec_convert_1): Likewise.
* gimplify.c (gimplify_expr): Remove premature folding of
&X + CST to &MEM[&X, CST].

* gcc.dg/pr15347.c: Use -O.
* c-c++-common/pr19807-1.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr19807-1.c
trunk/gcc/testsuite/gcc.dg/pr15347.c
trunk/gcc/tree-chrec.c

[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)

[antony at cosmologist dot info]

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

--- Comment #6 from Antony Lewis  ---
Not sure about that - 7.1.12 of 2008 is about constants, but in the example the
type instance is not a constant? The example is fine in ifort (and used in
cosmomc?).

Antony

> -Original Message-
> From: vehre at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org]
> Sent: 20 March 2015 11:59 AM
> To: ant...@cosmologist.info
> Subject: [Bug fortran/61275] Invalid initialization expression for ALLOCATABLE
> component in structure constructor at (1)
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275
> 
> --- Comment #5 from vehre at gcc dot gnu.org ---
> Completely right, the initial test is still not compilable. But this is 
> because
> assigning to an allocatable component in an initializer is not allowed by the
> standards:
> F2003, 7.1.7 (3) and also in
> F2008, 7.1.12 (3).
> 
> So the correct code would be:
> 
> module A
> 
> Type T
> character(LEN=:), allocatable :: S
> end type
> Type(T) :: TestObj = T(NULL())
> 
> TestObj%S = 'string'
> 
> contains
> 
> end module
> 
> which compiles and runs w/o error.
> Standard compliant implementation is tested for in
> 
> gfortran.dg/alloc_comp_init_expr.f03
> 
> only far allocatable arrays, but that's near enough for char arrays for me.
> 
> --
> You are receiving this mail because:
> You reported the bug.

[Bug lto/65239] typeinfo / VTT for some classes not visibile in shared library when LTO is used

[jana at saout dot de]

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

--- Comment #2 from Jana Saout  ---
No, sorry, ignore that last one... my mistake - it's still there.

[Bug lto/65239] typeinfo / VTT for some classes not visibile in shared library when LTO is used

[jana at saout dot de]

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

--- Comment #1 from Jana Saout  ---
Mmmh, the issue disappeared in the gcc of today. (so it was probably fixed
sometime between March 16th and March 20th)

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[linux at carewolf dot com]

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

--- Comment #3 from Allan Jensen  ---
The -O3 regression seems to go back a long way, but has become lesser over
time.

With gcc 4.6 and older it runs at 3.1s with -O3, and still at 1.8s with -O2.

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[linux at carewolf dot com]

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

--- Comment #2 from Allan Jensen  ---
Created attachment 35071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35071&action=edit
vector union test

[Bug tree-optimization/65492] Bad optimization in -O3 on SSE intrinsics

[linux at carewolf dot com]

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

--- Comment #1 from Allan Jensen  ---
Created attachment 35070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35070&action=edit
main

[Bug tree-optimization/65492] New: Bad optimization in -O3 on SSE intrinsics

[linux at carewolf dot com]

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

Bug ID: 65492
   Summary: Bad optimization in -O3 on SSE intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com

After investigating a loop using SSE intrinsics that was significantly faster
in clang than in gcc, I discovered gcc had the same performance as clang in
-O2, and only performed signficantly worse in -O3.

Disabling all the switches mentioned in the documentation as activates by -O3
(or enabling them for -O2), doesn't fully account for the difference, but the
switch -f(no-)tree-loop-vectorize accounts for roughly half of it.

I have attached the files I used to test it. Using gcc -O2 or clang -O2 or -O3,
it times in at 1.8s on my machine. Using g++ (4.9 or 5.0) -O3 it times in at
2.5s. Using -O3 -fno-tree-loop-vectorize it runs in 2.3s, and -O2
-ftree-vectorize at 2.25s.

Using callgrind, it seems the performance difference is mainly spend on the
accessing integers in the vector union.

[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)

[vehre at gcc dot gnu.org]

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

--- Comment #5 from vehre at gcc dot gnu.org ---
Completely right, the initial test is still not compilable. But this is because
assigning to an allocatable component in an initializer is not allowed by the
standards:
F2003, 7.1.7 (3) and also in
F2008, 7.1.12 (3).

So the correct code would be:

module A

Type T
character(LEN=:), allocatable :: S
end type
Type(T) :: TestObj = T(NULL())

TestObj%S = 'string'

contains

end module

which compiles and runs w/o error.
Standard compliant implementation is tested for in 

gfortran.dg/alloc_comp_init_expr.f03

only far allocatable arrays, but that's near enough for char arrays for me.

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[ktietz at gcc dot gnu.org]

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

--- Comment #9 from Kai Tietz  ---
(In reply to David from comment #8)
> (In reply to Kai Tietz from comment #7)
> The first code block in comment #6 is what is in the code now.  As you can
> see, it already has the #define you are describing.  I don't understand what
> you mean by "change it to" this, since it is already there.
> 
> Are you suggesting we delete the entire #ifdef
> __GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single
> #define? 
Right, this I suggest.

> I would be ok with that.  Using the #error (the second code block
> in comment #6) seemed like a more backward-compatible way to do this, since
> it would tell people what has happened and what to do to fix it rather than
> (silently) assuming we know what they want to do.

If a target doesn't provide the Interlocked-API, build with fail caused by it. 
I don't think we need to error out on such cases.  (We don't try to cover win
3.14 incompatibilities, so why we should start for Windows 9X?)

> But I am ok with either of these two solutions.

[Bug c++/65072] Segfault when parsing dectlype in trailing return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #10)
> Actually, sorry for the error, it really started with r151529.

Thanks -- I think I have a fix now.