[Bug fortran/64932] New: [5.0] ICE on module end, gfc_conv_descriptor_data_get

[shapero at uw dot edu]

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

Bug ID: 64932
   Summary: [5.0] ICE on module end, gfc_conv_descriptor_data_get
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shapero at uw dot edu

Created attachment 34661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34661&action=edit
internal compiler error backtrace

I have some Fortran 2003 code, hosted here:

https://github.com/danshapero/sigma

It builds and passes all tests on gfortran-4.7.2 and 4.8.2 on Intel 32, AMD64
and ARM with Linux, and Intel/OSX.

I'm attempting to build it with gfortran-5.0, because co-arrays :D.
Unfortunately, I'm getting an internal compiler error. GCC was configured with

../configure --prefix=/home/daniel/programs/gcc --enable-languages=c,fortran
--enable-checking=release --disable-bootstrap
--disable-build-poststage1-with-cxx --disable-libstdcxx-pch --disable-multilib

in accordance with the suggestions from
https://gcc.gnu.org/wiki/GFortranBinaries#FromSource. The GCC test suite
passes, and I've compiled some simple programs to verify that gfortran-5.0
works.

The backtrace is long; I've attached it as a text file. The library is built
with the usual

mkdir build
cd build
FC=gfortran-5.0 CC=gcc-5.0 cmake ..
make

The error also occurs when I do a debug build that includes -Wall -Wextra.

I can attempt to make a reduced test case for this, but I'm a bit out of my
depth here. Thanks for reading!

[Bug rtl-optimization/50380] [4.6 only] cc1 hangs eating 100% CPU

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
gnewsense devs ran into this problem on gnewsense, building libvpx's
vp9_cx_iface for mipsel-linux-gnu.  It happens on both gnewsense 3 (gcc 4.4ish)
and the upcoming gnewsense 4 (gcc 4.6ish).

I tracked it down to this bug, but I noticed the fix in it is incomplete; there
was a subsequent fix that complemented this one, that wasn't needed for the
testcase at hand, but I thought I'd help anyone else who ran into this problem
by adding a note to the subsequent fix as well:

http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189896

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #15 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> (In reply to Eric Botcazou from comment #12)
> > I'm about to install a patch that changes the costs on SPARC 64-bit to:
> > 
> > Use 1:
> >   cand  costcompl.  depends on
> >   0 4   0inv_expr:0
> >   1 8   0   
> >   4 6   0inv_expr:1
> >   5 0   0   
> >   6 0   0
> > 
> > but this doesn't change the outcome of the test. :-(
> 
> I will have a look why it fails with refined cost.
> 
> Thanks,
> bin

