[Bug bootstrap/61440] New: Bootstrap failure with --with-build-config=bootstrap-lto

[venkataramanan.kumar at amd dot com]

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

Bug ID: 61440
   Summary: Bootstrap failure with
--with-build-config=bootstrap-lto
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: venkataramanan.kumar at amd dot com

Machine - AMD64 (bdver1)
GCC FSF 4.9 branch 

Configure command
/work/sources/gcc/configure --with-build-config=bootstrap-lto
--prefix=/work/builds/basedon4.9branch/install --enable-languages=c,c++,fortran
--disable-werror

(Snip)
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ipa-inline-analysis.o differs
gcc/tree-ssa-uninit.o differs
gcc/ipa-devirt.o differs
gcc/tree-cfg.o differs
gcc/coverage.o differs
gcc/tree-eh.o differs
gcc/gimple-low.o differs
gcc/dumpfile.o differs
gcc/sel-sched-ir.o differs
gcc/build/genconfig.o differs
gcc/build/genpeep.o differs
gcc/tree-outof-ssa.o differs
gcc/emit-rtl.o differs
gcc/c-family/c-ada-spec.o differs
gcc/c-family/c-pragma.o differs
gcc/tree-diagnostic.o differs
gcc/omp-low.o differs
gcc/tree-sra.o differs
gcc/gimple.o differs
gcc/c/c-parser.o differs
gcc/c/c-typeck.o differs
gcc/cp/pt.o differs
gcc/cp/cp-gimplify.o differs
gcc/cp/parser.o differs
gcc/cp/name-lookup.o differs
gcc/cp/semantics.o differs
gcc/cp/class.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/cfgloopmanip.o differs
gcc/dwarf2cfi.o differs
gcc/tree-inline.o differs
gcc/tree-vrp.o differs
gcc/tree-switch-conversion.o differs
gcc/lto-cgraph.o differs
gcc/tree-ssa-propagate.o differs
gcc/cgraphunit.o differs
gcc/cfgexpand.o differs
gcc/cfgrtl.o differs
gcc/cfgloop.o differs
gcc/reload1.o differs
gcc/dbxout.o differs
gcc/i386.o differs
gcc/dwarf2out.o differs
gcc/varasm.o differs
gcc/tree-ssa-operands.o differs
gcc/sched-rgn.o differs
gcc/function.o differs
gcc/except.o differs
gcc/sel-sched.o differs
gcc/lto-streamer-out.o differs
gcc/tree-ssa-pre.o differs
gcc/tree.o differs
libcpp/lex.o differs
make[2]: *** [compare] Error 1
(Snip)

[Bug bootstrap/61440] Bootstrap failure with --with-build-config=bootstrap-lto

[venkataramanan.kumar at amd dot com]

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

--- Comment #1 from Venkataramanan  ---
Tried 

 objdump -d stage2-gcc/gimple.o >   stage2-gcc-gimple.s
 objdump -d stage3-gcc/gimple.o >   stage3-gcc-gimple.s

 diff -u  stage2-gcc-gimple.s stage3-gcc-gimple.s
--- stage2-gcc-gimple.s 2014-06-07 12:53:04.065381401 +0530
+++ stage3-gcc-gimple.s 2014-06-07 12:53:10.981381355 +0530
@@ -1,5 +1,5 @@

-stage2-gcc/gimple.o: file format elf64-x86-64
+stage3-gcc/gimple.o: file format elf64-x86-64


Tried 
readelf -S stage2-gcc/gimple.o > stage2-gcc-gimple.txt
readelf -S stage3-gcc/gimple.o > stage3-gcc-gimple.txt

diff -u  stage2-gcc-gimple.txt stage3-gcc-gimple.txt

--- stage2-gcc-gimple.txt   2014-06-07 12:56:19.089380090 +0530
+++ stage3-gcc-gimple.txt   2014-06-07 12:56:09.805380153 +0530
@@ -1,4 +1,4 @@
-There are 194 section headers, starting at offset 0xc3750:
+There are 194 section headers, starting at offset 0xc3710:

 Section Headers:
   [Nr] Name  Type Address   Offset
@@ -9,7 +9,7 @@
000c  0004  192   363 4
   [ 2] .text PROGBITS   0050
4ab3    AX   0 0 16
-  [ 3] .rela.textRELA   000cad78
+  [ 3] .rela.textRELA   000cad38
3b58  0018  192 2 8
   [ 4] .data PROGBITS   4b03
    WA   0 0 1
