[Bug c++/66034] New: Enhancement request: fiber-local storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034 Bug ID: 66034 Summary: Enhancement request: fiber-local storage Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- As a complement to __thread and thread_local, add __fiber storage class which is local storage for user-level threads. User-level threads is a common technique in high performance storage, and compiler support would be beneficial. On x86_64, __fiber storage can be accessed via gs:, which can be set (on newer processors) via set setgsbase instruction in userspace.
[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #1 from chrbr at gcc dot gnu.org --- same error building arm-none-eabi multilibs checking for library containing opendir... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[3]: *** [configure-target-libstdc++-v3] Error 1
[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 --- Comment #3 from Chris Johns chris at contemporary dot net.au --- Built GNU sed from source and added to my path: ruru rtems $ sed --version GNU sed version 4.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, to the extent permitted by law. The build was successful.
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Rainer Orth from comment #23) The bb-slp-14.c testcase now FAILs on Solaris/SPARC. Attaching the dump. Rainer /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-14.c:19:10: note: not vectorized: relevant stmt not supported: _11 = a0_4 * x_10(D); ok, so we miss to test for vect_int_mult.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 62283, which changed state. Bug 62283 Summary: basic-block vectorization fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 6 06:47:38 2015 New Revision: 222843 URL: https://gcc.gnu.org/viewcvs?rev=222843root=gccview=rev Log: 2015-05-06 Richard Biener rguent...@suse.de PR tree-optimization/62283 * gcc.dg/vect/bb-slp-14.c: Adjust. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/bb-slp-14.c
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 --- Comment #2 from Alan Modra amodra at gmail dot com --- Right, but there will be when I have my split-stack implementation done.
[Bug c++/66028] false positive, unused loop variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66028 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 35464 [details] Follow-up patch fixing latest regression. With this patch all code samples and the code in the tar-archive compile and execute well. This patch will need most of my previous patches. The total set of all of my patches is available on the gitmirror in the branch vehre/head_cosmo With this patch I still get the ICE when compiling the file evaluators.f90.
[Bug bootstrap/66009] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66009 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- That's an interesting idea - your argument is that if niter analysis was able to compute an expression for the number of iterations and the cast we are looking at is a widening of a BIV then it is ok to assume the BIV does not wrap. Unfortunately this breaks down (eventually not in practice due to your exclusion of constant initial BIV value) for cases like for (unsigned i = 3; i != 2; i+=7) ; where niter analysis can still compute the number of iterations (I've made the numbers up, so maybe that loop will never terminate...). Still the idea is interesting as we might be able to record whether BIVs overflow or not.
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|amodra at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
[Bug middle-end/65947] Vectorizer misses conditional assignment of constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- You definitely need special support for COND_EXPR a reduction operator. And yes, if it's in that simple form then reducing the condition is the thing to do. But then you have more complex reduction operators (generally an issue - we don't support those very well), like if (a[i]) res += x; which AFAICR is quite common as well.
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 Alan Modra amodra at gmail dot com changed: What|Removed |Added Target||powerpc* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-06 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Ever confirmed|0 |1
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 Rahul rahul.gundecha at gmail dot com changed: What|Removed |Added CC||rahul.gundecha at gmail dot com --- Comment #9 from Rahul rahul.gundecha at gmail dot com --- I am also experiencing the same issue. Is there any solution for it?
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Sounds like there is no testcase for any places where gen_nop is used.
[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66010
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-06
Target Milestone|--- |6.0
Ever confirmed|0 |1
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
apD.1859 = apD.1844;
# .MEM_7 = VDEF .MEM_3
# USE = nonlocal null { D.1844 D.1859 } (escaped)
# CLB = nonlocal null { D.1844 D.1859 } (escaped)
_6 = VA_ARG (apD.1859,
this also looks like double-indirection (and thus wrong-code?)
Note that I'd defer all possible optimization issues to _after_ re-writing
the stdarg pass to take advantage of va_arg not being lowered.
[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678 --- Comment #20 from vehre at gcc dot gnu.org --- This patch is for trunk, aka 6.0.
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #10 from Matt Whitlock gcc at mattwhitlock dot name ---
(In reply to Rahul from comment #9)
I am also experiencing the same issue. Is there any solution for it?
You can wrap a preprocessor macro around string literals that you want to
subject to the linker's garbage collection:
#define GCSTR(str) ({ static const char __str[] = str; __str; })
void hello() {
puts(GCSTR(111)); // NOT in .rodata
puts(222);// in .rodata
}
int main() {
puts(GCSTR(333)); // in .rodata
puts(444);// in .rodata
return 0;
}
$ gcc -ffunction-sections -fdata-sections -Wl,--gc-sections -o gcstr gcstr.c
$ objdump -s -j .rodata gcstr
gcstr: file format elf64-x86-64
Contents of section .rodata:
4005fd 32323200 34343400 3300 222.444.333.
The downside of this strategy, however, is that these strings then become
ineligible for merging, so if you have multiple *reachable* occurrences of the
same GCSTR in your code, then you'll have multiple copies of the string data in
the .rodata section of your linked binary.
These redundant copies would not be present if the compiler were correctly
outputting literal-initialized constant character arrays to sections with the
merge and strings flags set (which it should do only if
-fmerge-all-constants is set). You can simulate how this could/should work by
editing the compiler's assembly output so that it sets the section flags
appropriately.
Given this program, gcstr.c:
#define GCSTR(str) ({ static const char __str[] = str; __str; })
int main() {
puts(GCSTR(111));
puts(GCSTR(111));
puts(111);
return 0;
}
Compile (but do not assemble) the program:
$ gcc -S -ffunction-sections -fdata-sections -fmerge-all-constants -o gcstr.s
gcstr.c
Edit the assembly code so that all .rodata.__str.* sections are declared with
the merge and strings flags and an entity size of 1:
$ sed -e
's/\(\.section\t\.rodata\.__str\..*\),a,\(@progbits\)$/\1,aMS,\2,1/' -i
gcstr.s
Now assemble and link the program:
$ gcc -Wl,--gc-sections -o gcstr gcstr.s
Dumping the .rodata section from the resulting executable reveals that the
linker did correctly perform string merging.
$ objdump -s -j .rodata gcstr
gcstr: file format elf64-x86-64
Contents of section .rodata:
40060d 31313100 111.
Compare the above objdump output to that which results when skipping the sed
step:
40060d 31313100 31313100 31313100 111.111.111.
The needed correction is that the compiler should, when -fmerge-all-constants
is set, emit literal-initialized constant character array data to a section
with flags aMS and entsize==sizeof(T), where T is the type of characters in
the array.
A further correction (and really the main request in this bug report) would be
for the compiler to emit string literals to discrete sections when
-fdata-sections is set.
[Bug fortran/66035] New: [5.1 Regression] gfortran ICE segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66035 Bug ID: 66035 Summary: [5.1 Regression] gfortran ICE segfault Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Melven.Roehrig-Zoellner at DLR dot de Target Milestone: --- Created attachment 35474 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35474action=edit Failing pFUnit framework version from http://sourceforge.net/projects/pfunit/ When trying to compile the Fortran unit test framework pFUnit with gfortran 5.1.0 I obtain an internal compiler error - it just works fine with gfortran 4.9.2. Steps to reproduce in a Linux shell: Unpack the attached version of pFUnit (or checkout rev. efa55c3c of http://git.code.sf.net/p/pfunit/code) mkdir build_gcc5.1.0 cd build_gcc5.1.0 cmake .. make Output: [...] Building Fortran object source/CMakeFiles/pfunit.dir/RobustRunner.F90.o cd /home_local/zoel_ml/pFUnit_tests/pfunit-code/build_gcc5.1/source /tools/modulesystem/tools/gcc/gcc-5.1.0/install/sled11.x86_64.gcc-4.3.4.release/bin/gfortran -DBUILD_ROBUST -DGNU -g -O0 -fbounds-check -J../mod -I/home_local/zoel_ml/pFUnit_tests/pfunit-code/build_gcc5.1/mod -I/home_local/zoel_ml/pFUnit_tests/pfunit-code/build_gcc5.1/source-c /home_local/zoel_ml/pFUnit_tests/pfunit-code/source/RobustRunner.F90 -o CMakeFiles/pfunit.dir/RobustRunner.F90.o /home_local/zoel_ml/pFUnit_tests/pfunit-code/source/RobustRunner.F90:149:0: testCases = [TestCaseReference(aTest)] 1 internal compiler error: Speicherzugriffsfehler 0xa818bf crash_signal /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/toplev.c:383 0x85e5b9 fold_convert_loc(unsigned int, tree_node*, tree_node*) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fold-const.c:2204 0x6fe3e3 gfc_trans_subcomponent_assign /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-expr.c:6907 0x6fe18b gfc_trans_structure_assign /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-expr.c:7036 0x6ff6d4 gfc_conv_structure(gfc_se*, gfc_expr*, int) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-expr.c:7065 0x6d1ec7 gfc_trans_array_ctor_element /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-array.c:1389 0x6e119a gfc_trans_array_constructor_value /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-array.c:1634 0x6dfccb trans_array_constructor /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-array.c:2339 0x6dfccb gfc_add_loop_ss_code /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-array.c:2580 0x6e04f5 gfc_conv_loop_setup(gfc_loopinfo*, locus*) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-array.c:4750 0x7005f0 gfc_trans_assignment_1 /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-expr.c:8914 0x6cdc05 trans_code /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans.c:1665 0x72a88c gfc_trans_block_construct(gfc_code*) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:1571 0x6cd9f7 trans_code /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans.c:1770 0x724163 gfc_trans_if_1 /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:1115 0x724174 gfc_trans_if_1 /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:1119 0x72a49a gfc_trans_if(gfc_code*) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:1146 0x6cda67 trans_code /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans.c:1762 0x72c275 gfc_trans_integer_select /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:2221 0x72c275 gfc_trans_select(gfc_code*) /tools/modulesystem/tools/gcc/gcc-5.1.0/src/gcc/fortran/trans-stmt.c:2715 System information: self-build gcc 5.1.0 cmake: 2.8.12.1 OS: SUSE Linux Enterprise Desktop 11 service pack 2 libc: 2.11.3 (20110527) native gcc: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] kernel: Linux 3.0.13-0.27-default x86_64 GNU/Linux
[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015 --- Comment #2 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed May 6 11:19:56 2015 New Revision: 222848 URL: https://gcc.gnu.org/viewcvs?rev=222848root=gccview=rev Log: 2015-05-06 Christian Bruel christian.br...@st.com PR target/66015 * config/aarch64/aarch64.c (aarch64_override_options): Move align_loops, align_jumps, align_functions into aarch64_override_options_after_change. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/iinline-attr-1.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/66036] New: strided group loads are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036
Bug ID: 66036
Summary: strided group loads are not vectorized
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For example
struct Xd {
double x;
double y;
};
double testd (struct Xd *x, int stride, int n)
{
int i;
double sum = 0.;
for (i = 0; i n; ++i)
{
sum += x[i*stride].x;
sum += x[i*stride].y;
}
return sum;
}
or similar cases without reduction (simple case)
int testi (int *p, short *q, int stride, int n)
{
int i;
for (i = 0; i n; ++i)
{
q[i*4+0] = p[i*stride+0];
q[i*4+1] = p[i*stride+1];
q[i*4+2] = p[i*stride+2];
q[i*4+3] = p[i*stride+3];
}
}
or the more complex case
int testi2 (int *q, short *p, int stride, int n)
{
int i;
for (i = 0; i n; ++i)
{
q[i*4+0] = p[i*stride+0];
q[i*4+1] = p[i*stride+1];
q[i*4+2] = p[i*stride+2];
q[i*4+3] = p[i*stride+3];
}
}
because here the SLP group has smaller-than-vector size and thus requires
two scalar loads and a vector build from them (x86_64 movhlps/movulps).
The more complex form happens in SPEC CPUv6.
[Bug tree-optimization/66036] strided group loads are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-05-06 Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00214.html
regresses
FAIL: gcc.dg/tree-ssa/pr21559.c scan-tree-dump-times vrp1 Threaded jump 3
(a real missed optimization - a redundant if remains)
and also
FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite number of
SCo
Ps: 1 1
FAIL: gcc.dg/graphite/scop-dsyrk.c scan-tree-dump-times graphite number of
SCoP
s: 1 1
for 32bits, not investigated yet.
So it seems for the first regression that VRP somehow depends on mergephi,
or at least jump threading as performed by VRP. IL difference before VRP:
@@ -20,16 +19,19 @@
bb 4:
if (bytes_11 0)
-goto bb 7;
+goto bb 6;
else
goto bb 8;
bb 5:
toread_12 = toread_1 - bytes_11;
+ bb 6:
+ # toread_9 = PHI toread_12(5), toread_1(4)
+
bb 7:
- # toread_1 = PHI toread_1(4), 4096(2), toread_12(5)
- # bytes_2 = PHI bytes_11(4), 1(2), bytes_11(5)
+ # toread_1 = PHI toread_9(6), 4096(2)
+ # bytes_2 = PHI bytes_11(6), 1(2)
if (toread_1 != 0)
goto bb 3;
else
and then VRP gets
-fix_loop_structure: fixing up loops for function
-Disambiguating loop 1 with multiple latches
-Merged latch edges of loop 1
;; 2 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
-;; nodes: 0 1 2 3 4 5 7 11 8 9 10
+;; nodes: 0 1 2 3 4 5 6 7 8 9 10
;;
;; Loop 1
-;; header 11, latch 7
+;; header 7, latch 6
;; depth 1, outer 0
-;; nodes: 11 7 4 5 3
-;; 2 succs { 11 }
+;; nodes: 7 6 5 4 3
+;; 2 succs { 7 }
;; 3 succs { 4 5 }
-;; 4 succs { 7 8 }
-;; 5 succs { 7 }
-;; 7 succs { 11 }
-;; 11 succs { 3 8 }
+;; 4 succs { 6 8 }
+;; 5 succs { 6 }
+;; 6 succs { 7 }
+;; 7 succs { 3 8 }
;; 8 succs { 9 10 }
;; 9 succs { 10 }
;; 10 succs { 1 }
which might be already the whole story about this - it splits the merged PHI
again but in a different way, ending up with
- bb 7:
- # toread_9 = PHI toread_15(12), toread_12(5)
- # bytes_8 = PHI bytes_16(12), bytes_19(5)
- bb 11:
- # toread_1 = PHI toread_9(7), 4096(2)
- # bytes_2 = PHI bytes_8(7), 1(2)
instead of the following (without mergephi and re-splitting):
+ bb 6:
+ # toread_9 = PHI toread_12(5), toread_8(11)
+ bb 7:
+ # toread_1 = PHI toread_9(6), 4096(2)
+ # bytes_2 = PHI bytes_11(6), 1(2)
and as final result of VRP:
-bytes_2: ~[0, 0]
+bytes_2: VARYING
and that's the usual issue of VRP not inserting asserts at CFG merges
(it doesn't insert PHIs...). mergephi effectively inserting a PHI
for bytes_11 in BB 6 is pure luck :/
.optimized code difference:
foo ()
{
static char eof_reached = 0;
@@ -13,8 +15,8 @@
bb 2:
bb 3:
- # toread_22 = PHI toread_9(6), 4096(2)
- bytes_11 = bar (toread_22);
+ # toread_18 = PHI toread_9(6), 4096(2)
+ bytes_11 = bar (toread_18);
if (bytes_11 = 0)
goto bb 4;
else
@@ -27,21 +29,26 @@
goto bb 8;
bb 5:
- toread_12 = toread_22 - bytes_11;
+ toread_12 = toread_18 - bytes_11;
bb 6:
- # toread_9 = PHI toread_22(4), toread_12(5)
+ # toread_9 = PHI toread_12(5), toread_18(4)
if (toread_9 != 0)
goto bb 3;
else
goto bb 7;
bb 7:
- return;
+ if (bytes_11 == 0)
+goto bb 8;
+ else
+goto bb 9;
bb 8:
eof_reached = 1;
- goto bb 7;
+
+ bb 9:
+ return;
}
I'm inclined to XFAIL the testcase, but ...
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Bill Schmidt wschmidt at gcc dot gnu.org --- Re-closing.
[Bug fortran/66035] [5.1 Regression] gfortran ICE segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66035 --- Comment #1 from Melven.Roehrig-Zoellner at DLR dot de --- Created attachment 35475 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35475action=edit Full build log with failure
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #28 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 35476 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35476action=edit bb-slp-32.c.141t.slp2 dump A reghunt just confirmed that the patch also caused XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2 vectorization is not profitable Dump attached.
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283
--- Comment #29 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 6 May 2015, ro at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283
--- Comment #28 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 35476
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35476action=edit
bb-slp-32.c.141t.slp2 dump
A reghunt just confirmed that the patch also caused
XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2
vectorization is not profitable
Dump attached.
Well - for vect_no_align { ! vect_hw_misalign } it now tries to
build the vector from scalar loads and that (rightfully) fails due
to the cost model:
Vector inside of basic block cost: 4
Vector prologue cost: 3
Vector epilogue cost: 0
Scalar cost of basic block: 4
so I bet we can now simply remove the XFAIL for all archs. Will do that.
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #30 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed May 6 12:21:01 2015 New Revision: 222849 URL: https://gcc.gnu.org/viewcvs?rev=222849root=gccview=rev Log: 2015-05-06 Richard Biener rguent...@suse.de PR tree-optimization/62283 * gcc.dg/vect/bb-slp-32.c: Remove XFAIL. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/bb-slp-32.c
[Bug lto/65991] maybe-unitialized - false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65991 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- No feedback. Closing.
[Bug tree-optimization/66036] strided group loads are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66036
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Reduction case with unrolling
struct Xf {
float x;
float y;
};
float testf (struct Xf *x, int stride, int n)
{
int i;
float sum = 0.;
for (i = 0; i n; ++i)
{
sum += x[i*stride].x;
sum += x[i*stride].y;
}
return sum;
}
[Bug middle-end/66031] Spurious array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. We are confused by f being unsigned char somehow, so we don't see that bb 3: i_7 = i_1 + 1; _8 = (unsigned int) i_7; _9 = _8 + 4294967295; _10 = (unsigned int) f.1_5; if (_9 = _10) goto bb 4; else goto bb 6; bb 4: _11 = p[_8]; _12 = (char) _11; ... is never executed (thus _9 = _10 is true). DOM doesn't figure that out either, we are missing the simplification of i_7 = i_1 + 1; _8 = (unsigned int) i_7; _9 = _8 + 4294967295; to _9 = (unsigned int) i_1; but then we still have an unsigned int compare against f in one path and a signed int one in the other. We'd have to canonicalize to one form to eventually make DOM recognize the redundant compare - which OTOH won't help VRP to omit the warning (because VRP runs before DOM). VRPs analysis is not able to optimize such redundancy because it doesn't track symbolic ranges in addition to regular ones here. Summary: hard problem.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- [...] Not yet: those sparc boxes are slow, and it will take ages. I'll check if I can reproduce in a cross compiler. I can, and a reghunt determined that the last patch for PR tree-optimization/62283 caused the XPASS. Rainer
[Bug tree-optimization/66002] paq8p benchmark 50% slower than clang on sandybridge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66002 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- I'm testing adding a mergephi pass instead of moving the existing one.
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Rainer Orth from comment #6) Unfortunately, the fix broke the test completely on Solaris with /bin/ld: Also seen on x86 CentOS 5.11: cp_lto_pr65276_1.o: In function `std2::runtime_error::~runtime_error()':^M pr65276_1.C:(.text._ZN4std213runtime_errorD2Ev[_ZN4std213runtime_errorD5Ev]+0x8): undefined reference to `std2::exception::~exception()'^M cp_lto_pr65276_1.o: In function `std2::runtime_error::~runtime_error()':^M pr65276_1.C:(.text._ZN4std213runtime_errorD0Ev[_ZN4std213runtime_errorD5Ev]+0xc): undefined reference to `std2::exception::~exception()'^M cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x10): undefined reference to `std2::exception::~exception()'^M cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x18): undefined reference to `std2::exception::~exception()'^M collect2: error: ld returned 1 exit status^M
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #4 from JD t at sharklasers dot com --- I tried as you advised; this is the configuration I'm trying to build: $ ../gcc-5.1.0/configure --prefix=gcc5.1 --enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto --enable-bootstrap --with-build-config=bootstrap-lto --disable-multilib The linker is: GNU ld (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1 Information for package binutils: - Repository: openSUSE-13.2-Oss Name: binutils Version: 2.24-6.1.7 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date
[Bug libstdc++/59161] GDB pretty printers: iterator-reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 --- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com --- valid for: gcc-5.1.1-1.fc23.x86_64
[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208 --- Comment #4 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Wed May 6 14:23:57 2015 New Revision: 222853 URL: https://gcc.gnu.org/viewcvs?rev=222853root=gccview=rev Log: gcc/ 2015-05-06 Yvan Roux yvan.r...@linaro.org PR target/64208 * config/arm/iwmmxt.md (*iwmmxt_arm_movdi): Cleanup redundant alternatives. gcc/testsuite/ 2015-05-06 Yvan Roux yvan.r...@linaro.org PR target/64208 * gcc.target/arm/pr64208.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr64208.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/iwmmxt.md trunk/gcc/testsuite/ChangeLog
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #6 from JD t at sharklasers dot com --- Concerning the latest release of binutils, I have to admit I've never used a local installation, so I might be doing something wrong here. I downloaded and compiled version 2.25 and with that I get undefined references to libiberty functions. I attached the diagnostics.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 Andrew Macleod amacleod at redhat dot com changed: What|Removed |Added Attachment #35425|0 |1 is obsolete|| --- Comment #50 from Andrew Macleod amacleod at redhat dot com --- Created attachment 35478 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35478action=edit implement SYNC flag for memory model I've been working on patches for this. Adding a new MEMMODEL type was my first approach because it means that gcc has one representation for all the memory models it supports. I decided not to submit the patch because Aarch64 also needs an tag for the __sync acquire used in __sync_lock_test_and_set. Adding that touches more backends than the MEMMODEL_SYNC and some of those changes are not obvious (for the mips backend in particular). The reasons why Aarch64 needs a new acquire barrier are rather tenuous (they're in the earlier comments) and don't seem to justify the possibly invasive changes that would be needed. The approach I'm working on now is to add a target hook to allow a backend to supply its own expansion of calls to the __sync builtins. That makes for smaller changes in the target-independent code and lets the Aarch64 backend add the new barriers as target-specific memory models. The actual code generation goes through the infrastructure for the atomics. Adding the __sync barriers to coretypes.h is the better approach if more than one backend has this problem. Since it seems that only Aarch64 is affected, I think its better to go with the target hook. If a new architecture gets added with the same problem, it will be easy enough to switch to the coretypes.h approach. Well, if it affects some target now, it likely to affect some target in the future as well. Didn't someone also mention there is a potential issue with PPC somewhere too? In any case, I'm not a fan of adding target hooks for this... We ought to just bite the bullet and integrate it cleanly into the memory model. I have a patch which adds a SYNC flag to the upper bit of the memory model. It modifies all the generic code and target patterns to use access routines (declared in tree.h) instead of hard coding masks and flags (which probably should have be done in the first place). This makes carrying around the SYNC flag transparent until you want to look for it. There are new sync enum variants for SYNC_ACQUIRE, SYNC_SEQ_CST, and SYNC_RELEASE. The new access routines ignore the sync flag, so is_mm_acquire (model) will be true for MEMMODEL_ACQUIRE and MEMMODEL_SYNC_ACQUIRE. If a target doesn't care about differentiating sync (which is most targets) it will be transparent. It is also simple to check for the presence of sync is_mm_sync (model), or a particular MEMMODEL_SYNC variant model == MEMMODEL_SYNC_SEQ_CST. A quick hack to a couple of x86 patterns indicate this works and I can issue extra/different barriers for sync variants. This compiles on all targets, but is only runtime tested on x86_64-unknown-linux-gnu with no regressions. With this you should be able to easily issue whatever different insn sequence you need to within an atomic pattern. Give it a try. If it works as required, then we'll see about executing on all targets for testing...
[Bug debug/59171] pretty printers: reverse iterator off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171 --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- valid for: gcc-5.1.1-1.fc23.x86_64
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- There is also PR 62077.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com Version|lto |5.1.1 --- Comment #65 from H.J. Lu hjl.tools at gmail dot com --- GCC 5 branch on Linux/x86-64 with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --prefix=/usr/local --enable-gnu-indirect-function --disable-werror --with-build-config=bootstrap-lto --with-fpmath=sse I got gcc/except.o differs gcc/build/genconfig.o differs gcc/build/genpeep.o differs gcc/tree-cfg.o differs gcc/tree-ssa-loop-ivcanon.o differs gcc/tree-inline.o differs gcc/dbxout.o differs gcc/web.o differs gcc/sel-sched-ir.o differs gcc/reload1.o differs gcc/function.o differs gcc/tree-vrp.o differs gcc/tree-diagnostic.o differs gcc/dumpfile.o differs gcc/dwarf2cfi.o differs gcc/regcprop.o differs gcc/tree.o differs gcc/lto-streamer-out.o differs gcc/cfgexpand.o differs gcc/ipa-devirt.o differs gcc/tree-ssa-propagate.o differs gcc/ipa-inline-analysis.o differs gcc/java/lang.o differs gcc/java/expr.o differs gcc/tree-outof-ssa.o differs gcc/tree-eh.o differs gcc/emit-rtl.o differs gcc/cfgloop.o differs gcc/tree-ssa-pre.o differs gcc/cfgloopmanip.o differs gcc/lto-cgraph.o differs gcc/objc/objc-act.o differs gcc/varasm.o differs gcc/cp/pt.o differs gcc/cp/class.o differs gcc/cp/name-lookup.o differs gcc/cp/cp-gimplify.o differs gcc/cp/semantics.o differs gcc/cp/parser.o differs gcc/sched-rgn.o differs gcc/c/c-parser.o differs gcc/c/c-typeck.o differs gcc/gimple-low.o differs gcc/sel-sched.o differs gcc/tree-ssa-uninit.o differs gcc/coverage.o differs gcc/omp-low.o differs gcc/gimple.o differs gcc/c-family/c-ada-spec.o differs gcc/c-family/c-pragma.o differs gcc/dwarf2out.o differs gcc/tree-switch-conversion.o differs gcc/cfgrtl.o differs gcc/i386.o differs libcpp/lex.o differs
[Bug debug/59170] pretty printers: end iterator invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170 --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- -D_GLIBCXX_DEBUG gcc-5.1.1-1.fc23.x86_64 (gdb) p end._M_current == ((std::__debug::vectorint, std::allocatorint *)end._M_sequence)._M_impl._M_finish $11 = true
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 --- Comment #5 from JD t at sharklasers dot com --- Created attachment 35477 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35477action=edit errors using binutils 2.25
[Bug lto/66029] Build error compiling gcc5.1 using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66029 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to JD from comment #6) Concerning the latest release of binutils, I have to admit I've never used a local installation, so I might be doing something wrong here. I downloaded and compiled version 2.25 and with that I get undefined references to libiberty functions. I attached the diagnostics. You must configure binutils with --enable-plugins.
[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208 --- Comment #5 from Yvan Roux yroux at gcc dot gnu.org --- The latent bug on trunk is now fixed, but the issue is still present in 4.9.2 branch as the patch needs validation on that branch. I don't plan to validate it right now, as I don't always have access to the Cubox I validate trunk patch on and it's really long to do it.
[Bug fortran/66035] [5/6 Regression] gfortran ICE segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66035 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #3 from vehre at gcc dot gnu.org --- A shorter testcase is: program test_pr66035 type t end type t type w class(t), allocatable :: c end type w type(t) :: o call test(o) contains subroutine test(o) class(t), intent(inout) :: o type(w), dimension(:), allocatable :: list select type (o) class is (t) list = [w(o)] class default call abort() end select end subroutine end program
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 --- Comment #2 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Wed May 6 13:10:59 2015 New Revision: 222850 URL: https://gcc.gnu.org/viewcvs?rev=222850root=gccview=rev Log: PR target/66020 * gcc.target/powerpc/ppc64-abi-2.c (my_mcount): Rewrite. (gparms): Make volatile. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c
[Bug fortran/66035] [5/6 Regression] gfortran ICE segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66035 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 CC||pault at gcc dot gnu.org, ||vehre at gcc dot gnu.org Summary|[5.1 Regression] gfortran |[5/6 Regression] gfortran |ICE segfault|ICE segfault Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- The make completes without error with r219763 (2015-01-16). I get the ICE with r219823 (2015-01-18), likely revision r219801 (pr55932, pr60357, and pr61275). The ICE is still present on trunk (6.0 r222768). I'll try to reduce later today if nobody beats me.
[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015 --- Comment #1 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed May 6 10:54:40 2015 New Revision: 222847 URL: https://gcc.gnu.org/viewcvs?rev=222847root=gccview=rev Log: 2015-05-06 Christian Bruel christian.br...@st.com PR target/66015 * config/aarch64/aarch64.c (aarch64_override_options): Move align_loops, align_jumps, align_functions into aarch64_override_options_after_change. Added: trunk/gcc/testsuite/gcc.target/aarch64/iinline-attr-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug target/66033] rs6000 nops removed by rtl_dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66033 --- Comment #3 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Wed May 6 13:12:19 2015 New Revision: 222851 URL: https://gcc.gnu.org/viewcvs?rev=222851root=gccview=rev Log: PR target/66033 * config/rs6000/rs6000.md (nop): Use an unspec pattern. (UNSPEC_NOP): Define. (reload_vsx_from_gprmode): Add missing DONE. (reload_gpr_from_vsxmode): Likewise. * config/rs6000/vsx.md (vsx_mul_v2di): Likewise. (vsx_div_v2di, vsx_udiv_v2di): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/config/rs6000/vsx.md
[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66020 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Alan Modra amodra at gmail dot com --- Fixed
[Bug target/65955] [arm] ICE during movcond_addsi split
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955 --- Comment #11 from vries at gcc dot gnu.org --- (In reply to vries from comment #6) I'm now doing a nobootstrap build and test with and without the patch. Test results: ... $ diff -I guality -u FAILs.222758 FAILs.222758.patched --- FAILs.2227582015-05-05 19:07:39.0 +0800 +++ FAILs.222758.patched2015-05-06 21:14:10.0 +0800 @@ -374,12 +379,6 @@ nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/class_allocate_18.f90 -O3 -fomit-frame-pointer -funroll-loops execution test nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/class_allocate_18.f90 -O3 -g execution test nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/class_allocate_18.f90 -Os execution test -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/pr43984.f90 -O (internal compiler error) -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/pr43984.f90 -O (test for excess errors) -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/transfer_array_intrinsic_3.f90 -Os (internal compiler error) -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/transfer_array_intrinsic_3.f90 -Os (test for excess errors) -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/transfer_assumed_size_1.f90 -Os (internal compiler error) -nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/transfer_assumed_size_1.f90 -Os (test for excess errors) nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/ieee/ieee_6.f90 -O0 execution test nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/ieee/ieee_6.f90 -O1 execution test nobootstrap/build/gcc/testsuite/gfortran/gfortran.sum:FAIL: gfortran.dg/ieee/ieee_6.f90 -O2 execution test ...
[Bug target/66024] Implement AddressSanitizer support for IBM z Systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66024 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- Since this requires the base z Systems support on the LLVM side this BZ should be addressed first: https://llvm.org/bugs/show_bug.cgi?id=23433
[Bug target/66025] Implement ThreadSanitizer support for IBM z Systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66025 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- Since this requires the base z Systems support on the LLVM side this BZ should be addressed first: https://llvm.org/bugs/show_bug.cgi?id=23434
[Bug libstdc++/59161] GDB pretty printers: iterator-reference not printed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 Ever confirmed|0 |1
[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65990 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- .
[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65990 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Fixed everywhere.
[Bug bootstrap/66038] SIGSEGV at stage 2 build/genmatch --gimple ../../gcc-5.1.0/gcc/match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #1 from Douglas Mencken dougmencken at gmail dot com --- $ prev-gcc/xgcc -v Using built-in specs. COLLECT_GCC=prev-gcc/xgcc Target: powerpc-unknown-darwin Configured with: ../gcc-5.1.0/configure --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin --target=powerpc-unknown-darwin --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-slibdir=/usr/lib --program-prefix= --enable-languages=c,c++,objc,obj-c++ --disable-checking --enable-shared --enable-static --enable-threads=posix --with-__thread --with-system-zlib --disable-nls --disable-werror Thread model: posix gcc version 5.1.0 (GCC) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-unknown-darwin/4.9.2/lto-wrapper Target: powerpc-unknown-darwin Configured with: ../gcc-4.9.2/configure --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin --target=powerpc-unknown-darwin --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --with-slibdir=/usr/lib --program-prefix= --enable-languages=c,c++,objc,obj-c++ --disable-checking --enable-shared --enable-static --enable-threads=posix --with-__thread --with-system-zlib --disable-nls --disable-werror Thread model: posix gcc version 4.9.2 (GCC)
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Matt Whitlock from comment #11) Created attachment 35479 [details] put string literals into unique sections when -fmerge-constants -fdata-sections This patch puts each string literal into a (probably) unique section when compiling with -fmerge-constants -fdata-sections. The section name is constructed from the character width and string alignment (as before) plus a 32-bit hash of the string contents. Would it better to use MD5 checksum on string contents?
[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029 --- Comment #5 from Sebastian Pop spop at gcc dot gnu.org --- Maybe the patch was not committed because it was not ready before stage3: GCC 4.6 Stage 3 (starts 2010-11-03). I will update the patch and resubmit for review.
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192 --- Comment #13 from Matt Whitlock gcc at mattwhitlock dot name --- (In reply to H.J. Lu from comment #12) Would it better to use MD5 checksum on string contents? MD5 would be slower for not much gain in uniqueness (assuming its output is truncated to 32 bits). This application doesn't require a cryptographically strong hash function, as the consequence of a collision is merely that a string gets included in the binary when maybe it didn't need to be. Actually, I would favor replacing the very old (1996) Lookup2 hash function (implemented in libiberty/hashtab.c) with a more modern hash function, such as MurmurHash3, CityHash, or even Lookup3, all of which are faster than Lookup2. I would hesitate to use more than 32 bits, as the section names would start getting rather long.
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 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 --- This appears to be an intentional ICE (although I'm not sure why). The code in question is lines 2427-2430 in parse.c(verify_st_order). default: gfc_internal_error (Unexpected %s statement in verify_st_order() at %C, gfc_ascii_statement (st));
[Bug c/40115] -O2 and higher causes wrong label address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
Per Lundberg perlun at gmail dot com changed:
What|Removed |Added
CC||perlun at gmail dot com
--- Comment #4 from Per Lundberg perlun at gmail dot com ---
Hi,
Andrew - with all due respect, this bug should *not* have been closed. It it
still present (at least with gcc 4.7.2). Here is some code (very simplified):
new_tss-eip = (u32) new_thread_entry;
new_tss-cr3 = page_directory_physical_page * SIZE_PAGE;
// ...
mutex_kernel_signal(tss_tree_mutex);
mutex_kernel_signal(memory_mutex);
new_thread_entry:
DEBUG_MESSAGE(DEBUG, Enabling interrupts);
cpu_interrupts_enable();
Without -O2, the new_tss-eip gets the proper value of the code line right
below new_thread_entry. With -O2, I get this (objdump -S output):
new_tss-eip = (u32) new_thread_entry;
108314: c7 43 20 b1 85 10 00movl $0x1085b1,0x20(%ebx)
Here is where it points to. A number of instructions too early, causing the
code to entirely break down.
*list = tss_list_node;
1085b1: 89 46 0cmov%eax,0xc(%esi)
mutex_kernel_wait(memory_mutex);
mutex_kernel_wait(tss_tree_mutex);
process_info = (process_info_type *) new_tss-process_info;
thread_link_list(process_info-thread_list, new_tss);
thread_link(new_tss);
1085b4: 89 1c 24mov%ebx,(%esp)
1085b7: e8 04 f9 ff ff call 107ec0 thread_link
number_of_tasks++;
1085bc: a1 60 44 11 00 mov0x114460,%eax
1085c1: 83 c0 01add$0x1,%eax
1085c4: a3 60 44 11 00 mov%eax,0x114460
static inline u32 cpu_get_esp(void)
{
u32 return_value;
asm volatile (movl %%esp, %0
1085c9: 89 e0 mov%esp,%eax
new_tss-esp = cpu_get_esp();
1085cb: 89 43 38mov%eax,0x38(%ebx)
process_info-number_of_threads++;
1085ce: 83 46 10 01 addl $0x1,0x10(%esi)
mutex_kernel_signal(tss_tree_mutex);
1085d2: c7 04 24 64 3a 11 00movl $0x113a64,(%esp)
1085d9: e8 f2 21 00 00 call 10a7d0 mutex_kernel_signal
mutex_kernel_signal(memory_mutex);
1085de: c7 04 24 0c 44 11 00movl $0x11440c,(%esp)
1085e5: e8 e6 21 00 00 call 10a7d0 mutex_kernel_signal
asm (cli);
}
static inline void cpu_interrupts_enable(void)
{
asm (sti);
1085ea: fb sti
(the last instruction here is where it *should* have pointed at. :)
This used to work with older versions of gcc (last known good version is
something like 2.95), so obviously something relating to goto labels/O2 has
gotten broken during the years.
IMHO, this is a clear bug. In my case, I use the address for jumping but with
indirect jumping (in the new thread being created). Would you say that this is
not supported?
Does direct jumping (i.e. goto *foo) even work at the moment, with -O2? Are
there any unit tests or similar for this?
[Bug c++/65966] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- (In reply to Lewis Hyatt from comment #1) This seems to be an unrelated issue. It did not start failing at the above revision, rather it ICEs in that revision and the few prior to it that I checked. It also happens whether you have -std=c++11 or -std=c++14, and I see the same behavior in gcc 4.7, 4.8 and 4.9 as well (in those releases, it works, does not ICE, but does output the huge number of instructions). So it seems that over time, it has changed several times whether it ICEs or compiles, but it has always generated this unexpected code. Should I file this as a separate bug? Perhaps, no. This problem is known: PR65591, PR65503
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #29 from Thomas Koenig tkoenig at gcc dot gnu.org --- Further ideas: - Handling of TRANSPOSEd arguments - Temporaries for arguments which are not plain arrays - Remove size0 checks (the DO loops will do that on their own) - Remove double run-time checks, both at the beginning and in the DO loops themselves
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Wed, May 06, 2015 at 09:09:57PM +, kargl at gcc dot gnu.org wrote: --- Comment #2 from kargl at gcc dot gnu.org --- This appears to be an intentional ICE (although I'm not sure why). The code in question is lines 2427-2430 in parse.c(verify_st_order). default: gfc_internal_error (Unexpected %s statement in verify_st_order() at %C, gfc_ascii_statement (st)); The code in comments #1 and #, this diff generates an error message without the ICE Index: parse.c === --- parse.c (revision 222724) +++ parse.c (working copy) @@ -2425,8 +2425,7 @@ verify_st_order (st_state *p, gfc_statem break; default: - gfc_internal_error (Unexpected %s statement in verify_st_order() at %C, - gfc_ascii_statement (st)); + return false; } /* All is well, record the statement in case we need it next time. */
[Bug bootstrap/58476] In top-level configure --disable-static should change default for --with-boot-ldflags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 Michael Deutschmann michael at talosis dot ca changed: What|Removed |Added CC||michael at talosis dot ca --- Comment #4 from Michael Deutschmann michael at talosis dot ca --- I'm experiencing a problem almost exactly like this in the new GCC 5.1.0 -- link failures due to missing overloaded istream::ignore functions that go away when --disable-static is removed from the configure line. However, it is cc1 that is failing instead of go1 (which I'm not building). the effect is that go1 is linked against some other libstdc++ that it finds on the system, not the one that was just built. So it is not surprising that something went wrong. That appears not to be the problem, in my case at least. I've compared working and non-working build trees, and the non-working one has a libstdc++.a file that is missing several modules compared to the working one. One of them is compatibility.o, which contains the missing functions.
[Bug c/40115] -O2 and higher causes wrong label address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115 --- Comment #6 from Per Lundberg perlun at gmail dot com --- Well, the label is actually in the same function. It just happens to land there on the other thread. I can't really use a function pointer here, since I have no way (at least that I know of) to find out how much the stack pointer is offset within the function. In fact, I tried that approach but it failed specifically because of that (when trying to return from the other function, since esp wasn't pointing at the right adress). I am using -fomit-frame-pointers, otherwise I guess I could just take the ebp value. Any other suggestion? — Sent from Mailbox On Wed, May 6, 2015 at 11:52 PM, pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- In my case, I use the address for jumping but with indirect jumping (in the new thread being created). Would you say that this is not supported? yes that is not support is explicitly says it is not support: You may not use this mechanism to jump to code in a different function. . You just caused a jump to a different function. For these kind of things you should be using functions and function pointers instead of label addresses. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug c++/65966] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966
--- Comment #1 from Lewis Hyatt lhyatt at gmail dot com ---
Hello-
I have some additional information that I hope is helpful to look into this.
A. Regarding the first testcase, a regression from 4.9, which produces the
sorry, unimplemented error in 5.1:
1. I forgot to mention explicitly, this does require -std=c++14; with
-std=c++11 it works fine.
2. The issue started at the following revision:
==
Author: jason
Date: Mon Feb 9 19:15:55 2015
New Revision: 220544
URL: https://gcc.gnu.org/viewcvs?rev=220544root=gccview=rev
Log:
PR c++/64899
* init.c (build_vec_init): Handle default-initialized array with
constexpr default constructor.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
==
B. Regarding the second testcase, which compiles in 5.1, but produces
unexpected output (for an array of N elements total, there are N calls to the
constructor output in the code, no matter how large N may be):
This seems to be an unrelated issue. It did not start failing at the above
revision, rather it ICEs in that revision and the few prior to it that I
checked. It also happens whether you have -std=c++11 or -std=c++14, and I see
the same behavior in gcc 4.7, 4.8 and 4.9 as well (in those releases, it works,
does not ICE, but does output the huge number of instructions). So it seems
that over time, it has changed several times whether it ICEs or compiles, but
it has always generated this unexpected code.
Should I file this as a separate bug? It seems like it must not be intentional,
as it basically makes it impossible to brace-initialize large arrays (e.g. in
an object that is meant to be allocated dynamically, where the stack size is
not an issue, one might reasonably use an array with very many elements and not
expect the code size to be O(N) for N elements). Here is a simplified testcase,
it doesn't depend on NSDMI, just on brace initialization, and it's the same for
even 1D arrays:
==
struct A {
A();
};
#define N 1
struct B {
A array[N];
B() : array{} {}
} b;
==
And the issue is that this has had O(N) compile time and O(N) code size, since,
as far as I can tell, brace initialization was ever supported. Changing array{}
to array() works fine, as does omitting the initializer entirely.
Thanks...
-Lewis
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 --- Comment #28 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Wed May 6 20:23:48 2015 New Revision: 222864 URL: https://gcc.gnu.org/viewcvs?rev=222864root=gccview=rev Log: 2015-05-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/37131 * gfortran.h (gfc_isym_id): Add GFC_ISYM_FE_RUNTIME_ERROR. (gfc_intrinsic_sym): Add vararg. * intrinsic.h (gfc_check_fe_runtime_error): Add prototype. (gfc_resolve_re_runtime_error): Likewise. Add prototype for gfc_is_reallocatable_lhs. * trans-array.h (gfc_is_reallocatable_lhs): Remove prototype. * check.c (gfc_check_fe_runtime_error): New function. * intrinsic.c (add_sym_1p): New function. (make_vararg): New function. (add_subroutines): Add fe_runtime_error. (gfc_intrinsic_sub_interface): Skip sorting for variable number of arguments. * iresolve.c (gfc_resolve_fe_runtime_error): New function. * lang.opt (inline-matmul-limit): New option. (gfc_post_options): If no inline matmul limit has been set and BLAS is called externally, use the BLAS limit. * frontend-passes.c: Include intrinsic.h. (var_num): New global counter for naming temporary variablbles. (matrix_case): Enum for differentiating the different matmul cases. (realloc_string_callback): Add trim to the variable name. (create_var): Add optional argument vname as part of the name. Use var_num. Set dimension of result correctly. Split off block creation into (insert_block): New function. (cfe_expr_0): Use fcn as part of temporary variable name. (optimize_namesapce): Also set gfc_current_ns. Call inline_matmul_assign. (combine_array_constructor): Use constr as part of temporary name. (get_array_inq_function): New function. (build_logical_expr): New function. (get_operand): new function. (inline_limit_check): New function. (runtime_error_ne): New function. (matmul_lhs_realloc): New function. (is_functino_or_op): New function. (has_function_or_op): New function. (freeze_expr): New function. (freeze_references): New function. (convert_to_index_kind): New function. (create_do_loop): New function. (get_size_m1): New function. (scalarized_expr): New function. (inline_matmul_assign): New function. * simplify.c (simplify_bound): Simplify the case of the lower bound of an assumed-shape argument. 2015-05-06 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/37131 * gfortran.dg/dependency_26.f90: Add option to suppress inlining matmul. * gfortran.dg/function_optimize_1.f90: Likewise. * gfortran.dg/function_optimize_2.f90: Likewise. * gfortran.dg/function_optimize_5.f90: Likewise. * gfortran.dg/function_optimize_7.f90: Likewise. * gfortran.dg/inline_matmul_1.f90: New test. * gfortran.dg/inline_matmul_2.f90: New test. * gfortran.dg/inline_matmul_3.f90: New test. * gfortran.dg/inline_matmul_4.f90: New test. * gfortran.dg/inline_matmul_5.f90: New test. * gfortran.dg/inline_matmul_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inline_matmul_1.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_2.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_3.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_4.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_5.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_6.f90 Modified: trunk/gcc/fortran/check.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-array.h trunk/gcc/testsuite/gfortran.dg/dependency_26.f90 trunk/gcc/testsuite/gfortran.dg/function_optimize_1.f90 trunk/gcc/testsuite/gfortran.dg/function_optimize_2.f90 trunk/gcc/testsuite/gfortran.dg/function_optimize_5.f90 trunk/gcc/testsuite/gfortran.dg/function_optimize_7.f90
[Bug c/40115] -O2 and higher causes wrong label address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- In my case, I use the address for jumping but with indirect jumping (in the new thread being created). Would you say that this is not supported? yes that is not support is explicitly says it is not support: You may not use this mechanism to jump to code in a different function. . You just caused a jump to a different function. For these kind of things you should be using functions and function pointers instead of label addresses.
[Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #6 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- Hi! I did some more tests and it turns out, my current compiler can't even build gcc-4.9 anymore. Inspecting the build log [1] closer hints at problems when the stages 2 and 3 are being compared: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/d/ctfeexpr.dmd.o differs Makefile:19827: recipe for target 'compare' failed I have downgraded to a previous version of the gcc-4.9 package now which has built gcc-4.9 successfully in the past. I'm building gcc-4.9 and gcc-5 in parallel on different hosts now, I will know the result in the weekend (slow hardware). To be followed up. Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9arch=sh4ver=4.9.2-16stamp=1430922724
[Bug middle-end/192] String literals don't obey -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #11 from Matt Whitlock gcc at mattwhitlock dot name ---
Created attachment 35479
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35479action=edit
put string literals into unique sections when -fmerge-constants -fdata-sections
This patch puts each string literal into a (probably) unique section when
compiling with -fmerge-constants -fdata-sections. The section name is
constructed from the character width and string alignment (as before) plus a
32-bit hash of the string contents.
Consider the following program:
void used() {
puts(keep me);
puts(common);
puts(string);
puts(tail);
}
void not_used() {
puts(toss me);
puts(common);
puts(ring);
puts(entail);
}
int main() {
used();
return 0;
}
$ gcc -ffunction-sections -fdata-sections -fmerge-constants \
-Wl,--gc-sections -o test test.c
Compiling with an unpatched GCC produces a binary whose .rodata contains:
40061d 6b656570 206d6500 636f6d6d 6f6e0073 keep me.common.s
40062d 7472696e 6700746f 7373206d 6500656e tring.toss me.en
40063d 7461696c 00 tail.
Compiling with a patched GCC produces a binary whose .rodata contains:
40061d 6b656570 206d6500 636f6d6d 6f6e0073 keep me.common.s
40062d 7472696e 67007461 696c00 tring.tail.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #52 from Andrew Macleod amacleod at redhat dot com --- (In reply to mwahab from comment #51) The mips backend was the only one that stood out as needing some care, because the way it uses the memory models (e.g. in function mips_process_sync_loop) is a little different from the backends. Yeah, it looks a bit wonky, but doesn't need anything special when I looked closer. That 11 and 10 are special overrides on a couple of patterns, the rest are just normal memory model values from a specified operand. Although I did miss a conversion there that has no real effect, but should be put in place...I'll add it to my patches. *** mips.c 2015-05-06 12:15:04.145423200 -0400 --- BAK/mips.c 2015-05-06 12:12:57.265671466 -0400 *** mips_process_sync_loop (rtx_insn *insn, *** 13111,13117 model = MEMMODEL_ACQUIRE; break; default: ! model = memmodel_from_int (INTVAL (operands[memmodel_attr])); } mips_multi_start (); --- 13111,13117 model = MEMMODEL_ACQUIRE; break; default: ! model = (enum memmodel) INTVAL (operands[memmodel_attr]); } mips_multi_start ();
[Bug fortran/66035] [5/6 Regression] gfortran ICE segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66035 --- Comment #4 from vehre at gcc dot gnu.org --- Created attachment 35482 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35482action=edit Candidate patch for latest regressions. This is a candidate patch for trunk, aka 6.0, including all my candidate patches. I don't have the compute power to test this on a clean trunk, or on 5.1. Dominique, would you mind?
[Bug fortran/66040] New: ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 Bug ID: 66040 Summary: ICE on misplaced sequence in function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An ICE occurs with a misplaced sequence in a function. $ cat disrupt_2_sequence.f90 real function f(x) sequence end $ gfortran -c disrupt_2_sequence.f90 sequence 1 internal compiler error: Unexpected SEQUENCE statement in verify_st_order() at (1) Tested with gfortran 5.1.1 on SUSE Linux 13.2 (64 bit) Kind regards.
[Bug bootstrap/66022] 4.8.4 build fails with stage 2 and 3 comparison error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66022 --- Comment #1 from James Mason jrm at exa dot com --- Using the same machine and shell script (save changing the version variable from gcc-4.8.4 to gcc-4.9.2), a nearly identical failure occurs: gmake[2]: Entering directory `/opt/BUILD-gcc-4.9.2' gmake[3]: Entering directory `/opt/BUILD-gcc-4.9.2' rm -f stage_current gmake[3]: Leaving directory `/opt/BUILD-gcc-4.9.2' Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/coverage.o differs gcc/asan.o differs gcc/gimple-ssa-strength-reduction.o differs gcc/graphite-poly.o differs gcc/plugin.o differs gcc/ipa-devirt.o differs gcc/sel-sched-ir.o differs gcc/graphite-dependences.o differs gcc/tree-ssa-phiopt.o differs gcc/passes.o differs gcc/graphite-scop-detection.o differs gcc/graphite-clast-to-gimple.o differs gcc/bitmap.o differs gcc/dwarf2cfi.o differs gcc/graphite.o differs gcc/sel-sched.o differs gcc/ggc-common.o differs gcc/store-motion.o differs gcc/graphite-sese-to-poly.o differs gcc/tree-sra.o differs gcc/tree-ssa-uncprop.o differs gcc/graphite-blocking.o differs gcc/ira-costs.o differs gcc/graphite-interchange.o differs gcc/lto/lto.o differs gcc/cfg.o differs gcc/postreload-gcse.o differs gcc/dse.o differs gcc/ira-color.o differs gcc/tree-ssa-sccvn.o differs gcc/graphite-optimize-isl.o differs gcc/tree-into-ssa.o differs gcc/cselib.o differs gcc/tree-ssa-structalias.o differs gcc/tree-ssa-dom.o differs gcc/tree-complex.o differs gcc/tree-eh.o differs gcc/tree-ssa-pre.o differs gcc/haifa-sched.o differs gcc/trans-mem.o differs gcc/tree-cfg.o differs gcc/var-tracking.o differs gcc/tree-ssa-loop-im.o differs gcc/sched-deps.o differs gcc/gcse.o differs gcc/tree-pretty-print.o differs gcc/tree-ssa-tail-merge.o differs gcc/lto-streamer-in.o differs gcc/cp/class.o differs gcc/cp/semantics.o differs gcc/cp/error.o differs gcc/vtable-verify.o differs gcc/alloc-pool.o differs gcc/tree-ssa-threadupdate.o differs gcc/tree-ssa-strlen.o differs gcc/loop-iv.o differs gmake[2]: *** [compare] Error 1 gmake[2]: Leaving directory `/opt/BUILD-gcc-4.9.2' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/opt/BUILD-gcc-4.9.2' gmake: *** [all] Error 2
[Bug fortran/66040] ICE on misplaced sequence in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66040 --- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- There are more cases for ICEs on misplaced statements in a function. For example : --- real function f() block data end --- real function f() else end --- real function f() program p end --- Prints, respectivly : internal compiler error: Unexpected ... statement in verify_st_order() at (1)
[Bug fortran/66039] ICE on incomplete parentheses at rewind, flush, endfile, backspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-06
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org ---
Confirmed.
In io.c(gfc_resolve_filepos), the pointer fp-unit is
dereferenced without checking to see if it is NULL.
The issue appears come from match_filepos() where a
condition on checking for a valid expr is not correctly
checked.
Index: io.c
===
--- io.c(revision 222724)
+++ io.c(working copy)
@@ -2382,9 +2382,7 @@ match_filepos (gfc_statement st, gfc_exe
if (m == MATCH_NO)
{
m = gfc_match_expr (fp-unit);
- if (m == MATCH_ERROR)
- goto done;
- if (m == MATCH_NO)
+ if (m == MATCH_ERROR || m == MATCH_NO)
goto syntax;
}
The old 'goto done' in the above patch, branches to a portion of
the code that looks for an end-of-statement,which is found. Bad
things then ensue. The above patch appears to fix ICE for the
program in comment #1.
=== gfortran Summary ===
# of expected passes48475
# of unexpected failures8
# of unexpected successes 8
# of expected failures 71
# of unresolved testcases 8
# of unsupported tests 70
/mnt/sgk/gcc/obj6/gcc/testsuite/gfortran/../../gfortran version 6.0.0 20150502
(experimental) (GCC)
PS: 'unexpected failures' are all related to gfortran.dg/static_linking_1.f
[Bug other/66037] [docs] what is the difference between global_options and global_options_set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to ktkachov from comment #0) Would be nice if these variables at least were documented in options.texi Agreed. And document how to use them properly. Perhaps add some functions that can simplify its use. It seems nobody is actually using this mechanism and prefer to use Init(-1): https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00439.html
[Bug fortran/66039] New: ICE on incomplete parentheses at rewind, flush, endfile, backspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66039 Bug ID: 66039 Summary: ICE on incomplete parentheses at rewind, flush, endfile, backspace Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Created attachment 35483 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35483action=edit more code variants An ICE occurs with incomplete parentheses at rewind, flush, endfile, backspace. For example : program p flush (( end Tested with gfortran -c, versions 4.8.3, 4.9.0, 5.1.1 on SUSE Linux 13.2 (64 bit) The attachement contains more disrupting variants for rewind, flush, endfile, backspace. Interestingly, for that variants there are no ICEs for the statement wait. Kind regards.
[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65990 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Wed May 6 16:21:07 2015 New Revision: 222859 URL: https://gcc.gnu.org/viewcvs?rev=222859root=gccview=rev Log: PR target/65990 * config/i386/i386.c (ix86_parse_stringop_strategy_string): Error out if rep_8byte stringop strategy was specified for 32-bit target. testsuite/ChangeLog: PR target/65990 * gcc.target/i386/pr65990.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr65990.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 --- Comment #16 from Matt Whitlock gcc at mattwhitlock dot name --- Here's a working solution: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c11
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
--- Comment #5 from Robert Suchanek robert.suchanek at imgtec dot com ---
Sorry for late reply, I was on vacation.
The costs are equal if cost of moving general regs to/from fp regs or
memory are equal. So it looks ok to me.
r218 spilled in IRA is reassigned to a fp reg in *LRA*.
But I could try to use preferred class in LRA (after checking how it
affects x86/x86-64 performance), if such solution is ok for you.
Indeed, the above test case only shows the problem in LRA. If the preferred
class would be the winner then why not. However, there are still some issues
with IRA and I have another testcase to show it.
I am not sure, that the result code is better as we access memory 3
times instead of access to $f20.
On one hand, yes, it seems good but it's not always desirable to use FP regs
until absolutely necessary. For instance, compiling the dynamic linker that
uses FP regs does not seem to be right.
I had another thought about spilling into registers and how we could guarantee
spilling into the desirable class. In the majority of cases where integers end
up
in floating-point registers, I see the following in the dumps:
...
Reassigning non-reload pseudos
Assign 52 to r217 (freq=46)
...
This introduced the use of FP registers (in lra-assigns.c):
...
if (n != 0 lra_dump_file != NULL)
fprintf (lra_dump_file, Reassigning non-reload pseudos\n);
qsort (sorted_pseudos, n, sizeof (int), pseudo_compare_func);
for (i = 0; i n; i++)
{
regno = sorted_pseudos[i];
hard_regno = find_hard_regno_for (regno, cost, -1, false);
if (hard_regno = 0)
...
else
...
}
...
find_hard_regno_for chooses the FP registers freely because of allocno class
has ALL_REGS.
With a quick hack in the if conditional to skip the body for pseudos spilled to
memory:
...
if (hard_regno = 0 ! in_mem_p (regno))
...
forces the use of the TARGET_SPILL_CLASS hook and resolves spilling to FP regs
in over 95% cases but not entirely. In terms of the code size, this change had
a minor improvement on average case. Would this approach be the correct way to
guarantee spilling to the desired class?
In the remaining 5% cases, IRA assigns FP regs with LRA blindly following IRA's
decisions like in the following reduced case:
int a, b, d, e, j, k, n, o;
unsigned c, h, i, l, m, p;
int *f;
int *g;
int fn1(int p1) { return p1 - a; }
int fn2() {
b = b + 1 - a;
e = 1 + o + 1518500249;
d = d + n;
c = (int)c + g[0];
b = b + m + 1;
d = d + p + 1518500249;
d = d + k - 1;
c = fn1(c + j + 1518500249);
e = fn1(e + i + 1);
d = d + h + 1859775393 - a;
c = fn1(c + (d ^ 1 ^ b) + g[1] + 1);
b = fn1(b + m + 3);
d = fn1(d + l + 1);
b = b + (c ^ 1) + p + 1;
e = fn1(e + (b ^ c ^ d) + n + 1);
d = o;
b = 0;
e = e + k + 1859775393;
f[0] = e;
}
I'm not sure how this could be fixed in LRA and again this is related to
ALL_REGS for allocnos. Perhaps changing the class for reloads to the spill
class in LRA would do the trick but it may have other problems.
My last attempt was to increase the cost of FP_REGS in IRA for integral modes
(similar effect to increasing the costs of moving FPGR in the backend) but
the cost pass looks complicated and I'm not entirely sure where to tweak it.
Any suggestions/ideas?
I tried reverting the ALL_REGS patch and I don't see any regressions - in
fact allocations are slightly better (fewer registers with ALL_REGS
preference which is what we need - a strong decision to allocate to either
FP or int regs). So what was the motivation for it?
AFAICS, the aim was to fix the code generation regression for x86. x86 doesn't
seem to be as much affected as others. I did not notice code size differences
with -O2 and default arch for x86_64-unknown-linux-gnu triplet and CSiBE
benchmark, -Os showed some minor improvements/regression with the largest
difference in mpeg2dec-0.3.1 yielding ~0.3% improvement. I haven't evaluated
performance changes.
For MIPS, I also saw allocation improvements, more erratic than x86 with
improvement about 0.5% on average. Reverting the patch does bring the old issue
back but I wonder what is the impact of it and whether it is a justifiable fix
to the extent it outweights the disadvantages. Or maybe the original problem
could be fixed differently?
[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65990 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Wed May 6 16:17:59 2015 New Revision: 222858 URL: https://gcc.gnu.org/viewcvs?rev=222858root=gccview=rev Log: PR target/65990 * config/i386/i386.c (ix86_parse_stringop_strategy_string): Error out if rep_8byte stringop strategy was specified for 32-bit target. testsuite/ChangeLog: PR target/65990 * gcc.target/i386/pr65990.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr65990.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66010
--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 35480
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35480action=edit
Tentative patch
(In reply to Richard Biener from comment #5)
apD.1859 = apD.1844;
# .MEM_7 = VDEF .MEM_3
# USE = nonlocal null { D.1844 D.1859 } (escaped)
# CLB = nonlocal null { D.1844 D.1859 } (escaped)
_6 = VA_ARG (apD.1859,
this also looks like double-indirection (and thus wrong-code?)
It looks wrong to me as well, but I haven't seen any wrong generated code as a
consequence. There's some fixup code in gimplify_va_arg_internal, that adds an
occasional addr expression, I suspect this bit is handling (or balancing out)
this extra indirection:
...
/* For this case, the backends will be expecting a pointer to
TREE_TYPE (abi), but it's possible we've
actually been given an array (an actual TARGET_FN_ABI_VA_LIST).
So fix it. */
if (TREE_CODE (TREE_TYPE (valist)) == ARRAY_TYPE)
{
tree p1 = build_pointer_type (TREE_TYPE (have_va_type));
valist = fold_convert_loc (loc, p1,
build_fold_addr_expr_loc (loc, valist));
}
gimplify_expr (valist, pre_p, post_p, is_gimple_val, fb_rvalue);
...
Note that I'd defer all possible optimization issues to _after_ re-writing
the stdarg pass to take advantage of va_arg not being lowered.
Right. But the double indirection is suspicious, so I tried to get rid of it.
Attached tentative patch achieves this. It manages to generate:
...
f2_1 (struct * ap)
{
intD.6 D.1852;
# USE = anything
# CLB = anything
D.1852 = VA_ARG (apD.1837, 0B, 0);
return D.1852;
}
...
And after early inlinling we get in f2:
...
# .MEM_2 = VDEF .MEM_1(D)
# USE = anything
# CLB = anything
__builtin_va_startD.1030 (apD.1844, 0);
# .MEM_3 = VDEF .MEM_2
# USE = anything
# CLB = anything
_8 = VA_ARG (apD.1844, 0B, 0);
...
That fixes this PR:
...
f2: va_list escapes 0, needs to save 8 GPR units and 0 FPR units.
...
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 Ever confirmed|0 |1
[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862 --- Comment #6 from Matthew Fortune matthew.fortune at imgtec dot com --- (In reply to Robert Suchanek from comment #5) I am not sure, that the result code is better as we access memory 3 times instead of access to $f20. On one hand, yes, it seems good but it's not always desirable to use FP regs until absolutely necessary. For instance, compiling the dynamic linker that uses FP regs does not seem to be right. On the costs front then while it is true that moves between FPR and GPR are usually cheaper than moving to memory and back there is a secondary cost which is that simply turning on the FPU is costly. So, the reason for using FPRs needs to be that the floating point instructions are used rather than registers. Ideally we would not spill to FPRs unless there has been actual floating point code used, this suggests it would be good to set the cost of GPR-FPR higher than memory if no floating point code is present in the function. Otherwise if the FPU is in use anyway then using FPRs as scratch/spill for integer mode data is fine and the costs can be lower than memory. Matthew
[Bug bootstrap/66038] New: SIGSEGV at stage 2 build/genmatch --gimple ../../gcc-5.1.0/gcc/match.pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 Bug ID: 66038 Summary: SIGSEGV at stage 2 build/genmatch --gimple ../../gcc-5.1.0/gcc/match.pd Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dougmencken at gmail dot com Target Milestone: --- Created attachment 35481 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35481action=edit remake log I want to try GCC 5.1.0. But at bootstrap, it gives ... ld warning: atom sorting error for operand::gen_transform(__sFILE*, char const*, bool, int, char const*, capture_info*, dt_operand**, bool) and hash_tableid_base, xcallocator, false::find_with_hash(id_base const*, unsigned int) in build/genmatch.o /bin/sh: line 1: 44113 Segmentation fault build/genmatch --gimple ../../gcc-5.1.0/gcc/match.pd tmp-gimple-match.c make[3]: *** [s-match] Error 139 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 I attached remake log.
[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Daniel Krügler from comment #10) I read DR 1630 again and cannot follow that conclusion - could you clarify? It still says For copy-initialization, the candidate functions are all the converting constructors (12.3.1 [class.conv.ctor]) of that class and the issue example uses an explicit default constructor. Yes, but the previous sentence now says For direct-initialization or default-initialization, the candidate functions are all the constructors of the class of the object being initialized. This is default-initialization by way of value-initialization, so I think this sentence takes priority over the one you quote.
[Bug bootstrap/66009] [6 Regression] Bootstrap failure on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66009 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Hahaha, finally figured out what was going on here. The definition of types_match and single_use violate the C++ ODR in a non-optimizing compilation (ie, then they do not get inlined). There'll be two implementations of each function -- with different semantics and the linker will just pick one willy-nilly. Easily fixed by making them static inlines. Doh!
[Bug other/66037] [docs] what is the difference between global_options and global_options_set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- See https://gcc.gnu.org/ml/gcc-patches/2010-10/msg00051.html (whenever an options structure pointer is available, you should use that rather than global_*).
[Bug c++/53792] [C++11] improving compiler-time constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792
Balakrishnan B balakrishnan.erode at gmail dot com changed:
What|Removed |Added
CC||balakrishnan.erode at gmail
dot co
||m
--- Comment #8 from Balakrishnan B balakrishnan.erode at gmail dot com ---
Another testcase with c++14 extended constexpr (i.e supports loops and more
than one statement).
Code:
templateclass T
void sink(T);
constexpr unsigned foo(){
unsigned i = 1;
while((i1) i){
i = i1;
}
return i;
}
templateunsigned i
struct Foo
{
};
void bar(){
sink(foo());
sink(Foofoo(){});
}
Assembly for bar:
clang3.5.1 -O3 -std=c++14
bar():# @bar()
pushq %rax
movl$-2147483648, %edi # imm = 0x8000
callq void sinkunsigned int(unsigned int)
popq%rax
jmp void sinkFoo2147483648u (Foo2147483648u) # TAILCALL
gcc5.1.0 -O3 -std=c++14
bar():
movl$32, %eax
movl$1, %edi
jmp .L2
.L3:
movl%edx, %edi
.L2:
subl$1, %eax
leal(%rdi,%rdi), %edx
jne .L3
subq$8, %rsp
callvoid sinkunsigned int(unsigned int)
subq$8, %rsp
pushq $0
callvoid sinkFoo2147483648u (Foo2147483648u)
addq$24, %rsp
ret
Live demo: http://goo.gl/b56Q5k
[Bug tree-optimization/57558] Issue with number of iterations calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57558 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-05-06 CC||alalaw01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from alalaw01 at gcc dot gnu.org --- Seeing this too. Is another approach to fall back to an alternative (scalar?) path (perhaps just the epilogue?) if we can tell at the beginning of the loop that the iteration count will be infinite?
[Bug other/66037] New: [docs] what is the difference between global_options and global_options_set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66037 Bug ID: 66037 Summary: [docs] what is the difference between global_options and global_options_set? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- I'm working on something that touches the target option override code and I notice the i386 and rs6000 targets check and set fields in the global_options and global_options_set structures, but I can't figure out from the documentation what is the difference. Is it that global_options_set are the options explicitly set by the user? What is it's relationship to global_options? is one derived from the other? Can the target change values in global_options_set? Would be nice if these variables at least were documented in options.texi
[Bug fortran/66041] New: [6.0 Regression] Matmul ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66041 Bug ID: 66041 Summary: [6.0 Regression] Matmul ICE Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- cat test.f90 REAL*8, ALLOCATABLE :: a(:,:), b(:,:), v(:) ALLOCATE(a(N,N),b(N,N),v(N)) DO i=1,N v = MATMUL(a,b(:,i)) ENDDO END gfortran -O2 test.f90 test.f90:6:0: v = MATMUL(a,b(:,i)) 1 internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.c:8900 0x69057b gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) ../../gcc/gcc/fortran/trans-array.c:8900 0x690b90 gfc_walk_expr(gfc_expr*) ../../gcc/gcc/fortran/trans-array.c:9264 0x69287c gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-array.c:6568 0x6cfb03 gfc_conv_intrinsic_bound ../../gcc/gcc/fortran/trans-intrinsic.c:1860 0x6da3de gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-intrinsic.c:8048 0x6b767e gfc_conv_expr_op ../../gcc/gcc/fortran/trans-expr.c:3264 0x6b5e33 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/gcc/fortran/trans-expr.c:7414 0x6b5ed8 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*) ../../gcc/gcc/fortran/trans-expr.c:7428 0x686ddd gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc/gcc/fortran/trans-array.c:3306 0x6b651c gfc_conv_variable ../../gcc/gcc/fortran/trans-expr.c:2575 0x6b767e gfc_conv_expr_op ../../gcc/gcc/fortran/trans-expr.c:3264 0x6b767e gfc_conv_expr_op ../../gcc/gcc/fortran/trans-expr.c:3264 0x6b4777 gfc_trans_assignment_1 ../../gcc/gcc/fortran/trans-expr.c:9097 0x67ddc5 trans_code ../../gcc/gcc/fortran/trans.c:1682 0x6fa4a4 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1680 0x6fa4a4 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1843 0x67dbda trans_code ../../gcc/gcc/fortran/trans.c:1791 0x6fa4a4 gfc_trans_simple_do ../../gcc/gcc/fortran/trans-stmt.c:1680 0x6fa4a4 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/gcc/fortran/trans-stmt.c:1843 0x67dbda trans_code ../../gcc/gcc/fortran/trans.c:1791
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com ---
gcc-4.9.2-6.fc21.x86_64:
gcc-5.1.1-1.fc23.x86_64
#include debug/string
int main() { __gnu_debug::string s((const char *)0); }
g++ -o gcc59675b gcc59675b.C -Wall -g -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC
./gcc59675b 2/dev/null
/usr/include/c++/5.1.1/debug/functions.h:315: const _CharT*
__gnu_debug::__check_string(const _CharT*) [with _CharT = char]: Assertion '__s
!= 0' failed.
Aborted
I was hitting this issue often on some older GCC versions but now I find it
very difficult to reproduce. __glibcxx_assert() is probably no longer too much
used. For some reason I could no longer even reproduce it with std::string.