The cost of expression "p + ((sizetype)(99 - i_6(D)) + 1) * 4"  computed using
normal +/-/* operators on sparc64 is 18, but the cost is 32 if it is computed
as "p + ((sizetype)(99 - i_6(D)) + 1) << 2", which is returned by
get_shiftadd_cost.

>From the assembly code, it seems the computation is expensive on sparc64, I may
skip the test for these architectures if no other solutions.

Thanks.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan  ---
(In reply to Paul Thomas from comment #4)
> (In reply to H.J. Lu from comment #3)
> > gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> > and 4.9 branch:
> > 
> > https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
> > 
> > It is caused by r220191.
> 
> HJ,
> 
> I'll take a look at this tomorrow night. I find it to be enormously
> surprising that r220191 is causing this regression. I rather think that I
> have exposed another underlying bug.
> 
> Thanks
> 
> Paul

I've been seeing this test fail in cross-testing on arm-linux-gnueabi{hf} too.
However native testresults from gcc-testresults don't show this coming up
often. Not sure what's going on here.

Ramana

[Bug rtl-optimization/64916] [5.0 regression] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
Below is full dump of pr43920-2.c with "-mthumb -mcpu=cortex-m3 -Os" options:

   10: NOTE_INSN_BASIC_BLOCK 2
2: r116:SI=r0:SI
3: r117:SI=r1:SI
  REG_DEAD r1:SI
4: r118:SI=r2:SI
  REG_DEAD r2:SI
5: NOTE_INSN_FUNCTION_BEG
   12: r2:SI=0x1
   13: r1:SI=0
   15: r0:SI=call [`lseek'] argc:0
  REG_DEAD r2:SI
  REG_DEAD r1:SI
  REG_CALL_DECL `lseek'
   16: r111:SI=r0:SI
  REG_DEAD r0:SI
   17: r2:SI=0x2
   18: r1:SI=0
   19: r0:SI=r116:SI
  REG_DEAD r116:SI
   20: r0:SI=call [`lseek'] argc:0
  REG_DEAD r2:SI
  REG_DEAD r1:SI
  REG_CALL_DECL `lseek'
   21: r112:SI=r0:SI
  REG_DEAD r0:SI
   22: cc:CC=cmp(r111:SI,0x)
   23: pc={(cc:CC==0)?L46:pc}
  REG_DEAD cc:CC
  REG_BR_PROB 159
   24: NOTE_INSN_BASIC_BLOCK 3
   25: cc:CC=cmp(r112:SI,0x)
   26: pc={(cc:CC==0)?L50:pc}
  REG_DEAD cc:CC
  REG_BR_PROB 159
   27: NOTE_INSN_BASIC_BLOCK 4
   28: NOTE_INSN_DELETED
   29: {cc:CC_NOOV=cmp(r112:SI-r111:SI,0);r114:SI=r112:SI-r111:SI;}
  REG_DEAD r112:SI
   30: pc={(cc:CC_NOOV==0)?L54:pc}
  REG_DEAD cc:CC_NOOV
  REG_BR_PROB 400
   31: NOTE_INSN_BASIC_BLOCK 5
   32: [r117:SI]=r111:SI
  REG_DEAD r117:SI
  REG_DEAD r111:SI
   33: [r118:SI]=r114:SI
  REG_DEAD r118:SI
  REG_DEAD r114:SI
7: r110:SI=0
  REG_EQUAL 0
   76: pc=L34
   77: barrier
   46: L46:
   45: NOTE_INSN_BASIC_BLOCK 6
8: r110:SI=r111:SI
  REG_DEAD r111:SI
  REG_EQUAL 0x
   78: pc=L34
   79: barrier
   50: L50:
   49: NOTE_INSN_BASIC_BLOCK 7
6: r110:SI=r112:SI
  REG_DEAD r112:SI
  REG_EQUAL 0x
   80: pc=L34
   81: barrier
   54: L54:
   53: NOTE_INSN_BASIC_BLOCK 8
9: r110:SI=0x
  REG_EQUAL 0x
   34: L34:
   35: NOTE_INSN_BASIC_BLOCK 9
   40: r0:SI=r110:SI
  REG_DEAD r110:SI
   41: use r0:SI

Before r216169 (with REG_EQUAL in insn9), jumps from basic block 6/7/8 can be
merged because r110 equals to -1 afterwards.  But with the patch, the equal
information of r110==-1 in basic block 8 is lost.  As a result, jump from 8->9
can't be merged and two additional instructions are generated.

[Bug jit/64257] JIT documentation is not yet on the GCC website

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
"pyramid" theme was added in:
 
https://github.com/sphinx-doc/sphinx/commit/442229dd97160535e388473760002c1f1c495bf8
which appears to be in sphinx 1.1 onwards.

[Bug c++/64931] New: ICE on function with deduced return type and input is instantiated template class

[sneves at dei dot uc.pt]

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

Bug ID: 64931
   Summary: ICE on function with deduced return type and input is
instantiated template class
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sneves at dei dot uc.pt

Minimal example:

template
struct array {
  T data[N];
};

auto copy(array const& x) {
  return x;
}

This only seems to result in ICE if a) `copy` has deduced return type with
value semantics, i.e. `auto` but not `decltype(auto)`, and b) if the `array`
struct is a template, and `copy` takes in a specific instantiation of `array`.
Verified to ICE in GCC 4.8.2, 4.9.2, and 5.0.0 20150202.

[Bug testsuite/64796] effective target bswap64 globally caches target-specific use of lp64

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Feb  4 01:54:47 2015
New Revision: 220388

URL: https://gcc.gnu.org/viewcvs?rev=220388&root=gcc&view=rev
Log:
2015-02-04  Thomas Preud'homme  

PR testsuite/64796
* lib/target-supports.exp (check_effective_target_bswap64): Do not
cache result in a global variable.  Include all 32-bit targets for
bswap64 tests.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp

[Bug jit/64257] JIT documentation is not yet on the GCC website

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
https://gcc.gnu.org/ml/gccadmin/2015-q1/msg00077.html had:
  sphinx-build -b html -d _build/doctrees   . _build/html
  Making output directory...
  Running Sphinx v0.6.6

  Theme error:
  no theme named 'pyramid' found (missing theme.conf?)
  make: *** [html] Error 1

[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key

[fdumont at gcc dot gnu.org]

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

--- Comment #11 from François Dumont  ---
I just wanted to let you know about a way to enhance performance of your lookup
if you can afford it. I realized that if you copy the container before running
lookup you greatly enhance results. Here is what I obtain by just doing:

c1 = Container(c1);

between the 2 lookups:

Container:std::unordered_map  Key:int
Insertion: 16407 8818 7952 7881 7874  min=7874 max=16407
Lookup1:   15774 15767 15985 15845 15751  min=15751 max=15985
Lookup2:   13613 12725 12685 12678 12861  min=12678 max=13613

Container:std::tr1::unordered_map  Key:int
Insertion: 22044 5845 5716 5785 5608  min=5608 max=22044
Lookup1:   12620 12881 12597 12568 12656  min=12568 max=12881
Lookup2:   14385 12506 12043 13122 11970  min=11970 max=14385

You see that lookup 2 is much closer to the tr1 implementation. This is so
because after copy the container has a much better memory localization so less
memory page fault. If allocator keeps on returning memory node adjacent to each
other you end up with all nodes relying in the same memory block.

I have plan to document this. Of course you can only use it if you initialize
once for all or you barely update the content but lookup into it very often.

I am still looking at solutions to restore previous lookup performances.

[Bug target/64930] New: [5.0 regression] FAIL: gcc.target/powerpc/atomic-p7.c scan-assembler-times isync 12

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

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

Bug ID: 64930
   Summary: [5.0 regression] FAIL: gcc.target/powerpc/atomic-p7.c
scan-assembler-times isync 12
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
Target: powerpc64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/atomic-p7.c -mcpu=power7
-O2 -S -m64 -o atomic-p7.s
$ grep -c isync atomic-p7.s
16
$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/atomic-p8.c -mcpu=power8
-O2 -S -m64 -o atomic-p8.s
$ grep -c isync atomic-p8.s
25

[Bug target/64205] [5 Regression] powerpc64-linux --with-cpu=G5 bootstrap failure

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Ah, ok, it helps to read the bug report.  If you bootstrap with --with-cpu=G5
it fails, --with-cpu=power5 passes.

[Bug target/64205] [5 Regression] powerpc64-linux --with-cpu=G5 bootstrap failure

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Is -mcpu=power7 -mno-hard-dfp really a reasonable option?

I built a toolchain using --with-cpu=power5 from subversion id 219607 on a
powerpc64 linux system, and the system bootstrapped.

If I compile the code that Peter mentioned using -m32 -O2 -fPIC -S foo01.c
-mlong-double-128 -mno-minimal-toc -g -fbuilding-libgcc -fno-stack-protector -g
-mcpu=power5, it compiles fine.

As seger mentions, -mlra fixes this (but there are still problems with -mlra).

It does fail if you enable the stfiwx instruction (added in power7), but
disable DFP.  How many people do this?  I'm not sure this is a representation
of the original bug.

I suspect if you changed TARGET_NO_SDMODE_STACK in rs6000.h to eliminate the
TARGET_DFP test it should work.
#define TARGET_NO_SDMODE_STACK(TARGET_LFIWZX && TARGET_STFIWX)

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

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

--- Comment #28 from Eric Christopher  ---
Ah, but not every platform is ELF :)

ld64 has the flexibility to do this with Mach-O. As I said, I don't have any
better ideas at the moment, but warning that it is possible to break.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
And even without section anchors, there is no guarantee there aren't relative
relocations in between the symbols, that just have been applied already at
assembly time (say relocations against .L* symbols).
Another reason where this would break is that various programs accumulate
symbols in some sections and assume the result forms an array.  If the linker
attempted to break that appart, Linux kernel and various other projects would
fail miserably.
So without something like -fdata-sections the linker really can't do such
changes.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

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

--- Comment #26 from Eric Christopher  ---
Sure. Not the general case for other targets though.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[pinskia at gcc dot gnu.org]

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

--- Comment #25 from Andrew Pinski  ---
(In reply to Eric Christopher from comment #24)
> For the record btw, I don't believe there's a reason why the linker couldn't
> split up the data section by knowing the size of the variable so it's worth
> being very careful here - there be dragons and things could break.

We can't for most non-x86 targets where section anchors are being used.

[Bug fortran/64927] [4.7/4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Feb 03, 2015 at 09:49:16PM +, kargl at gcc dot gnu.org wrote:
> 
> I'll fix the typos in the manual in few minutes.
>

Fixed by r220381 in 5.0 and by r220382 in 4.9.

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

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

--- Comment #24 from Eric Christopher  ---
For the record btw, I don't believe there's a reason why the linker couldn't
split up the data section by knowing the size of the variable so it's worth
being very careful here - there be dragons and things could break. I don't have
any better ideas at the moment though.

[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu]

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

--- Comment #4 from lucier at math dot purdue.edu ---
On 02/03/2015 04:32 PM, pinskia at gcc dot gnu.org wrote:
> > --- Comment #2 from Andrew Pinski  ---
> Note phase opt and generate is a toplevel time area.
> The passes which take most of the time are:

I'm also concerned about excessive memory usage; the largest passes (> 
20 MB) are

  alias analysis  :   0.21 ( 1%) usr   0.00 ( 0%) sys   0.19 ( 
1%) wall   23934 kB ( 5%) ggc
  tree SSA incremental:   0.23 ( 1%) usr   0.01 ( 1%) sys   0.26 ( 
1%) wall   27481 kB ( 5%) ggc
  dominator optimization  :   0.22 ( 1%) usr   0.01 ( 1%) sys   0.22 ( 
1%) wall   27417 kB ( 5%) ggc
  tree loop invariant motion:   0.16 ( 0%) usr   0.03 ( 4%) sys   0.19 ( 
1%) wall   64219 kB (12%) ggc
  expand  :   0.39 ( 1%) usr   0.02 ( 2%) sys   0.40 ( 
1%) wall   87038 kB (17%) ggc
  CSE :   7.53 (21%) usr   0.01 ( 1%) sys   7.53 
(20%) wall   30934 kB ( 6%) ggc
  integrated RA   :   0.87 ( 2%) usr   0.00 ( 0%) sys   0.99 ( 
3%) wall   48097 kB ( 9%) ggc
  LRA non-specific:   1.61 ( 4%) usr   0.01 ( 1%) sys   1.63 ( 
4%) wall   37254 kB ( 7%) ggc

This also affects the 4.8 branch and the mainline.

[Bug fortran/64927] [4.7/4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
As the error does not appear in either 4.9 or 5.0, I
suspect that this should be closest as WONTFIX.  But,
I'll let other, more active, gfortran developers make
that call.

I'll fix the typos in the manual in few minutes.

[Bug libstdc++/64929] [5 Regression] FAIL: libstdc++-prettyprinters/48362.cc

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Also happens on Fedora 20 x86-32 and x86-64 with python-2.7.5-15.fc20:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00335.html
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00335.html

$2 = std::tuple containing = {[1] = "Johnny", [2] = 5Python Exception  Cannot parse more than 2 nodes in a tuple tree.: ^M
...}^M

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[echristo at gmail dot com]

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

--- Comment #23 from Eric Christopher  ---
So, I think Jakub's solution is strictly better here as it allows intermixing
of asan and non-asan code. It'll involve a bit of work in llvm's middle end to
keep track of symbol type to make sure to emit padding as we hit the backend,
but as long as we make sure to have full symbols for each variable it should be
fine on platforms like OS X where we have linkers that split sections based on
type of section and symbols in the section. It's an endless string of corner
cases, but as long as we're careful it'll probably work.

[Bug libstdc++/64929] [5 Regression] FAIL: libstdc++-prettyprinters/48362.cc

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
r219953 doesn't fix 32:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00332.html

[Bug jit/64257] JIT documentation is not yet on the GCC website

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Patch is installed on relevant machine, and showed up in last night's cronjob
log:
 https://gcc.gnu.org/ml/gccadmin/2015-q1/msg00075.html
as:
 sphinx-build -b html -d _build/doctrees   . _build/html
 make: sphinx-build: Command not found
 make: *** [html] Error 127

sphinx-build has now been installed on the machine in question.

[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog

--- Comment #3 from Andrew Pinski  ---
I think this is just an issue with computed goto (indirect gotos).

[Bug libstdc++/64929] New: [5 Regression] FAIL: libstdc++-prettyprinters/48362.cc

[hjl.tools at gmail dot com]

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

Bug ID: 64929
   Summary: [5 Regression] FAIL: libstdc++-prettyprinters/48362.cc
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On Linux/x86, r219789 gave

FAIL: libstdc++-prettyprinters/48362.cc print t2
FAIL: libstdc++-prettyprinters/cxx11.cc print rtpl
FAIL: libstdc++-prettyprinters/cxx11.cc print tpl

r219784 is OK.

[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note phase opt and generate is a toplevel time area.
The passes which take most of the time are:
 tree DSE:   2.80 ( 8%) usr   0.00 ( 0%) sys   2.80 ( 8%) wall 
 0 kB ( 0%) ggc
 out of ssa  :   5.90 (16%) usr   0.50 (59%) sys   6.41 (17%) wall 
26 kB ( 0%) ggc
 CSE :   7.53 (21%) usr   0.01 ( 1%) sys   7.53 (20%) wall 
 30934 kB ( 6%) ggc
 reload CSE regs :   5.74 (16%) usr   0.00 ( 0%) sys   5.73 (16%) wall 
 12325 kB ( 2%) ggc
 scheduling 2:   1.79 ( 5%) usr   0.01 ( 1%) sys   1.77 ( 5%) wall 
   299 kB ( 0%) ggc

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
(In reply to H.J. Lu from comment #3)
> gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> and 4.9 branch:
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
> 
> It is caused by r220191.

HJ,

I'll take a look at this tomorrow night. I find it to be enormously surprising
that r220191 is causing this regression. I rather think that I have exposed
another underlying bug.

Thanks

Paul

[Bug other/64928] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu]

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

--- Comment #1 from lucier at math dot purdue.edu ---
Created attachment 34660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34660&action=edit
Input file for bug

[Bug other/64928] New: unreasonable cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

[lucier at math dot purdue.edu]

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

Bug ID: 64928
   Summary: unreasonable cpu time and memory usage in "phase opt
and generate" with -ftest-coverage -fprofile-arcs
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucier at math dot purdue.edu

With this compiler:

firefly:~/Downloads/gambit/lib> /pkgs/gcc-4.9.2/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/pkgs/gcc-4.9.2/bin/gcc
COLLECT_LTO_WRAPPER=/pkgs/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4.9.2/configure --prefix=/pkgs/gcc-4.9.2
Thread model: posix
gcc version 4.9.2 (GCC) 


With this command:

/pkgs/gcc-4.9.2/bin/gcc -Q -save-temps -Wno-unused -Wno-write-strings -O1
-fno-math-errno -fschedule-insns2 -fno-strict-aliasing -fno-trapping-math
-fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp  -fprofile-arcs
-ftest-coverage  -I"../include" -c -o "_system.o" -I. -DHAVE_CONFIG_H
-D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"x86_64\""
-D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu\""
-D___CONFIGURE_COMMAND="\"./configure 'CC=/pkgs/gcc-4.9.2/bin/gcc -Q
-save-temps' '--enable-track-scheme' '--enable-coverage'"\"
-D___OBJ_EXTENSION="\".o\"" -D___EXE_EXTENSION="\"\"" -D___BAT_EXTENSION="\"\""
-D___PRIMAL _system.c -D___LIBRARY

I get the output:

Execution times (seconds)
 phase setup :   0.12 (100%) usr   0.00 ( 0%) sys   0.13 (100%)
wall   35712 kB (100%) ggc
 TOTAL :   0.12 0.00 0.13 
35728 kB
 btowc wctob mbrlen __signbitf __signbit __signbitl ___H__20___system
___H__23__23_type ___H__23__23_type_2d_cast ___H__23__23_subtype
___H__23__23_subtype_2d_set_21_ ___H__23__23_fixnum_3f_
___H__23__23_subtyped_3f_ ___H__23__23_subtyped_2d_mutable_3f_
___H__23__23_subtyped_2e_vector_3f_ ___H__23__23_subtyped_2e_symbol_3f_
___H__23__23_subtyped_2e_flonum_3f_ ___H__23__23_subtyped_2e_bignum_3f_
___H__23__23_special_3f_ ___H__23__23_ratnum_3f_ ___H__23__23_cpxnum_3f_
___H__23__23_structure_3f_ ___H__23__23_values_3f_ ___H__23__23_meroon_3f_
___H__23__23_jazz_3f_ ___H__23__23_frame_3f_ ___H__23__23_continuation_3f_
___H__23__23_promise_3f_ ___H__23__23_return_3f_ ___H__23__23_foreign_3f_
___H__23__23_flonum_3f_ ___H__23__23_bignum_3f_ ___H__23__23_unbound_3f_
___H__23__23_quasi_2d_append ___H__23__23_quasi_2d_list
___H__23__23_quasi_2d_cons ___H__23__23_quasi_2d_list_2d__3e_vector
___H__23__23_quasi_2d_vector ___H__23__23_case_2d_memv ___H__23__23_eqv_3f_
___H_eqv_3f_ ___H__23__23_eq_3f_ ___H_eq_3f_ ___H__23__23_bvector_2d_equal_3f_
___H__23__23_equal_3f_ ___H_equal_3f_ ___H__23__23_symbol_2d_hash
___H_symbol_2d_hash ___H__23__23_keyword_2d_hash ___H_keyword_2d_hash
___H__23__23_eq_3f__2d_hash ___H_eq_3f__2d_hash ___H__23__23_eqv_3f__2d_hash
___H_eqv_3f__2d_hash ___H__23__23_equal_3f__2d_hash ___H_equal_3f__2d_hash
___H__23__23_string_3d__3f__2d_hash ___H_string_3d__3f__2d_hash
___H__23__23_string_2d_ci_3d__3f__2d_hash ___H_string_2d_ci_3d__3f__2d_hash
___H__23__23_generic_2d_hash
___H__23__23_fail_2d_check_2d_invalid_2d_hash_2d_number_2d_exception
___H_invalid_2d_hash_2d_number_2d_exception_3f_
___H_invalid_2d_hash_2d_number_2d_exception_2d_procedure
___H_invalid_2d_hash_2d_number_2d_exception_2d_arguments
___H__23__23_raise_2d_invalid_2d_hash_2d_number_2d_exception
___H__23__23_fail_2d_check_2d_unbound_2d_table_2d_key_2d_exception
___H_unbound_2d_table_2d_key_2d_exception_3f_
___H_unbound_2d_table_2d_key_2d_exception_2d_procedure
___H_unbound_2d_table_2d_key_2d_exception_2d_arguments
___H__23__23_raise_2d_unbound_2d_table_2d_key_2d_exception
___H__23__23_gc_2d_hash_2d_table_3f_ ___H__23__23_gc_2d_hash_2d_table_2d_ref
___H__23__23_gc_2d_hash_2d_table_2d_set_21_
___H__23__23_gc_2d_hash_2d_table_2d_rehash_21_
___H__23__23_smallest_2d_prime_2d_no_2d_less_2d_than
___H__23__23_gc_2d_hash_2d_table_2d_resize_21_
___H__23__23_gc_2d_hash_2d_table_2d_allocate
___H__23__23_gc_2d_hash_2d_table_2d_for_2d_each
___H__23__23_gc_2d_hash_2d_table_2d_search
___H__23__23_gc_2d_hash_2d_table_2d_foldl ___H__23__23_mem_2d_allocated_3f_
___H__23__23_fail_2d_check_2d_table ___H_table_3f_ ___H__23__23_make_2d_table
___H_make_2d_table ___H__23__23_table_2d_get_2d_eq_2d_gcht
___H__23__23_table_2d_get_2d_gcht_2d_not_2d_mem_2d_alloc
___H__23__23_table_2d_get_2d_gcht ___H__23__23_table_2d_length
___H_table_2d_length ___H__23__23_table_2d_access ___H__23__23_table_2d_ref
___H_table_2d_ref ___H__23__23_table_2d_resize_21_
___H__23__23_table_2d_set_21_ ___H_table_2d_set_21_
___H__23__23_table_2d_search ___H_table_2d_search
___H__23__23_table_2d_for_2d_each ___H_table_2d_for_2d_each
___H__23__23_table_2d_foldl ___H__23__23_table_2d__3e_list
___H_table_2d__3e_list ___H__23__23_list_2d__3e_

[Bug fortran/64925] ICE with same names for dummy arg and internal procedure

[longb at cray dot com]

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

--- Comment #2 from Bill Long  ---
The error message in Comment 1 provides correct information, and the
compilation does not cause an ICE, so this is a definite improvement.

[Bug rtl-optimization/64756] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  3 20:41:38 2015
New Revision: 220377

URL: https://gcc.gnu.org/viewcvs?rev=220377&root=gcc&view=rev
Log:
PR rtl-optimization/64756
* cse.c (invalidate_dest): New function.
(cse_insn): Use it.  If dest != SET_DEST (sets[i].rtl) and
HASH (SET_DEST (sets[i].rtl), mode) computation sets do_not_record,
invalidate and do not record it.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr64756.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cse.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu

[aoliva at gcc dot gnu.org]

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

--- Comment #21 from Alexandre Oliva  ---
I went back to r219641, just before the problem disappeared again, installed
the r220031 patch to fix the dwarf2out crash, and compilation completed
sucessfully in 36s.  Installing the patch for bug 64817 brought it down to 30s,
which is still arguably excessive, but...  we're not really doing anything
wrong here.  The huge debug loc exprs you see are the result of the compiler
looking for, and finding, an alternate representations for a variable, when a
register used in its previous location is modified.  What we have before
var-track is a sequence of groups of insns that each sets ebx to an expression
involving its prior value, and then binds a variable to it.  The chain of exprs
goes all the way back to an entry value (not in ebx), so the compiler
successfully builds more and more complex locations for the variable every time
ebx is modified, emitting a location for the variable, just to have the next
insn bind the variable to ebx.

One thing we could do to alleviate this specific scenario is to try to optimize
out the emission of a location when it's about to be modified again.  This
would address this particular issue, but it would be no help if the long chain
of exprs were to set different user variables, rather than the same.  Assuming
the program still optimizes to the same non-debug insns, as it should, we'd
have to recompute the location for each remaining user variable because it is
not rebound, and we'd end up with the same complex rtl referring all the way
back to entry-point values.

Lowering the max-vartrack-expr-depth by 1, down to 11, cuts the compile time
down to tenths of a second, so the complexity limiters we have in place are
doing their job, it's just that this rtl turns out to be particularly expensive
to handle.

[Bug target/64660] [SH] Convert atomic_fetch_ to atomic__fetch

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Author: olegendo
Date: Tue Feb  3 20:24:13 2015
New Revision: 220376

URL: https://gcc.gnu.org/viewcvs?rev=220376&root=gcc&view=rev
Log:
gcc/
PR target/64660
* config/sh/sync.md (atomic__hard,
atomic_not_hard, atomic__soft_tcb,
atomic_not_soft_tcb, atomic_nand_hard,
atomic_nand_soft_tcb): New insns.
(atomic_fetch_si_hard): Convert to insn_and_split.
Split into atomic__fetchsi_hard if operands[0] is unused.
(define_insn "atomic_fetch_notsi_hard): Convert to insn_and_split.
Split into atomic_not_fetchsi_hard if operands[0] is unused.
(atomic_fetch__hard): Convert to insn_and_split.
Split into atomic__hard if operands[0] is unused.
(atomic_fetch_not_hard): Convert to insn_and_split.  Split into
atomic_not_hard if operands[0] is unused.
(atomic_fetch__soft_gusa): Convert to
insn_and_split.  Split into atomic__fetch_soft_gusa
if operands[0] is unused.
(atomic_fetch_not_soft_gusa): Convert to insn_and_split.  Split
into atomic_not_fetch_soft_gusa if operands[0] is unused.
(atomic_fetch__soft_tcb): Convert to insn_and_split.
Split into atomic__soft_tcb if operands[0] is
unused.
(atomic_fetch_not_soft_tcb): Convert to insn_and_split.  Split
into atomic_not_soft_tcb if operands[0] is unused.
(atomic_fetch__soft_imask): Convert to
insn_and_split.  Split into atomic__fetch_soft_imask
if operands[0] is unused.
(atomic_fetch_not_soft_imask): Convert to insn_and_split.  Split
into atomic_not_fetch_soft_imask is operands[0] is unused.
(atomic_fetch_nandsi_hard): Convert to insn_and_split.  Split into
atomic_nand_fetchsi_hard if operands[0] is unused.
(atomic_fetch_nand_hard): Convert to insn_and_split.  Split into
atomic_nand_hard if operands[0] is unused.
(atomic_fetch_nand_soft_gusa): Convert to insn_and_split.  Split
into atomic_nand_fetch_soft_gusa if operands[0] is unused.
(atomic_fetch_nand_soft_tcb): Convert to insn_and_split.  Split
into atomic_nand_soft_tcb if operands[0] is unused.
(atomic_fetch_nand_soft_imask): Convert to insn_and_split.  Split
into atomic_nand_fetch_soft_imask if operands[0] is unused.
(atomic__fetch_hard): Convert to insn_and_split.
Split into atomic__hard if operands[0] is unused.
(atomic_not_fetch_hard): Convert to insn_and_split.  Split into
atomic_not_hard if operands[0] is unused.
(atomic__fetch_soft_tcb): Convert to insn_and_split.
Split into atomic__soft_tcb if operands[0] is
unused.
(atomic_not_fetch_soft_tcb): Convert to insn_and_split.  Split
into atomic_not_soft_tcb if operands[0] is unused.
(atomic_nand_fetch_hard): Convert to insn_and_split.  Split into
atomic_nand_hard if operands[0] is unused.
(atomic_nand_fetch_soft_tcb): Convert to insn_and_split.  Split
into atomic_nand_soft_tcb if operands[0] is unused.

gcc/testsuite/
PR target/64660
* gcc.target/sh/pr64660-0.h: New.
* gcc.target/sh/pr64660-1.c: New.
* gcc.target/sh/pr64660-2.c: New.
* gcc.target/sh/pr64660-3.c: New.
* gcc.target/sh/pr64660-4.c: New.

Added:
trunk/gcc/testsuite/gcc.target/sh/pr64660-0.h
trunk/gcc/testsuite/gcc.target/sh/pr64660-1.c
trunk/gcc/testsuite/gcc.target/sh/pr64660-2.c
trunk/gcc/testsuite/gcc.target/sh/pr64660-3.c
trunk/gcc/testsuite/gcc.target/sh/pr64660-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sync.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-03
 Ever confirmed|0   |1

[Bug fortran/64927] [4.7/4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED

[anlauf at gmx dot de]

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

--- Comment #1 from Harald Anlauf  ---
There's also a typo in the online documentation on C_ASSOCIATED:

https://gcc.gnu.org/onlinedocs/gfortran/C_005fASSOCIATED.html

"c_prt_1" should read "c_ptr_1" in two places.

[Bug fortran/64925] ICE with same names for dummy arg and internal procedure

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Here's patch.  Not sure if it is completely correct.

Index: symbol.c
===
--- symbol.c(revision 220347)
+++ symbol.c(working copy)
@@ -458,6 +458,11 @@ check_conflict (symbol_attribute *attr, 
 }
 }

+  if (attr->dummy && ((attr->function || attr->subroutine) && 
+gfc_current_state () == COMP_CONTAINS))
+gfc_error_now ("internal procedure '%s' at %L conflicts with "
+   "DUMMY argument", name, where);
+
   conf (dummy, entry);
   conf (dummy, intrinsic);
   conf (dummy, threadprivate);

% gfc5x -c bl.f90
bl.f90:9:25:

   integer function ccc(i)
 1
Error: internal procedure 'ccc' at (1) conflicts with DUMMY argument

[Bug go/56839] make check: FAIL: go/types

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #3 from Ian Lance Taylor  ---
The libgo/go/go/types directory is gone.

[Bug go/64595] go programs abort when debug info is stripped

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||allan at archlinux dot org

--- Comment #22 from Ian Lance Taylor  ---
*** Bug 57194 has been marked as a duplicate of this bug. ***

[Bug go/57194] go binaries give "no debug info in ELF executable errno -1"

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
This was reopened later, and is now fixed.

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

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-03
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Goes away with -fno-devirtualize or -fno-devirtualize-speculatively.
Looking at the dumps, after IPA we have:
  [pol6.C:39:3] Head::parse (_33, _30);
call (looks fine), but instead of the 3 expected
  [pol6.C:39:3] Code_Block::parse (_36, _30);
  [pol6.C:39:3] Code_Block::parse (_36, _30);
  [pol6.C:39:3] Code_Block::parse (_36, _30);
calls that show e.g. with -fno-devirtualize-speculatively we instead have:
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
  [pol6.C:39:3] __builtin_unreachable (_36, _30);
and no wonder everything goes wrong afterwards.
I don't see why IPA devirtualization thinks something is wrong on the
Code_Block::parse calls.  And, because for these __builtin_unreachable calls
IPA doesn't strip the undesirable arguments, it isn't transformed even with
-fsanitize=undefined into __ubsan_handle_unreachable (), which would make it
far easier to figure this out.

Honza, can you please have a look?

[Bug go/58075] Unable to build go on ia64-hp-hpux11.31

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-03
 Ever confirmed|0   |1

[Bug go/59095] FAIL: TestMakeFunc on x32

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
This should be fixed by the change to libffi.  Please reopen if not.

[Bug go/60728] recover() should not work in recursive deferred fucntions

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Fixed by https://codereview.appspot.com/153950043 .

[Bug fortran/64927] New: [4.7/4.8 Regression] Surprising error with -Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED

[anlauf at gmx dot de]

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

Bug ID: 64927
   Summary: [4.7/4.8 Regression] Surprising error with
-Wsurprising (-Wall) and TRANSFER + C_ASSOCIATED
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gmx dot de

The following error occurs with 4.7 and 4.8, but not with 4.6 or 4.9.
The error is slightly annoying since -Wsurprising is automatically
enabled by -Wall, and it was a try-and-error by a colleague to trace
the problem to -Wsurprising.

The error shows up only if both indicated code lines with TRANSFER
and C_ASSOCIATED are active, commenting out any of them makes the
error disappear.  The dump-tree for 4.8 and 4.9 does not show
any difference if -Wno-surprising is set.  The error is bogus.

> cat gfcbug130.f90
! gfortran -c gfcbug130.f90 -Wall
! false error, compare -Wsurprising vs. -Wno-surprising

module surprise
  use iso_c_binding
  implicit none
  TYPE t_pointer
 TYPE(c_ptr) :: cptr
  END TYPE t_pointer
contains
  SUBROUTINE get_pointer (ibuf)
INTEGER, INTENT(IN) :: ibuf(:)
TYPE(t_pointer) :: zp
! Error disappears if any line is commented out:
zp = TRANSFER (ibuf, zp)
IF (C_ASSOCIATED (zp% cptr)) Print *, "OK"
  END SUBROUTINE get_pointer
end module surprise

> gfc-48 -c gfcbug130.f90 -Wall   
gfcbug130.f90:16.22:

IF (C_ASSOCIATED (zp% cptr)) Print *, "OK"
  1
Error: Type mismatch in argument 'c_ptr_1' at (1); passed INTEGER(4) to
TYPE(c_ptr)

> gfc-48 -c gfcbug130.f90 -Wall -Wno-surprising

The problem does not occur in 4.9.  If there is an
easy fix for 4.8, could it be backported?

(I understand that the 4.7 branch is already closed.)

Thanks,
Harald

[Bug go/60995] gccgo ignores .a files with "/SYM64/" symbol table

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Fixed by https://codereview.appspot.com/154800044 .

[Bug go/61624] Internal compiler error: in read_type, at go/gofrontend/import.cc:669

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Your test case doesn't compile; add_person.go doesn't define proto.  I've tried
to fix it, but I'm unable to reproduce the problem either either GCC 4.8 or
mainline.  I'm closing this bug.  Please reopen if you have a standalone test
case.

[Bug c++/64926] Variable declared in if-statement-header is in wrong scope

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
No GCC is correct, the scope of the variable x is for both the true part and
the false part of the if statement.  You can't declare another variable with
the name of x in either part though but in your case we have a single statement
of if(true) {..} which means you can declare another variable of the same name
in the {} part as it is an inner-scope.

[Bug go/64900] gotools don't link on Solaris 11/x86

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Normally libgo.so will get the symbol _Unwind_GetLanguageSpecificData from
libgcc_s.so.  The first step here is to find out why that didn't happen.  Was
libgo.so not linked against libgcc_s.so?  Does libgcc_s.so not define
_Unwind_GetLanguageSpecificData?

[Bug c++/64926] Variable declared in if-statement-header is in wrong scope

[humbug at deeptown dot org]

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

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

[Bug c++/64926] Variable declared in if-statement-header is in wrong scope

[humbug at deeptown dot org]

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

Roman Proskuryakov  changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic
   Severity|major   |critical

[Bug c++/64926] New: Variable declared in if-statement-header is in wrong scope

[humbug at deeptown dot org]

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

Bug ID: 64926
   Summary: Variable declared in if-statement-header is in wrong
scope
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: humbug at deeptown dot org

A friend of mine (Dmitry Kashitsyn) found a bug:

#include 

int main()
{
if (int* x=NULL) // <<< declare 'x'
{}
else if(true)
{
std::printf("%d\n", *x); // <<< You may access 'x' inside this scope
}
return 0;
}

[Bug fortran/64925] New: ICE with same names for dummy arg and internal procedure

[longb at cray dot com]

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

Bug ID: 64925
   Summary: ICE with same names for dummy arg and internal
procedure
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com

> cat test.f90
subroutine foo(nnn, aaa, bbb, ccc)
  implicit none
  integer :: nnn, aaa, bbb(nnn)
  integer :: i
  do i=1,nnn
 aaa = aaa + bbb(ccc(i))
  end do
contains
  integer function ccc(i)
implicit none
integer :: i
ccc = i
  end function ccc
end subroutine foo
> gfortran -c test.f90
test.f90: In function 'foo':
test.f90:1:0: internal compiler error: Segmentation fault
 subroutine foo(nnn, aaa, bbb, ccc)
 ^
0x99c48f crash_signal
../../cray-gcc-4.9.2/gcc/toplev.c:337
0x687b03 create_function_arglist
../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:2142
0x68af6b gfc_create_function_decl(gfc_namespace*, bool)
../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:2585
0x68f689 gfc_generate_contained_functions
../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:4762
0x68f689 gfc_generate_function_code(gfc_namespace*)
../../cray-gcc-4.9.2/gcc/fortran/trans-decl.c:5589
0x62efe0 translate_all_program_units
../../cray-gcc-4.9.2/gcc/fortran/parse.c:4953
0x62efe0 gfc_parse_file()
../../cray-gcc-4.9.2/gcc/fortran/parse.c:5150
0x66c105 gfc_be_parse_file
../../cray-gcc-4.9.2/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Expected: Error message saying that a dummy argument and an internal procedure
cannot have the same name in a scoping unit. (Both are class 1 local
identifiers in subclause 16.3.1.)

[Bug c++/64924] Callback function passed as a parameter with typename declaration produces an ICE.

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-03
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.4, 4.9.2, 5.0

--- Comment #1 from Markus Trippelsdorf  ---
clang and the intel compiler reject the testcase.
All supported gcc versions crash.

markus@x4 /tmp % clang++ -std=c++11 te.cpp
te.cpp:9:34: error: no type named 'CallbackFunction' in 'PP'
PP(T* instance, typename PP::CallbackFunction callbackFunction);
~^~~~
te.cpp:19:8: error: out-of-line definition of 'PP' does not match any
declaration in 'PP'
PP::PP(T* instance, CallbackFunction callbackFunction)
   ^~
2 errors generated.

markus@x4 /tmp % icpc -std=c++11 te.cpp
te.cpp(19): error: no instance of overloaded function "PP::PP" matches the
specified type
  PP::PP(T* instance, CallbackFunction callbackFunction)
 ^

te.cpp(9): error: class "PP" has no member "CallbackFunction"
  PP(T* instance, typename PP::CallbackFunction callbackFunction);
   ^
  detected during instantiation of class "PP [with T=JJ]" at line 42

compilation aborted for te.cpp (code 2)

markus@x4 /tmp % g++ -std=c++11 te.cpp
te.cpp:19:57: internal compiler error: Segmentation fault
 PP::PP(T* instance, CallbackFunction callbackFunction)
 ^
0xc96d4f crash_signal
../../gcc/gcc/toplev.c:383
0xeeed10 strip_array_types(tree_node*)
../../gcc/gcc/tree.c:8025
0x73c1e8 cp_type_quals(tree_node const*)
../../gcc/gcc/cp/typeck.c:8916
0x73c2b8 original_type
../../gcc/gcc/cp/typeck.c:259
0x7431d8 merge_types(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck.c:752
0x743313 merge_types(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck.c:797
0x7438fb commonparms
../../gcc/gcc/cp/typeck.c:243
0x7438fb merge_types(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck.c:863
0x743ac3 merge_types(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck.c:898
0x62c083 duplicate_decls(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/decl.c:1975
0x590a5c grokfndecl
../../gcc/gcc/cp/decl.c:8035
0x639dbd grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10992
0x63b466 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../gcc/gcc/cp/decl.c:13730
0x72798c cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:23342
0x72798c cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:17064
0x72832c cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23801
0x7285b2 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:23592
0x731ab9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11336
0x731baa cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11258
0x731ebf cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4109
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/64924] New: Callback function passed as a parameter with typename declaration produces an ICE.

[martin.boretto at tallertechnologies dot com]

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

Bug ID: 64924
   Summary: Callback function passed as a parameter with typename
declaration produces an ICE.
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.boretto at tallertechnologies dot com

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

The code below produces an ICE error:


// --
template
class PP
{
public:
/**
* @brief Constructor with instance and callback function.
*/
PP(T* instance, typename PP::CallbackFunction callbackFunction);

