[Bug driver/62290] New: --print-file-name doesn't work for liblto_plugin.so

[amker.cheng at gmail dot com]

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

Bug ID: 62290
   Summary: --print-file-name doesn't work for liblto_plugin.so
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker.cheng at gmail dot com

At least with revision@214413, gcc configured with below options on x86_64.
$ ../gcc/configure --prefix=../target/
--enable-languages=c,c++,ada,fortran,java,objc,obj-c++,go

Option --print-file-name=liblto_plugin.so doesn't work for installed GCC.

$ ./gcc -print-file-name=liblto_plugin.so
liblto_plugin.so

The file is installed into
./libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/liblto_plugin.so, but gcc's search
dir for libraries are like below (formatted for easy reading's sake).

./gcc --print-search-dirs

libraries: =
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/
:../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-unknown-linux-gnu/5.0.0/:
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/x86_64-linux-gnu/:
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/../lib64/:
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../x86_64-unknown-linux-gnu/5.0.0/:
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../x86_64-linux-gnu/:
../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../lib64/
:/lib/x86_64-unknown-linux-gnu/5.0.0/
:/lib/x86_64-linux-gnu/
:/lib/../lib64/
:/usr/lib/x86_64-unknown-linux-gnu/5.0.0/
:/usr/lib/x86_64-linux-gnu/
:/usr/lib/../lib64/
:../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/lib/
:../target/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../
:/lib/
:/usr/lib/


It happens on arm/aarch64 too.

[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820

[chris2553 at googlemail dot com]

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

--- Comment #3 from Chris Clayton  ---
Yes, the preprocessed file is the one providing the unresolved references.

It surely won't be a surprise to anyone to here that the same failure occurs
when building with yesterday's 4.9 snapshot 4.9-20140827.

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

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 27 Aug 2014, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
> 
> --- Comment #7 from Jan Hubicka  ---
> > Honza, did you get anything working?
> Sorry, I am at Mountain trip till 6th of September, so I do not have much
> chance to hack.  Will take it as priority afterwards.  I think cleanest
> approach would be to lower these calls into sequence of warning/error builtin
> and call.

The issue is that we resolve aliases in a bogus way, not warning/error
stuff.

[Bug driver/62290] --print-file-name doesn't work for liblto_plugin.so

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It doesn't find 'cc1' either, use -print-prog-name instead for searching
libexec.

[Bug middle-end/62289] [5 Regression] ICE (segfault) for gfortran.dg/graphite/pr42393.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-28
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Henrik Holst from comment #4)
> Thank you Richard for looking into this issue.
> 
> You probably know already exactly why this bug appeared. I just wanted to
> stress the severity of this issue, and especially for Fortran which is often
> used in "number crunching" applications AND subroutine arguments are passed
> by reference by default.
> 
> The following F2008 code works as expected:
> 
>   subroutine test1(x,y)
>   real x(4),y(4)
>   gamma=3.141593
>   block
> beta=gamma
> y(1)=y(1)+beta*x(1)
> y(2)=y(2)+beta*x(2)
> y(3)=y(3)+beta*x(3)
> y(4)=y(4)+beta*x(4)
>   end block
>   end
> 
> but when `beta=gamma` is replaced with `beta=alpha` it again fails and
> generates scalar code. So I ask: Does this bug force *ALL* computations
> which involves directly or indirectly parameter values to subroutines and
> functions, to be done in scalar? If so, its pretty bad.

For basic-block vectorization?  It depends whether the first use of
the indirect parameter is in the same basic-block that is supposed
to be vectorized or not ...

> Related or not, the following codes also generates scalar code:
> 
>   subroutine test2(x,y)
>   real x(4),y(4)
>   beta=3.141593
>   do i=1,4
> y(i)=y(i)+beta*x(i)
>   end do
>   end

That's because we decide to peel for alignment and then decide the
result is not profitable to vectorize.  With -fno-vect-cost-model
the loop is vectorized (but in an awkward way).  You may want to
file a separate bug about this.

> and
> 
>   subroutine test3(x,y)
>   real x(4),y(4)
>   beta=3.141593
>   y=y+beta*x
>   end

Same issue (add it as another testcase to the new bug).

It is of course pointless to peel for alignment if the remaining loop
will always run less than the vectorization factor.  Versioning for
alignment may still be applied here.

> as well. I can create another bug for this if you think they are unrelated.

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> (In reply to Henrik Holst from comment #4)
> > Thank you Richard for looking into this issue.
> > 
> > You probably know already exactly why this bug appeared. I just wanted to
> > stress the severity of this issue, and especially for Fortran which is often
> > used in "number crunching" applications AND subroutine arguments are passed
> > by reference by default.
> > 
> > The following F2008 code works as expected:
> > 
> >   subroutine test1(x,y)
> >   real x(4),y(4)
> >   gamma=3.141593
> >   block
> > beta=gamma
> > y(1)=y(1)+beta*x(1)
> > y(2)=y(2)+beta*x(2)
> > y(3)=y(3)+beta*x(3)
> > y(4)=y(4)+beta*x(4)
> >   end block
> >   end
> > 
> > but when `beta=gamma` is replaced with `beta=alpha` it again fails and
> > generates scalar code. So I ask: Does this bug force *ALL* computations
> > which involves directly or indirectly parameter values to subroutines and
> > functions, to be done in scalar? If so, its pretty bad.
> 
> For basic-block vectorization?  It depends whether the first use of
> the indirect parameter is in the same basic-block that is supposed
> to be vectorized or not ...
> 
> > Related or not, the following codes also generates scalar code:
> > 
> >   subroutine test2(x,y)
> >   real x(4),y(4)
> >   beta=3.141593
> >   do i=1,4
> > y(i)=y(i)+beta*x(i)
> >   end do
> >   end
> 
> That's because we decide to peel for alignment and then decide the
> result is not profitable to vectorize.  With -fno-vect-cost-model
> the loop is vectorized (but in an awkward way).  You may want to
> file a separate bug about this.
> 
> > and
> > 
> >   subroutine test3(x,y)
> >   real x(4),y(4)
> >   beta=3.141593
> >   y=y+beta*x
> >   end
> 
> Same issue (add it as another testcase to the new bug).
> 
> It is of course pointless to peel for alignment if the remaining loop
> will always run less than the vectorization factor.  Versioning for
> alignment may still be applied here.

I have a simple patch for this.

> > as well. I can create another bug for this if you think they are unrelated.

[Bug libstdc++/61841] broken std::thread on Hurd

[1o5g4r8o at gmail dot com]

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

--- Comment #4 from Gabriele Giacone <1o5g4r8o at gmail dot com> ---
FYI according to [0], Matthias Klose backported [1] but it didn't fix the
issue.
Samuel Thibault did fix it with [2] on libpthread side.
Both needed?

[0] http://patchwork.ozlabs.org/patch/379715/
[1]
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.9/debian/patches/pr61841.diff?revision=7572&view=markup&sortby=date
[2]
http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/cvs-libpthread_std_thread.diff?revision=6243&view=markup&sortby=date

[Bug c++/62282] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[dmitry.petroff at gmail dot com]

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

--- Comment #3 from Dmitry Petrov  ---
Created attachment 33408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33408&action=edit
g++ + gperf bug in action

Guys, I'm software developer myself and I can understand your attitute to
"declare bug as a feature". But please note, that this bug is breaking normal
development with gperf which is also a GNU tool.

In the attached archive try
make => failure in compiling bug++
make CFLAGS=-O => success, inlining happens
make CXX=clang++ => success

You're saying "we've designed this extension and it works as it should". But
why gcc links this successfully, but g++ don't? It looks like either C or C++
compiler bug.

P. S. I'm using gperf to generate code for both C server-side and C++
tools/testcases and such g++ behaviour is really unpleasing when making debug
builds.

[Bug libstdc++/61841] broken std::thread on Hurd

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
The asm solution that Matthias applied to the Debian 4.8 branch should ensure
that libpthread.so gets linked to, and so I would expect the
__gthread_active_p() test that looks for __pthread_key_create to succeed even
without Samuel's change.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||4.2.4
 Resolution|INVALID |---
   Target Milestone|--- |4.8.4
Summary|Undefined reference with|[4.8/4.9/5 Regression]
   |__inline|Undefined reference with
   |__attribute(__gnu_inline__) |__inline
   |with -O0|__attribute(__gnu_inline__)
   ||with -O0
  Known to fail||4.3.6

--- Comment #4 from Richard Biener  ---
(In reply to Andrew Pinski from comment #2)
> Except it is not vague in general, the idea is that there is another
> definition somewhere of test and not just in this translation unit. Since we
> are at -O0, we decide not to inline it and it does not get emitted.

So with C++ 'inline __attribute__((__gnu_inline__))' is equivalent to
'extern inline __attribute__((__gnu_inline__))'?  What's the reason for
that?

It seems it is at least inconsistent with pre-c99 inline semantic?

G++ 4.1 links the test just fine (G++ 4.3 already shows the bad behavior),
but G++ 4.1 also links 'extern inline' fine (but it doesn't inline).

At least it's very old behavior it seeems, but a regression from G++ 4.2
which knows the attribute but correctly preserves the function(?).

Note that the C frontend happily links the testcase as well, preserving
the function.  That's an inconvenient difference between behavior of
C and C++ for an attribute that was introduced to provide backward
compatibility with pre-C99 inline semantics.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Jason?  Joseph?

[Bug tree-optimization/62291] New: PRE uses too much memory and compile-time

[rguenth at gcc dot gnu.org]

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

Bug ID: 62291
   Summary: PRE uses too much memory and compile-time
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
Blocks: 47344

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

For the attached testcase (from GHC) PRE blows up memory and compile-time wise
at -O2, -O2 -fno-tree-pre and -O1 are fine.

Usual suspect is AVAIL_OUT which was only eliminated for FRE.

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 28 13:13:45 2014
New Revision: 214678

URL: https://gcc.gnu.org/viewcvs?rev=214678&root=gcc&view=rev
Log:
2014-08-28  Richard Biener  

PR tree-optimization/62283
* tree-vect-data-refs.c (vect_enhance_data_refs_alignment):
Do not peel loops for alignment where the vector loop likely
doesn't run at least VF times.

* gfortran.dg/vect/pr62283.f: New testcase.
* gcc.dg/tree-ssa/cunroll-5.c: Adjust.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-33.c: Likewise.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c: Likewise.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-33.c: Likewise.
* gcc.dg/vect/vect-33.c: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr62283.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-5.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/i386/costmodel-vect-33.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c
trunk/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-33.c
trunk/gcc/testsuite/gcc.dg/vect/vect-33.c
trunk/gcc/tree-vect-data-refs.c

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
testcases in comment#4 should now work (no need to file a separate bug).

[Bug middle-end/62292] New: [5 Regression] FAIL: (geterrorname|getmethodname) run

[dominiq at lps dot ens.fr]

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

Bug ID: 62292
   Summary: [5 Regression] FAIL: (geterrorname|getmethodname) run
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hjl.tools at gmail dot com, rguenth at gcc dot gnu.org

The libjava tests geterrorname and getmethodname have started to fail between
revisions r214571 (OK) and r214574, see e.g.
https://gcc.gnu.org/ml/gcc-regression/2014-08/msg00353.html. This likely due to
r214574.

[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-08-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, mine.

[Bug c++/62293] New: Obsure error message

[skvadrik at gmail dot com]

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

Bug ID: 62293
   Summary: Obsure error message
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skvadrik at gmail dot com

Created attachment 33410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33410&action=edit
obscure_error.h

Given the following program (file obscure_error.h):
class A {
inline void * f (size_t n) {return 0;}
};

GCC generates the following error message:
$ g++ obscure_error.h 
obscure_error.h:3:22: error: ‘f’ declared as an ‘inline’ field
 inline void * f (size_t n) {return 0;}
  ^
obscure_error.h:3:19: error: expected ‘;’ at end of member declaration
 inline void * f (size_t n) {return 0;}
   ^
obscure_error.h:3:29: error: expected ‘)’ before ‘n’
 inline void * f (size_t n) {return 0;}
 ^

It would do a better job reporting something like:
$ g++ good_error.h 
good_error.h:3:20: error: ‘size_t’ has not been declared
 inline void f (size_t n) {}
^
Which it does if I slightly modify source (file good_error.h):
class A {
inline void f (size_t n) {}
};

[Bug sanitizer/55577] g++.dg/asan/asan_test.C failures

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #4 from Yury Gribov  ---
HJ, can we close this?

[Bug libstdc++/61841] broken std::thread on Hurd

[1o5g4r8o at gmail dot com]

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

--- Comment #6 from Gabriele Giacone <1o5g4r8o at gmail dot com> ---
https://bugs.debian.org/749290#53

Please consider replying to its recipients.

[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

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

--- Comment #18 from Yury Gribov  ---
Fixed with last merge from LLVM.

[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
No difference in the code for geterrorname.jar or natgeterrorname.cc so this
must
be a libjava miscompile.

Trying to spot the error in the patch instead.

[Bug sanitizer/55577] g++.dg/asan/asan_test.C failures

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed.

[Bug sanitizer/61422] False Asan positive in libopus

[m.zakirov at samsung dot com]

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

Marat Zakirov  changed:

   What|Removed |Added

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

--- Comment #8 from Marat Zakirov  ---
Already fixed by Gribov commit.

[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 214680)
+++ gcc/gimple-fold.c   (working copy)
@@ -1440,7 +1440,7 @@ gimple_fold_builtin_strcpy (gimple_stmt_
   if (!fn)
 return false;

-  tree len = get_maxval_strlen (src, 1);
+  tree len = get_maxval_strlen (src, 0);
   if (!len)
 return false;

@@ -1477,7 +1477,7 @@ gimple_fold_builtin_strncpy (gimple_stmt
 return false;

   /* Now, we must be passed a constant src ptr parameter.  */
-  tree slen = get_maxval_strlen (src, 1);
+  tree slen = get_maxval_strlen (src, 0);
   if (!slen || TREE_CODE (slen) != INTEGER_CST)
 return false;


may fix it.

[Bug libstdc++/61841] broken std::thread on Hurd

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Ah I see, so Samuel's change is needed to make __gthread_active_p work on Hurd.
We could have changed __gthread_active_p (as we've done e.g. for Bionic) but
there's no point now.

[Bug c++/62293] Obscure error message: declared as an 'inline' field

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-28
Summary|Obsure error message|Obscure error message:
   ||declared as an 'inline'
   ||field
 Ever confirmed|0   |1

[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  ---
While the patch fixes this particular case the problem appears to be more
fundamental. The S/390 backend only considers GPR register pairs starting with
an even register to be valid (REGNO_PAIR_OK in s390.h). However, thanks to our
ABI we might encounter invalid pairs with hard regs during parameter passing.
This used to be resolved by the call preparation code which loads the parameter
into a pseudo first. That's why our move patterns are capable of dealing with
overlapping register pairs. However, the other patterns aren't. In that case it
was the negdi pattern but there might be similar issues with add, sub, ... .

In this example the invalid register pair in the negdi pattern comes from
combining the move which has been generated during call preparation (insn 18)
with the negdi pattern:

before combine:

(insn 17 16 18 5 (parallel [
(set (reg:DI 49 [ D.1409 ])
(neg:DI (reg:DI 44 [ D.1409 ])))
(clobber (reg:CC 33 %cc))
]) t.c:20 491 {*negdi2_31}
 (expr_list:REG_DEAD (reg:DI 44 [ D.1409 ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
(insn 18 17 19 5 (set (reg:DI 3 %r3)
(reg:DI 49 [ D.1409 ])) t.c:20 64 {*movdi_31}
 (expr_list:REG_DEAD (reg:DI 49 [ D.1409 ])
(nil)))

after combine:

(insn 18 17 19 5 (parallel [
(set (reg:DI 3 %r3)
(neg:DI (reg:DI 44 [ D.1409 ])))
(clobber (reg:CC 33 %cc))
]) t.c:20 491 {*negdi2_31}
 (expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_DEAD (reg:DI 44 [ D.1409 ])
(nil

r44 then is assigned to hard reg r2 creating the problematic overlap:

(insn 18 20 19 5 (parallel [
(set (reg:DI 3 %r3)
(neg:DI (reg:DI 2 %r2 [orig:44 D.1409 ] [44])))
(clobber (reg:CC 33 %cc))
]) t.c:20 491 {*negdi2_31}
 (nil))

I'm not sure what the best way is to fix this. Instead of implementing
splitters for all these cases the easiest might to mark the destination
operands as early clobber in the split patterns. That way reload is forced to
repair the situation.

[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Created attachment 33411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33411&action=edit
Reduced testcase

compile with -O2 -mesa -m31 -march=g5

[Bug c/62294] New: Missing "passing argument [...] from incompatible pointer type" warning.

[Emmanuel.Thome at inria dot fr]

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

Bug ID: 62294
   Summary: Missing "passing argument [...] from incompatible
pointer type" warning.
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Emmanuel.Thome at inria dot fr

Hi.

The following code should cause a warning.

#include 

void what(mpz_t a, mpz_t p, gmp_randstate_t rstate)
{
mpz_urandomm(a, p, rstate); /* WRONG */
mpz_urandomm(a, rstate, p); /* correct */
}

Alas, gcc-4.9.1 seems happy:
/tmp $ gcc-4.9 -W -Wall -Wextra -c b.c

gcc-4.8 moans appropriately.
/tmp $ gcc-4.8 -W -Wall -Wextra -c b.c
b.c: In function ‘what’:
b.c:5:5: warning: passing argument 2 of ‘__gmpz_urandomm’ from incompatible
pointer type [enabled by default]
 mpz_urandomm(a, p, rstate); /* WRONG */
 ^
In file included from b.c:1:0:
/usr/include/x86_64-linux-gnu/gmp.h:1115:21: note: expected ‘struct
__gmp_randstate_struct *’ but argument is of type ‘struct __mpz_struct *’
 __GMP_DECLSPEC void mpz_urandomm (mpz_ptr, gmp_randstate_t, mpz_srcptr);
 ^
b.c:5:5: warning: passing argument 3 of ‘__gmpz_urandomm’ from incompatible
pointer type [enabled by default]
 mpz_urandomm(a, p, rstate); /* WRONG */
 ^
In file included from b.c:1:0:
/usr/include/x86_64-linux-gnu/gmp.h:1115:21: note: expected ‘mpz_srcptr’ but
argument is of type ‘struct __gmp_randstate_struct *’
 __GMP_DECLSPEC void mpz_urandomm (mpz_ptr, gmp_randstate_t, mpz_srcptr);

Here is gcc -v:

/tmp $ gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=gcc-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-4) 

I'm happy to provide any further information.

Regards,

E.

[Bug c/62294] [4.9 Regression] Missing "passing argument [...] from incompatible pointer type" warning.

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-28
Summary|Missing "passing argument   |[4.9 Regression] Missing
   |[...] from incompatible |"passing argument [...]
   |pointer type" warning.  |from incompatible pointer
   ||type" warning.
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Hmm, it works with gcc-5 where it is controlled by -Wincompatible-pointer-types
(enabled by default), but that's a recent thing and 4.9 was still supposed to
have it directly enabled by default...

[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #6 from jgreenhalgh at gcc dot gnu.org ---
> Also there seem to be other code (gimplify.c) which still depends on
> PUSH_ARGS_REVERSED?!

Indeed. I left that out of mercy to those users (erroneously) relying on the
order of evaluating function arguments. C and C++ explicitly mark the
evaluation order as unspecified, but there seems no good reason to break user
expectations.

If we were to revert my patch, we would have to either remove the tie between
what gimple thinks of as PUSH_ARGS_REVERSED and what expand thinks of as
PUSH_ARGS_REVERSED, or break (admittedly broken and not-portable) user code.

> I'm also not sure about the performance impact of this. On S/390 the generated
> code changes a lot with your patch.

As mentioned in the original patch submission [1], the effect is to allow
removal the removal of temporary registers when shuffling arguments for a call.

I can't speak to the performance on S/390. Certainly if your arguments are
predominantly stack-based I wouldn't expect to see any benefit, but I
wouldn't expect to see much harm either, assuming and reading and writing to
descending stack locations was as efficient as reading and writing to ascending
stack locations. That assumption might well not hold for S/390.

If S/390 passes small numbers of arguments in registers, I'd expect the net
result to be positive for performance.

[1]: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01252.html

[Bug c++/62295] New: Variable Lenth Ararys can't be passed to functions in c++

[cdkrot at yandex dot ru]

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

Bug ID: 62295
   Summary: Variable Lenth Ararys can't be passed to functions in
c++
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cdkrot at yandex dot ru

Hello!
The https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable-Length
says that gcc accepts variable length arrays in c++.
But i found that passing VLA's to function doesn't work in c++.

For example compiling function with following prototype succeeds in c, but
fails in c++.

> int sum(int n, int mat[][n])

This is probably a documentation bug or c++ compiler error.

[Bug libstdc++/58962] Pretty printers use obsolete Python syntax

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu Aug 28 16:22:21 2014
New Revision: 214682

URL: https://gcc.gnu.org/viewcvs?rev=214682&root=gcc&view=rev
Log:
2014-08-28  Samuel Bronson  

Backport r212453 from trunk
2014-07-11  Samuel Bronson  
Matthias Klose  

PR libstdc++/58962
* python/libstdcxx/v6/printers.py: Port to Python 2+3
(imap): New compat function.
(izip): Likewise.
(Iterator): New mixin to allow writing iterators in Python 3 style
regardless of which version we're running on.
[Python3] (long) New compat alias for "int".
* testsuite/lib/gdb-test.exp: Port to Python 2+3 (print syntax)

Backport r210625 from trunk
2014-05-19  Jonathan Wakely  

* python/libstdcxx/v6/printers.py: Use Python3 raise syntax.

Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/python/libstdcxx/v6/printers.py
branches/gcc-4_8-branch/libstdc++-v3/testsuite/lib/gdb-test.exp

[Bug libstdc++/58962] Pretty printers use obsolete Python syntax

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|4.9.2   |4.8.4

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #59 from Jason Merrill  ---
(In reply to Markus Trippelsdorf from comment #58)

These are breaking with -flto because make_decl_local clears DECL_COMDAT, so
the check I added to ipa_devirt doesn't trigger.  Honza, can we just remove
that from make_decl_local?  It seems harmless to me to leave the flag set.

[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
The patch in comment 3 fixes the failures after a clean bootstrap (a simple
update was not enough, i.e., the faulty parts of (lib)?java are not marked as
depending upon gcc/gimple-fold.c). So far I have done a full regtesting of
libjava and gfortran only without regression).

Thanks for the quick fix.

[Bug c++/61492] Nested-name-specifier lookup finds function

[aaw at gcc dot gnu.org]

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

Ollie Wild  changed:

   What|Removed |Added

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

--- Comment #2 from Ollie Wild  ---
This looks like a duplicate of 60994.

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

[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier

[aaw at gcc dot gnu.org]

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

Ollie Wild  changed:

   What|Removed |Added

 CC||potswa at mac dot com

--- Comment #6 from Ollie Wild  ---
*** Bug 61492 has been marked as a duplicate of this bug. ***

[Bug libfortran/62296] New: EXECUTE_COMMAND_LINE not F2008 conforming

[anlauf at gmx dot de]

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

Bug ID: 62296
   Summary: EXECUTE_COMMAND_LINE not F2008 conforming
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de

It appears that EXECUTE_COMMAND_LINE does not fully conform to F2008
in case the execute command fails.

F2008, 13.7.57 states:

CMDSTAT (optional) shall be a default integer scalar. It is an INTENT (OUT)
argument. It is assigned the value −1 if the processor does not support
command line execution, a processor-dependent positive value if an error
condition occurs, or the value −2 if no error condition occurs but WAIT
is present with the value false and the processor does not support
asynchronous execution. Otherwise it is assigned the value 0.
[...]
If a condition occurs that would assign a nonzero value to CMDSTAT but the
CMDSTAT variable is not present, error termination is initiated.


However, the following example behaves as follows:

program gfcbug126
  integer :: stat, cstat
  call execute_command_line ("/bin/true",  exitstat=stat, cmdstat=cstat)
  print *, stat, cstat
  call execute_command_line ("/bin/false", exitstat=stat, cmdstat=cstat)
  print *, stat, cstat
  call execute_command_line ("/bin/true",  exitstat=stat)
  print *, stat
  call execute_command_line ("/bin/false", exitstat=stat)
  print *, stat
end

Output:
   0   0
   1   0
   0
   1

I think the correct output should be like:
   0   0
   1   (some positive number, e.g. 1)
   0
 (error termination)

e.g. xlf 14.1 produces:
 0 0
 1 1
 0
"gfcbug126.f90", line 9: 1525-610 Error encountered while attempting to execute
the command:
/bin/false

Also, the (online) documentation should be adjusted to match the standard.

[Bug fortran/43849] Add _gfortran_finalize function to close down the library

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||steven at gcc dot gnu.org

--- Comment #5 from Steven Bosscher  ---
(In reply to Dominique d'Humieres from comment #4)
> Is this PR still pertinent (2013-12-21)?

Yes, it could be necessary to force the shutdown from other libraries
that may want to output something and will need the buffers to be
flushed for that (e.g. libcaf).

[Bug fortran/62297] New: Internal Compiler Error in fold_convert_loc

[fmartinez at gmv dot com]

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

Bug ID: 62297
   Summary: Internal Compiler Error in fold_convert_loc
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmartinez at gmv dot com

m_string.f90:737:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2074
   res = this
 ^
0x53d898 ???
../sysdeps/x86_64/elf/start.S:113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The ICE also occurs in 4.10

[Bug c++/62299] New: [4.9/5 regression] ICE with __attribute__((__weakref__(""))) and __thread

[lucdanton at free dot fr]

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

Bug ID: 62299
   Summary: [4.9/5 regression] ICE with
__attribute__((__weakref__(""))) and __thread
   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

$ g++-trunk --version
g++-trunk (GCC) 5.0.0 20140828 (experimental)
Copyright (C) 2014 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 testcase.cpp
static __typeof 0 __gthrw_pthread_once __attribute__((__weakref__("")));
template  class keyword_tss_ptrnoncopyable {
  static __thread T *value_;
};
$ g++-trunk testcase.cpp -c
testcase.cpp:4:2: internal compiler error: Segmentation fault
 };
  ^
0xc11bff crash_signal
../../gcc/gcc/toplev.c:339
0x8a49f4 tree_check
../../gcc/gcc/tree.h:2962
0x8a49f4 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/gcc/symtab.c:69
0x8a4c73 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/gcc/symtab.c:181
0x8a4efc symbol_table::symtab_initialize_asm_name_hash()
../../gcc/gcc/symtab.c:263
0x8a6d6f symtab_node::get_for_asmname(tree_node const*)
../../gcc/gcc/symtab.c:947
0x8b2f38 handle_alias_pairs
../../gcc/gcc/cgraphunit.c:
0x8b7ddc symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2264
0x69cde2 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
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.

--

This testcase was mechanically derived from preprocessed source. As best as I
can tell the original __gthrw_pthread_once comes from
c++/5.0.0/x86_64-unknown-linux-gnu/bits/gthr-default.h., in case that matters.

The testcase is accepted by GCC 4.8 and 4.9.

[Bug fortran/62298] New: Internal Compiler Error in fold_convert_loc

[fmartinez at gmv dot com]

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

Bug ID: 62298
   Summary: Internal Compiler Error in fold_convert_loc
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmartinez at gmv dot com

m_string.f90:737:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2074
   res = this
 ^
0x53d898 ???
../sysdeps/x86_64/elf/start.S:113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The ICE also occurs in 4.10

[Bug fortran/62298] Internal Compiler Error in fold_convert_loc

[fmartinez at gmv dot com]

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

--- Comment #1 from Fran Martinez Fadrique  ---
Created attachment 33412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33412&action=edit
Source causing the ICE. No dependencies.

[Bug bootstrap/62300] New: [5 Regression] internal compiler error: in as_a, at is-a.h:192

[hjl.tools at gmail dot com]

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

Bug ID: 62300
   Summary: [5 Regression] internal compiler error: in as_a, at
is-a.h:192
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86-64, when configured with --with-multilib-list=m32,m64,mx32,
r214699 failed to bootstrap:

In file included from
../../../../src-trunk/libgcc/config/libbid/bid_internal.h:27:0,
 from
../../../../src-trunk/libgcc/config/libbid/bid_round.c:108:
../../../../src-trunk/libgcc/config/libbid/bid_round.c: In function
â__bid_round64_2_18â:
../../../../src-trunk/libgcc/config/libbid/bid_conf.h:48:22: internal compiler
error: in as_a, at is-a.h:192
 #define round64_2_18 __bid_round64_2_18
  ^
../../../../src-trunk/libgcc/config/libbid/bid_round.c:111:1: note: in
expansion of macro âround64_2_18â
 round64_2_18 (int q,
 ^
0x781642 rtx_insn* as_a(rtx_def*)
../../src-trunk/gcc/is-a.h:192
0x90b93c assign_parm_setup_reg
../../src-trunk/gcc/function.c:3044
0x90d763 assign_parms
../../src-trunk/gcc/function.c:3453
0x9117cf expand_function_start(tree_node*)
../../src-trunk/gcc/function.c:4809
0x760cd9 execute
../../src-trunk/gcc/cfgexpand.c:5715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[8]: *** [bid_round.o] Error 1
make[8]: *** Waiting for unfinished jobs
../../../../src-trunk/libgcc/config/libbid/bid128_fma.c: In function
ârounding_correction.constpropâ:
../../../../src-trunk/libgcc/config/libbid/bid128_fma.c:33:1: internal compiler
error: in as_a, at is-a.h:192
 rounding_correction (unsigned int rnd_mode,
 ^
0x781642 rtx_insn* as_a(rtx_def*)
../../src-trunk/gcc/is-a.h:192
0x90b93c assign_parm_setup_reg
../../src-trunk/gcc/function.c:3044
0x90d763 assign_parms
../../src-trunk/gcc/function.c:3453
0x9117cf expand_function_start(tree_node*)
../../src-trunk/gcc/function.c:4809
0x760cd9 execute
../../src-trunk/gcc/cfgexpand.c:5715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[8]: *** [bid128_fma.o] Error 1
make[8]: Leaving directory
`/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/x32/libgcc'
make[7]: *** [multi-do] Error 1
make[7]: Leaving directory
`/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/libgcc'
make[6]: *** [all-multi] Error 2
make[6]: Leaving directory
`/export/gnu/import/git/gcc-test-x32/bld/x86_64-unknown-linux-gnu/libgcc'
make[5]: *** [all-stage1-target-libgcc] Error 2
make[5]: Leaving directory `/export/gnu/import/git/gcc-test-x32/bld'
make[4]: *** [stage1-bubble] Error 2
make[4]: Leaving directory `/export/gnu/import/git/gcc-test-x32/bld'
make[3]: *** [bootstrap] Error 2

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 33413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33413&action=edit
A testcase

[x32@gnu-35 gcc]$ ./xgcc -B./ -S -fPIC -O2 /tmp/x.i  -mx32
../../../../src-trunk/libgcc/config/libbid/bid128_fma.c: In function
‘rounding_correction.constprop’:
../../../../src-trunk/libgcc/config/libbid/bid128_fma.c:33:1: internal compiler
error: in as_a, at is-a.h:192
0x781642 rtx_insn* as_a(rtx_def*)
../../src-trunk/gcc/is-a.h:192
0x90b93c assign_parm_setup_reg
../../src-trunk/gcc/function.c:3044
0x90d763 assign_parms
../../src-trunk/gcc/function.c:3453
0x9117cf expand_function_start(tree_node*)
../../src-trunk/gcc/function.c:4809
0x760cd9 execute
../../src-trunk/gcc/cfgexpand.c:5715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-08-29
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
r214689 is OK.

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[dmalcolm at redhat dot com]

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

--- Comment #3 from Dave Malcolm  ---
Created attachment 33414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33414&action=edit
Candidate fix, only lightly tested so far

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[dmalcolm at redhat dot com]

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

--- Comment #4 from Dave Malcolm  ---
Sorry about this.

The issue is here:

  3042insn = as_a  (
  3043 gen_extend_insn (op0, t, promoted_nominal_mode,
  3044  data->passed_mode, unsignedp));

which I mistakenly introduced in r214698.

The result of the gen_extend_insn is a SET, not an insn:

(set (reg/v:DI 151 [ ptrres ])
(zero_extend:DI (mem/f/c:SI (reg/f:SI 77 virtual-incoming-args) [8 ptrres+0
S4 A64])))

hence the as_a  fails.

Am attaching a patch which appears to fix it.

[Bug rtl-optimization/54300] [4.7, 4.8 Regression] regcprop incorrectly looks through parallel register swap operation

[gregory.0xf0 at gmail dot com]

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

gregory.0xf0 at gmail dot com changed:

   What|Removed |Added

 CC||gregory.0xf0 at gmail dot com

--- Comment #19 from gregory.0xf0 at gmail dot com ---
(In reply to Richard Earnshaw from comment #15)
> Author: rearnsha
> Date: Mon Dec  9 14:54:00 2013
> New Revision: 205807
> 
> URL: http://gcc.gnu.org/viewcvs?rev=205807&root=gcc&view=rev
> Log:
>   PR rtl-optimization/54300
> 
> gcc/
> 
>   PR rtl-optimization/54300
>   * regcprop.c (copyprop_hardreg_forward_1): Ensure any unused
>   outputs in a single-set are killed from the value chains.
> 
> gcc/testsuite:
> 
>   PR rtl-optimization/54300
>   * gcc.target/arm/pr54300.C: New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.target/arm/ldrd-strd-offset.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/arm/arm.c
> trunk/gcc/testsuite/ChangeLog

There probably isn't much that can be done to fix this now, but in case anyone
else was confused because this change was tagged with PR 54300, it looks like
this change ended up with the wrong commit message (changelog is correct). 
FMI: https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00850.html

[Bug bootstrap/62301] New: PowerPC bootstrap broken since r214654

[wschmidt at gcc dot gnu.org]

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

Bug ID: 62301
   Summary: PowerPC bootstrap broken since r214654
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: rdsandiford at googlemail dot com
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

Bootstrap is failing in stage 2 for powerpc64le-unknown-linux-gnu (and likely
in powerpc64-unknown-linux-gnu as well, though I have not yet confirmed this). 
I've bisected the start of the failure to r214654:

2014-08-28  Richard Sandiford   

* rtl.h (get_pool_constant, rtx_referenced_p): Replace rtx parameters   
with const_rtx parameters.  
* varasm.c (get_pool_constant): Likewise.   
* rtlanal.c (rtx_referenced_p_1): Delete.   
(rtx_referenced_p): Use FOR_EACH_SUBRTX instead of for_each_rtx.
Assert that the rtx we're looking for is nonnull.  Allow searches   
for constant pool SYMBOL_REFs.  

Many compiles fail while building libgcc, all segfaulting:

/home/wschmidt/gcc/gcc-mainline-base/libgcc/libgcc2.c: In function '__ashlti3':
/home/wschmidt/gcc/gcc-mainline-base/libgcc/libgcc2.c:454:1: internal compiler
error: Segmentation fault
 }
 ^
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I'll try to get more information in the morning.

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from dmalcolm at gcc dot gnu.org ---
Author: dmalcolm
Date: Fri Aug 29 03:12:01 2014
New Revision: 214714

URL: https://gcc.gnu.org/viewcvs?rev=214714&root=gcc&view=rev
Log:
PR bootstrap/62300
* function.c (assign_parm_setup_reg): Remove erroneous checked
cast to rtx_insn * on result of gen_extend_insn in favor of
introducing a new local rtx "pat".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c

[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192

[dmalcolm at redhat dot com]

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

--- Comment #6 from Dave Malcolm  ---
Fix committed as r214714.

[Bug c++/62302] New: Change in the comdat used for constructors

[rafael.espindola at gmail dot com]

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

Bug ID: 62302
   Summary: Change in the comdat used for constructors
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael.espindola at gmail dot com
CC: hubicka at gcc dot gnu.org

It looks like an unintended consequence of r211434 wast that given

template  struct foo { foo(); };
template  foo::foo() {}
template class foo;

gcc now prints

.section.text._ZN3fooIiEC2Ev,"axG",@progbits,_ZN3fooIiEC2Ev,comdat

before it did

.section.text._ZN3fooIiEC2Ev,"axG",@progbits,_ZN3fooIiEC5Ev,comdat

Note the change in comdat.

[Bug bootstrap/62301] PowerPC bootstrap broken since r214654

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn
   |nu  |u
   Host|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn
   |nu  |u
  Build|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn
   |nu  |u

--- Comment #1 from Bill Schmidt  ---
Confirmed that this fails for big-endian as well as little-endian (both Power8
boxes).

[Bug middle-end/62289] [5 Regression] ICE (segfault) for gfortran.dg/graphite/pr42393.f90

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
(In reply to amker from comment #1)
> Some comments on it at
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02274.html

Namely:
> This is a bug in ISL. Theyâll fix it in a new version of ISL.
> https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk

The thread lists the ISL patch,
  https://11523367451463622537.googlegroups.com/attach/9eb3bcd38b58b2b1/diff
and: "Does the attached help?" - "Yes, It helps to fix the problem in
isl-0.13."

[Bug debug/62225] DW_AT_location for local variable is missing

[qiyao at gcc dot gnu.org]

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

--- Comment #3 from Yao Qi  ---
(In reply to Andrew Pinski from comment #1)
> I bet if you remove register, it will work. Or compile with variable
> tracking turned on.

I compiled the code again with -fvar-tracking, and looks DW_AT_location for
local variable is there.

 <2><9a>: Abbrev Number: 7 (DW_TAG_variable)
<9b>   DW_AT_name: l
<9d>   DW_AT_decl_file   : 1
<9e>   DW_AT_decl_line   : 15
<9f>   DW_AT_type: <0x25>
   DW_AT_location: 0x0 (location list)
 <2>: Abbrev Number: 7 (DW_TAG_variable)
   DW_AT_name: r
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 15
   DW_AT_type: <0x25>
   DW_AT_location: 0x2a (location list)

Contents of the .debug_loc section:

Offset   BeginEnd  Expression
 080483b1 080483b4 (DW_OP_reg11 (st0))
000b 080483b4 080483cf (DW_OP_fbreg: 0)
0017 080483cf 080483d2 (DW_OP_reg11 (st0))
0022 
002a 080483b4 080483cb (DW_OP_reg11 (st0))
0035 080483cb 080483ef (DW_OP_fbreg: 12)
0041