[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #5 from Jakub Jelinek --- If you only care about tail recursion and not tail call optimization, perhaps, but either solution would be very dumb. We now have var ={v} {CLOBBER}; stmts, even if those vars escape and are address taken, if there is a clobber stmt for those vars on every path from the escape point to the tail call candidate, we could perform tail recursion or tail call optimization, what we are really after is that the address of no automatic variable from the current function can escape to the tail recursion/call candidate. As in: void bar (char *); void foo (char *p) { char c; bar (&c); bar (NULL); // We can't tail call optimize this } void baz (char *p) { { char c; bar (&c); } bar (NULL); // We could tail call optimize this }
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #4 from Nikolay Orliuk --- Andrew Pinski, as long as address of variable isn't taken out of scope of function that is being tail-call optimized there is no need to worry about it and it is safe to optimize. Am I wrong? If stdc++ lib contains code like: ostream &operator<<(ostream &os, char x) { os.__escape = &x; } That's probably wrong and should be fixed. Tried to override with: ostream &operator<<(ostream &os, char x) { cout.put(x); return os; } // works on all 4.5.4, 4.7.3 and 4.8.2 ostream &operator<<(ostream &os, char x) { cout.write(&x, 1); return os; } // fails even without "bar" for 4.7.3 and 4.8.2 Note that strange behaviour of 4.7.3. Is that means that adding "bar" fires inlining?..
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 --- Comment #3 from Jakub Jelinek --- Thanks, looks good to me in my testing (s390-linux and s390x-linux --enable-checking=release 4.8 branch --with-arch=z196 --with-tune=zEC12 bootstraps/regtests), and it even fixed one FAIL in the testsuite: -FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (internal compiler error) -FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (test for excess errors) -UNRESOLVED: gcc.dg/torture/vshuf-v32qi.c -O2 compilation failed to produce executable which apparently ICEd the same way with e.g. -O2 -march=z10 or -O2 -march=z196 without the patch and doesn't with the patch. Though I'd say the #c0 testcase doesn't hurt, can you please add it to say gcc.c-torture/compile/ (or gcc.dg/torture/)?
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #5 from Yukhin Kirill --- (In reply to Uroš Bizjak from comment #3) > (In reply to Uroš Bizjak from comment #2) > > Kirill, please update also sse-13.c with new builtins. > > And sse-12.c with new options. Sure, I think this is obvious change if no regressions. Will do today.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #4 from Yukhin Kirill --- (In reply to Uroš Bizjak from comment #2) > Kirill, please update also sse-13.c with new builtins. Fix is posted as part of: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00761.html I may strip it into separate one...
[Bug c++/59819] New: -Wunused-value reports incorrect values as unused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59819 Bug ID: 59819 Summary: -Wunused-value reports incorrect values as unused Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: caibbor at gmail dot com Created attachment 31836 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31836&action=edit The program in full to replicate this bug This is pretty trivial but the warning outputs incorrect information. given the line: int foo = static_cast< int >( 1, 2, 3 ); G++ reports that value 2 and 3 are not used, when in fact 1 and 2 are not used. G++ 4.8.1's output (with -Wall): test.cpp: In function ‘int main()’: test.cpp:15:35: warning: left operand of comma operator has no effect [-Wunused-value] int foo = static_cast< int >( 1, 2, 3 ); ^ test.cpp:15:38: warning: right operand of comma operator has no effect [-Wunused-value] int foo = static_cast< int >( 1, 2, 3 ); ^ Clang 3.2.7 gets it right, however: test.cpp:15:32: warning: expression result unused [-Wunused-value] int foo = static_cast< int >( 1, 2, 3 ); ^ test.cpp:15:35: warning: expression result unused [-Wunused-value] int foo = static_cast< int >( 1, 2, 3 ); ^ 2 warnings generated.
[Bug c++/59818] [4.9 regression] Bogus error: call of overloaded .... is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59818 --- Comment #1 from ppluzhnikov at gcc dot gnu.org --- Author: ppluzhnikov Date: Wed Jan 15 05:35:24 2014 New Revision: 206618 URL: http://gcc.gnu.org/viewcvs?rev=206618&root=gcc&view=rev Log: For Google b/12471166 and PR 59818, rollback r206534 (which was a back-port from trunk of r197790). Modified: branches/google/gcc-4_8/gcc/cp/pt.c branches/google/gcc-4_8/gcc/testsuite/g++.dg/template/non-deducible1.C branches/google/gcc-4_8/gcc/testsuite/g++.dg/template/nontype25.C
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #10 from Jerry DeLisle --- Very interesting and good sleuthing! The way this is suppose to work: For G formatting, we compute the equivalent F or E formatting, as defined in the standard, and pass this new format to output_float which then uses the regular existing formatting processes to do the work. This line: (on or about line 1105 in write_float.def newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\ is suppose to compute the new 'd' from mid and the given "d" and pass that into output_float using the newf fnode structure. In the failing case the new 'd' is being set to zero and being passed on. As far as your 'kludge'. I don't think of it that way, but we should see if there is a way to correctly compute the d_o value where you are using it in output_float. There should be a way. Since the standard defines all we do in terms of F and E formatting, I think we are mishandling something there in output_float. You are very close to the solution here. (of course I could be wrong). Someone on the list once said, if it fixes the bug, its probably good enough. The computer has no feelings about "correctness" of approach.
[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #12 from Paul Pluzhnikov --- The r197790 appears to have caused PR 59818.
[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59782 --- Comment #5 from Andrew Pinski --- Isn't it better to disable this code when not optimizing so that stage 1 is never miscompiled?
[Bug c++/59818] New: [4.9 regression] Bogus error: call of overloaded .... is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59818 Bug ID: 59818 Summary: [4.9 regression] Bogus error: call of overloaded is ambiguous Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com This is caused by r197790 (fix for PR c++/23055). Google ref: b/12471166 /// --- cut --- template struct Identity { typedef T type; }; struct Foo { template Foo(T*, void (Identity::type::*m)(void)); template Foo(const T*, void (Identity::type::*m)(void) const); }; struct Bar { void Method(void) const; }; void Bar::Method(void) const { Foo foo(this, &Bar::Method); } /// --- cut --- Using g++ (GCC) 4.9.0 20140110 (experimental) g++ -c t.cc t.cc: In member function 'void Bar::Method() const': t.cc:20:29: error: call of overloaded 'Foo(const Bar*, void (Bar::*)() const)' is ambiguous Foo foo(this, &Bar::Method); ^ t.cc:20:29: note: candidates are: t.cc:11:3: note: Foo::Foo(const T*, void (Identity::type::*)() const) [with T = Bar; typename Identity::type = Bar] Foo(const T*, void (Identity::type::*m)(void) const); ^ t.cc:8:3: note: Foo::Foo(T*, void (Identity::type::*)()) [with T = const Bar; typename Identity::type = const Bar] Foo(T*, void (Identity::type::*m)(void)); ^ Replacing 'Identity::type' with 'T' makes the problem go away. Source accepted by gcc-4.8 and Clang.
[Bug c++/59742] compilation failed for package ‘RcppEigen’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59742 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- >g++: internt kompilatorfel: Dödad (program cc1plus) How much memory do you have installed or even how much swap space do you have? cc1plus is being killed by the kernel due to out of memory.
[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug target/59780] ICE in aarch64_split_128bit_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/59817] New: ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817 Bug ID: 59817 Summary: ICE in extract_affine_chrec with -O2 -ftree-loop-linear Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org The following testcase: c -O2 -ftree-loop-linear SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, * CASMIN) LOGICAL CASMIN DIMENSION ICAST(NDET,NM),IMP(NM) IF(CASMIN) THEN DO K=1,NDET DO L=1,NM IF(L.EQ.K-1) ICAST(K,L) = 1 END DO END DO END IF fails on a powerpc64-linux build from today with: # gfortran -c -O2 -ftree-loop-linear testcase.f testcase.f: In function ‘prepd’: testcase.f:3:0: internal compiler error: in extract_affine_chrec, at graphite-sese-to-poly.c:620 SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, ^ 0x10cf684f extract_affine_chrec ../../gcc/gcc/graphite-sese-to-poly.c:619 0x10cf684f extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:803 0x10cf62fb extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:842 0x10cf843f pdr_add_memory_accesses ../../gcc/gcc/graphite-sese-to-poly.c:1486 0x10cf843f build_poly_dr ../../gcc/gcc/graphite-sese-to-poly.c:1583 0x10cf843f build_pbb_drs ../../gcc/gcc/graphite-sese-to-poly.c:1846 0x10cf843f build_scop_drs ../../gcc/gcc/graphite-sese-to-poly.c:1929 0x10cfa8d7 build_poly_scop(scop*) ../../gcc/gcc/graphite-sese-to-poly.c:3171 0x10cdcabb graphite_transform_loops() ../../gcc/gcc/graphite.c:300 0x10cdd227 graphite_transforms ../../gcc/gcc/graphite.c:332 0x10cdd227 execute ../../gcc/gcc/graphite.c:416
[Bug target/59725] [4.9 Regression] ARM,AArch64 r206148 (PR tree-optimization/59544) caused regressions in pr52943
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59725 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code, patch Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-01/msg00805.htm ||l Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/59816] New: [c++11] Incorrect visibility check in template instantiation when the default constructor is a variadic template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59816 Bug ID: 59816 Summary: [c++11] Incorrect visibility check in template instantiation when the default constructor is a variadic template. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: libremax90 at gmail dot com The following C++11 code won't compile on GCC 4.8.2 while clang++ will accept it without a warning. In the following test case, GCC seems to check Base's default constructor visibility in the test function's context, where the templates are instantiated. class Base { protected: template Base(TArgs...) {} // Uncomment to workaround //Base() {} }; class Class : public Base { public: template Class(TArgs... args) : Base { args... } {} // Another workaround: //Class() {} }; void test() { Class{}; } Here is `g++ -v`'s output: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.8-20131219/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.2 20131219 (prerelease) (GCC)
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 Severity|major |normal --- Comment #3 from Andrew Pinski --- The early inliner is inlining a function which contains a variable which maybe escapes (address taken) which is causing the tail-call elimination not to happen. There are a few ways of fixing this: 1) Changing the the early inlining heuristics so it will not inline functions where local variables have their address taken. 2) Or have a tail-call optimize pass before early inlining.
[Bug target/59814] powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Alan Modra --- Created attachment 31835 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31835&action=edit make rs6000.c match rs6000.md This patch simply avoids the ICE by ensuring we don't generate these insns in the first place. The insns currently have && WORDS_BIG_ENDIAN in their predicates.
[Bug c++/59500] Bogus maybe-unintialized warning due to optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 --- Comment #1 from Andy Lutomirski --- This might be a duplicate of PR56574
[Bug libfortran/53962] Tab handling with formatted stream output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 Known to fail||4.7.4, 4.8.2, 4.9.0 --- Comment #2 from Dominique d'Humieres --- Confirmed at r206590.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #30 from Vincent Lefèvre --- (In reply to Nick Maclaren from comment #29) > It is not an "explicit definition of BEHAVIOR" (my emphasis), The pragma is just a directive. It has no additional behavior, so that there is nothing else to define. > >Note that the C standard doesn't explicitly say how a source file as a > >sequence > >of bytes is to be interpreted as a sequence of character, so that if you just ^ > > restrict to the C standard, everything is undefined. > > Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, > paragraph 1.1: > > Physical source file multibyte characters are mapped, in an Read again. I'm talking of a sequence of bytes. What your quoting is about a sequence of multibyte characters. The interpretation of the sequences of bytes as a sequence of multibyte characters is not defined. > You imply that you are also relying on some other standards or > specifications. Not other standards, just the implementation.
[Bug fortran/56675] I/O: Check edit descriptors with READ/WRITE used in FORMAT statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56675 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Related to pr28397 if not a duplicate.
[Bug fortran/28397] Check format mismatches at compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397 --- Comment #4 from Dominique d'Humieres --- See also pr56675.
[Bug target/58675] ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 --- Comment #1 from Peter Bergner --- Pat, this doesn't ICE for me anymore. Can we close this?
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 --- Comment #2 from Andrew Pinski --- I think this is a duplicate of bug 37804.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #9 from Dominique d'Humieres --- I have understood the problem in comment 8. It is illustrated by the following code print "(ru,g45.3)", 891.1 print "(rd,g45.3)", -891.1 end which gives the output 9. -9. with current releases and trunk. The problem comes from the lines newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\ and if (w > 0 && d == 0 && p == 0) nbefore = 1; in libgfortran/io/write_float.def when mid==d+1. I have also noticed the sentence "the asm volatile is required for 32-bit x86 platforms" which seems to answer my question in comment 6. These remarks led me to the following patch --- ../_clean/libgfortran/io/write_float.def2014-01-04 15:51:53.0 +0100 +++ libgfortran/io/write_float.def2014-01-14 22:55:24.0 +0100 @@ -112,7 +112,7 @@ determine_precision (st_parameter_dt * d static bool output_float (st_parameter_dt *dtp, const fnode *f, char *buffer, size_t size, - int nprinted, int precision, int sign_bit, bool zero_flag) + int nprinted, int precision, int sign_bit, bool zero_flag, int d_o) { char *out; char *digits; @@ -373,7 +373,7 @@ output_float (st_parameter_dt *dtp, cons updown: rchar = '0'; - if (w > 0 && d == 0 && p == 0) + if (w > 0 && d_o == 0 && p == 0) nbefore = 1; /* Scan for trailing zeros to see if we really need to round it. */ for(i = nbefore + nafter; i < ndigits; i++) @@ -1018,13 +1018,14 @@ output_float_FMT_G_ ## x (st_parameter_d int d = f->u.real.d;\ int w = f->u.real.w;\ fnode newf;\ - GFC_REAL_ ## x rexp_d, r = 0.5;\ + GFC_REAL_ ## x rexp_d, r = 0.5, r_sc;\ int low, high, mid;\ int ubound, lbound;\ char *p, pad = ' ';\ int save_scale_factor, nb = 0;\ bool result;\ int nprinted, precision;\ + volatile GFC_REAL_ ## x temp;\ \ save_scale_factor = dtp->u.p.scale_factor;\ \ @@ -1043,10 +1044,13 @@ output_float_FMT_G_ ## x (st_parameter_d break;\ }\ \ - rexp_d = calculate_exp_ ## x (-d);\ - if ((m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0)))\ + rexp_d = calculate_exp_ ## x (d);\ + r_sc = (1 - r / rexp_d);\ + temp = 0.1 * r_sc;\ + if ((m > 0.0 && ((m < temp) || (r >= (rexp_d - m\ || ((m == 0.0) && !(compile_options.allow_std\ - & (GFC_STD_F2003 | GFC_STD_F2008\ + & (GFC_STD_F2003 | GFC_STD_F2008)))\ + || d == 0)\ { \ newf.format = FMT_E;\ newf.u.real.w = w;\ @@ -1066,10 +1070,9 @@ output_float_FMT_G_ ## x (st_parameter_d \ while (low <= high)\ { \ - volatile GFC_REAL_ ## x temp;\ mid = (low + high) / 2;\ \ - temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\ + temp = (calculate_exp_ ## x (mid - 1) * r_sc);\ \ if (m < temp)\ { \ @@ -1106,7 +1109,7 @@ output_float_FMT_G_ ## x (st_parameter_d \ finish:\ result = output_float (dtp, &newf, buffer, size, nprinted, precision,\ - sign_bit, zero_flag);\ + sign_bit, zero_flag, d);\ dtp->u.p.scale_factor = save_scale_factor;\ \ \ @@ -1240,7 +1243,7 @@ determine_en_precision (st_parameter_dt else\ nprinted = DTOA(y,precision,tmp);\ output_float (dtp, f, buffer, size, nprinted, precision,\ - sign_bit, zero_flag);\ + sign_bit, zero_flag, f->u.real.d);\ }\ }\ I agree that the additional dummy argument d_o is a kludge, but I did not find a better way to distinguish between d==0 in the format and mid==d+1. Comments and improvements welcomed. Regtested without regression r206590 plus the patch.
[Bug libfortran/48925] Code cleanup in write_float.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- For having looked at the code for pr59774, I agree that libgfortran/io/write_float.def badly needs some cleaning in next stage 1.
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 --- Comment #1 from Paul Pluzhnikov --- Slightly more reduced test: namespace foo { template < typename > class A { template < typename > friend class Outer; }; A a; // comment out -> bug goes away. template < typename > class Outer; } using foo::Outer;
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #2 from Nikolay Orliuk --- My 4.5.4 built without graphite support. Both 4.7.3 and 4.8.2 built with cloog 0.17.0 and isl 0.11.2
[Bug c++/59815] New: Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 Bug ID: 59815 Summary: Apparently bogus error: 'Outer' is already declared in this scope Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Google ref: b/12471255 /// --- cut --- namespace foo { template < typename > class A { template < typename > friend class Outer; }; class B:foo::A < int > { }; template < typename > class Outer; } using foo::Outer; /// --- cut --- Using g++ (GCC) 4.9.0 20140110 (experimental): g++ -c tt.cc tt.cc:13:12: error: 'Outer' is already declared in this scope using foo::Outer; ^ Source is accepted by Clang and is believed to be valid.
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #1 from Nikolay Orliuk --- In 4.7.3 that code works, but changing it to void foo() { cout << "x" << endl; // ok cout << 'x' << endl; // kills tail-call elimination in gcc 4.8.2 struct {} bar; // kills tail-call elimination in 4.7.3 foo(); } Removing either "bar" or 'x' results in normal infinite loop. In 4.5.4 this works fine as is.
[Bug target/59814] New: powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814 Bug ID: 59814 Summary: powerpc64le ICE with -O2 -mpower8 -ffast-math Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org The following test case: /* -O2 -mcpu=power8 -ffast-math */ float val; int verbose; void bar(float x); void foo(void) { if (val < 0.0) { val = 1.0; if (!verbose) zot(); bar(val); } } fails with: # gcc -c -O2 -mcpu=power8 -ffast-math testcase.c testcase.c: In function ‘foo’: testcase.c:16:1: error: unrecognizable insn: } ^ (insn 52 16 3 3 (parallel [ (set (reg:SF 33 1 [orig:125 D.2152 ] [125]) (unspec:SF [ (reg:SF 9 9 [131]) ] UNSPEC_P8V_RELOAD_FROM_GPR)) (clobber (reg:DI 8 8)) ]) -1 (nil)) testcase.c:16:1: internal compiler error: in extract_insn, at recog.c:2154
[Bug c++/59813] New: tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Bug ID: 59813 Summary: tail-call elimintation didn't fired with left-shift of char to cout Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: virkony at gmail dot com #include using namespace std; void foo() { cout << "x" << endl; // ok cout << 'x' << endl; // kills tail-call elimination in gcc 4.8.2 foo(); } int main() { foo(); return 0; } // core-dups by long stack while in 4.7.3 works as expected (infinite loop)
[Bug rtl-optimization/56742] [4.8/4.9 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 --- Comment #13 from at2010 --- Hello. I also observed the 64bit compile problem while muxing. And after using the new build the problem is indeed resolved. However I still see a remnant wxwiget error in the logs that you may wish to fix as well. Error is In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). This is the pre-fix log. The post-fix log is below. mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52 'notrealfilename.avi': Using the demultiplexer for the format 'AVI'. 'notrealfilename.avi' track 0: Using the output module for the format 'MPEG-4'. 'notrealfilename.avi' track 1: Using the output module for the format 'AC3'. The file 'notrealfilename (1).mkv' has been opened for writing. Progress: 0% [Fails with return code 3] Output of Debug window: 12:34:22: dpi is 96/96 12:34:22: Querying mkvmerge's capabilities 12:34:23: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52 12:34:23: Capability: 12:34:23: Capability: FLAC 12:34:23: Capability: 12:34:23: about to check... btw int? 0 12:34:23: update state changed, now 1 12:34:26: update state changed, now 2 12:34:32: identify 1: command: ``"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" "@C:\Users\notme\AppData\Local\Temp\mmg-mkvmerge-options-3992-1389731672"'' 12:34:33: identify 1: result: 0 12:34:33: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI [is_providing_timecodes:1]'' 12:34:33: identify 1: output[1]: ``'' 12:34:33: identify 1: output[2]: ``Track ID 0: video (MPEG-4p2)'' 12:34:33: identify 1: output[3]: ``'' 12:34:33: identify 1: output[4]: ``Track ID 1: audio (AC3/EAC3)'' 12:34:33: identify 1: output[5]: ``'' 12:36:58: Locale selection logic: select_locale English (English) uu_locale_lower en translation_c::get_default_ui_locale() en app->m_ui_locale en 12:37:20: Querying mkvmerge's capabilities 12:37:20: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52 12:37:20: Capability: 12:37:20: Capability: FLAC 12:37:20: Capability: In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). 12:57:49: dpi is 96/96 12:57:49: Querying mkvmerge's capabilities 12:57:49: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52 12:57:49: Capability: 12:57:49: Capability: FLAC 12:57:49: Capability: 12:58:00: identify 1: command: ``"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" "@C:\Users\Marty\AppData\Local\Temp\mmg-mkvmerge-options-4540-1389733080"'' 12:58:01: identify 1: result: 0 12:58:01: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI [is_providing_timecodes:1]'' 12:58:01: identify 1: output[1]: ``'' 12:58:01: identify 1: output[2]: ``Track ID 0: video (MPEG-4p2)'' 12:58:01: identify 1: output[3]: ``'' 12:58:01: identify 1: output[4]: ``Track ID 1: audio (AC3/EAC3)'' 12:58:01: identify 1: output[5]: ``'' In file /home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp at line 576: 'SetFocus' failed with error 0x0057 (the parameter is incorrect.). mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 11 2014 10:17:39 'notrealfilename.avi': Using the demultiplexer for the format 'AVI'. 'notrealfilename.avi' track 0: Using the output module for the format 'MPEG-4'. 'notrealfilename.avi' track 1: Using the output module for the format 'AC3'. The file 'notrealfilename (2).mkv' has been opened for writing. Progress: 0% [omitted lines] Progress: 100% The cue entries (the index) are being written... Muxing took 53 seconds. Output of Debug window: 13:01:17: dpi is 96/96 13:01:17: Querying mkvmerge's capabilities 13:01:17: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 11 2014 10:17:39 13:01:17: Capability: 13:01:17: Capability: FLAC 13:01:17: Capability: 13:01:36: identify 1: command: ``"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" "@C:\Users\notme\AppData\Local\Temp\mmg-mkvmerge-options-4456-1389733296"'' 13:01:37: identify 1: result: 0 13:01:37: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI [is_providing_t
[Bug rtl-optimization/56742] [4.8/4.9 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 at2010 changed: What|Removed |Added CC||g63marty at yahoo dot com --- Comment #12 from at2010 --- Created attachment 31834 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31834&action=edit save output log and debug window log (at end)
[Bug fortran/59806] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- Possibly related to or duplicate of PR 59440.
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #25 from joseph at codesourcery dot com --- On Mon, 13 Jan 2014, jakub at gcc dot gnu.org wrote: > But the glibc headers case you're mentioning wasn't initializing the flexible > array members, right? (Or even initialization with {} initializer is fine I I don't have details of exactly what uses of flexible array members they were making beyond those permitted by ISO C. I guess the general point is to be careful about disallowing such uses because it might break existing code (so allowing plenty of time before a release for distribution rebuilds to catch any problems with such a change, for example).
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #3 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #2) > Kirill, please update also sse-13.c with new builtins. And sse-12.c with new options.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #2 from Uroš Bizjak --- Kirill, please update also sse-13.c with new builtins.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 Uroš Bizjak changed: What|Removed |Added Component|target |testsuite --- Comment #1 from Uroš Bizjak --- Somebody forgot to update gcc.target/i386/sse-14.c, in the same way as sse-22.c [1]. [1] http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.target/i386/sse-22.c?limit_changes=0&r1=206596&r2=206595&pathrev=206596
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Tue Jan 14 19:07:01 2014 New Revision: 206605 URL: http://gcc.gnu.org/viewcvs?rev=206605&root=gcc&view=rev Log: 2014-01-14 Vladimir Makarov PR target/59787 * config/arm/arm.c (arm_coproc_mem_operand): Add lra_in_progress. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug c/59812] Missing aggressive loop optimization warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The warning is documented to warn only about loops with constant number of iterations. Generally the number of iterations analysis which computes that the loop has at most 4 (valid) iterations on the other side doesn't have access to VRP to see what the values would be here, while for post-VRP it could use remembered SSA_NAME_RANGE_INFO, during VRP when this is optimized it can't, it isn't stored there yet.
[Bug c/59812] New: Missing aggressive loop optimization warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 Bug ID: 59812 Summary: Missing aggressive loop optimization warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Google ref: b/12015772 The following source: int x[4]; int foo (int a) { int n = a ? 1 : 2; int i; for(i = 0; i < 4 + n; i++ ) x[i]++; return 0; } compiles into infinite loop due to aggressive loop optimization, but produces no warnings with g++ (GCC) 4.9.0 20140110 (experimental) g++ -c -O2 -Wall -Wextra t.c && objdump -d t.o t.o: file format elf64-x86-64 Disassembly of section .text: <_Z3fooi>: 0: b8 00 00 00 00 mov$0x0,%eax 5: 83 00 01addl $0x1,(%rax) 8: 48 83 c0 04 add$0x4,%rax c: eb f7 jmp5 <_Z3fooi+0x5> It would be much nicer to end-user to emit compile time warning here.
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 --- Comment #2 from Chengnian Sun --- Thanks for your reply. One more question regarding this issue. Support I have a closed program static volatile int a; int main() {return 0;} Even though "a" is not read anywhere in this program, do you mean that it is still possible for "a" to be used somewhere else? I checked the C standard draft(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). In Page 122, it says that what constitutes an access to an object that has volatile-qualified type is implementation-defined. Is this the reason why GCC thinks the variable is used, but Clang treats it unused? Thanks again.
[Bug fortran/59811] New: Huge increase in memory usage and compile time with gfortran 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Bug ID: 59811 Summary: Huge increase in memory usage and compile time with gfortran 4.8 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bastian.feigl at kit dot edu Created attachment 31833 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31833&action=edit Example fortran source code file with problems with gfortran 4.8 When switching from gfortran 4.7 to gfortran 4.8 the memory usage and compile time vastly increases for some files in our project, e.g. for the attached example file. gfortran 4.8.2 needs 50s to compile, using up to 1.7 GB of RAM, while gfortran 4.7 compiles it in 7s with a memory usage of 136 MB. The command line of the gfortran-call for the attached example is /opt/gcc/4.8.2/bin/gfortran -fno-automatic -ffixed-line-length-none -O2 -c FermionBoxEventempCoupling_Div.F -o output.o The problem seems to be partly linked to the option -fno-automatic, since omitting it inhibits the memory increase, but the compile time is still 14s with gfortran 4.8, compared to 6s with gfortran 4.7. The problem arises with optimizations -O2 and -O1 lead to a similar discrepancy, with -O0 the problem does not exist. The gfortran 4.8 which shows the problematic behaviour is built with: Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/opt/gcc/4.8.2 --enable-languages=c,c++,fortran gcc version 4.8.2 (GCC) The gfortran 4.7 is the built-in from openSUSE 12.2: Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #3 from Jonathan Wakely --- In other words, we already have all the machinery in place to handle such cases, it just needs to be used for the target.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #29 from Nick Maclaren --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 > >> >The FENV_ACCESS pragma provides a means to inform the implementation whe >n a >> >program might access the floating-point environment to test floating-poi >nt >> >status flags or run under non-default floating-point control modes. > >> I suggest looking up the word "explicit" in a dictionary. > >The above is an explicit definition. Where do you see an undefined behavior >here? It is not an "explicit definition of BEHAVIOR" (my emphasis), and what it implies for any nnon-IEEE system is completely unclear. Of the two countries active during the standardisation of C99, one voted "no" on these grounds (among others). >Note that the C standard doesn't explicitly say how a source file as a sequ >ence >of bytes is to be interpreted as a sequence of character, so that if you ju >st > restrict to the C standard, everything is undefined. Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, paragraph 1.1: Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary. ... You imply that you are also relying on some other standards or specifications. ISO/IEC Directives Part II is quite clear (in 6.2.2) that they shall be referenced in the ISO standard. Which ones are you referring to and why? If you are claiming that C99 and beyond support only systems that conform to IEEE 754, then I can tell you that was not the intention of WG21 at the time and is not a requirement of the standard. To repeat, how many other such systems are you familiar with? The grounds that the UK voted "no" to this aspect was that the whole 'IEEE 754' morass (including "fenv.h") was neither dependent on __STD_IEC_559__ nor implementation-dependent nor sufficiently explicit to be interpreted on any non-IEEE system. > The discussion is going nowhere. Now, at least that is true. Regards, Nick Maclaren.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #2 from Jonathan Wakely --- It a target's pthread_mutex requires cleanup then it should not define __GTHREAD_MUTEX_INIT, it should use the init function, and then it gets a chance to also run a destroy function. That can be controlled by defining _GTHREAD_USE_MUTEX_INIT_FUNC in the relevant libstdc++-v3/config/os/xxx/os_defines.h header.
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 --- Comment #2 from Andreas Krebbel --- Created attachment 31832 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31832&action=edit Experimental fix This patch fixes the problem. I'll post/commit it when it passed regtesting.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #9 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Jan 14 16:41:10 2014 New Revision: 206603 URL: http://gcc.gnu.org/viewcvs?rev=206603&root=gcc&view=rev Log: Consolidate ABI warning into type_natural_mode gcc/ PR target/59794 * config/i386/i386.c (type_natural_mode): Add a bool parameter to indicate if type is used for function return value. Warn ABI change if the vector mode isn't available for function return value. (ix86_function_arg_advance): Pass false to type_natural_mode. (ix86_function_arg): Likewise. (ix86_gimplify_va_arg): Likewise. (function_arg_32): Don't warn ABI change. (ix86_function_value): Pass true to type_natural_mode. (ix86_return_in_memory): Likewise. (ix86_struct_value_rtx): Removed. (TARGET_STRUCT_VALUE_RTX): Likewise. gcc/testsuite/ PR target/59794 * g++.dg/ext/vector23.C: Also prune ABI change for Linux/x86. * gcc.target/i386/pr39162.c (y): New __m256i variable. (bar): Change return type to void. Set y to x. * gcc.target/i386/pr59794-1.c: New testcase. * gcc.target/i386/pr59794-2.c: Likewise. * gcc.target/i386/pr59794-3.c: Likewise. * gcc.target/i386/pr59794-4.c: Likewise. * gcc.target/i386/pr59794-5.c: Likewise. * gcc.target/i386/pr59794-6.c: Likewise. * gcc.target/i386/pr59794-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr59794-1.c trunk/gcc/testsuite/gcc.target/i386/pr59794-2.c trunk/gcc/testsuite/gcc.target/i386/pr59794-3.c trunk/gcc/testsuite/gcc.target/i386/pr59794-4.c trunk/gcc/testsuite/gcc.target/i386/pr59794-5.c trunk/gcc/testsuite/gcc.target/i386/pr59794-6.c trunk/gcc/testsuite/gcc.target/i386/pr59794-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/vector23.C trunk/gcc/testsuite/gcc.target/i386/pr39162.c
[Bug target/59810] New: [AArch64] LDn/STn implementations are not ABI-conformant for bigendian.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 Bug ID: 59810 Summary: [AArch64] LDn/STn implementations are not ABI-conformant for bigendian. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org Permuted loads/stores implemented in the aarch64 backend do not conform to AArch64 ABI for bigendian. The ABI states that "... On a little endian system this means that element 0 will always contain the lowest addressed element of a short vector; on a big endian system element 0 will contain the highest addressed element of a short vector." In the implementations of vec_loadlanes and vec_storelanes in aarch64-simd.md, they are just loaded lane-wise for both endianness. This may be correct for little endian, but for bigendian, this is the reversed order. Because the architecture does not offer a way to perform opaque loads/stores(LDR q, STR q) for permuted loads, the lanes will need to be reversed after permuted loading and reversed before permuted storing.
[Bug c++/59809] New: template non-type parameter in nested class-template said not be declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59809 Bug ID: 59809 Summary: template non-type parameter in nested class-template said not be declared Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jorenheit at gmail dot com The following code results in a compiler error on GCC 4.7.2: gccbug.cc:8:15: error: ‘V’ was not declared in this scope Code: // --- // gccbug.cc template struct S { template struct Inner { int a{V}; }; }; // --- Output of gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --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.7.2 (Debian 4.7.2-5) Command that triggers the error: g++ --std=c++11 -c gccbug.cc This might be related to bug 57239.
[Bug target/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug target/59808] New: [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 Bug ID: 59808 Summary: [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: kirill.yukhin at intel dot com On Linux/x86, r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #28 from Vincent Lefèvre --- (In reply to Nick Maclaren from comment #27) > On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: > >The FENV_ACCESS pragma provides a means to inform the implementation when a > >program might access the floating-point environment to test floating-point > >status flags or run under non-default floating-point control modes. > > I suggest looking up the word "explicit" in a dictionary. The above is an explicit definition. Where do you see an undefined behavior here? #include #pragma STDC FENV_ACCESS ON int main (void) { return 0; } The modes and so on are dealt with in other parts of the standard, e.g. Each of the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and only if the implementation supports getting and setting the represented rounding direction by means of the fegetround and fesetround functions. This doesn't mean that the rounding direction will necessarily be honored even for the basic operations (just like the C standard doesn't require "1.0+2.0" to evaluate as 3.0, and a poorly-designed implementation could decide that 1-bit accuracy is OK), but honoring the rounding direction when the processor does[*] is a reasonable QoI feature. Basically, this means: disabling some optimizations when STDC FENV_ACCESS is set to ON. This is what this bug is about. [*] a weaker requirement than __STDC_IEC_559__ being set to 1. Note that the C standard doesn't explicitly say how a source file as a sequence of bytes is to be interpreted as a sequence of character, so that if you just restrict to the C standard, everything is undefined. The discussion is going nowhere.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #1 from Andrey H. --- Simplest code which leaks handles on Windows: for(;;) { std::mutex op_mutex; op_mutex.lock(); op_mutex.unlock(); }
[Bug libstdc++/59807] New: mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 Bug ID: 59807 Summary: mutex misses destructor if non-function call initialization is used Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ahanins at gmail dot com Hi, Follow up to https://sourceforge.net/p/mingw-w64/bugs/376/ This is related to GTHR interface to pthread. C++11 __mutex_base class does not define a destructor if __GTHREAD_MUTEX_INIT is defined. It means, underlying implementation (pthread for example) has no any means to do a resource cleanup when std::mutex is destructed. In particular, it causes semaphore object resource (handle) leak on Windows in MinGW winpthread implementation where semaphore object is created during first pthread_mutex_lock invocation. Wouldn't it be more robust to always define a destructor for __mutex_base which calls __gthread_mutex_destroy, or even more flexibly, introduce a separate macro like __GTHREAD_MUTEX_DESTROY_FUNCTION which controls whether destructor should be defined at all or not.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #27 from Nick Maclaren --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 > >> What "explicit definition of behavior" is there for the case when >> STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one? > >The behavior is defined. The standard says, e.g. for C99: > >7.6.1 The FENV_ACCESS pragma > >The FENV_ACCESS pragma provides a means to inform the implementation when a >program might access the floating-point environment to test floating-point >status flags or run under non-default floating-point control modes. I suggest looking up the word "explicit" in a dictionary. Unless __STDC_IEC_559__ is set to 1, what modes and flags exist (and, even more importantly) what there semantics are) is at best implicit and more realistically unspecified - see footnote 204 for a clear statement of that. Have you ever implemented a C system for an architecture with non-IEEE arithmetic but with modes and flags? Because I have, and I have used several others. >> As there is none, it is undefined behaviour. gcc can therefore do >> whatever it likes. > >No. You are quite simply wrong. Regards, Nick Maclaren.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #26 from Vincent Lefèvre --- (In reply to Nick Maclaren from comment #25) > 3.4.3 says: > undefined behavior > behavior, upon use of a nonportable or erroneous program construct > or of erroneous data, for which this International Standard imposes > no requirements > > 4. Conformance, paragraph 2, says: > ... Undefined behavior is otherwise indicated in this International > Standard by the words "undefined behavior" or by the omission of any > explicit definition of behavior. There is no difference in emphasis > among these three; they all describe "behavior that is undefined". > > What "explicit definition of behavior" is there for the case when > STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one? The behavior is defined. The standard says, e.g. for C99: 7.6.1 The FENV_ACCESS pragma The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes.184) [...] 184) The purpose of the FENV_ACCESS pragma is to allow certain optimizations that could subvert flag tests and mode changes (e.g., global common ubexpression elimination, code motion, and constant folding). In general, if the state of FENV_ACCESS is ``off'', the translator can assume that default modes are in effect and the flags are not tested. And there is here no relation at all with __STDC_IEC_559__. > As there is none, it is undefined behaviour. gcc can therefore do > whatever it likes. No.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 CC||ktkachov at gcc dot gnu.org, ||vmakarov at redhat dot com Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Adding Vlad to cc, since this seems to be an LRA ICE.
[Bug c++/59791] [4.9 Regression] ICE: Error reporting routines re-entered. with -fcompare-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59791 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- You don't need -fcompare-debug for that, even just ./cc1plus -std=c++11 testcase.C ICEs (though, not with -quiet).
[Bug rtl-optimization/38518] Excessive compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 Richard Biener changed: What|Removed |Added CC||stevenb.gcc at gmail dot com --- Comment #6 from Richard Biener --- The issue here is the DF machinery, or rather the fact that RTL invariant motion calls df_analyze () for each loop, thus void move_loop_invariants (void) { struct loop *loop; if (flag_ira_loop_pressure) { df_analyze (); regstat_init_n_sets_and_refs (); ira_set_pseudo_classes (true, dump_file); calculate_loop_reg_pressure (); regstat_free_n_sets_and_refs (); } df_set_flags (DF_EQ_NOTES + DF_DEFER_INSN_RESCAN); /* Process the loops, innermost first. */ FOR_EACH_LOOP (loop, LI_FROM_INNERMOST) { curr_loop = loop; /* move_single_loop_invariants for very large loops is time consuming and might need a lot of memory. */ if (loop->num_nodes <= (unsigned) LOOP_INVARIANT_MAX_BBS_IN_LOOP) move_single_loop_invariants (loop); } here move_single_loop_invariants -> find_invariants -> find_defs which does static void find_defs (struct loop *loop, basic_block *body) { unsigned i; bitmap blocks = BITMAP_ALLOC (NULL); for (i = 0; i < loop->num_nodes; i++) bitmap_set_bit (blocks, body[i]->index); if (dump_file) { fprintf (dump_file, "*starting processing of loop %d **\n", loop->num); } df_remove_problem (df_chain); df_process_deferred_rescans (); df_chain_add_problem (DF_UD_CHAIN); df_set_blocks (blocks); df_set_flags (DF_RD_PRUNE_DEAD_DEFS); df_analyze (); ... which is excessive. It looks like the above DF stuff does not affects the whole function but only the BBs in the loop. Still the fact that we iterate from inner to outer loops still makes the DF analysis time quadratic in the loop depth. The testcase has only loops of depth 1 (but 2164 ones), so it seems that the DF restriction to a set of BBs does not work as expected? >From the profile I see that the most time spent in df_analyze is inverted_post_order_compute and post_order_compute (obviosly not region aware!) and then bitmap_set_bit and df_prune_to_subcfg. I wonder if it isn't possible to either update the DF during the transform, deal with partly out-of-date DF info (like process loop siblings without re-calculating DF, and re-compute whole FN DF after such iteration).
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #25 from Nick Maclaren --- On Jan 10 2014, vincent-gcc at vinc17 dot net wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 > >--- Comment #24 from Vincent Lefèvre - > >(In reply to Nick Maclaren from comment #23) > >> If __STDC_IEC_559__ is unset or does not have the value 1, setting >> STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and >> Annex F), unless the implementation explicitly chooses to extend the >> language to support it. > >You're wrong. The C standard doesn't say that. I am sorry, but it is you that is wrong. >6.10.8.3 says: "__STDC_IEC_559__ The integer constant 1, intended to indica >te >conformance to the specifications in annex F (IEC 60559 floating-point >arithmetic)." and nothing about STDC FENV_ACCESS. 3.4.3 says: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 4. Conformance, paragraph 2, says: ... Undefined behavior is otherwise indicated in this International Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined". What "explicit definition of behavior" is there for the case when STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one? As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. Regards, Nick Maclaren.
[Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806 Bug ID: 59806 Summary: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Hi all, the attached code results in an internal compiler error when compiled with gfortran -ggdb -finit-real=snan -c ice.f90 Removing -ggdb and/or -finit-real=snan the code compiles correctly. Also, removing the namelist containing xx the problem disappears. (Sorry for the long "summary", could't find a shorter one). $ gfortran --version GNU Fortran (GCC) 4.9.0 20140110 (experimental) $ gfortran -ggdb -finit-real=snan -c ice.f90 ice.f90: In function ‘prog’: ice.f90:5:0: internal compiler error: in force_decl_die, at dwarf2out.c:20111 real :: xx ^ 0x704d34 force_decl_die gcc/dwarf2out.c:20111 0x705207 gen_namelist_decl gcc/dwarf2out.c:20632 0x700fd3 gen_decl_die gcc/dwarf2out.c:20435 0x71314f decls_for_scope gcc/dwarf2out.c:19969 0x6fe0ea gen_subprogram_die gcc/dwarf2out.c:18354 0x701014 gen_decl_die gcc/dwarf2out.c:20336 0x701df8 dwarf2out_function_decl gcc/dwarf2out.c:20776 0x75289c rest_of_handle_final gcc/final.c:4469 0x75289c execute gcc/final.c:4513 program prog implicit none real :: xx character(len=100) :: message ! removing the following line the problem disappears namelist /input/ xx contains subroutine check() write(message,'(e8.2)') xx end subroutine check end program prog
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #8 from H.J. Lu --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00784.html
[Bug preprocessor/59805] New: invalid preprocessing directive not diagnosed with assembler-with-cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59805 Bug ID: 59805 Summary: invalid preprocessing directive not diagnosed with assembler-with-cpp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: aldot at gcc dot gnu.org CC: tromey at redhat dot com -x assembler-with-cpp remains silent instead of emitting some kind of diagnostics. $ cat libcpp-bug.c # INCLUDE <./does-not-exist.HHH> # HUH <./does-not-exist.HHH> $ gcc -x assembler-with-cpp -o xxx.o -c libcpp-bug.c -W -Wall -pedantic -Wextra Properly diagnosed with c or c-header: $ gcc -x c -o xxx.o -c libcpp-bug.c -W -Wall -pedantic -Wextra libcpp-bug.c:1:3: error: invalid preprocessing directive #INCLUDE # INCLUDE <./does-not-exist.HHH> ^ libcpp-bug.c:2:3: error: invalid preprocessing directive #HUH # HUH <./does-not-exist.HHH> ^ libcpp-bug.c:2:0: warning: ISO C forbids an empty translation unit [-Wpedantic] # HUH <./does-not-exist.HHH> ^ gcc-4.9-trunk@206144 Since the #INCLUDE was not processed this missing diagnostics resulted in wrong code generated, but adding that keyword. Didn't look if this is a driver bug.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 H.J. Lu changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8/4.9 Regression] |i386 backend fails to |i386 backend fails to |detect MMX/SSE/AVX return |detect MMX/SSE/AVX ABI |value |changes --- Comment #7 from H.J. Lu --- [hjl@gnu-17 tmp]$ cat /tmp/f.i typedef int __v4si __attribute__ ((__vector_size__ (16))); typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__)); __m128i f1(void) { return __extension__ (__m128i)(__v4si){ 0, 0, 0, 0 }; } [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -S -O /tmp/f.i -mno-sse -m32 /tmp/f.i: In function `f1': /tmp/f.i:6: warning: SSE vector return without SSE enabled changes the ABI [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -v Reading specs from /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs Configured with: ../../../gcc/configure --prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 3.5.0 20040615 (experimental) [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -S -O /tmp/f.i -mno-sse -m32 [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -v Reading specs from /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs Configured with: ../../../gcc/configure --prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 3.5.0 20040725 (experimental) [hjl@gnu-17 tmp]$
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #5 from Richard Biener --- http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00780.html Even better would be to get rid of the explicit maximum set (just ignore incoming edges with the maximum set, aka 'unvisited' edges during bitmap_intersection_of_preds). Basically follow what tree PRE does for antic-in compute. That would make using regular bitmaps possible (if that is a win - at least computing the changed bit is free). Also queuing succs at the end of the worklist messes up iteration order for everything but the first iteration. PRE uses a sbitmap that records whether a BB was changed. Anyway, the above simple patch dramatically improves the numbers for this testcase.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 Renlin Li changed: What|Removed |Added CC||renlin.li at arm dot com, ||yufeng at gcc dot gnu.org --- Comment #1 from Renlin Li --- Confirm that, gcc.target/arm/mmx-2.c cause an ICE with the following configuration. --target=arm-none-linux-gnueabihf --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp (insn 51 50 52 2 (set (reg:DI 534 [orig:139 D.4720 ] [139]) (mem/v/c:DI (plus:SI (reg/f:SI 102 sfp) (const_int -20 [0xffec])) [0 llsink+0 S8 A64])) mmx-2.c:4 2 447 {*iwmmxt_arm_movdi} (nil)) (insn 573 0 0 (set (reg:DI 139 [ D.4720 ]) (reg:DI 534 [orig:139 D.4720 ] [139])) -1 (nil)) lra_constraints() keeps reloading until Max. number of reload insns is reached.
[Bug c++/59804] New: C++ front-end checking ends in an infinite loop on erroneous code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59804 Bug ID: 59804 Summary: C++ front-end checking ends in an infinite loop on erroneous code Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Created attachment 31831 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31831&action=edit Testcase I discovered this problem when multidelta-reducing a different PR. Multidelta produced this invalid source that however causes the c++ front-end of an checking-enabled compiler to end up in an infinite loop (or just takes incredible time to finish but I doubt that). Release-checking g++ compains about errors and exits normally. x86_64-linux, no compiler options necessary.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #6 from H.J. Lu --- [hjl@gnu-17 tmp]$ cat /tmp/f.i typedef int __v4si __attribute__ ((__vector_size__ (16))); typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__)); __m128i f1(void) { return __extension__ (__m128i)(__v4si){ 0, 0, 0, 0 }; } [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -S -O /tmp/f.i -mno-sse -m32 /tmp/f.i: In function `f1': /tmp/f.i:6: warning: SSE vector return without SSE enabled changes the ABI [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -v Reading specs from /export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs Configured with: ../../../gcc/configure --prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 3.5.0 20040615 (experimental) [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -S -O /tmp/f.i -mno-sse -m32 [hjl@gnu-17 tmp]$ /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -v Reading specs from /export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs Configured with: ../../../gcc/configure --prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++ --disable-bootstrap Thread model: posix gcc version 3.5.0 20040725 (experimental) [hjl@gnu-17 tmp]$
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Richard Biener changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Richard Biener --- (In reply to David Binderman from comment #3) > (In reply to Richard Biener from comment #2) > > Oh, did you configure with --enable-checking=release for 4.9? (I did) > > No, I used --enable-checking=yes. That makes the comparison to 4.8 invalid (uses --enable-checking=release by default). Btw, callgrind shows that compile-time is dominated by bitmap_intersection_of_preds (and bitmap_ior_and_compl), called from lcm.c:compute_available. LCM works with sbitmaps which can be very expensive for large functions. tree PRE uses regular bitmaps, but it seems that LCM can end up using the full bitmap via returning bitmap_ones from bitmap_intersection_of_preds (for a block with no preds). It seems compute_available doesn't use optimal iteration order and that explicitely representing the maximum set instead of handling unvisited preds makes things more expensive (need to use sbitmaps). Iterating in inverted postorder gets me CPROP : 2.13 ( 5%) usr 0.06 (10%) sys 2.20 ( 5%) wall kB ( 2%) ggc with no changes in generated code ...
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- And looking at the libstdc++ code, it indeed has _M_saved initially uninitialized, and all reads of it guarded by _M_saved_available flag. Supposedly predicate aware unitialized warning pass isn't able to figure that out.
[Bug target/59797] GCC doesn't warn AVX-512 ABI change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59797 --- Comment #2 from H.J. Lu --- (In reply to Yukhin Kirill from comment #1) > Sorry, didn't get the problem. > > According to output you provided - GCC warns ABI changes > > Here is analogue for AVX2: > $ cat 2.c > typedef long long __m256i __attribute__ ((__vector_size__ (32), > __may_alias__)); > > __m256i > f1(__m256i x, __m256i y) > { > return y; > } > $ gcc -S 2.c > 2.c: In function ‘f1’: > 2.c:4:1: note: The ABI for passing parameters with 32-byte alignment has > changed in GCC 4.6 This isn't a ABI change warning. It just informs users that GCC has changed ABI in GCC 4.6. > f1(__m256i x, __m256i y) > ^ > 2.c:4:1: warning: AVX vector argument without AVX enabled changes the ABI > [enabled by default] This is the ABI change warning for __m256i when AVX is disabled. > Difference is that AVX[2] warns about using data types without enabling > AVX2. Is that the case We need a similar warning for __m512i when AVX-512 is disabled.
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-14 Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andreas Krebbel --- There is a secondary reload which is supposed to handle that case. I'll try to figure out what went wrong here. Due to LRA being enabled by default on S/390 the situation on trunk is probably not comparable.
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- That's not an error but a warning?! Anyway, it's triggered by -Wmaybe-uninitialized. Also happens on trunk.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #3 from David Binderman --- (In reply to Richard Biener from comment #2) > Oh, did you configure with --enable-checking=release for 4.9? (I did) No, I used --enable-checking=yes.
[Bug c++/59791] [4.9 Regression] ICE: Error reporting routines re-entered. with -fcompare-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59791 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #24 from Alan Modra --- Nick's latest patch passes bootstrap and regression testing powerpc64-linux.
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek --- (void) cast it away in the Darwin macro. But that is tracked already in PR59496.
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 Jakub Jelinek changed: What|Removed |Added CC||krebbel at gcc dot gnu.org Target Milestone|--- |4.8.3
[Bug target/59803] New: [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 Bug ID: 59803 Summary: [4.8 Regression] s390x -march=z10 reload ICE Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org extern void baz (void) __attribute__ ((__noreturn__)); struct A { int g, h; }; extern struct A a; struct B { unsigned char i, j, k, l, m; }; int c, d, e; static int f; void foo (void) { f = 1; } void bar (struct B *x) { x->i = e; x->k = c; x->l = d; x->j = a.h; x->m = f; if (x->i != e) baz (); if (x->k != c) baz (); if (x->j != a.h) baz (); } ICEs with -O2 -march=z10 on 4.8 branch (verified with x86_64-linux -> s390x-linux cross at r206599). Works in 4.6 and works on the trunk, though it is unclear if it just isn't latent. Before reload we have: (insn 10 9 11 2 (set (reg:SI 58 [ d ]) (mem/c:SI (symbol_ref:DI ("d") ) [2 d+0 S4 A32])) rh1052372.ii:19 67 {*movsi_zarch} (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI ("d") ) [2 d+0 S4 A32]) (nil))) (insn 11 10 13 2 (set (mem:QI (plus:DI (reg/v/f:DI 57 [ x ]) (const_int 3 [0x3])) [0 x_4(D)->l+0 S1 A8]) (subreg:QI (reg:SI 58 [ d ]) 3)) rh1052372.ii:19 74 {*movqi} (expr_list:REG_DEAD (reg:SI 58 [ d ]) (nil))) and the ICE is about unrecognized instruction: (insn 61 10 11 2 (set (reg:DI 12 %r12) (const:DI (plus:DI (symbol_ref:DI ("d") ) (const_int 3 [0x3] rh1052372.ii:19 -1 (nil)) If I look at trunk dumps, it seems the difference there is already at expansion time, while on the trunk *.expand has separate insns to set (symbol_ref:DI ("d") to a pseudo and load (mem:SI (that pseudo)), 4.8 branch uses movsi_zarch insn which is load from (mem:SI (symbol_ref:DI ("d"))). Then, at combine time trunk combines the store with the load (and not symbol_ref larl), while 4.8 fails to combine the store with the load because I suppose lowest bit in larl loaded value can't be set?
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #2 from Martin Husemann --- Unfortunately I can not reproduce the issue with the .i file generated with -save-temps (but still with the original .c file).
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #2 from Richard Biener --- Oh, did you configure with --enable-checking=release for 4.9? (I did)
[Bug middle-end/38518] Excessive compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 --- Comment #5 from Richard Biener --- With GCC 4.8 we see loop invariant motion : 16.79 (32%) usr 0.02 ( 3%) sys 16.65 (31%) wall 148 kB ( 0%) ggc loop unswitching: 10.43 (20%) usr 0.02 ( 3%) sys 10.42 (20%) wall 0 kB ( 0%) ggc TOTAL : 52.07 0.6753.00 363360 kB which is RTL loop optimizers.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Component|c |rtl-optimization Summary|excessive compile time in |excessive compile time in |loop unswitching|RTL optimizers (loop ||unswitching, CPROP) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- GCC 4.8 shows CPROP : 45.00 (57%) usr 0.02 ( 4%) sys 45.01 (57%) wall 4016 kB ( 2%) ggc TOTAL : 78.48 0.5779.04 213705 kB while GCC 4.9 has loop invariant motion : 10.11 (11%) usr 0.01 ( 2%) sys 10.16 (11%) wall 2 kB ( 0%) ggc loop unswitching: 9.81 (11%) usr 0.00 ( 0%) sys 9.83 (11%) wall 1 kB ( 0%) ggc CPROP : 48.16 (54%) usr 0.04 ( 7%) sys 48.20 (54%) wall kB ( 2%) ggc so I can't really confirm the unswitching slowness (this is r205857 which is somewhat older than your test). Generally I think we should probably consider removing RTL unswitching, there is not a single loop unswitched by RTL for this testcase.
[Bug ada/57795] Fail Canadian cross building Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57795 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 55946 ***
[Bug ada/55946] wrong tools used for build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 Eric Botcazou changed: What|Removed |Added CC||alexpux at gmail dot com --- Comment #7 from Eric Botcazou --- *** Bug 57795 has been marked as a duplicate of this bug. ***
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 --- Comment #17 from Jan-Benedict Glaw --- (In reply to Marek Polacek from comment #16) > > tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, > > ^ > > cc1plus: all warnings being treated as errors > > Should be fixed now. No, not yet. The most recent build for powerpc64-darwin done by my build robot still faces this warning and thus breaks: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=89063 --> http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=733877 So what shall we do with this? The macro is called with two arguments, of which one ("field") isn't used. Just mark it as unused or (void)-cast it away?
[Bug target/58172] ifcvt test failures for armv8-a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58172 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from ktkachov at gcc dot gnu.org --- These tests pass with multilib -march=armv8-a flags in current trunk (r206577) The lsl Ld, Ln, #1 is now being caught I believe. Closing as fixed, please reopen if you find them failing in some configuration.
[Bug ada/57795] Fail Canadian cross building Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57795 Yaakov (Cygwin Ports) changed: What|Removed |Added CC||yselkowitz at users dot sourceforg ||e.net --- Comment #1 from Yaakov (Cygwin Ports) --- I also ran into this when cross-compiling a native gcc with Ada (i686-pc-cygwin/x86_64-pc-cygwin/x86_64-pc-cygwin) in the process of porting GNAT to a new platform. In fact, I believe this would happen any time $build != $host (regardless of $target), but NOT with the typical cross-compiler ($build == $host, $host != $target). The root of the problem is RTS_DIR override (immediately prior to gnattools-cross rule) in gnattools/Makefile.in, which calls gnatls (for $build) where IIUC it should be something like $(GNATMAKE:gnatmake=gnatls) (for $host). There is another problem in this situation: in gcc/ada/gcc-interface/Make-lang.in, the xgnatugn rule (part of building doc/projects.texi and doc/gnat_ugn.texi) calls $(GNATMAKE), resulting in a xgnatugn which runs on $host instead of $build; this probably needs to be just gnatmake instead.
[Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #11 from Markus Trippelsdorf --- (In reply to David Kredba from comment #10) > After your patch applied it not segfaults any more. > Unfortunately it not builds too, link of one module fails: > > [build MOD] swext > S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 > && O=$S/solver/unxlngx6.pro && W=$S/workdir/unxlngx6.pro && mkdir -p > $W/Module/ & touch $W/Module/swext > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In > function `~egmentProgressBar': > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > include/oox/helper/progressbar.hxx:110: undefined reference to > `oox::ISegmentProgresBar::~ISegmentProgressBar()' > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > include/oox/helper/progressbar.hxx:110: undefined reference to > `oox::ISegmentProgresBar::~ISegmentProgressBar()' > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > include/oox/helper/progressbar.hxx:110: undefined reference to > `oox::ISegmentProgresBar::~ISegmentProgressBar()' > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In > function `ox::SegmentProgressBar::~SegmentProgressBar()': > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > include/oox/helper/progressbar.hxx:110: undefined reference to > `oox::ISegmentProgresBar::~ISegmentProgressBar()' > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In > function `~egmentProgressBar': > /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ > include/oox/helper/progressbar.hxx:110: undefined reference to > `oox::ISegmentProgresBar::~ISegmentProgressBar()' > collect2: error: ld returned 1 exit status > > Can this be anyhow related to your patch? Or GCC at all? No. I ran into exactly the same issue a while ago. "$W/CxxObject/oox/source/helper/progressbar.o" is missing in the list of object files when linking. This is a libreoffice bug.
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 Bug 58921 depends on bug 59006, which changed state. Bug 59006 Summary: [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Jan 14 09:04:50 2014 New Revision: 206599 URL: http://gcc.gnu.org/viewcvs?rev=206599&root=gcc&view=rev Log: 2014-01-14 Richard Biener PR tree-optimization/58921 PR tree-optimization/59006 * tree-vect-loop-manip.c (vect_loop_versioning): Remove code hoisting invariant stmts. * tree-vect-stmts.c (vectorizable_load): Insert the splat of invariant loads on the preheader edge if possible. * gcc.dg/torture/pr58921.c: New testcase. * gcc.dg/torture/pr59006.c: Likewise. * gcc.dg/vect/pr58508.c: XFAIL no longer handled cases. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58921.c trunk/gcc/testsuite/gcc.dg/torture/pr59006.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 --- Comment #7 from Richard Biener --- Author: rguenth Date: Tue Jan 14 09:04:50 2014 New Revision: 206599 URL: http://gcc.gnu.org/viewcvs?rev=206599&root=gcc&view=rev Log: 2014-01-14 Richard Biener PR tree-optimization/58921 PR tree-optimization/59006 * tree-vect-loop-manip.c (vect_loop_versioning): Remove code hoisting invariant stmts. * tree-vect-stmts.c (vectorizable_load): Insert the splat of invariant loads on the preheader edge if possible. * gcc.dg/torture/pr58921.c: New testcase. * gcc.dg/torture/pr59006.c: Likewise. * gcc.dg/vect/pr58508.c: XFAIL no longer handled cases. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58921.c trunk/gcc/testsuite/gcc.dg/torture/pr59006.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-stmts.c
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized "vect_[^\\n]*\\+ " 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Don't mark the variable volatile then. Volatile tells the compiler the variable may be used through means not known to the compiler, so it isn't unused.