private:
/**
* @brief callback function.
*/
typedef void (T::*CallbackFunction)(void);
};

template
PP::PP(T* instance, CallbackFunction callbackFunction)
{}


// --
class JJ
{
public:
/**
* Constructor class.
*/
JJ():
_attr(this, &JJ::m)
{}

/**
* @brief Call back function.
*/
void m()
{}

private:
/** @brief Class attribute instantiated with "this" class. */
PP _attr;
};

// --

int main(int argc, char const *argv[])
{
JJ juancillo;
return 0;
}


Execution:

g++ -std=c++11 -Wall -Wextra -ansi -pedantic-errors example.cpp -o example

[Bug c/64918] invalid (?) warning when initializing structure

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
There isn't currently an option to disable this warning.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
Summary|[5 Regression] FAIL:|[4.9/5 Regression] FAIL:
   |gfortran.dg/class_allocate_ |gfortran.dg/class_allocate_
   |18.f90 with -fPIC   |18.f90

--- Comment #3 from H.J. Lu  ---
gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
and 4.9 branch:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html

It is caused by r220191.

[Bug c++/64877] [5 Regression] strange warning message from -Waddress

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC|paolo.carlini at oracle dot com|
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #8 from Paolo Carlini  ---
Fixed.

[Bug c++/64877] [5 Regression] strange warning message from -Waddress

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Feb  3 17:21:49 2015
New Revision: 220374

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

