[Bug tree-optimization/61438] New: ICE on valid code at -O3 on x86_64-linux-gnu in in loop_preheader_edge, at cfgloop.c:1668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61438
Bug ID: 61438
Summary: ICE on valid code at -O3 on x86_64-linux-gnu in in
loop_preheader_edge, at cfgloop.c:1668
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140606 (experimental) [trunk revision 211322] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.9.0 -O3 small.c; a.out
$
$ gcc-trunk -O3 small.c
small.c: In function ‘foo’:
small.c:12:1: internal compiler error: in loop_preheader_edge, at
cfgloop.c:1668
foo ()
^
0x62e9ce loop_preheader_edge(loop const*)
../../gcc-trunk/gcc/cfgloop.c:1668
0xa3a6e0 block_before_loop
../../gcc-trunk/gcc/tree-scalar-evolution.h:48
0xa3a6e0 analyze_scalar_evolution(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.c:2042
0xa3b9ea analyze_scalar_evolution_in_loop
../../gcc-trunk/gcc/tree-scalar-evolution.c:2139
0xa3bb4f simple_iv(loop*, loop*, tree_node*, affine_iv*, bool)
../../gcc-trunk/gcc/tree-scalar-evolution.c:3244
0xae08a9 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-pre.c:4217
0xe94927 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:177
0xadd372 eliminate
../../gcc-trunk/gcc/tree-ssa-pre.c:4451
0xadd7c3 execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4867
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
-
#include assert.h
int a, c, **d, e, g;
static int b = 1;
struct
{
int f0;
} f;
void
foo ()
{
int h, *i = a;
for (; e;)
{
for (c = 0; c 1; c++)
for (; b;)
;
for (;;)
{
if (a)
{
for (; f.f0; f.f0++)
;
if (g)
break;
}
for (h = 0; h 2; h++)
{
i = *d;
assert (i);
}
}
}
assert (i);
}
int
main ()
{
foo ();
return 0;
}
[Bug other/61439] New: contrib/download_prerequisites script does not verify integrity of packages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61439 Bug ID: 61439 Summary: contrib/download_prerequisites script does not verify integrity of packages Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jim at garrison dot cc The InstallingGCC page on the wiki recommends the use of the contrib/download_prerequisites script for fetching gcc's dependencies. However, the script fails to check the integrity of the downloaded files. Since it downloads specific versions of packages, perhaps it would be best to check against the known hash of each tarball.
[Bug bootstrap/61440] New: Bootstrap failure with --with-build-config=bootstrap-lto
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61440
--- Comment #1 from Venkataramanan venkataramanan.kumar at amd dot com ---
Tried
objdump -d stage2-gcc/gimple.ostage2-gcc-gimple.s
objdump -d stage3-gcc/gimple.ostage3-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
[Bug fortran/29602] [F2003] I/O specifiers can now be of any kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29602 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58498 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2012-12-04 00:00:00 |2014-6-7 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- 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 (bn)|(a(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58020 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #25 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fkrogh#gcc at mathalacarte dot com --- Comment #13 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- *** Bug 58020 has been marked as a duplicate of this bug. ***
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59026 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Was fixed on 4.9, not a regression: closing.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #14 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61427 Torsten Robitzki Torsten at Robitzki dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Torsten Robitzki Torsten at Robitzki dot de --- 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
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 stdio.h
#include math.h
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 main:
400630: a9be7bfdstp x29, x30, [sp,#-32]!
400634: 910003fdmov x29, sp
400638: 18000160ldr w0, 400664 main+0x34
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 main:
400630: a9bf7bfdstp x29, x30, [sp,#-16]!
400634: 910003fdmov x29, sp
400638: 5c80ldr d0, 400648 main+0x18
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'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 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 fxcoudert at gcc dot gnu.org --- 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'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60468 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 --- Comment #3 from Aurelien Jarno aurelien at aurel32 dot net --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58015 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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'
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=feclearexcepttype=2of=HP-UXsf=3m Thanks, Dave -- John David Anglindave.ang...@bell.net
[Bug bootstrap/61442] New: [Aarch64] ICE while bootstraping GCC with --with-build-config=bootstrap-lto
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
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=32907action=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Jun 7 17:35:35 2014 New Revision: 211345 URL: http://gcc.gnu.org/viewcvs?rev=211345root=gccview=rev Log: 2014-06-07 Jerry DeLisle jvdeli...@gcc.gnu 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Jun 7 17:39:31 2014 New Revision: 211346 URL: http://gcc.gnu.org/viewcvs?rev=211346root=gccview=rev Log: 2014-06-07 Jerry DeLisle jvdeli...@gcc.gnu 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on 4.9, and closing.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #28 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on Trunk, closing
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Missed the button.
[Bug fortran/56744] [meta-bug] Namelist bugs
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Closing.
[Bug c/61444] New: Missing undeclared identifier message
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
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*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8117
0x564959 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, 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 http://gcc.gnu.org/bugs.html 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Sun Jun 8 05:43:29 2014 New Revision: 211353 URL: http://gcc.gnu.org/viewcvs?rev=211353root=gccview=rev Log: PR 56981 Flush buffer at record boundary if possible. 2014-06-08 Janne Blomqvist j...@gcc.gnu.org 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