@@ -330,66 +330,66 @@
   [162] .gnu.lto_.refs.0  PROGBITS   0003e76f
03c2     E   0 0 1
   [163] .gnu.lto_.decls.0 PROGBITS   0003eb31
-   0002d715     E   0 0 1
-  [164] .gnu.lto_.symtab. PROGBITS   0006c246
+   0002d70b     E   0 0 1
+  [164] .gnu.lto_.symtab. PROGBITS   0006c23c
2afc     E   0 0 1
-  [165] .gnu.lto_.optsPROGBITS   0006ed42
+  [165] .gnu.lto_.optsPROGBITS   0006ed38
00a2     E   0 0 1
-  [166] .text.unlikelyPROGBITS   0006ede4
+  [166] .text.unlikelyPROGBITS   0006edda
0015    AX   0 0 1
-  [167] .rela.text.unlike RELA   000ce8d0
+  [167] .rela.text.unlike RELA   000ce890
0048  0018  192   166 8
-  [168] .rodata.str1.8PROGBITS   0006ee00
+  [168] .rodata.str1.8PROGBITS   0006edf0
001f  0001 AMS   0 0 8
-  [169] .rodata.str1.1PROGBITS   0006ee1f
+  [169] .rodata.str1.1PROGBITS   0006ee0f
02e8  0001 AMS   0 0 1
-  [170] .rodata   PROGBITS   0006f140
+  [170] .rodata   PROGBITS   0006f100
0810     A   0 0 64
-  [171] .rela.rodata  RELA   000ce918
+  [171] .rela.rodata  RELA   000ce8d8
06a8  0018  192   170 8
-  [172] .text.unlikely._Z PROGBITS   0006f950
+  [172] .text.unlikely._Z PROGBITS   0006f910
   AXG   0 0 2
-  [173] .text._ZN5va_gc7r PROGBITS   0006f950
+  [173] .text._ZN5va_gc7r PROGBITS   0006f910
00d7   AXG   0 0 16
-  [174] .rela.text._ZN5va RELA   000cefc0
+  [174] .rela.text._ZN5va RELA   000cef80
0060  0018  192   173 8
-  [175] .debug_info   PROGBITS   0006fa27
+  [175] .debug_info   PROGBITS   0006f9e7
0001e7f2     0 0 1
-  [176] .rela.debug_info  RELA   000cf020
+  [176] .rela.debug_info  RELA   000cefe0
000341b8  0018  192   175 8
-  [177] .debug_abbrev PROGBITS   0008e219
+  [177] .debug_abbrev PROGBITS   0008e1d9
0a8e     0 0 1
-  [178] .debug_locPROGBITS   0008eca7
+  [178] .debug_locPR

[Bug fortran/29602] [F2003] I/O specifiers can now be of any kind

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #3 from Francois-Xavier Coudert  ---
This has been fixed since the last comment, as per
https://gcc.gnu.org/ml/fortran/2014-06/msg00064.html

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 29602, which changed state.

Bug 29602 Summary: [F2003] I/O specifiers can now be of any kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29602

   What|Removed |Added

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

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 36462, which changed state.

Bug 36462 Summary: [F03] Audit intrinsics for KIND arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462

   What|Removed |Added

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

[Bug fortran/36462] [F03] Audit intrinsics for KIND arguments

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #6 from Francois-Xavier Coudert  ---
After a long and tedious look through the F2003 and F2008 standards, it appears
we've got this covered.

[Bug fortran/58498] Bogus "Invalid kind for INTEGER"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #4 from Francois-Xavier Coudert  ---
Reduced testcase, to summarize:

  integer, parameter :: arr(1) = [ 1 ]
  integer, parameter :: x(1) = [( range(int(0,arr(i))), i=1,1 )]
  integer :: i
  print *, x
  print *, range(int(0,arr(1)))
  end

Intel wrongly refuses to compile it ("A kind type parameter must be a
compile-time constant"), and IBM compiles it but gives a wrong answer (range of
-51378971).

So it's indeed tricky code. Both prints should output the same number.

[Bug target/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Last reconfirmed|2012-12-04 00:00:00 |2014-6-7

--- Comment #6 from Marc Glisse  ---
Several things:

1) https://gcc.gnu.org/ml/gcc/2014-06/msg00063.html points out that our shrd
patterns wrongly use ashiftrt instead of lshiftrt