PR c++/64877
* typeck.c (cp_build_binary_op): Avoid spurious -Waddress warnings
for generated expressions.

/testsuite
2015-02-03  Paolo Carlini  

PR c++/64877
* g++.dg/warn/Waddress-2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Waddress-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
I got

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xF763FACE
#1  0xF763EBDE
#2  0xF773CBBF
#3  0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
#4  0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
#5  0x8048A59 in MAIN__ at class_allocate_18.f90:?
FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test

But I couldn't reproduce it on another machine. I will keep an eye on it.

[Bug jit/64810] jit not working on armv7hl ("ld: error: /tmp/libgccjit-ZGemdr/fake.so uses VFP register arguments, /tmp/ccJFCBsE.o does not")

[dmalcolm at gcc dot gnu.org]

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

--- Comment #24 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb  3 17:19:58 2015
New Revision: 220373

URL: https://gcc.gnu.org/viewcvs?rev=220373&root=gcc&view=rev
Log:
PR jit/64810: driver, arm, jit: configure-time default options

gcc/ChangeLog:
PR jit/64810
* Makefile.in (GCC_OBJS): Add gcc-main.o.
* gcc-main.c: New file, containing "main" taken from gcc.c.
* gcc.c (do_self_spec): Free decoded_options.
(class driver): Move declaration to gcc.h.
(main): Move declaration and implementation to new file
gcc-main.c.
(driver_get_configure_time_options): New function.
* gcc.h (class driver): Move this declaration here, from
gcc.c.
(driver_get_configure_time_options): New declaration.

