[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125 Marek Polacek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r201439.
[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125 --- Comment #3 from Marek Polacek --- Seems like we're trying to access &(*inline_summary_vec)[node->uid]; where the node->uid is 8, but inline_summary_vec's length is 8.
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 A. Kasahara changed: What|Removed |Added CC||latlon90180+gcc_bugzilla@gm ||ail.com --- Comment #8 from A. Kasahara --- Is there any progress on this? REAL128 of gfortran4.8 is still 10.
[Bug c++/58129] [C++11] Lack of access control checking using auto type deduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58129 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Access control applies to names, and you don't use the private name "Private" so there's no error.
[Bug gcov-profile/58127] [4.9 Regression] 37 failures in gcc.dg/tree-prof/ for x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58127 --- Comment #1 from Dominique d'Humieres --- Revision 201632 is OK, r201634 is not.
[Bug tree-optimization/57980] [4.7/4.8/4.9 Regression] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Mon Aug 12 08:46:41 2013 New Revision: 201660 URL: http://gcc.gnu.org/viewcvs?rev=201660&root=gcc&view=rev Log: PR tree-optimization/57980 Added: trunk/gcc/testsuite/gcc.dg/pr57980.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-tailcall.c
[Bug tree-optimization/57980] [4.7/4.8/4.9 Regression] gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57980 --- Comment #4 from Marek Polacek --- Fixed on trunk.
[Bug tree-optimization/58006] [4.8/4.9 Regression] ICE compiling VegaStrike with -ffast-math -ftree-parallelize-loops=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58006 vincent.legoll at gmail dot com changed: What|Removed |Added CC||vincent.legoll at gmail dot com --- Comment #7 from vincent.legoll at gmail dot com --- Hello, I got the same under Debian Jessie $ gcc-4.8 -v Using built-in specs. COLLECT_GCC=gcc-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-2)
[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039
--- Comment #4 from Alexander Barkov ---
Mikael, thanks for your comment on this.
(In reply to Mikael Pettersson from comment #3)
> Your code performs mis-aligned uint16_t stores, which x86 allows.
Right, this is done for performance purposes.
> The
> vectorizer turns those into larger and still mis-aligned `movdqa' stores,
> which x86 does not allow, hence the SEGV.
Can you please clarify: is it a bug in the recent gcc versions?
Note, we've used such performance improvement tricks for years.
It worked perfectly fine until now.
Has anything changed in how the gcc vectorizer works recently?
>
> Replace the non-portable mis-aligned stores with portable code like
>
> #define int2store_little_endian(s,A) memcpy((s), &(A), 2)
>
> or gcc-specific code like
>
> struct __attribute__((__packed__)) packed_uint16 {
> uint16_t u16;
> };
> #define int2store_little_endian(s,A) ((struct packed_uint16*)(s))->u16 = (A)
>
> and then the vectorizer generates large `movdqu' stores, which is pretty
> much the best you can hope for unless you rewrite the code to avoid
> mis-aligned stores.
Unfortunately it's not possible to avoid mis-aligned stores due to the
project architecture.
I've read somewhere that gcc vectorizer generates two code branches,
for aligned memory and for non-aligned memory (but can't find
the reference now). Can you please confirm this?
Thanks.
[Bug tree-optimization/58135] New: [x86] Missed opportunities for partial SLP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58135
Bug ID: 58135
Summary: [x86] Missed opportunities for partial SLP
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ysrumyan at gmail dot com
If we consider the following simple test-case
int a[100];
void foo()
{
a[0] = a[1] = a[2] = a[3] = 0;
}
SLP vectorization of basic block takes place:
gcc -S -O3 -m32 t.c -ftree-vectorizer-verbose=1
t.c:4: note: Vectorized basic-block
but if we add at least one more assignment it won't be vectorized:
a[0] = a[1] = a[2] = a[3] = a[4] = 0;
t11.c:4: note: Build SLP failed: unrolling required in basic block SLP
It is clear that gcc can do partial BB vectorization, i.e. vectorize the first
4 assignments only.
[Bug tree-optimization/58039] -ftree-vectorizer makes a loop crash on a non-aligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58039 --- Comment #5 from Mikael Pettersson --- (In reply to Alexander Barkov from comment #4) > > The > > vectorizer turns those into larger and still mis-aligned `movdqa' stores, > > which x86 does not allow, hence the SEGV. > > Can you please clarify: is it a bug in the recent gcc versions? > > Note, we've used such performance improvement tricks for years. > It worked perfectly fine until now. > Has anything changed in how the gcc vectorizer works recently? I know next to nothing about the vectorizer, so I cannot comment on this. > Unfortunately it's not possible to avoid mis-aligned stores due to the > project architecture. Mis-aligned accesses are Ok, as long as they are expressed using the proper mechanisms (memcpy, attribute packed, or pragma packed). > I've read somewhere that gcc vectorizer generates two code branches, > for aligned memory and for non-aligned memory (but can't find > the reference now). Can you please confirm this? I don't know, see above.
[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #4 from Jan Hubicka --- Mine...
[Bug lto/58108] [4.9 regression] 32-bit g++.dg/torture/covariant-1.C -O2 -flto FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58108 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- Does this bug still reproduce (I fixed problem related to x86 local calls that may fix this too)
[Bug libgomp/38724] Segfault caused by derived-type with allocatable component in private clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38724 --- Comment #7 from janus at gcc dot gnu.org --- see also https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/vPs4MJamnCM
[Bug regression/58084] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 --- Comment #5 from Jan Hubicka --- OK, the problem is that the return type of nested function is variable sized type of the outer functions. These types go to function sections and are not merged. We used to not ICE just by luck - RESTLT_DECL went to global section that created yet another unmerged version of the type that got into RESULT_DECL. This is not only problem of this kind and I am not quite sure what to do here: either we need to invent way how to refer items in the other function section, or we need to put all abstract origins into global stream completely. The second would be very expensive... In this partiuclar case we probably can just teach tree-inline to VOID_CONVERT_EXPR when needed?
[Bug fortran/56655] [F03] ASSOCIATE construct with OpenMP triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655 --- Comment #4 from janus at gcc dot gnu.org --- The final specification of OpenMP 4.0 has been published by now and apparently supports the ASSOCIATE construct.
[Bug c/58136] New: Initialized static global variables cause segfault on AIX with debugging symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58136
Bug ID: 58136
Summary: Initialized static global variables cause segfault on
AIX with debugging symbols
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at rkeene dot org
Tested with gcc 4.6.3 and gcc 4.8.1 with binutils 2.22
Program Listing #1 (test-1.c):
static unsigned int test = 3;
int main(int argc, char **argv) {
test = 4;
return(0);
}
Program Listing #2 (test-2.c):
static unsigned int test;
int main(int argc, char **argv) {
test = 4;
return(0);
}
Compiling program listing #1 (above) with the "-gxcoff" argument causes a
segfault. Leaving off the "-gxcoff" argument, or not initializing the static
global (program listing #2, above) causes the program to not segfault.
$ powerpc-ibm-aix5.3.0.0-gcc -gxcoff -o test-1_g test-1.c
$ ./test-1_g
Segmentation fault (core dumped)
$ powerpc-ibm-aix5.3.0.0-gcc -o test-1 test-1.c
$ ./test-1
$ powerpc-ibm-aix5.3.0.0-gcc -gxcoff -o test-2_g test-2.c
$ ./test-2_g
$ powerpc-ibm-aix5.3.0.0-gcc -o test-2 test-2.c
$ ./test-2
[Bug fortran/38724] Segfault caused by derived-type with allocatable component in private clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38724 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-12 Component|libgomp |fortran Ever confirmed|0 |1 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Steve Kargl from comment #6) > I agree gfortran should reject the program until we have some idea of > the behavior with regards to OpenMP 4.0. It seems that the final OpenMP 4.0 specification does not support allocatable components. In particular it lists "Allocatable enhancement" as unsupported, which supposedly refers to TR 15581 and therefore includes alloc. comp., see http://openmp.org/wp/openmp-specifications/ So the test case should probably be rejected by the front end (alternatively: support it as a GNU extension).
[Bug tree-optimization/58137] New: [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
Bug ID: 58137
Summary: [trunk, ICE] full unroll + AVX2 vectorization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Created attachment 30635
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30635&action=edit
Reproducer
Hello attached test produces ICE, when compiled as
$ gcc -S -O3 1.c -mavx2
It seems that full unroll or copyprop (or whatever) introduces something wrong.
1.c: In function 'more_xrv':
1.c:23:1: error: type mismatch in pointer plus expression
more_xrv(void)
^
struct XRV *
struct XRV *
struct XRV *
vect_vec_iv_.15_88 = vect_cst_.13_60 + { 64B, 64B, 64B, 64B };
1.c:23:1: error: type mismatch in pointer plus expression
struct XRV *
struct XRV *
struct XRV *
...
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 --- Comment #1 from Yukhin Kirill --- Actually, this case come while debugging Spec2000's perl workload on AVX-512 changes (with bigger tripcount).
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||janus at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|OpenMP default(none) and|[F03] OpenMP default(none)
|procedure pointers |and procedure pointers
--- Comment #2 from janus at gcc dot gnu.org ---
Here is a simple patch to accept version A:
Index: gcc/fortran/openmp.c
===
--- gcc/fortran/openmp.c(revision 201653)
+++ gcc/fortran/openmp.c(working copy)
@@ -847,7 +847,7 @@ resolve_omp_clauses (gfc_code *code)
for (n = omp_clauses->lists[list]; n; n = n->next)
{
n->sym->mark = 0;
-if (n->sym->attr.flavor == FL_VARIABLE)
+if (n->sym->attr.flavor == FL_VARIABLE || n->sym->attr.proc_pointer)
continue;
if (n->sym->attr.flavor == FL_PROCEDURE
&& n->sym->result == n->sym
@@ -876,8 +876,6 @@ resolve_omp_clauses (gfc_code *code)
if (el)
continue;
}
-if (n->sym->attr.proc_pointer)
- continue;
}
gfc_error ("Object '%s' is not a variable at %L", n->sym->name,
&code->loc);
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to mrestelli from comment #0) > With version B: > gfortran -fopenmp omp_test.f90 -o omp_test > omp_test.f90: In function ‘test’: > omp_test.f90:25:0: error: ‘pf’ not specified in enclosing parallel > omp_test.f90:23:0: error: enclosing parallel What is actually the problem here? That error message looks correct to me, doesn't it?
[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717 jules at gcc dot gnu.org changed: What|Removed |Added CC||jules at gcc dot gnu.org --- Comment #7 from jules at gcc dot gnu.org --- Here's another candidate patch: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00668.html
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #9 from Steve Kargl --- On Mon, Aug 12, 2013 at 08:08:18AM +, latlon90180+gcc_bugzilla at gmail dot com wrote: > Is there any progress on this? > REAL128 of gfortran4.8 is still 10. > Need a short example. gfortran has supported a 128-bit real type for quite some time (since 4.6). real(4) a real(8) b real(10) c real(16) d print '(4(I0,1X))', digits(a), digits(b), digits(c), digits(d) end % gfortran46 -o z a.f90 && ./z 24 53 53 113 PS: yes, the output is correct for real(10). FreeBSD-i386's long double only has 53-bits of precision.
[Bug fortran/52153] REAL128 gives extended precision, not quad precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52153 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Steve Kargl from comment #9) > On Mon, Aug 12, 2013 at 08:08:18AM +, latlon90180+gcc_bugzilla at gmail > dot com wrote: > > Is there any progress on this? > > REAL128 of gfortran4.8 is still 10. > > > > Need a short example. gfortran has supported a 128-bit real type > for quite some time (since 4.6). > > real(4) a > real(8) b > real(10) c > real(16) d > print '(4(I0,1X))', digits(a), digits(b), digits(c), digits(d) > end > > % gfortran46 -o z a.f90 && ./z > 24 53 53 113 > > PS: yes, the output is correct for real(10). FreeBSD-i386's long double > only has 53-bits of precision. Ignore. I should have read the audit trail first.
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > Here is a simple patch to accept version A: ... which regtests cleanly!
[Bug lto/58108] [4.9 regression] 32-bit g++.dg/torture/covariant-1.C -O2 -flto FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58108 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jan Hubicka --- > Does this bug still reproduce (I fixed problem related to x86 local calls that > may fix this too) The failure still exists in a i386-pc-solaris2.10 bootstrap as of r201663. Rainer
[Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 --- Comment #9 from ccoutant at google dot com --- >>> + if (!active_insn_p (insn)) >>> +continue; >> >> I'm not clear on why this is needed. Is it because after the >> change_scope, insn will now be a NOTE? If that's it, just put the >> continue in the previous if clause. > > Because the notes were being skipped by the iteration over > instructions, which previously only walked active instructions (notes > are not active instructions). So to see the switch section note I had > to walk all instructions, and just skip non-active instructions after > I am done checking for the note of interest. Oh, right. I didn't notice the change in the for loop. -cary
[Bug c++/58138] New: #include gives warning: macro "__code_model_small__" is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58138
Bug ID: 58138
Summary: #include gives warning: macro
"__code_model_small__" is not used
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
At least with a trunk revision 201654 (aka LATEST-4.9) build (on Fedora 18
x86_64):
> $ cat test1.cc
> #include
> namespace {}
> $ ~/gcc/LATEST-4.9/inst/bin/g++ -std=gnu++11 -Wunused-macros -c test1.cc
> test1.cc:2:12: warning: macro "__code_model_small__" is not used
> [-Wunused-macros]
> namespace {}
> ^
I was able to strip that down to the following excerpt of
~/gcc/LATEST-4.9/inst/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include/ia32intrin.h:
> $ cat test2.cc
> #include "test2.h"
> namespace {}
> $ cat test2.h
> #pragma GCC system_header
> #pragma GCC push_options
> #pragma GCC target("sse4.2")
> #pragma GCC pop_options
> $ ~/gcc/LATEST-4.9/inst/bin/g++ -Wunused-macros -c test2.cc test2.cc:2:12:
> warning: macro "__code_model_small__" is not used [-Wunused-macros]
> namespace {}
> ^
With a build of tags/gcc_4_8_1_release, compiling test1.cc does not give a
warning while test2.cc does. And with a random old build of
branches/gcc-4_6-branch, compiling neither test1.cc nor test2.cc gives a
warning (replacing -std=gnu++11 with -std=gnu++0x when compiling test1.cc).
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 --- Comment #5 from mrestelli --- (In reply to janus from comment #3) > (In reply to mrestelli from comment #0) > > With version B: > > gfortran -fopenmp omp_test.f90 -o omp_test > > omp_test.f90: In function ‘test’: > > omp_test.f90:25:0: error: ‘pf’ not specified in enclosing parallel > > omp_test.f90:23:0: error: enclosing parallel > > What is actually the problem here? That error message looks correct to me, > doesn't it? Janus, you are probably right that version B should not compile. I guess when I posted the bug report I was not sure which was the correct version according to the OpenMP specifications, since fp is a variable (requiring an OpenMP attribute), but it behaves like a subroutine (so, no OpenMP attribute). Clearly however at least one of the two versions should work, hence my pointing out that both alternatives do not work. Well, at least this is my recollection, since it was quite a while ago. As a note, I mention that ifort (version 13.1) accepts both versions, but maybe this is an issue with ifort itself. Regards, Marco Restelli
[Bug fortran/46271] [F03] OpenMP default(none) and procedure pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271 --- Comment #6 from janus at gcc dot gnu.org --- Hi Marco, > Janus, you are probably right that version B should not compile. I > guess when I posted the bug report I was not sure which was the > correct version according to the OpenMP specifications, since fp is a > variable (requiring an OpenMP attribute), but it behaves like a > subroutine (so, no OpenMP attribute). well, since a procedure pointer can be assigned and change its value, I would say it counts as a variable and one should make up one's mind whether it is supposed to be shared or private in an OpenMP loop (as for any other variable, this can clearly make a difference). Hence my interpretation that the error message is correct. However, I should note that I'm not much of an OpenMP expert and haven't checked whether the OpenMP specifications makes any definitive statement about this. It's merely my 'gut feeling'. > As a note, I mention that ifort (version 13.1) accepts both versions, > but maybe this is an issue with ifort itself. ifort is not exactly known for it's strictness on invalid programs, and of course it may have bugs. I don't know if this is allowed on purpose or if the missing error is an oversight. If ifort accepts the program, it would be interesting whether it treats the procptr as private or shared with default(none), and whether this behavior is documented somewhere (either in the OpenMP spec or the ifort docs). Some people claim that documentation is the only thing that distinguishes a feature from a bug ;) Cheers, Janus
[Bug target/58139] New: PowerPC volatile VSX register live across call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
Bug ID: 58139
Summary: PowerPC volatile VSX register live across call
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
void tightness3_intrinsics2(double* A, double* B, int N) {
__vector double * vA = (__vector double*)A;
__vector double * vB = (__vector double*)B;
__vector double va0, va1;
double b0, b1, b2, b3;
va0 = vA[0];
va1 = vA[1];
b0 = log(vec_extract(va0, 0));
b1 = log(vec_extract(va0, 1));
b2 = log(vec_extract(va1, 0));
b3 = log(vec_extract(va1, 1));
__vector double vb0 = {b0, b1};
__vector double vb1 = {b2, b3};
vB[0] = vb0;
vB[1] = vb1;
}
xxpermdi 1,63,63,2
xxpermdi 30,30,29,0
bl log
nop
addi 1,1,192
li 0,-80
stxvd2x 30,0,30
GCC should not expect VSX 30 to be preserved across the call to log().
[Bug target/58139] PowerPC volatile VSX register live across call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139 David Edelsohn changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2013-08-12 CC||bergner at gcc dot gnu.org Host||powerpc*-*-* Ever confirmed|0 |1 Known to fail||4.6.3, 4.7.3, 4.8.1 Build||powerpc*-*-* --- Comment #1 from David Edelsohn --- Confirmed.
[Bug c++/58140] New: -Wnon-virtual-dtor shouldn't fire for classes declared final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58140 Bug ID: 58140 Summary: -Wnon-virtual-dtor shouldn't fire for classes declared final Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tudorb at fb dot com Created attachment 30636 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30636&action=edit Test case In C++11, we can declare a class as "final" to indicate that it can't be derived from. In that case, having a public non-virtual destructor is fine, even if the class has virtual methods (no derived classes exist, so deleting an instance via a pointer is always safe). In the attached example, the warning should fire for NonFinalDerived, but not for FinalDerived.
[Bug c++/58140] -Wnon-virtual-dtor shouldn't fire for classes declared final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58140 --- Comment #1 from Tudor Bosman --- (Tested with gcc 4.7.1, compiled with -std=c++11 -Wnon-virtual-dtor
[Bug middle-end/58134] -ftree-vectorizer-verbose= shows vectroiyed loops only for N== 1 and N >2 but not for N==2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58134
--- Comment #1 from Tobias Burnus ---
The reason is the following:
dump_printf_loc (MSG_OPTIMIZED_LOCATIONS, vect_location,
"Vectorized loop\n");
And in opts-global.c's dump_remap_tree_vectorizer_verbose:
switch (value)
{
case 0:
break;
case 1:
remapped_opt_info = "optimized";
break;
case 2:
remapped_opt_info = "missed";
break;
default:
remapped_opt_info = "all";
break;
}
And dumpfile.h:
#define MSG_OPTIMIZED_LOCATIONS (1 << 26) /* -fopt-info optimized sources */
#define MSG_MISSED_OPTIMIZATION (1 << 27) /* missed opportunities */
#define MSG_NOTE (1 << 28) /* general optimization info */
#define MSG_ALL (MSG_OPTIMIZED_LOCATIONS | MSG_MISSED_OPTIMIZATION \
| MSG_NOTE)
[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectroiyed loops only for N== 1 and N >2 but not for N==2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58134 Tobias Burnus changed: What|Removed |Added CC||singhai at gcc dot gnu.org Summary|-ftree-vectorizer-verbose=< |[4.8/4.9 Regression] |n> shows vectroiyed loops |-ftree-vectorizer-verbose=< |only for N== 1 and N >2 but |n> shows vectroiyed loops |not for N==2|only for N== 1 and N >2 but ||not for N==2 --- Comment #2 from Tobias Burnus --- Using g++-4.7 -O3 -ftree-vectorizer-verbose=2 it works as one gets: 7: LOOP VECTORIZED. Seemingly caused by r193061
[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectroiyed loops only for N== 1 and N >2 but not for N==2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58134 --- Comment #3 from Sharad Singhai --- I think this is the intended behavior. While working on the new dump infrastructure, I modified the behavior of -ftree-vectorizer-verbose. Thus right now -ftree-vectorizer-verbose=1 : dump info about optimized loops ...=2 : dump info about missed loops ...>2 : dump info about optimized _and_ missed loops Thus at 3 and greater, you are again seeing info available at 1. But really, only 1 and 2 are meaningful. Anything higher is a combination of these two kinds of information. This was a way to preserve compatibility with old scripts, while deprecating this flag. I didn't see any tests relying on the old behavior. Here is the current documentation about this flag in gcc.info: `-ftree-vectorizer-verbose=N' This option is deprecated and is implemented in terms of `-fopt-info'. Please use `-fopt-info-KIND' form instead, where KIND is one of the valid opt-info options. It prints additional optimization information. For N=0 no diagnostic information is reported. If N=1 the vectorizer reports each loop that got vectorized, and the total number of loops that got vectorized. If N=2 the vectorizer reports locations which could not be vectorized and the reasons for those. For any higher verbosity levels all the analysis and transformation information from the vectorizer is reported.
[Bug c++/58140] -Wnon-virtual-dtor shouldn't fire for classes declared final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58140 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-12 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- This should be pretty simple to fix, but why use -Wnon-virtual-dtor anyway, when -Wdelete-non-virtual-dtor is more accurate and more useful?
[Bug c++/58140] -Wnon-virtual-dtor shouldn't fire for classes declared final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58140 --- Comment #3 from Jonathan Wakely --- (In reply to Tudor Bosman from comment #0) > In C++11, we can declare a class as "final" to indicate that it can't be > derived from. In that case, having a public non-virtual destructor is fine, > even if the class has virtual methods (no derived classes exist, so deleting > an instance via a pointer is always safe). N.B. this is only true if there's no base class with a public destructor, which is true for your example, but not in general.
[Bug c/58141] New: [bfin]: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58141 Bug ID: 58141 Summary: [bfin]: ICE: Segmentation fault Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: canyon at recursivebliss dot com Created attachment 30637 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30637&action=edit Preprocessed source Description of problem: When compiling Das U-Boot for a Blackfin target, there is a internal compiler error: Segmentation fault . Version-Release number of selected component (if applicable): bfin-uclinux-gcc 4.8.1 How reproducible: Every time. Steps to Reproduce: 1. git clone git://git.denx.de/u-boot.git 2. cd u-boot 3. make bf518f-ezbrd Actual results: main.c: In function 'builtin_run_command': main.c:1434:1: internal compiler error: Segmentation fault } Expected results: Successful build. Additional info: If you comment out the call of process_macros in builtin_run_command the build is successful.
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #2 from Bernd Edlinger --- reproduced also with arm-none-eabi: ../arm-eabi/bin/arm-eabi-gcc -O3 -mfpu=neon -mfloat-abi=softfp 1.c
[Bug tree-optimization/58121] [4.9 regression] FAIL: cc1224a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58121 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I cannot reproduce: === acats tests === === acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is ia64-unknown-linux-gnu === gnat tests === Running target unix === gnat Summary === # of expected passes1168 # of expected failures 18 # of unsupported tests 10
[Bug other/58133] GCC should emit arm assembly following the unified syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133 --- Comment #1 from Sven --- It seems, that for targets like -mcpu=cortex-m4 the gcc does generate unified syntax. So is the unified syntax only used for newer targets that use the thumb2 instruction set whereas the divided syntax is used for older thumb1 targets?
[Bug c++/58142] New: _pthread_tsd_cleanup called before destructors are called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142
Bug ID: 58142
Summary: _pthread_tsd_cleanup called before destructors are
called
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soonhok at cs dot cmu.edu
Created attachment 30638
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30638&action=edit
preprocessed input file
It seems when a thread is finished, its thread cleanup routine is called before
destructors of TLS(Thread Local Storage) variables are called and it causes
(possible) segmentation faults. I provided a simplified small program which
reproduces the behavior. Even if it doesn't generate a segmentation fault,
running valgrind over it indicates the same problem is going on in run-time.
This problem happens only on OSX. When I tried the same C++ code on Ubuntu12.04
with g++-4.8.1. There was no problem. I also tried with clang++-3.3 on OSX.
There was no problem either.
1. The exact version of GCC:
gcc-4.8.1
2. the system type:
OSX 10.8.4, Darwin air 12.4.0 Darwin Kernel Version 12.4.0
3. the options given when GCC was configured/built:
g++-4.8 -std=c++11 thread.cpp -O thread
4. the complete command line that triggers the bug;
valgrind thread
5. the compiler output (error messages, warnings, etc.); and
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).
Preprocessed file is attached. Here is the original source code (much shorter):
==
#include
#include
#include
#include
static void foo() {
static thread_local std::vector v(1024);
if (v.size() != 1024) {
std::cerr << "Error\n";
exit(1);
}
}
static void tst1() {
unsigned n = 5;
for (unsigned i = 0; i < n; i++) {
std::thread t([](){ foo(); });
t.join();
}
}
int main() {
tst1();
}
==
The following is the output of valgrind:
...
==18408== Invalid read of size 8
==18408==at 0x121B3: std::_Vector_base
>::~_Vector_base() (in ./a.out)
==18408==by 0x12054: std::vector >::~vector()
(in ./a.out)
==18408==by 0xB9F5: (anonymous namespace)::run(void*) (in
/usr/local/lib/libstdc++.6.dylib)
==18408==by 0x29CA01: _pthread_exit (in /usr/lib/system/libsystem_c.dylib)
==18408==by 0x29C7AC: _pthread_start (in /usr/lib/system/libsystem_c.dylib)
==18408==by 0x2891E0: thread_start (in /usr/lib/system/libsystem_c.dylib)
==18408== Address 0x1000257a8 is 8 bytes inside a block of size 32 free'd
==18408==at 0x5632: free (in
/usr/local/Cellar/valgrind/3.8.1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==18408==by 0x1CAA12: emutls_destroy (in /usr/local/lib/libgcc_s.1.dylib)
==18408==by 0x101: ???
==18408==by 0xB0080E9F: ???
==18408==by 0xB008186F: ???
==18408==by 0x2A34DF: _pthread_tsd_cleanup (in
/usr/lib/system/libsystem_c.dylib)
==18408==by 0xB008105F: ???
...
[Bug target/58139] PowerPC volatile VSX register live across call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139
--- Comment #2 from Peter Bergner ---
This looks like a scheduling bug. Just before sched2, we have:
(call_insn 29 28 31 2 (parallel [
(set (reg:DF 33 1)
(call (mem:SI (symbol_ref:DI ("log") [flags 0x41]
) [0 __builtin_log S4 A8])
(const_int 64 [0x40])))
(use (const_int 0 [0]))
(clobber (reg:SI 65 lr))
]) bug.c:17 509 {*call_value_nonlocal_aix64}
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:REG_NON_LOCAL_GOTO (use (reg:DF 33 1))
(nil)))
(insn 31 29 34 2 (set (reg:V2DF 62 30 [orig:140 vb0 ] [140])
(unspec:V2DF [
(reg/v:DF 62 30 [orig:123 b0 ] [123])
(reg/v:DF 61 29 [orig:125 b1 ] [125])
] UNSPEC_VSX_CONCAT)) bug.c:18 920 {vsx_concat_v2df}
(expr_list:REG_DEAD (reg/v:DF 61 29 [orig:125 b1 ] [125])
(expr_list:REG_EQUIV (mem:V2DF (reg/v/f:DI 30 30 [orig:133 B ] [133])
[2 MEM[(__vector double *)B_2(D)]+0 S16 A128])
(nil
Here, insn 31 sets VSX reg 62 (ie, fpr30,vsr30). In DFmode, reg 62 is a
non-volatile register, but in V2DFmode, it is volatile. After sched2, we have:
insn:TI 31 28 29 2 (set (reg:V2DF 62 30 [orig:140 vb0 ] [140])
(unspec:V2DF [
(reg/v:DF 62 30 [orig:123 b0 ] [123])
(reg/v:DF 61 29 [orig:125 b1 ] [125])
] UNSPEC_VSX_CONCAT)) bug.c:18 920 {vsx_concat_v2df}
(expr_list:REG_DEAD (reg/v:DF 61 29 [orig:125 b1 ] [125])
(expr_list:REG_EQUIV (mem:V2DF (reg/v/f:DI 30 30 [orig:133 B ] [133])
[2 MEM[(__vector double *)B_2(D)]+0 S16 A128])
(nil
(call_insn 29 31 72 2 (parallel [
(set (reg:DF 33 1)
(call (mem:SI (symbol_ref:DI ("log") [flags 0x41]
) [0 __builtin_log S4 A8])
(const_int 64 [0x40])))
(use (const_int 0 [0]))
(clobber (reg:SI 65 lr))
]) bug.c:17 509 {*call_value_nonlocal_aix64}
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:REG_NON_LOCAL_GOTO (use (reg:DF 33 1))
(nil)))
So it looks like the scheduler is somehow thinking that reg 62 is non-volatile
when it's really volatile in V2DFmode and moving it before the call which ends
up clobbering it.
Still digging.
[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 --- Comment #8 from Paolo Carlini --- The ICE is indeed fixed in mainline. I'm going to commit a (reduced) testcase and close the issue.
[Bug c++/57416] internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57416 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #9 from Paolo Carlini --- Done.
[Bug go/58075] Unable to build go on ia64-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58075 --- Comment #2 from Paul Ackersviller --- Thanks, I have sent this on to HP. Should I report back a patch number, or whatever they end up responding with?
[Bug tree-optimization/58137] [trunk, ICE] full unroll + AVX2 vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137 --- Comment #3 from Bernd Edlinger --- Created attachment 30639 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30639&action=edit possible fix This seems to be a bug in the constant folding of constant vector values at forwprop4. Could some one check if the generated code is now correct ? Thanks.
[Bug go/58075] Unable to build go on ia64-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58075 --- Comment #3 from Ian Lance Taylor --- Yes, please. Thanks.
[Bug middle-end/58143] New: wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143
Bug ID: 58143
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and gcc 4.8 produce wrong code for the following testcase
on x86_64-linux when compiled at -O3 (in both 32-bit and 64-bit modes). This is
a regression from 4.7.x.
$ gcc-trunk -v
gcc version 4.9.0 20130812 (experimental) [trunk revision 201658] (GCC)
$ gcc-trunk -O2 small.c
$ a.out
0
$ gcc-4.7 -O3 small.c
$ a.out
0
$ gcc-trunk -O3 small.c
$ a.out
-1
$ gcc-4.8 -O3 small.c
$ a.out
-1
$
--
int printf (const char *, ...);
int a, b, c, d, e, f, g, h = 1, i;
int foo (int p)
{
return p < 0 && a < -2147483647 - 1 - p ? 0 : 1;
}
int *bar ()
{
int j;
i = h ? 0 : 1 % h;
for (j = 0; j < 1; j++)
for (d = 0; d; d++)
for (e = 1; e;)
return 0;
return 0;
}
int baz ()
{
for (; b >= 0; b--)
for (c = 1; c >= 0; c--)
{
int *k = &c;
for (;;)
{
for (f = 0; f < 1; f++)
{
g = foo (*k);
bar ();
}
if (*k)
break;
return 0;
}
}
return 0;
}
int main ()
{
baz ();
printf ("%d\n", b);
return 0;
}
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #1 from Andrew Pinski --- -2147483647 - 1 - p Hmm, this overflows for p > 1.
[Bug middle-end/58143] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58143 --- Comment #2 from Zhendong Su --- Andrew, because of short-circuiting, when p >= 0, the expression "-2147483647 - 1 - p" isn't actually evaluated. Thanks for looking into this so quickly! Zhendong
[Bug c++/58144] New: Receive "virtual memory exhausted: Cannot allocate memory" while compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58144 Bug ID: 58144 Summary: Receive "virtual memory exhausted: Cannot allocate memory" while compiling Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: amit.chitnis at gmail dot com g++ (GCC) 4.4.6 20130305 (Red Hat 4.4.6-4). Steps to reproduce 1. create a small hello world program with iostream,stdio.h and stdlib.h using namespace std; 2. create a big file (say 900M) named "new" in a location which is a part of your include path. 3. Compile the hello world cpp and it should fail with the above error. This seems to be because of the size and name of the file created in step 2 above. g++ -g -pthread -D_THREAD_SAFE -D_REENTRANT -I/opt/performance -o helloworld.o -c helloworld.cpp file "new" was created at location /opt/performance/
[Bug middle-end/58145] New: [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 Bug ID: 58145 Summary: [Regression]: volatileness of write is discarded, perhaps in "lim1" related to loop optimizations Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target: cris-*-*, crisv32-*-* Created attachment 30640 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30640&action=edit Preprocessed code; compile at -O2, e.g. "cc1 -O2 y.i -o y.s" The exact version in which the bug appeared is not yet triaged: it's present on r201675 of trunk, r201652 of the 4.8 branch, r190527 of the 4.7 branch (!) but appears to not be present in r135713 of the 4.3 branch (!). The bug is that the volatileness of the dereference of the write (the assignment through a pointer to a volatile structure) in function pb_out is discarded, leaving a single write after the loop. Note also that together with the discarded-volatileness-bug there seems to be a missed-optimization-bug in that the loop is redundant; the loop awkwardly computes iterates over 0..31 and computes 1<
[Bug fortran/58146] New: Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 Bug ID: 58146 Summary: Array slice bounds checking Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org The following doesn't trigger an error at compile time, neither does it do so with -fcheck=all at runtime: ig25@linux-fd1f:/tmp> cat diff.f90 program main implicit none integer :: n real, dimension(10) :: a n = 0 call random_number(a) if (any(a(n+1:n+4) > [1.0, 2.0, 3.0])) print *,"Hello!" end program main ig25@linux-fd1f:/tmp> gfortran -fcheck=all diff.f90 ig25@linux-fd1f:/tmp> ./a.out ig25@linux-fd1f:/tmp>
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 Thomas Koenig changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