2) We can convince the current compiler to generate shrd by constructing
unsigned long long)a)<<32) | b) >> n (take care not to use '+' in place of
'|' because gcc is unable to realize that x+0 has no carry and thus leaves
plenty of unneeded code in that case). For a constant shift, it manages to
clean up all the useless code. At least that works for the 32 bit version with
-m32 and the 64 bit version (using unsigned __int128) with -m64, it doesn't
work for the 32 bit version with -m64.

3) With extra patterns as attached here, combine can handle the case where the
shift amount is constant. However, the non-constant pattern is too big for
combine. The closest it gets to matching is (b<>(l-n)), but replacing l
with 32 is one more substitution than it is willing  to try (it also ignores
the REG_EQUAL note that would give (32-n) with one substitution less).
Improving combine would be nice. I am not sure what intermediate pattern (not
too artificial) we could introduce to help it. Maybe a>>(32-n), though I don't
even know if it is better to implement that as a subtraction and a shift or as
generating zero then using sh[lr]d.

[Bug libfortran/58020] Code for handling IEEE exceptions

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #25 from Francois-Xavier Coudert  ---
Thanks for the suggestion and code. I have decided to follow up a different
route to achieve support of the IEEE intrinsic modules in gfortran (patch
currently submitted for review here:
https://gcc.gnu.org/ml/fortran/2014-06/msg00038.html). I am thus closing this
PR, and marking it as a duplicate of PR29383, so we retain a link between the
two.

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

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fkrogh#gcc at mathalacarte dot 
com

--- Comment #13 from Francois-Xavier Coudert  ---
*** Bug 58020 has been marked as a duplicate of this bug. ***

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bug 29383 depends on bug 58020, which changed state.

Bug 58020 Summary: Code for handling IEEE exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020

   What|Removed |Added

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

[Bug fortran/59026] ELEMENTAL procedure with VALUE arguments emits wrong code

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #3 from Francois-Xavier Coudert  ---
Was fixed on 4.9, not a regression: closing.

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bug 29383 depends on bug 59026, which changed state.

Bug 59026 Summary: ELEMENTAL procedure with VALUE arguments emits wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59026

   What|Removed |Added

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

[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #14 from Francois-Xavier Coudert  ---
I posted a patch adding a rather complete IEEE support here:
https://gcc.gnu.org/ml/fortran/2014-06/msg00038.html

[Bug other/61427] Fail to build due to #error GATHER_STATISTICS must be defined

[Torsten at Robitzki dot de]

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

Torsten Robitzki  changed:

   What|Removed |Added

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

--- Comment #2 from Torsten Robitzki  ---
after unsetting CPLUS_INCLUDE_PATH, DYLD_LIBRARY_PATH and LIBRARY_PATH the
build succeeded. Thanks to all who contribute to gcc!!! :-)

[Bug target/61441] New: ARM aarch64 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

Bug ID: 61441
   Summary: ARM aarch64 fails to quiet signaling NaN
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Host: aarch64-unknown-linux-gnu
Target: aarch64-unknown-linux-gnu
 Build: aarch64-unknown-linux-gnu

Consider the following code:

#define _GNU_SOURCE
#include 
#include 

int main (void)
{
  float sNaN = __builtin_nansf ("");
  double x = (double) sNaN;
  return issignaling(x);
}

It correctly returns 0 at -O0 optimisation level, but returns 1 at -O1 and -O2
optimisation levels.

Here is the generated assembly code at -O0:
00400630 :
  400630:   a9be7bfdstp x29, x30, [sp,#-32]!
  400634:   910003fdmov x29, sp
  400638:   18000160ldr w0, 400664 
  40063c:   b9001fa0str w0, [x29,#28]
  400640:   b9401fa0ldr w0, [x29,#28]
  400644:   1e27fmovs0, w0
  400648:   1e22c000fcvtd0, s0
  40064c:   9e66fmovx0, d0
  400650:   f9000ba0str x0, [x29,#16]
  400654:   fd400ba0ldr d0, [x29,#16]
  400658:   978ebl  400490 <__issignaling@plt>
  40065c:   a8c27bfdldp x29, x30, [sp],#32
  400660:   d65f03c0ret
  400664:   7fa0.word   0x7fa0

Here is the generated assembly code at -O1:
00400630 :
  400630:   a9bf7bfdstp x29, x30, [sp,#-16]!
  400634:   910003fdmov x29, sp
  400638:   5c80ldr d0, 400648 
  40063c:   9795bl  400490 <__issignaling@plt>
  400640:   a8c17bfdldp x29, x30, [sp],#16
  400644:   d65f03c0ret
  400648:   .word   0x
  40064c:   7ff4.word   0x7ff4

As you can see at -O1, the sNaN constant is propagated, and the propagated
value is loaded and passed directly to issignaling. Quoting the IEEE Std 754
standard:
"Under default exception handling, any operation signaling an invalid operation
exception and for which a floating-point result is to be delivered shall
deliver a quiet NaN."

So it looks like the copy propagation is not done correctly, the sNaN should be
silenced in the process.

[Bug libfortran/60468] ./fpu-target.h:93:3: error: unknown type name 'choke'

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||https://gcc.gnu.org/ml/fort
   ||ran/2014-06/msg00082.html
   Last reconfirmed||2014-06-07
 CC||fxcoudert at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Francois-Xavier Coudert  ---
Patch proposed here to fix the issue on hpux10:
https://gcc.gnu.org/ml/fortran/2014-06/msg00082.html

For hpux11, what should be used for FPU control? Googl'ing suggests that HP/UX
has moved to fenv.h support, with additional fegettrapenable/fesettrapenable
function calls. Would you be able to confirm this, and point me to
documentation for hpux11 fenv's documentation? If so, I'm willing to add
support for that platform.

[Bug libfortran/60468] ./fpu-target.h:93:3: error: unknown type name 'choke'

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
Please note that the following patch fixes the issue:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01421.html

[Bug libfortran/58015] FAIL: gfortran.dg/round_4.f90: Unsatisfied symbol "nextafterl"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #11 from Francois-Xavier Coudert  ---
I don't think we want to provide a full long double fallback libc as part of
gfortran. So, I'll close this as WONTFIX: the testcases have been XFAIL'ed, and
the proper course now is to for those targets to provide a full libc, or for
users not to rely on long double types in the meantime.

[Bug c++/61421] Invalid -O2 optimization breaks program

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #20 from Eric Botcazou  ---
> One last comment on strict aliasing rules: It is ironic that these rules are
> supposed to make programs faster, but those developers that really care
> about speed are prevented from implementing even moderate optimizations (see
> discussion) because of these rules! Again, the concept of strict aliasing
> rules is broken.

The strict aliasing rules work well for C, but are indeed more problematic for
higher level languages like C++ or Ada.

[Bug libfortran/60468] ./fpu-target.h:93:3: error: unknown type name 'choke'

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 7-Jun-14, at 6:49 AM, fxcoudert at gcc dot gnu.org wrote:

> For hpux11, what should be used for FPU control? Googl'ing suggests  
> that HP/UX
> has moved to fenv.h support, with additional fegettrapenable/ 
> fesettrapenable
> function calls. Would you be able to confirm this, and point me to
> documentation for hpux11 fenv's documentation? If so, I'm willing to  
> add
> support for that platform.

Correct.  fenv.h is available from 11.00 onward.  The following calls  
are defined:

extern void feclearexcept(int);
extern void fegetexceptflag(fexcept_t *, int);
extern void feraiseexcept(int);
extern void fesetexceptflag(const fexcept_t *, int);
extern int  fetestexcept(int);
extern int  fegetround(void);
extern int  fesetround(int);
extern void fegetenv(fenv_t *);
extern int  feholdexcept(fenv_t *);
extern void fesetenv(const fenv_t *);
extern void feupdateenv(const fenv_t *);

  extern int  fegetflushtozero(void);
  extern void fesetflushtozero(int);
  extern int  fegettrapenable(void);
  extern void fesettrapenable(int);

In addition, ia64 has:

extern int  fegetprec(void);
extern int  fesetprec(int);

Documentation is getting harder to get online.  The following link is  
for ia64 but should be mostly
relevant :
http://h21007.www2.hp.com/portal/site/dspp/menuitem.863c3e4cbcdc3f3515b49c108973a801/?ciid=0008a22194f02110a22194f02110275d6e10RCRD

I have an older pdf version that is parisc specific.

It seems HP no longer has man pages online, so third-party links are  
all that's available:
http://www.polarhome.com/service/man/generic.php?qf=feclearexcept&type=2&of=HP-UX&sf=3m

Thanks,
Dave

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

[Bug bootstrap/61442] New: [Aarch64] ICE while bootstraping GCC with --with-build-config=bootstrap-lto

[venkataramanan.kumar at amd dot com]

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

Bug ID: 61442
   Summary: [Aarch64] ICE while bootstraping GCC with
--with-build-config=bootstrap-lto
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: venkataramanan.kumar at amd dot com

Machine: Aarch64 
Build Config line: 

./gcc/configure --prefix=/work/GCC_Team/vekumar/ltoinstall/
--with-gmp=/work/GCC_Team/vekumar/installpre/installdir/
--with-build-config=bootstrap-lto
--with-mpfr=/work/GCC_Team/vekumar/installpre/installdir/
--with-mpc=/work/GCC_Team/vekumar/installpre/installdir/ --disable-werror
--enable-languages=c,c++,fortran

(---Snip---)
/root/work/GCC_Team/vekumar/ltobuild/./gcc/xgcc
-B/root/work/GCC_Team/vekumar/ltobuild/./gcc/
-B/work/GCC_Team/vekumar/ltoinstall/aarch64-unknown-linux-gnu/bin/
-B/work/GCC_Team/vekumar/ltoinstall/aarch64-unknown-linux-gnu/lib/ -isystem
/work/GCC_Team/vekumar/ltoinstall/aarch64-unknown-linux-gnu/include -isystem
/work/GCC_Team/vekumar/ltoinstall/aarch64-unknown-linux-gnu/sys-include-g
-O2 -O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-fPIC -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include-o _cmpdi2.o
-MT _cmpdi2.o -MD -MP -MF _cmpdi2.dep -DL_cmpdi2 -c
../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc/libgcc/libgcc2.c: In function â__ashrti3â:
../../../gcc/libgcc/libgcc2.c: In function â__lshrti3â:
../../../gcc/libgcc/libgcc2.c:415:30: internal compiler error: in
iterative_hash_expr, at tree.c:7475
   w.s.low = (UWtype) uu.s.high >> -bm;
  ^
../../../gcc/libgcc/libgcc2.c:471:22: internal compiler error: in
iterative_hash_expr, at tree.c:7475
   w.s.high = uu.s.high >> (W_TYPE_SIZE - 1);
  ^
../../../gcc/libgcc/libgcc2.c: In function â__negti2â:
In file included from ../../../gcc/libgcc/libgcc2.h:506:0,
 from ../../../gcc/libgcc/libgcc2.c:56:
../../../gcc/libgcc/libgcc2.c: In function â__multi3â:
../../../gcc/libgcc/libgcc2.c:67:36: internal compiler error: in
iterative_hash_expr, at tree.c:7475
   const DWunion w = { {.low = -uu.s.low,
^
../../../gcc/libgcc/libgcc2.c: In function â__cmpti2â:
../../../gcc/libgcc/libgcc2.c:551:39: internal compiler error: in
iterative_hash_expr, at tree.c:7475
   DWunion w = {.ll = __umulsidi3 (uu.s.low, vv.s.low)};
(---Snip---)

With GCC 4.9 release FSF, getting bootstrapping with LTO resulted compare
errors. Finding the revision, which cause ICE is in progress.

[Bug target/61443] New: [avr] ICE when varargs argument is indirect addr-space access

[gjl at gcc dot gnu.org]

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

Bug ID: 61443
   Summary: [avr] ICE when varargs argument is indirect addr-space
access
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: addr-space, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
Target: avr

Created attachment 32907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32907&action=edit
C Test Case

== C Source ==

extern void vfun (char, ...);

void boo (const __flash int *p)
{
vfun (0, *p);
}


== Command Line ==

$ avr-gcc foo.c -S -Os

Occurs also with optimization turned on.


== Diagnose ==

foo.c: In function 'boo':
foo.c:6:1: error: unrecognizable insn:
 }
 ^
(insn 6 3 7 2 (set (reg:QI 44)
(subreg:QI (mem:HI (reg/v/f:HI 43 [ p ]) [2 *p_2(D)+0 S2 A8 AS1]) 1))
foo.c:5 -1
 (nil))
foo.c:6:1: internal compiler error: in extract_insn, at recog.c:2150

foo.c:6:1: internal compiler error: Segmentation fault

[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Jun  7 17:35:35 2014
New Revision: 211345

URL: http://gcc.gnu.org/viewcvs?rev=211345&root=gcc&view=rev
Log:
2014-06-07  Jerry DeLisle  

Backport from trunk.
PR libfortran/61173
* io/list_read.c (eat_spaces): If the next character pointed to
is a space, don't seek, must be at the end.

Modified:
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/list_read.c

[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Jun  7 17:39:31 2014
New Revision: 211346

URL: http://gcc.gnu.org/viewcvs?rev=211346&root=gcc&view=rev
Log:
2014-06-07  Jerry DeLisle  

Backport from trunk.
PR libfortran/61173
* gfortran.dg/arrayio_14.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/arrayio_14.f90
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous "end of file" with internal read

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #11 from Jerry DeLisle  ---
Fixed on 4.9, and closing.

[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle  ---
Fixed on Trunk, closing

[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #29 from Jerry DeLisle  ---
Missed the button.

[Bug fortran/56744] [meta-bug] Namelist bugs

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 55117, which changed state.

Bug 55117 Summary: Programs fails to read namelist (contains derived types 
objects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117

   What|Removed |Added

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

[Bug fortran/56744] [meta-bug] Namelist bugs

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 52539, which changed state.

Bug 52539 Summary: I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist 
read and nml write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from Jerry DeLisle  ---
Closing.

[Bug c/61444] New: Missing "undeclared identifier" message

[jennifertf6 at gmail dot com]

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

Bug ID: 61444
   Summary: Missing "undeclared identifier" message
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jennifertf6 at gmail dot com

gcc (Debian 4.4.5-8) 4.4.5

The "undeclared identifier" message is only produced the first time an
undeclared identifier is referenced.  I don't want only the first reference.  I
want ALL of them.

[Bug c++/61445] New: [C++11][4.10 Regression] ice in instantiate_decl

[ppluzhnikov at google dot com]

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

Bug ID: 61445
   Summary: [C++11][4.10 Regression] ice in instantiate_decl
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

This appears to be a recent regression in trunk.
Source reduced from llvm/tools/clang/tools/clang-check/ClangCheck.cpp

Using trunk @r211286:

gcc-svn-r211286/bin/g++ -c t1.ii -std=c++11
t1.ii: In instantiation of ‘void newFrontendActionFactory(FactoryT*,
int*)::A::m_fn1() [with FactoryT = int]’:
t1.ii:18:5:   required from ‘void newFrontendActionFactory(FactoryT*, int*)
[with FactoryT = int]’
t1.ii:19:33:   required from here
t1.ii:11:13: internal compiler error: in instantiate_decl, at cp/pt.c:19753
 B (0, 0);
 ^
0x5c6d0f instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19752
0x63cda3 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5016
0x557f73 build_over_call
../../gcc/cp/call.c:7335
0x563880 build_new_method_call_1
../../gcc/cp/call.c:8047
0x563880 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8117
0x564959 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.c:7661
0x607df6 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:1935
0x5bbf86 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:14415
0x5ca963 tsubst_expr
../../gcc/cp/pt.c:14133
0x5cad61 tsubst_expr
../../gcc/cp/pt.c:13559
0x5caf03 tsubst_expr
../../gcc/cp/pt.c:13731
0x5c8503 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:20043
0x5caa2b tsubst_expr
../../gcc/cp/pt.c:13872
0x5ca273 tsubst_expr
../../gcc/cp/pt.c:13545
0x5caf03 tsubst_expr
../../gcc/cp/pt.c:13731
0x5c8503 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:20043
0x601387 instantiate_pending_templates(int)
../../gcc/cp/pt.c:20159
0x63e7ef cp_write_global_declarations()
../../gcc/cp/decl2.c:4348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The crash does not reproduce without -std=c++11, nor using trunk build
@r210629.

/// -- cut ---
template < typename FactoryT > void newFrontendActionFactory (FactoryT *, int *
= 0);
int a;

template < typename FactoryT >
void newFrontendActionFactory (FactoryT *, int *)
{
class A
{
void m_fn1 ()
{
B (0, 0);
}
class B
{
public:
B (FactoryT, int);
};
};
newFrontendActionFactory (&a);
}

[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well

[jb at gcc dot gnu.org]

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

--- Comment #10 from Janne Blomqvist  ---
Author: jb
Date: Sun Jun  8 05:43:29 2014
New Revision: 211353

URL: http://gcc.gnu.org/viewcvs?rev=211353&root=gcc&view=rev
Log:
PR 56981 Flush buffer at record boundary if possible.

2014-06-08  Janne Blomqvist  

PR libfortran/56981
* io/unix.h (struct stream_vtable): Add new member function,
markeor.
(smarkeor): New inline function.
(flush_if_unbuffered): Remove prototype.
* io/unix.c (raw_markeor): New function.
(raw_vtable): Initialize markeor member.
(buf_markeor): New function.
(buf_vtable): Initialize markeor member.
(mem_vtable): Likewise.
(mem4_vtable): Likewise.
(flush_if_unbuffered): Remove function.
* io/transfer.c (next_record): Call smarkeor instead of
flush_if_unbuffered.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/unix.h