gcc/jit/ChangeLog:
PR jit/64810
* Make-lang.in (jit_OBJS): Add jit/jit-spec.o and gcc.o.
(LIBGCCJIT_FILENAME): Add EXTRA_GCC_OBJS.
* jit-playback.c: Include gcc.h.
(gcc::jit::playback::context::compile): Move mutex acquisition
to before the call to make_fake_args.
(append_arg_from_driver): New function.
(gcc::jit::playback::context::make_fake_args): On the first call,
call into driver_get_configure_time_options to get configure-time
default options and cache them.  Add them to the args for
toplev::main.
* jit-spec.c: New source file.
* docs/internals/test-hello-world.exe.log.txt: Update to reflect
above changes.


Added:
trunk/gcc/gcc-main.c
trunk/gcc/jit/jit-spec.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/gcc.c
trunk/gcc/gcc.h
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/Make-lang.in
trunk/gcc/jit/docs/_build/texinfo/libgccjit.texi
trunk/gcc/jit/docs/internals/test-hello-world.exe.log.txt
trunk/gcc/jit/jit-playback.c

[Bug c/64923] [s390] Generated code uses struct padding instead of just the bitfield

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
It is checking the sign bit via a compare and then less than or greater/equal
than zero. So it does not depend on the other bits. This is a false warning
from valgrind.

