[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-03 16:00:35 UTC --- I don't think this is a G++ bug, there are three problems with this code: 1) You need to #include new to use placement new 2) factory::apply is non-const but the parameter 'f' is const 3) f.template applyT finds the current instantiation, ::applyT, rather than the member function you are trying to call, use f.FactoryT::template applyT instead
[Bug c++/55015] [4.7/4.8 Regression] Lambda functions not found at link time when declared in an inline function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/54170] Call to lambda elided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-12-03 16:01:43 UTC --- Author: paolo Date: Mon Dec 3 16:01:32 2012 New Revision: 194098 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194098 Log: /cp 2012-12-03 Paolo Carlini paolo.carl...@oracle.com PR c++/54170 * cvt.c (cp_convert_to_pointer): Don't discard side-effects from expressions of nullptr_t. * typeck.c (build_ptrmemfunc): Likewise. /testsuite 2012-12-03 Paolo Carlini paolo.carl...@oracle.com PR c++/54170 * g++.dg/cpp0x/lambda/lambda-nullptr.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nullptr.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55032] [4.7/4.8 Regression] Internal compiler error: in strip_typedefs, at cp/tree.c:1199
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55032 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/55033] [4.6/4.7/4.8 Regression] PowerPC section type conflict error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55033 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-rtems4.11 |powerpc-rtems4.11 ||powerpc-eabi Priority|P3 |P4
[Bug rtl-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55006 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2012-11/msg01607.htm |atches/2012-12/msg00076.htm |l |l --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-12-03 16:03:19 UTC --- Correct, not yet fixed. Patch is pending. This is a bit of a can of worms, and getting a patch approved has turned out to be a bit more troublesome than I had hoped.
[Bug middle-end/55046] [4.8 Regression] ICE in ira_reuse_stack_slot at ira-color.c:4065
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55046 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #5 from dave.anglin at bell dot net 2012-12-03 16:06:22 UTC --- I have a patch to ignore the comparison failure and a couple changes to libbacktrace for hpux. The btest program now runs successfully on hpux. However, backtrace still doesn't work from within compiler.
[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-03 16:08:31 UTC --- Indeed. I also want to add that neither Icc 13, nor Oracle Solaris Studio 12.3, nor Clang 3.0 accept it, whereas the code adjusted per Jon's points compiles just fine with all of them.
[Bug c++/54170] Call to lambda elided
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54170 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-03 16:10:13 UTC --- Fixed for 4.8.0.
[Bug middle-end/55401] uninstrumented path in TM clones are still instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55401 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-03 16:11:33 UTC --- Author: aldyh Date: Mon Dec 3 16:11:21 2012 New Revision: 194099 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194099 Log: PR middle-end/55401 * trans-mem.c (get_tm_region_blocks): Exclude uninstrumented blocks from vector if requested. (collect_bb2reg): Pass new argument to get_tm_region_blocks. (get_bb_regions_instrumented): Add INCLUDE_UNINSTRUMENTED_P argument, and pass it to expand_regions. (execute_tm_mark): Pass new argument to get_bb_regions_instrumented. (execute_tm_edges): Same. Added: trunk/gcc/testsuite/gcc.dg/tm/pr55401.c Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55571 --- Comment #6 from Richard Henderson rth at gcc dot gnu.org 2012-12-03 16:48:59 UTC --- Created attachment 28861 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28861 proposed patch 4.6 only IMO there are multiple problems being exposed here. Some of them probably require more build surgery than others. In the case of gcc 4.6 (and probably 4.7) I'd like to fix nothing other than the minimal. This patch links libgcc_s.so.1 with libgcc.a. That brings in the hidden __sync_synchronize symbol (as well as all of the others) into the shared library so that it doesn't require external resolution. I've only tested this via cross-compile so far, wherein I see what I expected from the dynamic symbol table.
[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55571 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/53663] [4.7 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2012-12-03 16:53:39 UTC --- Author: rguenth Date: Mon Dec 3 16:53:25 2012 New Revision: 194101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194101 Log: 2012-12-03 Richard Biener rguent...@suse.de Backport from mainline 2012-09-24 Richard Guenther rguent...@suse.de PR tree-optimization/53663 * tree-ssa-sccvn.c (vn_reference_lookup_3): Conditional native encode/interpret translation on VN_WALKREWRITE. * gcc.dg/torture/pr53663-1.c: New testcase. * gcc.dg/torture/pr53663-2.c: Likewise. * gcc.dg/torture/pr53663-3.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53663-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53663-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53663-3.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/53663] [4.7 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2012-12-03 16:54:13 UTC --- Fixed.
[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-03 17:20:01 UTC --- Author: jakub Date: Mon Dec 3 17:19:47 2012 New Revision: 194102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194102 Log: PR bootstrap/55380 PR other/54691 * files.c (read_file_guts): Allocate extra 16 bytes instead of 1 byte at the end of buf. Pass size + 16 instead of size to _cpp_convert_input. * charset.c (_cpp_convert_input): Reallocate if there aren't at least 16 bytes beyond to.len in the buffer. Clear 16 bytes at to.text + to.len. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c trunk/libcpp/files.c
[Bug bootstrap/55380] All search_line_fast implementations read beyond buffer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-03 17:20:01 UTC --- Author: jakub Date: Mon Dec 3 17:19:47 2012 New Revision: 194102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194102 Log: PR bootstrap/55380 PR other/54691 * files.c (read_file_guts): Allocate extra 16 bytes instead of 1 byte at the end of buf. Pass size + 16 instead of size to _cpp_convert_input. * charset.c (_cpp_convert_input): Reallocate if there aren't at least 16 bytes beyond to.len in the buffer. Clear 16 bytes at to.text + to.len. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c trunk/libcpp/files.c
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #12 from Gary Funck gary at intrepid dot com 2012-12-03 17:24:03 UTC --- (In reply to comment #10) Thanks for the experiment. I think that you just need to always bootstrap the compiler (i.e. don't pass --disable-bootstrap) since it's precisely designed to avoid this kind of problems. For cross-compilers, the trick is to bootstrap a native compiler and use it to build them. Thanks. I can confirm that a full bootstrap using the system installed /usr/bin/gcc and /usr/bin/g++ compilers with default compilation switches was able to build gcc and g++ without issue. Case closed.
[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-03 17:29:05 UTC --- Should be fixed now.
[Bug middle-end/55046] [4.8 Regression] ICE in ira_reuse_stack_slot at ira-color.c:4065
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55046 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2012-12-03 Ever Confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2012-12-03 17:41:45 UTC --- The patch to use DF_LIVE in IRA was already reverted.
[Bug sanitizer/55577] New: g++.dg/asan/asan_test.C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577 Bug #: 55577 Summary: g++.dg/asan/asan_test.C failures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org On Linux/x86, revision 194082 gave FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf1 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf2 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf3 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BitFieldPositiveTest x-bf4 = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_BuiltinLongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_FileNameInGlobalReportTest Ident(p[15]) execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalStringConstTest Ident(p[15]) execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest fs2[Ident(-1)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest func_static15[Ident(15 + 9)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest func_static15[Ident(15)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest static110[Ident(110)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_GlobalTest static110[Ident(110+7)] = 0 execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_LongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SigLongJmpTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SignalTest *c = 0 output pattern test, should match AddressSanitizer: SEGV on unknown address FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_SignalTest *c = 0 output pattern test, should match AddressSanitizer: SEGV on unknown address FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadStackReuseTest execution test FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_ThreadedTest ThreadedTestSpawn() output pattern test, should match Thread T.*created.*Thread T.*created.*Thread T.*created
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-03 17:44:37 UTC --- HJ, can you find when we regressed on this?
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||mjambor at suse dot cz Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-12-03 17:49:32 UTC --- It is caused by revision 190830: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00809.html
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|mjambor at suse dot cz | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-03 17:58:13 UTC --- Are you kidding? This is a front-end issue and happens also at -O0.
[Bug sanitizer/55577] g++.dg/asan/asan_test.C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-03 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 17:59:17 UTC --- I have them too.
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2012-12-03 18:07:06 UTC --- (In reply to comment #3) It is caused by revision 190830: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00809.html Oops. Right revision, wrong link: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00808.html
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|hjl.tools at gmail dot com | --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-03 18:21:56 UTC --- Thanks.
[Bug c++/55578] New: Disabling warnings inside macro definition doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
Bug #: 55578
Summary: Disabling warnings inside macro definition doesn't
work
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rub...@gmail.com
When compiling following code with just -Wall option I'm getting below
mentioned warning.
#define FF() \
_Pragma(GCC diagnostic push) \
_Pragma(GCC diagnostic ignored \-Wunused-variable\) \
{int x;} \
_Pragma(GCC diagnostic pop)
int main()
{
FF();
return 0;
}
In function 'int main()':
warning: unused variable 'x' [-Wunused-variable]
But when I also specify -no-integrated-cpp or -save-temps options the warning
doesn't show up.
It looks like when preprocessor and compiler work in one shop the warning
doesn't get disabled. BTW this happens for any warning not just with
unused-variable one.
GCC version is: 4.6.2
Command line is: gcc file-name -Wall
System is: Linux 2.6.18-238.el5 #1 SMP Sun Dec 19 14:22:44 EST 2010 x86_64
x86_64 x86_64 GNU/Linux
[Bug rtl-optimization/51771] trans-mem: abnormal edges get lost or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771 --- Comment #9 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-03 18:43:14 UTC --- Created attachment 28862 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28862 patch to revert the returns twice patch
[Bug sanitizer/55577] g++.dg/asan/asan_test.C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-03 18:43:58 UTC --- Everybody has them, I've said in the mail containing the patch that there are a few unanalyzed failures, and what the reasons for some of those failures are (e.g. not instrumenting bitfields yet).
[Bug sanitizer/55577] g++.dg/asan/asan_test.C failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55577 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 18:48:08 UTC --- Everybody has them, I've said in the mail containing the patch that there are a few unanalyzed failures, and what the reasons for some of those failures are (e.g. not instrumenting bitfields yet). Ah, sorry. You can XFAIL them in the meantime though, adding testcases that don't pass is a bit weird in my opinion.
[Bug rtl-optimization/51771] trans-mem: abnormal edges get lost or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-03 18:51:44 UTC --- I no longer see a Genome failure on trunk, even though we are stripping off the abnormal edges as part of the expansion of gimple into RTL (as described in comment 8). Perhaps, this could be a nice side-effect of the abnormal edge rewriting that went in with the uninstrumented path? Can someone (Torvald or Patrick) verify this so we can close this PR if appropriate? For the record, this is what I've done. I reverted the returns-twice patch by applying the patch in comment 9. I seem to be running Stamp: 0.9.10 (8 Sept 2008) (from the VERSIONS file in the STAMP distribution). I am testing with current mainline as of trunk@194099. And I am using a Makefile.local of: CC=/build/trunk/install/bin/gcc LDFLAGS=-Wl,-rpath=/build/trunk/install/lib64 THREADS=4 TESTS=test-genome I do a make clean make test and get: cd genome \ ./genome -t 4 true Creating gene and segments... done. Gene length = 16384 Segment length = 64 Number segments = 16777216 Sequencing gene... done. Time = 13.305184 Sequence matches gene: yes Deallocating memory... done. This seems correct.
[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55571 --- Comment #7 from Richard Henderson rth at gcc dot gnu.org 2012-12-03 19:04:28 UTC --- Created attachment 28863 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28863 proposed patch for 4.7 Same as 4.6 modulo fuzz + conflicts.
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
--- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-12-03 19:15:09 UTC ---
adding it helps
t = build_constructor (TREE_TYPE (t), n);
+ if (TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
+t = fold (t);
TREE_CONSTANT (t) = true;
unfortunately generates ICE for the class constructor at cp/tree.c:2712
struct Rot3 {
typedef float T;
typedef V4 Vec;
Vec axis[3];
constexpr Rot3( V4 ix, V4 iy, V4 iz) :
axis{ix,iy,iz}{}
constexpr Rot3(T xx, T xy, T xz, T yx, T yy, T yz, T zx, T zy, T zz) :
Rot3( (Vec){xx,xy,xz,0},
(Vec){yx,yy,yz,0},
(Vec){zx,zy,zz,0}
){}
};
constexpr Rot3 r2( (V4){0, 1 ,0,0}, (V4){0, 0, 1,0},(V4){1, 0, 0,0});
constexpr Rot3 r1( 0, 1 ,0, 0, 0, 1, 1, 0, 0);
ceVec.cc:26:46: in constexpr expansion of ‘((Rot3*)( r1))-Rot3::Rot3(0.0,
1.0e+0, 0.0, 0.0, 0.0, 1.0e+0, 1.0e+0, 0.0, 0.0)’
ceVec.cc:21:4: in constexpr expansion of
‘((Rot3*)this)-Rot3::Rot3(Rot3::Vec{xx, xy, xz, 0.0f}, Rot3::Vec{yx, yy, yz,
0.0f}, Rot3::Vec{zx, zy, zz, 0.0f})’
ceVec.cc:26:46: internal compiler error: in cp_tree_equal, at cp/tree.c:2712
constexpr Rot3 r1( 0, 1 ,0, 0, 0, 1, 1, 0, 0);
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org 2012-12-03 19:52:39 UTC --- Created attachment 28864 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28864 minimal cumulative patch for comment #9 (In reply to comment #9) adding it helps t = build_constructor (TREE_TYPE (t), n); + if (TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE) +t = fold (t); TREE_CONSTANT (t) = true; I would have put it after TREE_CONSTANT, but that's not the problem. unfortunately generates ICE for the class constructor at cp/tree.c:2712 Indeed, cp_tree_equal is missing a VECTOR_CST case. We can likely just forward to operand_equal_p. With this patch (I am not proposing it, it conflicts with Jakub's), your last code compiles.
[Bug debug/55579] New: SRA doesn't create debug stmts when they would be useful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55579
Bug #: 55579
Summary: SRA doesn't create debug stmts when they would be
useful
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: jamb...@gcc.gnu.org
Consider -g -O2:
struct S { int a; char b; char c; short d; };
int
foo (int x)
{
struct S s = { x + 1, x + 2, x + 3, x + 4 };
char *p = s.c;
return x;
}
Unfortunately, SRA doesn't add here any debug stmts and everything is DSEd
later on.
*.esra dump says:
Candidate (1722): s
Marking s offset: 0, size: 32 to be replaced with debug statements.
Marking s offset: 32, size: 8 to be replaced with debug statements.
Marking s offset: 40, size: 8 to be replaced with debug statements.
Marking s offset: 48, size: 16 to be replaced with debug statements.
! Disqualifying s - No scalar replacements to be created.
If there are just debug replacements, no normal ones, and the aggregate still
has been candidate for SRA (i.e. no address escape, etc.), it would be nice if
the debug replacements could be emitted anyway. CDDCE or DSE will then remove
the actual stmts, but debug info will be accurate.
[Bug middle-end/55545] [4.8 Regression] Incredibly large compile-time performance regression on IA64 compiling 253.perlbmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55545 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Depends on||55158 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 21:04:46 UTC --- Don't you have the tentative patch for PR rtl-opt/55158 in your tree? It changes ICEs into timeouts in the testsuite.
[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 21:06:23 UTC --- Someone needs to do something here because the C/C++/Fortran testsuite results are abysmal at -O3. And the tentative fix doesn't really help, it turns the ICEs of the testsuite at -O3 into timeouts.
[Bug c++/55580] New: internal compiler error: Segmentation fault - with variadic template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55580
Bug #: 55580
Summary: internal compiler error: Segmentation fault - with
variadic template parameter
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arturswidersk...@gmail.com
Created attachment 28865
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28865
main.cpp to reproduce bug
Code( I belive valid one ) listed below crashes compiler
I compile it with g++ -c -std=c++11 main.cpp
template int const _speed
struct ConstValue
{
static int const Value = _speed;
};
template typename ... _Rest
struct Features
{
typedef ConstValue 0 Average;
};
template typename ... _Rest
template int const _speed
struct Features ConstValue _speed , _Rest ...
{
typedef ConstValue 2 Average;
};
int main ()
{
Features ConstValue 2 , ConstValue 2 ::Average Oki;
return 0;
}
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 21:13:50 UTC --- Author: burnus Date: Mon Dec 3 21:13:42 2012 New Revision: 194104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194104 Log: 2012-12-03 Tobias Burnus bur...@net-b.de Janus Weil ja...@gcc.gnu.org PR fortran/37336 * class.c (gfc_is_finalizable): New function. * gfortran.h (gfc_is_finalizable): Its prototype. * module.c (mio_component): Read initializer for vtype's _final. * resolve.c (resolve_fl_derived0): Call gfc_is_finalizable. * trans-expr.c (gfc_vtable_final_get): New function. (conv_parent_component_references): Fix comment. (gfc_conv_variable): Fix for scalar coarray components. * trans-intrinsic.c (conv_intrinsic_move_alloc): For BT_CLASS, pass the BT_CLASS type and not the declared type to gfc_deallocate_scalar_with_status. * trans.h (gfc_vtable_final_get): New prototype. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
--- Comment #11 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-12-03 21:58:05 UTC ---
thanks Marc,
adding your proposed change above Jason's one make my full test works (but when
subscripting is involved..)
this is my current svn diff
Hope that c++ maintainers came make, out of all this, an optimal patch for the
trunk.
I'm not expert enough on the details to judge what best (besides that I did not
run regression!)
Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c(revision 194084)
+++ gcc/cp/tree.c(working copy)
@@ -2468,7 +2468,8 @@
case COMPLEX_CST:
return cp_tree_equal (TREE_REALPART (t1), TREE_REALPART (t2))
cp_tree_equal (TREE_IMAGPART (t1), TREE_IMAGPART (t2));
-
+case VECTOR_CST:
+ return operand_equal_p (t1, t2, OEP_ONLY_CONST);
case CONSTRUCTOR:
/* We need to do this when determining whether or not two
non-type pointer to member function template arguments
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c(revision 194084)
+++ gcc/cp/semantics.c(working copy)
@@ -6451,6 +6451,14 @@
/* Avoid wrapping an aggregate value in a NOP_EXPR. */
if (TREE_CODE (temp) == CONSTRUCTOR)
return build_constructor (type, CONSTRUCTOR_ELTS (temp));
+ if (TREE_CODE (temp) == VECTOR_CST)
+{
+ int i, count = TYPE_VECTOR_SUBPARTS (type);
+ tree *vec = XALLOCAVEC (tree, count);
+ for (i = 0; i count; i++)
+vec[i] = cp_fold_convert (TREE_TYPE (type), VECTOR_CST_ELT (temp, i));
+ return build_vector (type, vec);
+}
gcc_assert (SCALAR_TYPE_P (type));
return cp_fold_convert (type, temp);
}
@@ -7134,7 +7142,10 @@
vec_free (n);
return t;
}
+
t = build_constructor (TREE_TYPE (t), n);
+ if (TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
+t = fold (t);
TREE_CONSTANT (t) = true;
return t;
}
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
--- Comment #12 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-12-03 22:05:29 UTC ---
about subscripting I get an ICE (set fault)
with
constexpr V4 v = {1,1,1,0};
constexpr V4 m[3] = { (V4){1,0,0,0}, (V4){0,1,0,0}, (V4){0,0,1,0}};
constexpr V4 r = v[0]*m[0] + v[1]*m[1] + v[2]*m[2];
constexpr V4 r = v[0]*m[0] + v[1]*m[1] + v[2]*m[2];
^
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
cxx_eval_constant_expression (call=0x0, t=0x1425961b0,
allow_non_constant=value temporarily unavailable, due to optimizations,
addr=value temporarily unavailable, due to optimizations,
non_constant_p=0x7fff5fbff31e, overflow_p=0x7fff5fbff31f) at
../.././gcc/cp/semantics.c:7122
7122 if (TREE_CODE (ce-index) == COMPONENT_REF)
(gdb) were
Undefined command: were. Try help.
(gdb) where
#0 cxx_eval_constant_expression (call=0x0, t=0x1425961b0,
allow_non_constant=value temporarily unavailable, due to optimizations,
addr=value temporarily unavailable, due to optimizations,
non_constant_p=0x7fff5fbff31e, overflow_p=0x7fff5fbff31f) at
../.././gcc/cp/semantics.c:7122
#1 0x0001001bdbb2 in cxx_eval_constant_expression (call=0x0, t=0x0,
allow_non_constant=value temporarily unavailable, due to optimizations,
addr=value temporarily unavailable, due to optimizations,
non_constant_p=0x14242fee8, overflow_p=0x14258dc40) at
../.././gcc/cp/semantics.c:6791
[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548 --- Comment #2 from janus at gcc dot gnu.org 2012-12-03 22:06:45 UTC --- Author: janus Date: Mon Dec 3 22:06:41 2012 New Revision: 194105 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194105 Log: 2012-12-03 Janus Weil ja...@gcc.gnu.org PR fortran/55548 * intrinsics/system_clock.c (gf_gettime_mono): Add argument 'tck', which returns the clock resolution. (system_clock_4): Get resolution from gf_gettime_mono, but limit to 1000/s. (system_clock_8): Get resolution from gf_gettime_mono. 2012-12-03 Janus Weil ja...@gcc.gnu.org PR fortran/55548 * intrinsic.texi (SYSTEM_CLOCK): Update documentation of SYSTEM_CLOCK. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/system_clock.c
[Bug c++/55581] New: Too-eager instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55581
Bug #: 55581
Summary: Too-eager instantiation
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@boostpro.com
IMO this program should compile with -ftemplate-depth=1, as it does on Clang.
[Sorry for the inline code; technical difficulties prevent me from adding an
attachment before I reboot my machine]
template long N
struct mooch
{
struct arrow
{
moochN-1 operator-();
};
arrow operator-();
};
template
struct mooch0
{
int x;
mooch0* operator-();
};
mooch1 a; // compiles with -ftemplate-depth 1
decltype(a.operator-()) y; // compiles with -ftemplate-depth 1
decltype(a-x) z; // requires -ftemplate-depth=2 on g++ but not
on clang++
[Bug tree-optimization/55559] [4.6/4.7/4.8 Regression] Marshalling double through union with inlines, incorrect behavior with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #7 from Mihai Preda mpreda at gmail dot com 2012-12-03 22:13:03 UTC --- Thanks, I didn't realize that (unsigned)-1.0 is undefined. For the behavior I was expecting it's enough to use an intermediary cast through int, e.g. (unsigned)(int)-1.0. It may be nice to generate a consistent (-O0/-O1) result for (unsigned)-1.0 though, even if not required by the standard.
[Bug fortran/55548] SYSTEM_CLOCK with integer(8) provides nanosecond resolution, but only microsecond precision (without -lrt)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55548 --- Comment #3 from janus at gcc dot gnu.org 2012-12-03 22:19:27 UTC --- (In reply to comment #0) However, the precision claimed by the COUNT_RATE argument should better match the actual precision (also with default flags!). Possible solutions: 1) Use a nanosecond COUNT_RATE only when -lrt is given, and microsecond otherwise. This has been implemented in r194105. Leftover to-do item: Using SYSTEM_CLOCK with integer(16) arguments currently results in: sysclock.f90:(.text+0x455): undefined reference to `_gfortran_system_clock_16' ... add an integer(16) version of SYSTEM_CLOCK!
[Bug c++/53094] constexpr vector subscripting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
--- Comment #13 from Marc Glisse glisse at gcc dot gnu.org 2012-12-03
22:30:53 UTC ---
typedef float __attribute__( ( vector_size( 4*sizeof(float) ) ) ) V4;
constexpr V4 v = {1,1,1,0};
constexpr V4 r = v[0]+v;
is enough to reproduce your latest ICE. cxx_eval_bare_aggregate doesn't check
that ce-index is not NULL for the constructor elements, and tests its
TREE_CODE, which segfaults. Easiest workaround is to test if ce-index is zero
and in that case skip the COMPONENT_REF and NOP_EXPR tests. Which brings you
back to a regular not a constant expression error message.
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 --- Comment #6 from dave.anglin at bell dot net 2012-12-03 22:33:39 UTC --- On 12/3/2012 11:06 AM, John David Anglin wrote: However, backtrace still doesn't work from within compiler. Problem is with fileline_initialize. The techniques currently being used to obtain the full pathname of the executable don't work on HP-UX. http://www.cplusplus.com/forum/general/11104/ Dave
[Bug c++/55580] internal compiler error: Segmentation fault - with variadic template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55580
--- Comment #1 from vlukas at gmx dot de 2012-12-03 22:42:06 UTC ---
I believe the following reduced snippet reproduces the original crash:
---
templateint struct V { };
templatetypename... struct F { };
templatetypename... Ps
templateint I
struct FVI, Ps...
{ };
FV0 x;
With gcc version 4.8.0 20121122 (experimental) (GCC) I get the following:
55580.cc:10:9: internal compiler error: tree check: expected class
'expression', have 'constant' (integer_cst) in tree_operand_check, at
tree.h:4113
FV0 x;
^
0xc8eb59 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc_svn/gcc/tree.c:9006
0x4e32ed expr_check
../../gcc_svn/gcc/tree.h:3849
0x4e32ed tree_operand_check
../../gcc_svn/gcc/tree.h:4113
0x5af3f5 tree_operand_check
../../gcc_svn/gcc/tree.h:3870
0x5af3f5 unify_pack_expansion
../../gcc_svn/gcc/cp/pt.c:16058
0x5b385f unify
../../gcc_svn/gcc/cp/pt.c:16737
0x5b19cf unify
../../gcc_svn/gcc/cp/pt.c:16579
0x5b22ac unify
../../gcc_svn/gcc/cp/pt.c:16729
0x5b49fe get_class_bindings
../../gcc_svn/gcc/cp/pt.c:17439
0x5b566c most_specialized_class
../../gcc_svn/gcc/cp/pt.c:17688
0x5c2840 instantiate_class_template_1
../../gcc_svn/gcc/cp/pt.c:8514
0x5c2840 instantiate_class_template(tree_node*)
../../gcc_svn/gcc/cp/pt.c:9019
0x64d83b complete_type(tree_node*)
../../gcc_svn/gcc/cp/typeck.c:134
0x54c385 start_decl_1(tree_node*, bool)
../../gcc_svn/gcc/cp/decl.c:4665
0x56bd42 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc_svn/gcc/cp/decl.c:4628
0x63a538 cp_parser_init_declarator
../../gcc_svn/gcc/cp/parser.c:15882
0x63aede cp_parser_simple_declaration
../../gcc_svn/gcc/cp/parser.c:10546
0x63cd87 cp_parser_block_declaration
../../gcc_svn/gcc/cp/parser.c:10427
0x645c0b cp_parser_declaration
../../gcc_svn/gcc/cp/parser.c:10324
0x64483d cp_parser_declaration_seq_opt
../../gcc_svn/gcc/cp/parser.c:10210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
--
The backtrace I get from the original testcase is slightly different, but the
toplevel is the same (internal compiler error: tree check: expected class
'expression', have 'constant' (integer_cst) in tree_operand_check, at
tree.h:4113).
I do not know whether the introduction of a second template parameter list for
the partial specialization is valid C++. It can be made to work by changing it
to:
template typename ... _Rest, int const _speed
//template int const _speed
struct Features ConstValue _speed , _Rest ...
--
I hope that helps.
[Bug c++/55582] New: [C++11] Unable to define string user-defined literal without leading underscore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55582 Bug #: 55582 Summary: [C++11] Unable to define string user-defined literal without leading underscore. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: 3dw...@verizon.net This bug is brought to you by the letter 's'. Now that PR54413 is fixed I tried to implement the user-defined literal suffixes proposed by Peter Sommerlad in his paper n3468.pdf I ran into trouble with the string literal suffix 's'. The hangup is the -Wliteral-suffix flag which was added for PR52538 in 2012-04-27 by Ollie Wild a...@google.com which treats any character or string suffix that does *not* start with '_' as a separate token. This to fix broken code with printing macros in inttype.h. With the paper presented by Peter Sommerlad above, the suffix 's' is proposed to create std::string, etc. This wont work with the tokenization introduced for PR52538. Basically, I think some deal needs to be struck and could be struck here. I see five possibilities: * let the letter 's' go by as a user-defined literal (with appropriate comment) * If the macros in are all upper case we could let lower case suffixes go. * We could try to figure out if a suffix has been defined as a literal and let those through. * All the inttype.h macros start with PRI or SCN AFAICS. Just split those. * This problem is above my pay grade. Test case is forthcoming. Ideas? Ed
[Bug c++/55580] internal compiler error: Segmentation fault - with variadic template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55580 --- Comment #2 from arturswiderski82 at gmail dot com arturswiderski82 at gmail dot com 2012-12-03 23:10:49 UTC --- Yes it solved my problem thanks
[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670 --- Comment #10 from Matt Hargett matt at use dot net 2012-12-03 23:17:22 UTC --- I no longer have access to the source tree that exhibited this problem, but it was likely the same as the qemu issue referenced earlier. Feel free to resolve as fixed.
[Bug bootstrap/45700] [4.5/4.6 Regression] --enable-checking=fold bootstrap failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45700 Matt Hargett matt at use dot net changed: What|Removed |Added CC||matt at use dot net --- Comment #5 from Matt Hargett matt at use dot net 2012-12-03 23:18:45 UTC --- *** Bug 42628 has been marked as a duplicate of this bug. ***
[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628 Matt Hargett matt at use dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #13 from Matt Hargett matt at use dot net 2012-12-03 23:18:45 UTC --- Cleaning up my bug list. I didn't realize that I would resolve something as duplicate myself. *** This bug has been marked as a duplicate of bug 45700 ***
[Bug middle-end/50398] ICE when compiling openssl-1.0.0d with -O2 -floop-flatten
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398 --- Comment #1 from Matt Hargett matt at use dot net 2012-12-03 23:20:57 UTC --- loop flattening was removed as a feature, yes? If so, this bug can be closed.
[Bug rtl-optimization/55158] [4.8 Regression] segfault in schedule_region at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #14 from Jan Hubicka hubicka at ucw dot cz 2012-12-03 23:24:13 UTC --- Someone needs to do something here because the C/C++/Fortran testsuite results are abysmal at -O3. And the tentative fix doesn't really help, it turns the ICEs of the testsuite at -O3 into timeouts. Yes, i aplied it to our tester a while a go. It helps to some tests but not to others. Honza
[Bug middle-end/55046] ICE in ira_reuse_stack_slot at ira-color.c:4065
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55046 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-12-03 23:24:58 UTC --- Fixed.
[Bug debug/48670] [4.6 regression] explosion in time and stack usage when using -ggdb on a class with many members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670 Matt Hargett matt at use dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #11 from Matt Hargett matt at use dot net 2012-12-04 00:02:52 UTC --- Marking it resolved myself.
[Bug rtl-optimization/55583] New: Extended shift instruction on x86-64 is not used, producing unoptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583
Bug #: 55583
Summary: Extended shift instruction on x86-64 is not used,
producing unoptimal code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mtkilpai...@torni.org
Created attachment 28866
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28866
Source code demonstrating bad code generation
On x86-64, extended shift instruction is not generated for some reason.
Combined with other problems this creates very bad code.
Test functions included for signed and unsigned 16,32,64-bit types for both
left and right shifts and for constant n and function parameter n.
Code of this form:
unsigned int a, b; const int n = 2;
void test32l (void) { b = (b n) | (a (32 - n)); }
expected code:
mov a(%rip),%eax
shld$0x2,%eax,b(%rip)
ret
produced code:
movb(%rip), %edx ; Size of register used here depends on gcc version
mova(%rip), %eax ; Size of register used here depends on gcc version
sal$2, %edx; Size of register used here depends on gcc version
shr$25, %eax
or %edx, %eax
mov%eax, b(%rip)
ret
Tested with:
COLLECT_GCC_OPTIONS='-v' '-c' '-save-temps' '-O2' '-Wall' '-W' '-o'
'gcc_shld_not_used' '-mtune=generic'
I tried gcc versions:
GNU C (Debian 4.7.2-4) version 4.7.2 (x86_64-linux-gnu)
GNU C (Debian 4.6.3-11) version 4.6.3 (x86_64-linux-gnu)
GNU C (Debian 4.5.3-9) version 4.5.3 (x86_64-linux-gnu)
GNU C (Debian 4.4.7-2) version 4.4.7 (x86_64-linux-gnu)
GNU C (GCC) version 4.8.0 20121203 (experimental) [trunk revision 194106]
(x86_64-unknown-linux-gnu)
All produce the same code modulo register size differences mentioned above. gcc
HEAD changes sal to leal (,%rcx,4),%eax
[Bug rtl-optimization/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 --- Comment #1 from Mikko Markus Torni mtkilpailut at torni dot org 2012-12-04 00:08:21 UTC --- Created attachment 28867 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28867 gcc-HEAD compiler output
[Bug c++/55580] internal compiler error: Segmentation fault - with variadic template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55580 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-04 CC|arturswiderski82 at gmail | |dot com | Ever Confirmed|0 |1 Severity|major |normal
[Bug lto/50468] ICE in force_type_die when compiling binutils with -flto -O[12]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468 Matt Hargett matt at use dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #2 from Matt Hargett matt at use dot net 2012-12-04 00:13:29 UTC --- Can no longer reproduce with gcc-4.7 and binutils-2.23.51.0.3. I think it's safe to assume that the numerous LTO fixes that went into 4.7 resolved this issue.
[Bug rtl-optimization/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-04 CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com, ubizjak at gmail ||dot com Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-12-04 00:21:02 UTC --- Clang generates: movla(%rip), %eax shldl$2, %eax, b(%rip) ret at -O2.
[Bug middle-end/55401] uninstrumented path in TM clones are still instrumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55401 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-12-04 00:24:57 UTC --- fixed in trunk
[Bug c++/55582] [C++11] Unable to define string user-defined literal without leading underscore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55582 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-04 00:35:24 UTC --- (In reply to comment #0) * let the letter 's' go by as a user-defined literal (with appropriate comment) IMHO special cases to allow std-defined literals would make sense.
[Bug rtl-optimization/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 Mikko Markus Torni mikko.markus.torni at iki dot fi changed: What|Removed |Added Attachment #28866|0 |1 is obsolete|| --- Comment #3 from Mikko Markus Torni mikko.markus.torni at iki dot fi 2012-12-04 01:03:44 UTC --- Created attachment 28868 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28868 Source code demonstrating code generated (updated) Bug fixes in signed integer testcases. Clang 3.0 seems to produce optimal looking code in the following test cases: test32rn testu64l testu32l testu16l testu64ln testu64rn testu32ln testu32rn Clang 3.0 manages to use shld/shrd, but generates extra moves in the following test cases: test64r test32r test16r test64rn test32rn testu64rn testu32r testu16r Clang 3.0 fails to use shld/shrd in the following test cases: test64l test32l test16l test64ln test32ln test16ln test16rn testu16ln testu16rn Tested with clang: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S -disable-free -disable-llvm-verifier -main-file-name gcc_shld_not_used.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file gcc_shld_not_used.s -resource-dir /usr/bin/../lib/clang/3.0 -O2 -Wall -W -ferror-limit 19 -fmessage-length 0 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -o gcc_shld_not_used.s -x cpp-output gcc_shld_not_used.i clang -cc1 version 3.0 based upon llvm 3.0 hosted on x86_64-pc-linux-gnu
[Bug c/55584] New: __sync_fetch_and_* friends do not issue warnings when CPU does not support them natively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55584
Bug #: 55584
Summary: __sync_fetch_and_* friends do not issue warnings when
CPU does not support them natively
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsa...@gmail.com
Section 6.5.1 of the GCC 4.7.2 manual states:
Not all operations are supported by all target processors.
If a particular operation cannot be implemented on the target
processor, a warning will be generated and a call an external
function will be generated. ...
-http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc.pdf
However, I cannot get this warning to be generated. I added -Wall and -Wextra.
I opened the vanilla source code for 4.7.2, but the only related warning I
could find was -Wsync-nand ( which warns about how the __sync*nand* functions
changed their meanings with 4.4 ).
The command line is:
gcc test_sync_on_old_platforms.c -c -W -Wall -Wextra -m32 -march=i386
And it returns without error and emits a valid .o file. If I add the '-S' flag
to GCC, the output assembly lists a call to __sync_fetch_and_add_4, as the i386
does not support atomic operations. This much is correct, but it would be good
to warn when this is happening.
The platform is:
rsaxvc@slashtop:~/code$ gcc --version
gcc (Debian 4.7.2-4) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rsaxvc@slashtop:~/code/gccbug$ uname -a
Linux slashtop 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
rsaxvc@slashtop:~/code$
Similar behaviour is seen on OpenBSD/Sparc32.
Here is the input code:
rsaxvc@slashtop:~/code$ cat test_sync_on_old_platforms.c
static unsigned int the_count;
unsigned int test_sync_increment( void )
{
return __sync_fetch_and_add( the_count, 1 );
}
rsaxvc@slashtop:~/code$
[Bug bootstrap/55571] [4.6/4.7/4.8 regression] PR48076 fix broke bootstrap on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55571 --- Comment #8 from Joel Brobecker brobecker at gnat dot com 2012-12-04 04:51:45 UTC --- Created attachment 28869 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28869 Small reproducer with arm-eabi In case it's useful to anyone else, a small program that reproduces the problem. % arm-linux-gnueabi-gcc -o utils utils.c [same problem with __sync_synchronize]
[Bug c++/55576] Fails to compile a call to template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55576
Antony Polukhin antoshkka at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #3 from Antony Polukhin antoshkka at gmail dot com 2012-12-04
07:12:12 UTC ---
(In reply to comment #1)
I don't think this is a G++ bug, there are three problems with this code:
1) You need to #include new to use placement new
2) factory::apply is non-const but the parameter 'f' is const
Fixed
3) f.template applyT finds the current instantiation, ::applyT, rather
than
the member function you are trying to call, use f.FactoryT::template applyT
instead
That is the point. `f.template applyT(address);` is accepted by some
compilers without `FactoryT::`
Fixed version:
struct factory {
template typename T
void * apply(void * address) const {
return 0;
}
};
template typename T
struct apply {
template typename FactoryT
void* operator()(FactoryT const f, void * address) const {
return f.template applyT(address); // error: invalid use of ‘struct
applyT’ why???
}
};
int main() {
int place;
applyint()(factory(), place);
return 0;
}