[Bug c/64923] New: [s390] Generated code uses struct padding instead of just the bitfield

[siddhesh at redhat dot com]

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

Bug ID: 64923
   Summary: [s390] Generated code uses struct padding instead of
just the bitfield
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at redhat dot com

Reproducer:

struct obstack
{
  unsigned use_extra_arg:1;
  unsigned extra_bitfield:1;
};

void
myfree (void *f)
{
}

void (*freefun) (void *) = myfree;

void
obstack_free (struct obstack *h, void *obj)
{
  if (h->use_extra_arg)
freefun ((void *) 0x42);
  else
freefun ((void *) 0x0);
}

int
main (int argc, char **argv)
{
  struct obstack ob;

  ob.use_extra_arg = 0;

  obstack_free (&ob, (void *) 0);
  return 0;
}

Build with:

gcc -g -O2 -o obs{,.c}

$ valgrind ./obs
==20292== Memcheck, a memory error detector
==20292== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20292== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20292== Command: ./obs
==20292== 
==20292== Conditional jump or move depends on uninitialised value(s)
==20292==at 0x85B4: obstack_free (obs.min.c:17)
==20292==by 0x8455: main (obs.min.c:30)
==20292== 
==20292== 
==20292== HEAP SUMMARY:
==20292== in use at exit: 0 bytes in 0 blocks
==20292==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==20292== 
==20292== All heap blocks were freed -- no leaks are possible
==20292== 
==20292== For counts of detected and suppressed errors, rerun with: -v
==20292== Use --track-origins=yes to see where uninitialised values come from
==20292== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

This works correctly on x86 since the generated code explicitly selects the
relevant bit in the bitfield to test. s390x on the other hand doesn't when
built with -O2.  It looks like the instruction combiner pass removes the AND
operation that selects the bit and instead tests the entire word.

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
My current understanding is that the std::string "foo" temporary is
constructed, then destructed, then a store to here is performed (where here
shares the stack slot with std::string "foo" temporary), and then for some
reason the std:;string temporary is destructed again.

[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
   Severity|normal  |enhancement

--- Comment #14 from Segher Boessenkool  ---
Mine.

[Bug c/64918] invalid (?) warning when initializing structure

[oystein at gnubg dot org]

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

--- Comment #2 from Øystein Schønning-Johansen  ---
Really insightful, Joseph. I do understand the warning a bit better now. I have
not looked into the GCC parsing code, but based on your description and my
(limited) understanding of the problem, I guess a fix is not trivial? Can I
suppress this warning in any way?

-Ø

[Bug rtl-optimization/64688] [4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
Sorry, I should have just changed the regression marker on this rather than
closing.  Sorry for making more work for folks.

Vlad & Jakub are in the best position to decide if this ought to be backported.

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Program received signal SIGSEGV, Segmentation fault.
0x004018e7 in __exchange_and_add (__val=-1, __mem=0xfff9)
at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:49
49  { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL); }
(gdb) bt
#0  0x004018e7 in __exchange_and_add (__val=-1,
__mem=0xfff9)
at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:49
#1  __exchange_and_add_dispatch (__val=-1, __mem=0xfff9)
at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/ext/atomicity.h:82
#2  _M_dispose (__a=..., this=0xffe9)
at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2639
#3  ~basic_string (this=0x7fffde70, __in_chrg=)
at
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2941
#4  File::File (this=0x7fffdf10, file_name=...) at x.cc:89
#5  0x00400c49 in main (argc=, argv=0x7fffe058) at
x.cc:143

[Bug middle-end/64922] runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
It might have started with r219695.  Or maybe with r219823.

[Bug middle-end/64922] New: runtime error: member call on misaligned address for type 'struct _Rep'

[mpolacek at gcc dot gnu.org]

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

Bug ID: 64922
   Summary: runtime error: member call on misaligned address for
type 'struct _Rep'
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org

Compile x.cc with -fsanitize=alignment,bool,enum -O2
-D_GLIBCXX_USE_CXX11_ABI=0.  Then run the generated binary:

$ ./a.out d_mos1.model
/home/marek/x/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:2941:9:
runtime error: member call on misaligned address 0xffe9 for type
'struct _Rep', which requires 8 byte alignment
0xffe9: note: pointer points here

Segmentation fault (core dumped)

That runtime error seems like a bug.  Note that the failure goes away with e.g.
-fno-tree-fre.  Without -fsanitize=... it doesn't even segfault, which is what
makes this bug extremely hard to analyze.  Also I haven't manage to reduce the
test case more.

$ cat d_mos1.model
/**/
$ cat x.cc
#include 
class CS_FILE {};
class CS {
private:
  char* _name;
  char* _cmd;
  int  _cnt;
  bool _ok;
  int  _length;
  static enum MATCH_STYLE {msPARTIAL, msIGNORE_CASE, msEXACT} _ms;
public:
  explicitCS(CS_FILE, const std::string& name, int i=0);
  int  cursor()const{return _cnt;}
  boolstuck(int* last){bool ok=*last<_cnt; *last=_cnt; return !ok;}
operator bool()const{return _ok;}
  char  peek()const{return _cmd[_cnt];}
  bool  ns_more()const{return peek()!='\0';}
  CS&  dmatch(const std::string&);
  bool  match1(char c)const{return (peek()==c);}
  CS&  skip(int c=1){_cnt+=c; _ok=_cnt<=_length; return *this;}
  CS&  skipbl();
  CS&  skip1b(char);
  CS&  skip1(char);
  CS&  skipto1(char);
  CS&  operator>>(const char x){return skip1b(x);}
};
template 
inline bool get(CS& cmd, const std::string& key, T* val)
{
  if (cmd.dmatch(key)) {
cmd >> '=' >> *val;
return true;
  }
  return false;
}
template 
inline CS& operator>>(CS& cmd, T& val)
{
  val.parse(cmd);
  return cmd;
}
class Base;
class Code_Block;
class Head;
class File;
class CS;
class Base
{
public:
  virtual void parse(CS&) = 0;
  virtual ~Base() {}
};
class Code_Block
  :public Base
{
  const char* _begin;
  const char* _end;
public:
  void parse(CS& f);
  Code_Block() :_begin(0), _end(0) {}
};
class Head
  :public Base
{
public:
  void parse(CS& f);
};
class File
{
  std::string_name;
  CS_file;
  Head_head;
  Code_Block_h_headers;
public:
  File(const std::string& file_name);
};
void Code_Block::parse(CS& file) 
{
  file.skipbl().skip1('{');
}
void Head::parse(CS& file)
{
  file.skipto1('*');
}
File::File(const std::string& file_name)
  :_name(file_name),
   _file(CS_FILE(), file_name)
{
  get(_file, "foo", &_head);
  int here = _file.cursor();
  for (;;) {
  get(_file, "X", &_h_headers)
  || get(_file, "X", &_h_headers)
  || get(_file, "X", &_h_headers)
  ;
if (_file.stuck(&here))
  break;
  }
}
CS::MATCH_STYLE CS::_ms(msPARTIAL);
CS& CS::dmatch(const std::string& s)
{
  asm ("": "+r" (_ms));
  return *this;
}
CS::CS(CS_FILE, const std::string& name, int i)
  :_name(0),
   _cmd(0),
   _cnt(i),
   _ok(true),
   _length(0)
{
  _name = new char[name.length()+1];
  __builtin_strcpy(_name, name.c_str());
  _length = 1;
  _cmd = new char[_length+2];
  _cmd[_length++] = '\0';
}
CS& CS::skipbl()
{
  while (peek() && (!isgraph(peek(
skip();
  return *this;
}
CS& CS::skip1b(char t)
{
  return *this;
}
CS& CS::skip1(char t)
{
  if (match1(t))
skip();
  return *this;
}
CS& CS::skipto1(char c)
{
  while (ns_more() && !match1(c))
skip();
  return *this;
}
int main(int argc, char** argv)
{
  File f(argv[1]);
}

[Bug middle-end/61225] [5/6 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|5.0 |6.0
Summary|[5 Regression] Several new  |[5/6 Regression] Several
   |failures after r210458 on   |new failures after r210458
   |x86_64-*-* with -m32|on x86_64-*-* with -m32

--- Comment #23 from Jakub Jelinek  ---
So deferring to 6.0 then.

[Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
r220371 generates identical code to r220350 on this testcase.
Do you mean libgfortran.so has been miscompiled?
But then really -fPIC shouldn't matter here, as libgfortran is built with
-fpic, and I've certainly bootstrapped/regtested my patch on both i686-linux
and x86_64-linux.

[Bug c/64918] invalid (?) warning when initializing structure

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I think the logical side-effect in C standard terms of the initializer 
being overridden is that it contains a compound literal, and so executing 
that initializer has the side-effect of initializing that compound literal 
(compound literal initializers being executed each time the compound 
literal is reached in the order of execution).  The warning is because 
it's unspecified whether overridden initializers are executed at all, and 
so whether their side-effects occur - but in this case it's maybe not so 
helpful, because the compound literal in the overridden initializer can't 
actually be accessed so it doesn't matter if the side-effect of 
initializing it gets lost (unless any of its initializers contained other 
side-effects, which they don't in this case).

[Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC

[hjl.tools at gmail dot com]

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

Bug ID: 64921
   Summary: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
with -fPIC
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com

On x86-32, r220369 gave

FAIL: gfortran.dg/class_allocate_18.f90   -O0  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O1  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O2  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -O3 -g  execution test
FAIL: gfortran.dg/class_allocate_18.f90   -Os  execution test

when -fPIC is used.  r220364 is OK.

[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[rafael.espindola at gmail dot com]

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

Rafael Avila de Espindola  changed:

   What|Removed |Added

 CC||rafael.espindola at gmail dot 
com

--- Comment #13 from Rafael Avila de Espindola  ---
See also
https://sourceware.org/bugzilla/show_bug.cgi?id=17902

[Bug fortran/59765] [4.9/5 Regression] [OOP] ICE on valid with finalizable array components

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #14 from Mikael Morin  ---
(In reply to janus from comment #5)
> Either we have to scalarize this later on (this is currently not
> implemented, because this is forbidden in actual Fortran code, see comment
> 4), or we have to generate a loop directly instead of the full-array
> expression.

For what it's worth, class.c's finalizer_insert_packed call generates a
scalarization loop "by hand"; maybe part of it can be reused.

[Bug fortran/63744] [4.8/4.9/5 Regression] Duplicate use-statement causes error

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin  ---
Created attachment 34658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34658&action=edit
check the symtree (local) name instead of the original name

Here is a patch to accept it.

I think it makes sense to accept it; it's not ambiguous.
The current error message is at least confusing.

[Bug middle-end/64920] New: bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1

[burnus at gcc dot gnu.org]

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

Bug ID: 64920
   Summary: bootstrap-ubsan [build/gengtype -r gtype.state]:
libiberty/regex.c:6970:11: runtime error: left shift
of negative value -1
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
Depends on: 63426

Running bootstrap-ubsan on x86_64 shows the following error during stage 2 for

build/gengtype -r gtype.state

../../libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
../../libiberty/regex.c:7165:4: runtime error: left shift of negative value -1


The debugger shows:

Breakpoint 3, byte_re_match_2_internal (bufp=bufp@entry=0x7fffda70,
string1=string1@entry=0x0, size1=size1@entry=0, string2=string2@entry=0x93773d
"../../gcc/objc/objc-next-runtime-abi-02.c", size2=size2@entry=41,
pos=pos@entry=0, regs=0x7fffda50, stop=41)
at ../../libiberty/regex.c:6970
6970  EXTRACT_NUMBER_AND_INCR (mcnt, p);

(gdb) p p
$3 = (unsigned char *) 0xb80116 "\362\377\002\001/\a\002"

(gdb) p mcnt
$4 = 

(gdb) bt
#0  byte_re_match_2_internal (bufp=bufp@entry=0x7fffda70,
string1=string1@entry=0x0, size1=size1@entry=0, string2=string2@entry=0x93773d
"../../gcc/objc/objc-next-runtime-abi-02.c", size2=size2@entry=41,
pos=pos@entry=0, regs=0x7fffda50, stop=41)
at ../../libiberty/regex.c:6970
#1  0x00439f63 in byte_re_search_2 (bufp=bufp@entry=0x7fffda70,
string1=string1@entry=0x0, size1=size1@entry=0, string2=string2@entry=0x93773d
"../../gcc/objc/objc-next-runtime-abi-02.c", size2=size2@entry=41,
startpos=startpos@entry=0, range=1,
regs=0x7fffda50, stop=41) at ../../libiberty/regex.c:5208
#2  0x004442e8 in xre_search_2 (stop=, regs=, range=, startpos=0, size2=,
string2=0x93773d "../../gcc/objc/objc-next-runtime-abi-02.c", size1=0,
string1=0x0, bufp=)
at ../../libiberty/regex.c:4961
#3  xre_search (regs=, range=, startpos=0,
size=, string=0x93773d
"../../gcc/objc/objc-next-runtime-abi-02.c", bufp=) at
../../libiberty/regex.c:4921
#4  xregexec (preg=0xb87f80, string=0x93773d
"../../gcc/objc/objc-next-runtime-abi-02.c", nmatch=10, pmatch=0x7fffdb30,
eflags=) at ../../libiberty/regex.c:8036
#5  0x00413a29 in get_output_file_with_visibility (inpf=0x937730) at
../../gcc/gengtype.c:2221
#6  0x0041a148 in write_func_for_structure (orig_s=0x9377b0,
s=0x9377b0, wtd=0x4743e0 ) at ../../gcc/gengtype.c:3512
#7  0x0041b80c in write_types (output_header=,
structures=, wtd=0x4743e0 ) at
../../gcc/gengtype.c:3786
#8  0x00404acd in main (argc=, argv=) at
../../gcc/gengtype.c:5368

[Bug target/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2015-02/msg00135.ht
   ||ml
 CC|amodra at gcc dot gnu.org, |
   |amodra at gmail dot com|
   Target Milestone|--- |5.0

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

Torbjörn Gard  changed:

   What|Removed |Added

  Attachment #34656|0   |1
is obsolete||

--- Comment #5 from Torbjörn Gard  ---
Created attachment 34657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34657&action=edit
Top level config log

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

--- Comment #4 from Torbjörn Gard  ---
Created attachment 34656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34656&action=edit
top level config.log

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

--- Comment #3 from Torbjörn Gard  ---
Created attachment 34655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34655&action=edit
confg.log for libgcc

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

--- Comment #2 from Torbjörn Gard  ---
Created attachment 34654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34654&action=edit
Using truss for the compile: Note that cc1 command does not exist

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

Torbjörn Gard  changed:

   What|Removed |Added

 CC||tgard at opentext dot com

--- Comment #1 from Torbjörn Gard  ---
Created attachment 34653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34653&action=edit
Manual compile with config.log values

[Bug bootstrap/64919] New: bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[tgard at opentext dot com]

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

Bug ID: 64919
   Summary: bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tgard at opentext dot com

Created attachment 34652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34652&action=edit
The command from config.log which fails

The HPUX version is 11.31
gcc-4.9.2 did not bootstrap using HPUX aCC so I installed gcc-4.7.2 and used
this.

The latest gnu assembler is used as I failed to get gcc-4.7.2 to work.

The error is:
---
configure:3389: /builds/gbgbuild/bld/gcc/stbldh01/obj-4.9.2/./gcc/xgcc
-B/builds/gbgbuild/bld/gcc/stbldh01/obj-4.9.2/./gcc/
-B/usr/local/gcc-4.9.2/ia64-hp-hpux11.31/bin/
-B/usr/local/gcc-4.9.2/ia64-hp-hpux11.31/lib/ -isystem
/usr/local/gcc-4.9.2/ia64-hp-hpux11.31/include -isystem
/usr/local/gcc-4.9.2/ia64-hp-hpux11.31/sys-include-o conftest -g -O2  
conftest.c  >&5
conftest.c: In function 'main':
conftest.c:11:1: internal compiler error: Segmentation fault
 main ()
 ^
libbacktrace could not find executable to open
Please submit a full bug report,

configure:3620: error: in
`/builds/gbgbuild/bld/gcc/stbldh01/obj-4.9.2/ia64-hp-hpux11.31/libgcc':
configure:3623: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
--
See also attachments

[Bug c/64918] New: invalid (?) warning when initializing structure

[oystein at gnubg dot org]

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

Bug ID: 64918
   Summary: invalid (?) warning when initializing structure
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oystein at gnubg dot org

Created attachment 34651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34651&action=edit
Code that trigger the invalid warning.

Hi!

I'm initializing a complex structure with designated initialisers and
overriding an array element (intentionally), and I then get the error message:

sideffects.c:26:13: warning: initialized field with side-effects overwritten
 [3] = { .func = thefunction, .args = &((char*[]){"foo4", "bar4",
"baz4"})},
 ^
sideffects.c:26:13: warning: (near initialization for 'myconfig.config[3]')

However I do believe my code is correct. It complains about initializing with
side-effects, but I think my code is legal c99. (Please tell me otherwise.)

I compile the attached code with:
gcc -std=gnu99 -Wall -Wextra -Wno-override-init sideeffects.c -o sideeffects

I have tried several different versions of GCC, and here is a short summary:

GCC 4.9.2 (Arch Linux x86_64)  -> Warning generated.
GCC 4.9.2 (Mingw32-w64 x86_64) -> Warning generated.
GCC 4.8.0 (Linux x86_64)   -> Warning generated. 
GCC 4.4.7 (Red Hat 4.4.7-4)-> No warning.
GCC 4.1.2 (Red Hat 4.1.2-52)   -> No warning.
clang 3.5.1 (Arch Linux)   -> No warning.

Best regards,
-Øystein



Full info on compilers used (Those that generates warning):

[oystein@jupiter ~]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20141224/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20141224 (prerelease) (GCC)


[14:29:03,90 c:\APPL]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Program\
Files/mingw-w64/x86_64-4.9.2-posix-seh-rt_v3-rev1/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw492/x86_64-492-posix-seh-rt_v3-rev1/mingw64
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-isl-version-check --disable-cloog-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw492/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw492/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw492/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw492/prerequisites/x86_64-w64-mingw32-static
--with-cloog=/c/mingw492/prerequisites/x86_64-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='x86_64-posix-seh-rev1, Built by
MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64
CFLAGS='-O2 -pipe
-I/c/mingw492/x86_64-492-posix-seh-rt_v3-rev1/mingw64/opt/include
-I/c/mingw492/prerequisites/x86_64-zlib-static/include
-I/c/mingw492/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw492/x86_64-492-posix-seh-rt_v3-rev1/mingw64/opt/include
-I/c/mingw492/prerequisites/x86_64-zlib-static/include
-I/c/mingw492/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw492/x86_64-492-posix-seh-rt_v3-rev1/mingw64/opt/lib
-L/c/mingw492/prerequisites/x86_64-zlib-static/lib
-L/c/mingw492/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 4.9.2 (x86_64-posix-seh-rev1, Built by MinGW-W64 project)

[ojohans@st-linapp30 ~/tmp]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=

[Bug rtl-optimization/64916] [5.0 regression] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target||arm*
 Status|UNCONFIRMED |NEW
  Known to work||4.8.0, 4.8.1, 4.8.2, 4.9.0,
   ||4.9.1, 4.9.2
   Last reconfirmed||2015-02-03
  Component|testsuite   |rtl-optimization
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ira.c update_equiv_regs |[5.0 regression] ira.c
   |patch causes|update_equiv_regs patch
   |gcc/testsuite/gcc.target/ar |causes
   |m/pr43920-2.c regression|gcc/testsuite/gcc.target/ar
   ||m/pr43920-2.c regression
  Known to fail||5.0
  Build|arm-none-eabi   |

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug java/64917] Remove spurious '^L' from libjava/libltdl/COPYING.LIB.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The control l mark a new page. 

Also libltdl is imported from an upstream sources.

[Bug java/64917] New: Remove spurious '^L' from libjava/libltdl/COPYING.LIB.

[sam.ellis at arm dot com]

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

Bug ID: 64917
   Summary: Remove spurious '^L' from libjava/libltdl/COPYING.LIB.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: java
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sam.ellis at arm dot com

The file libjava/libltdl/COPYING.LIB contains spurious text '^L' amongst the
licenses, which makes it hard for automated license scanning tools to
accurately match against this license. Please can these characters be removed.
The can be seen on lines 60, 117, 223, 274, 336, 377, 430, 464 here:

https://gcc.gnu.org/viewcvs/gcc/trunk/libjava/libltdl/COPYING.LIB?view=markup

[Bug testsuite/64916] New: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

[Alex.Velenko at arm dot com]

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

Bug ID: 64916
   Summary: ira.c update_equiv_regs patch causes
gcc/testsuite/gcc.target/arm/pr43920-2.c regression
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Alex.Velenko at arm dot com
CC: amker.cheng at gmail dot com, fei.yang0953 at gmail dot com,
law at redhat dot com, marcus.shawcroft at arm dot com
 Build: arm-none-eabi

Created attachment 34650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34650&action=edit
Tar with patched and non-patched rtl dump file tars

In pr43920-2.c code block for "return -1;" c statement is not getting reused
after
ira.c update_equiv_regs patch. I believe svn it's number is r216169.
Reason - patch removes "(expr_list:REG_EQUAL (const_int -1
[0x])" note in ira pass, which prevents jump2 optimization.
This information still needs to be passed to jump2 pass.
See rtl dump attachments below.

[Bug c++/64915] New: lambda partially drops constness of 'this'

[gene at staubsaal dot de]

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

Bug ID: 64915
   Summary: lambda partially drops constness of 'this'
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gene at staubsaal dot de

When calling a non-const member function inside a lambda expression the
constness of 'this' is being ignored:

Example example.cpp:
struct Foo {
int x;
void bar() const {
[=]() { bad(); }(); // This sould be an compiler error
}
void bad() {
x = 42;
}
};

compiled with: g++ -std=c++11 -Wall -Wextra


More Info
$ gcc --version
gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

[Bug target/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':

[gang.chen.5i5j at gmail dot com]

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

--- Comment #16 from Chen Gang  ---
(In reply to Jeffrey A. Law from comment #15)
> The patch needs to be reviewed.  It's been a long time since I thought about
> the _STRICT variants of the REG_OK_ macros and how all that's supposed to
> work.  I'll have to read up on their semantics before I can review this
> patch.

Can I do anything helpful for this issue, next? If I can, please let me know,
and I shall try.

[Bug middle-end/61225] [5 Regression] Several new failures after r210458 on x86_64-*-* with -m32

[segher at gcc dot gnu.org]

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

--- Comment #22 from Segher Boessenkool  ---
Author: segher
Date: Tue Feb  3 12:15:32 2015
New Revision: 220370

URL: https://gcc.gnu.org/viewcvs?rev=220370&root=gcc&view=rev
Log:
PR middle-end/61225
gcc.target/i386/pr49095.c: XFAIL for ia32.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug rtl-optimization/56590] Replace auto-inc-dec pass with generic address mode selection pass

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
(In reply to amker from comment #1)
> This surely sounds interesting.  Like I suggested in PR62173, RTL optimizer
> might be able to do more in address expression re-association and addressing
> mode choosing.
> But it's difficult to change base/offset for addresses which are IVOPTed on
> GIMPLE.

(Proper) AMS is a difficult problem and depends a lot on the target address
mode capabilities and the context of the memory accesses.  I wouldn't try to do
that on GIMPLE or in ivopt.  There's simply not enough information on the
instructions that will be used for actually carrying out the memory accesses. 
Whatever is done on GIMPLE without taking the target into account will result
in missed optimization cases eventually.  I would rather not distribute the AMS
problem across sevaral compilation phases like doing a bit on GIMPLE and doing
a bit on RTL later.  Of course it'd be helpful if the tree optimizers can
prepare some things that make AMS optimization more successful.  But generally
I think an AMS pass should be able to work on its own.

[Bug sanitizer/64914] [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org
  Component|c++ |sanitizer
Summary|With -g3:   |[UBSAN/bootstrap-ubsan]
   |libiberty/md5.c:336:7:  |With -g3:
   |runtime error: load of  |libiberty/md5.c:336:7:
   |misaligned address  for |runtime error: load of
   |type 'const md5_uint32',|misaligned address  for
   |which requires 4 byte   |type 'const md5_uint32',
   |alignment   |which requires 4 byte
   ||alignment

--- Comment #1 from Tobias Burnus  ---
The run-time error occurs for libiberty/md5.c:336 to 350, which look like:

  OP (B, C, D, A, 22, (md5_uint32) 0x49b40821);

with definitions:

  md5_uint32 A = ctx->A;
  md5_uint32 B = ctx->B;
  md5_uint32 C = ctx->C;
  md5_uint32 D = ctx->D;


#define OP(a, b, c, d, s, T)\
  do\
{   \
  a += FF (b, c, d) + (*cwp++ = SWAP (*words)) + T; \
  ++words;  \
  CYCLIC (a, s);\
  a += b;   \
}   \
  while (0)

At a glance, the code looks fine.

[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #14 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> I'm about to install a patch that changes the costs on SPARC 64-bit to:
> 
> Use 1:
>   cand  costcompl.  depends on
>   0 4   0inv_expr:0
>   1 8   0   
>   4 6   0inv_expr:1
>   5 0   0   
>   6 0   0
> 
> but this doesn't change the outcome of the test. :-(

I will have a look why it fails with refined cost.

Thanks,
bin

[Bug c++/64914] New: With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment

[burnus at gcc dot gnu.org]

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

Bug ID: 64914
   Summary: With -g3: libiberty/md5.c:336:7: runtime error: load
of misaligned address  for type 'const md5_uint32',
which requires 4 byte alignment
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
Blocks: 63426

Created attachment 34649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34649&action=edit
test.ii - compile with "g++ -g3" (UBSAN GCC build)

That's with a --with-build-config=bootstrap-ubsan GCC build.

Compiling a program with "g++ -g3" leads to the ICE:

../../libiberty/md5.c:336:7: runtime error: load of misaligned address
0x7fe74964c553 for type 'const md5_uint32', which requires 4 byte alignment


(If you prefer an .ii file, remove the

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

[dodji at gcc dot gnu.org]

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

--- Comment #19 from Dodji Seketeli  ---
(In reply to Tom Tromey from comment #16)
> I've tripped across this enough that I've actually filed dups twice now.
> 
> I think it would be best to change the ordering here.
> That is, the initial error ought to generally be the
> location of the outermost expansion.  Then, the remaining
> notes ought to delineate the macro expansions.
> 
> While it is true that this will yield a sub-optimal result in some
> cases, I think that it will have better results in the preponderance
> of cases.  That is, there's no way to be perfect here but gcc could be more
> useful.


I am starting to think the same here.  In the unwinding, it seems less
surprising to start from the code the user has the most chance to have written
herself, that is, the code at the point of expansion of the outermost macro,
rather than the point where the offending token was spelled -- which can be
hidden anywhere.

If everyone agrees, then I am okay to change the unwinding direction for the
next stage 1.

Manuel, Jonathan, what do you think?

[Bug target/64851] [SH] Add atomic not

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #2 from Oleg Endo  ---
Fixed for GCC 5.