[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #16 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-24 09:18:19 UTC --- The issue from comment 5 onward started with: Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Nov 3 14:46:26 2011 + 2011-11-03 Richard Guenther rguent...@suse.de PR lto/44965 * lto-opts.c: Re-implement. * lto-streamer.h (lto_register_user_option): Remove. (lto_read_file_options): Likewise. (lto_reissue_options): Likewise. (lto_clear_user_options): Likewise. (lto_clear_file_options): Likewise. * opts-global.c (post_handling_callback): Remove. (set_default_handlers): Do not set post_handling_callback. (decode_options): Remove LTO specific code. * lto-wrapper.c (merge_and_complain): New function. (run_gcc): Read all input file options and prepend a merged set before the linker driver options. * gcc.c (driver_post_handling_callback): Remove. (set_option_handlers): Do not set post_handling_callback. * opts-common.c (handle_option): Do not call post_handling_callback. * opts.h (struct cl_option_handlers): Remove post_handling_callback. lto/ * lto-lang.c (lto_post_options): Do not read file options. * lto.c (lto_read_all_file_options): Remove. (lto_init): Call lto_set_in_hooks here. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180827 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #6 from Harald van Dijk harald at gigawatt dot nl 2012-11-24
09:28:44 UTC ---
A compile-only test for this can be
struct S { S(); };
void f(S *);
void g() {
S *s = new S[0];
f(s);
}
which causes a bogus warning:
test.cc: In function 'void g()':
test.cc:5:7: warning: 's' is used uninitialized in this function
[-Wuninitialized]
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 09:32:48 UTC --- Thanks. Relying on a warning seems a bit brittle, maybe a scan in the original dump would be good enough in terms of compile only testcases, but I sent to the mailing list a run time test.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 09:43:14 UTC --- Let's make a deal: you provide a self-contained short testcase (say below 50 lines, definitely doable with the help of c-reduce or delta) and I add it to the mainline testsuite, to avoid regressions. I'll do that for free! ;)
[Bug c++/54403] [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54403
stepik-777 at mail dot ru changed:
What|Removed |Added
CC||stepik-777 at mail dot ru
--- Comment #4 from stepik-777 at mail dot ru 2012-11-24 10:03:55 UTC ---
You can use !this-m_barbar intead of !m_barbar as a workaround.
This bug is still present in 4.7.2.
templatetypename T
struct Struct
{
int member;
Struct()
{
[=]{ !this-member; }; // this works
[=]{ !member; }; // internal compiler error: Segmentation fault
}
};
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 10:04:27 UTC --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01991.html
[Bug middle-end/55438] [4.8 Regression]: tmpdir-gcc.dg-struct-layout-1/t001 - t028, gcc.c-torture/execute/991118-1.c, gcc.c-torture/execute/bf64-1.c, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55438 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-24 AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2012-11-24 10:36:34 UTC --- Gah, I'd misremembered what BIGGEST_ALIGMNENT means. Testing a patch.
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446
--- Comment #9 from Harald van Dijk harald at gigawatt dot nl 2012-11-24
11:27:25 UTC ---
Ah, okay, an alternative compile-only testcase that does not rely on particular
warnings would be
struct S { S(); };
__typeof__(new S[0]) s;
test.cc:2:23: error: invalid type in declaration before ';' token
but if you've already got a good testcase, sure, go with that :)
[Bug c++/55367] Probably problem with c++ vptr under templates and multiple inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55367 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-24 11:52:24 UTC --- (In reply to comment #8) Dup. *** This bug has been marked as a duplicate of bug 55171 *** Hmm, indeed a dup. It seems to be related to the thunk-code for thiscall. I will take a look to it.
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-24 11:53:19 UTC --- So, in .cse1 we have: ENTRY | | 2 | | + 4 --+ |/ \ | | / \ | | 6 5| | /\ |\ | |/ \| \ | | 73 | 8 | | || | /\/ +---|| | / \ / | --109/ |-/ EXIT-/ (3-4 and 9-4 are back edges). Now, in bypass_block, when we're trying to bypass BB 4, we iterate over BB 4's incoming edges. We skip certain edges (e.g. complex), then we're iterating over reg_use_table (registers used in insn). Here we call set = find_bypass_set (regno, e-src-index); If set == NULL, we skip to another iteration. But in this case the set is not NULL, and we end up with this: Redirecting fallthru edge 3-4 to 6 JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (const_int 1 [0x1]) Bypass edge from 3-4 to 6 Redirecting fallthru edge 9-4 to 5 JUMP-BYPASS: Proved reg 59 in jump_insn 15 equals constant (const_int 3 [0x3]) Bypass edge from 9-4 to 5 but how can be two different constants in one reg? The hash table is: SET hash table (11 buckets, 3 entries) Index 0 (hash value 4) (reg:SI 59 [ D.1735 ]) := (const_int 1 [0x1]) Index 1 (hash value 5) (reg/v/f:DI 60 [ b ]) := (const_int 0 [0]) Index 2 (hash value 4) (reg:SI 59 [ D.1735 ]) := (const_int 3 [0x3]) redirect_edge_and_branch_force then redirect edges and BB 4 is gone. I'd say we cannot redirect edges of BBs which have 2 and more incoming back edges if in the hash table there are more entries with the same hash values, but the SRC rtx's differ. I'll post something to ML.
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-24 12:02:56 UTC --- (In reply to comment #5) I have no problem to pay someone, I'm a bit disappointed seeing a bug closed because new version works without investigate if the problem is still there in new versions but not triggered by my test case. I'm a bit disappointed you think I didn't investigate. I'm a bit disappointed you didn't try a current release as requested at http://gcc.gnu.org/bugs/ (or even the most recent 4.4 release!) I'm a bit disappointed you didn't reduce the testcase to something that doesn't include thousands of lines of boost code. I'm a bit diappointed you didn't include the output of 'g++ -v'. But I got over my disappointment and I tested with half a dozen different versions of GCC and looked for old bugs in the area which I know about. I didn't find anything, but the bug is not reproducible in current releases. Exactly how much time do you expect someone to spend chasing a bug that doesn't appear to exist any more? If you can reproduce it with a current release then reopen the bug, otherwise this is a bug in a release series that is discontinued and not going to be fixed. If you pay me I'll find exactly which patch fixed it, otherwise the onus is on you to demonstrate there's still a problem. Also if 4.4.3 is not supported why while submitting the bug I was able to target the 4.4.3? There are lots of existing bugs with that version, so it has to be a valid option, or we'd have to delete all the old bugs. We could make it unselectable, but that would prevent us fixing or re-categorising old bugs if we need to, and is it really worth the effort of customising bugzilla in that way?
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #28 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 12:05:57 UTC --- (In reply to comment #27) (In reply to comment #26) Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it. Well, we need to make sure that the (very basic) program program main character*10 x open(10,file=foo.dat) write (10,'(A)') '' write (10,'(A)') '' close (10) open(10,file=foo.dat) write (10,'(A)') '' close (10) open(10,file=foo.dat) 100 continue read (10,'(A)',end=200) x write (*,'(A)') x goto 100 200 continue close(10,status=delete) end continues to work as expected: That probably means truncating on close and rewind. I can see what I can do, but I have little time... (as always)
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #8 from Gaetano Mendola mendola at gmail dot com 2012-11-24 12:25:35 UTC --- Jonathan, I have nothing against you personaly, what you wrote is: GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in current releases. and doesn't exactly show that you have investigate, I have also stated that with 4.7.3 works. Actualy the code I have submitted was tailored already I couldn't shrink more than I did. To be honest with the real code instead to have a pure virtual call I had a simple core with gdb finding bogus data in the core, that was the smallest test I was able to make it reproducible. About the fact I didn't post the g++ -v output you are right, I have issued the command g++ -v -save-temps ... but somehow the output get lost in the archive attached. If you are interested in the output I will provide it. About the fact to pay you to find the patch/commit correcting it just send me a commercial proposal to my email address. Thank you for your time. Regards Gaetano Mendola
[Bug fortran/55255] [4.6 Regression] Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from janus at gcc dot gnu.org 2012-11-24 12:35:12 UTC --- (In reply to comment #1) I can confirm the error with: gcc version 4.6.0 20110505 [gcc-4_6-branch revision 173419] (SUSE Linux) However, all other versions I tried compile the test case correctly (including 4.3, 4.5, 4.7 and trunk). In fact it seems that it has also been fixed on the 4.6 branch already: gcc version 4.6.3 20120531 [gcc-4_6-branch revision 188067] (SUSE Linux) works for me on both comment 0 and comment 2. Closing as fixed!
[Bug c++/55171] [4.7/4.8 Regression] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-24
Ever Confirmed|0 |1
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-24 12:47:37
UTC ---
Yes, the issue here is the generation of patterns - like
movl(%ecx), %eax
addl-12(%eax), %ecx
- for thunks.
The following patch solves this issue for me.
Index: i386.c
===
--- i386.c(Revision 193669)
+++ i386.c(Arbeitskopie)
@@ -9567,6 +9567,8 @@
tree decl = current_function_decl, fntype = TREE_TYPE (decl);
bool fastcall_p
= lookup_attribute (fastcall, TYPE_ATTRIBUTES (fntype)) != NULL_TREE;
+ bool thiscall_p
+= lookup_attribute (thiscall, TYPE_ATTRIBUTES (fntype)) != NULL_TREE;
bool static_chain_p = DECL_STATIC_CHAIN (decl);
int regparm = ix86_function_regparm (fntype, decl);
int drap_regno
@@ -9577,10 +9579,13 @@
if ((regparm 1 || (fastcall_p !static_chain_p))
drap_regno != AX_REG)
regno = AX_REG;
- else if (regparm 2 drap_regno != DX_REG)
+ else if (thiscall_p
+ !static_chain_p drap_regno != DX_REG)
+ regno = DX_REG;
+ else if (regparm 2 !thiscall_p drap_regno != DX_REG)
regno = DX_REG;
/* ecx is the static chain register. */
- else if (regparm 3 !fastcall_p !static_chain_p
+ else if (regparm 3 !fastcall_p !thiscall_p !static_chain_p
drap_regno != CX_REG)
regno = CX_REG;
else if (ix86_save_reg (BX_REG, true))
@@ -11092,12 +11097,15 @@
return R11_REG;
else
{
- bool is_fastcall;
+ bool is_fastcall, is_thiscall;
int regparm;
is_fastcall = (lookup_attribute (fastcall,
TYPE_ATTRIBUTES (TREE_TYPE (cfun-decl)))
!= NULL);
+ is_thiscall = (lookup_attribute (thiscall,
+ TYPE_ATTRIBUTES (TREE_TYPE (cfun-decl)))
+ != NULL);
regparm = ix86_function_regparm (TREE_TYPE (cfun-decl), cfun-decl);
if (is_fastcall)
@@ -0,6 +8,12 @@
}
return AX_REG;
}
+ else if (is_thiscall)
+{
+ if (!DECL_STATIC_CHAIN (cfun-decl))
+return DX_REG;
+ return AX_REG;
+}
else if (regparm 3)
{
if (!DECL_STATIC_CHAIN (cfun-decl))
@@ -25046,7 +25060,7 @@
fntype = TREE_TYPE (fndecl);
ccvt = ix86_get_callcvt (fntype);
- if ((ccvt (IX86_CALLCVT_FASTCALL | IX86_CALLCVT_THISCALL)) != 0)
+ if ((ccvt IX86_CALLCVT_FASTCALL) != 0)
{
/* Fastcall functions use ecx/edx for arguments, which leaves
us with EAX for the static chain.
@@ -25054,6 +25068,8 @@
leaves us with EAX for the static chain. */
regno = AX_REG;
}
+ else if ((ccvt IX86_CALLCVT_THISCALL) != 0)
+regno = DX_REG;
else if (ix86_function_regparm (fntype, fndecl) == 3)
{
/* For regparm 3, we have no free call-clobbered registers in
@@ -34713,8 +34729,10 @@
else
{
unsigned int ccvt = ix86_get_callcvt (TREE_TYPE (function));
- if ((ccvt (IX86_CALLCVT_FASTCALL | IX86_CALLCVT_THISCALL)) != 0)
+ if ((ccvt IX86_CALLCVT_FASTCALL) != 0)
tmp_regno = AX_REG;
+ else if ((ccvt IX86_CALLCVT_THISCALL) != 0)
+tmp_regno = DX_REG;
else
tmp_regno = CX_REG;
}
[Bug c++/55171] [4.7/4.8 Regression] incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2012-11-24 12:54:40 UTC --- The pattern is movl4(%esp), %eax movl(%eax), %eax addl-16(%eax), %eax As here the saved this-pointer in %eax gets clobbered.
[Bug fortran/51520] [4.6 Regression] ICE in gfortran 4.6.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51520 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[4.6 Regression] ICE in |[4.6 Regression] ICE in |gfortran 4.6.2, x86_64 |gfortran 4.6.x --- Comment #6 from janus at gcc dot gnu.org 2012-11-24 13:14:22 UTC --- Slightly further reduced test case: module sidl_array_array_F03 use iso_c_binding type sidl__array type(c_ptr) :: a = c_null_ptr end type end module use sidl_array_array_F03 type (sidl__array) :: res call is_null_s(res) contains subroutine is_null_s(ext) class(sidl__array) :: ext end subroutine end Still segfaults with the current 4.6 branch version: gcc version 4.6.4 20121124 (prerelease) [gcc-4_6-branch revision 193777] (GCC)
[Bug fortran/52679] [4.6 Regression] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52679 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org 2012-11-24 14:08:58 UTC --- Further reduced test case, based on comment 1: module Args_Basic_type_F03 use, intrinsic :: iso_c_binding type Args_Basic_t type(c_ptr) :: d_ior = c_null_ptr end type contains subroutine cache_epv_s(self) class(Args_Basic_t) :: self end subroutine end module use Args_Basic_type_F03 type, extends(Args_Basic_t) :: Args_Basic_impl_t end type type(Args_Basic_impl_t) :: obj call cache_epv_s(obj) contains real function passeverywherechar_impl(self) type(Args_Basic_impl_t) :: self end function end This still ICEs with: gcc version 4.6.4 20121124 (prerelease) [gcc-4_6-branch revision 193777] (GCC)
[Bug fortran/52679] [4.6 Regression] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52679 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from janus at gcc dot gnu.org 2012-11-24 14:12:47 UTC --- I'm sure this is a duplicate of PR51520. Both have the same valgrind backtrace and the test cases are very similar (both include a C_NULL_PTR initialization and a CLASS variable). *** This bug has been marked as a duplicate of bug 51520 ***
[Bug fortran/51520] [4.6 Regression] ICE in gfortran 4.6.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51520 --- Comment #7 from janus at gcc dot gnu.org 2012-11-24 14:12:47 UTC --- *** Bug 52679 has been marked as a duplicate of this bug. ***
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.0 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-24 14:21:12 UTC --- (In reply to comment #8) Jonathan, I have nothing against you personaly, what you wrote is: GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in current releases. and doesn't exactly show that you have investigate, I have also stated that with 4.7.3 works. I investigated and couldn't find anything conclusive, so I said seems because I wasn't certain. If you assume I didn't investigate and reply with time to adopt ICC then feel free to do so, I don't volunteer my time to GCC for people with that attitude. Actualy the code I have submitted was tailored already I couldn't shrink more than I did. To be honest with the real code instead to have a pure virtual call I had a simple core with gdb finding bogus data in the core, that was the smallest test I was able to make it reproducible. http://gcc.gnu.org/bugs/minimize.html http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction About the fact I didn't post the g++ -v output you are right, I have issued the command g++ -v -save-temps ... but somehow the output get lost in the archive attached. If you are interested in the output I will provide it. I'm not interested, the point is you provided an incomplete bug report but are then happy to complain about the effort put in by people who look at it. The bug was fixed by http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html so is fixed in 4.5.0 and later
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 15:00:23 UTC --- Author: tkoenig Date: Sat Nov 24 15:00:16 2012 New Revision: 193778 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193778 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 * gfortran.dg/allocate_error_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/55457] New: Having some predefined macros to get more information about gcc vector extensions capabilities would be nice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 Bug #: 55457 Summary: Having some predefined macros to get more information about gcc vector extensions capabilities would be nice Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: siarhei.siamas...@gmail.com One practical problem is how to identify whether vector extensions are beneficial or a fallback to the standard C code is better to be taken. In the case of OpenCL, there are param values such as CL_DEVICE_PREFERRED_VECTOR_WIDTH_INT, CL_DEVICE_PREFERRED_VECTOR_WIDTH_FLOAT, etc. http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceInfo.html If gcc could have some sort of predefined macro telling that preferred vector width is 1, it could be used in the code to avoid getting performance penalty by just using normal C code when compiling for non-SIMD capable platforms.
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-11-24 16:39:00
UTC ---
LTO miscompiled:
/* Skip frontend and driver specific options here. */
if (!(cl_options[option-opt_index].flags
(CL_COMMON|CL_TARGET|CL_LTO)))continue;
with
extern const struct cl_option cl_options[];
Stage 1 GCC shows
Starting program:
/export/build/gnu/gcc-lto-asan/build-x86_64-linux/stage1-gcc/cc1 -fpreprocessed
/tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64 -auxbase x -version
-flto -o x.s
Breakpoint 6, main (argc=14, argv=0x7fffe0f8)
at /export/gnu/import/git/gcc/gcc/main.c:36
36 return toplev_main (argc, argv);
(gdb) p cl_options_count
$6 = 1246
(gdb) p ((struct cl_option *) cl_options)[0]
$7 = {opt_text = 0x13ef100 -###, help = 0x0, missing_argument_error = 0x0,
warn_message = 0x0, alias_arg = 0x0, neg_alias_arg = 0x0,
alias_target = 1246, back_chain = 1246, opt_len = 3 '\003', neg_index = -1,
flags = 524288, cl_disabled = 0, cl_separate_nargs = 0,
cl_separate_alias = 0, cl_negative_alias = 0, cl_no_driver_arg = 0,
cl_reject_driver = 0, cl_reject_negative = 0, cl_missing_ok = 0,
cl_uinteger = 0, cl_host_wide_int = 0, cl_tolower = 0, cl_report = 0,
flag_var_offset = 65535, var_enum = 0, var_type = CLVC_BOOLEAN,
var_value = 0}
(gdb) p cl_options[0]
$8 = {opt_text = 0x13ef100 -###, help = 0x0, missing_argument_error = 0x0,
warn_message = 0x0, alias_arg = 0x0, neg_alias_arg = 0x0,
alias_target = 1246, back_chain = 1246, opt_len = 3 '\003', neg_index = -1,
flags = 524288, cl_disabled = 0, cl_separate_nargs = 0,
cl_separate_alias = 0, cl_negative_alias = 0, cl_no_driver_arg = 0,
cl_reject_driver = 0, cl_reject_negative = 0, cl_missing_ok = 0,
cl_uinteger = 0, cl_host_wide_int = 0, cl_tolower = 0, cl_report = 0,
flag_var_offset = 65535, var_enum = 0, var_type = CLVC_BOOLEAN,
var_value = 0}
(gdb)
Stage 2 GCC shows
Starting program:
/export/build/gnu/gcc-lto-asan/build-x86_64-linux/prev-gcc/cc1 -fpreprocessed
/tmp/x.i -quiet -dumpbase x.i -mtune=generic -march=x86-64 -auxbase x -version
-flto -o x.s
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
Breakpoint 6, main (argc=14, argv=0x7fffe108)
at /export/gnu/import/git/gcc/gcc/main.c:36
36 return toplev_main (argc, argv);
(gdb) p ((struct cl_option *) cl_options)[0]
$24 = {
opt_text = 0x432d2d002323232d Address 0x432d2d002323232d out of bounds,
help = 0x485441505353414c Address 0x485441505353414c out of bounds,
missing_argument_error = 0x772d6c6c612d2d00 Address 0x772d6c6c612d2d00 out
of bounds,
warn_message = 0x73676e696e7261 Address 0x73676e696e7261 out of bounds,
alias_arg = 0x2d0069736e612d2d Address 0x2d0069736e612d2d out of bounds,
neg_alias_arg = 0x6c626d657373612d Address 0x6c626d657373612d out of
bounds, alias_target = 101, back_chain = 11565, opt_len = 97 'a',
neg_index = 1627419762, flags = 1919251315, cl_disabled = 0,
cl_separate_nargs = 2, cl_separate_alias = 0, cl_negative_alias = 1,
cl_no_driver_arg = 1, cl_reject_driver = 1, cl_reject_negative = 0,
cl_missing_ok = 1, cl_uinteger = 0, cl_host_wide_int = 0, cl_tolower = 1,
cl_report = 0, flag_var_offset = 28271, var_enum = 27936,
var_type = 1735289203, var_value = 3242718661498139237}
(gdb)
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #18 from H.J. Lu hjl.tools at gmail dot com 2012-11-24 16:49:43 UTC --- I think LTO is confused extern const struct cl_option cl_options[]; with extern const struct cl_option cl_options*;
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #19 from H.J. Lu hjl.tools at gmail dot com 2012-11-24 17:03:13
UTC ---
The same issue can be reproduced with this patch:
diff --git a/gcc/lto-opts.c b/gcc/lto-opts.c
index a235f41..cd3730b 100644
--- a/gcc/lto-opts.c
+++ b/gcc/lto-opts.c
@@ -19,6 +19,7 @@ You should have received a copy of the GNU General Public
License
along with GCC; see the file COPYING3. If not see
http://www.gnu.org/licenses/. */
+#define BAD_LTO
#include config.h
#include system.h
#include coretypes.h
diff --git a/gcc/opts.h b/gcc/opts.h
index b6a4361..14a31e4 100644
--- a/gcc/opts.h
+++ b/gcc/opts.h
@@ -122,7 +122,11 @@ struct cl_option_state {
char ch;
};
+#ifdef BAD_LTO
+extern const struct cl_option *cl_options;
+#else
extern const struct cl_option cl_options[];
+#endif
extern const unsigned int cl_options_count;
extern const char *const lang_names[];
extern const unsigned int cl_lang_count;
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 17:13:31 UTC --- Author: tkoenig Date: Sat Nov 24 17:13:25 2012 New Revision: 193780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193780 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * gfortran.dg/allocate_error_4.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/55449] [4.4.3] pure virtual call only with -O1/2/3 (boost::optional)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55449 --- Comment #10 from Gaetano Mendola mendola at gmail dot com 2012-11-24 17:49:41 UTC --- (In reply to comment #9) (In reply to comment #8) Jonathan, I have nothing against you personaly, what you wrote is: GCC 4.4 is no longer supported, and the problem *seems* to be already fixed in current releases. and doesn't exactly show that you have investigate, I have also stated that with 4.7.3 works. I investigated and couldn't find anything conclusive, so I said seems because I wasn't certain. If you assume I didn't investigate and reply with time to adopt ICC then feel free to do so, I don't volunteer my time to GCC for people with that attitude. Well, I have to admit that was a poor and over reacted reply from my side, but as you spent your time to investigate the issue I have spent my time to understand why it was happening and some hours, no kidding, to shrink it as much I could to create the test case I have submitted, as you can see that code is useful to nothing. I was frustrated to see a short it work/fixed in current release after having work half noon to submit it, the fast it was working with a new gcc release was an information I already knew it, I'd expect something on the line: o yes, it was an old bug we have already corrected, that's why I have submitted the bug not to drive someone else trying the same I did. As you can see from my first post I have tried to shrink more than that, and each piece I was removing was then making the test passing. I'm not interested, the point is you provided an incomplete bug report but are then happy to complain about the effort put in by people who look at it. I'm not happy to complain, why would I? I'm happy when stuff works and when a submitted bug was a real bug helping to improve gcc quality. When I submitted it, for me the bug report was not incomplete otherwise I wouldn't have submitted it, I did follow the guide and the only piece missing, my fault, was the output of g++ -v -save-temps because I forgot to redirect the output to a file. I would have provided it immediately if you would have pointed it out earlier. The bug was fixed by http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html so is fixed in 4.5.0 and later Thank you for it. May I say now then: time to upgrade gcc ? I'm sorry it was not my intention to hurt anyone.
[Bug bootstrap/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #20 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-24 19:47:37 UTC ---
With:
diff --git a/gcc/lto-opts.c b/gcc/lto-opts.c
index a235f41..1c05534 100644
--- a/gcc/lto-opts.c
+++ b/gcc/lto-opts.c
@@ -93,6 +93,8 @@ lto_write_options (void)
{
struct cl_decoded_option *option = save_decoded_options[i];
+ gcc_assert (option-opt_index cl_options_count);
+
/* Skip frontend and driver specific options here. */
if (!(cl_options[option-opt_index].flags
(CL_COMMON|CL_TARGET|CL_LTO)))
continue;
I get:
markus@x4 gcc_build_dir % ./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/ -c -flto
/home/markus/t.c
/home/markus/t.c:1:1: internal compiler error: in lto_write_options, at
lto-opts.c:96
[Bug rtl-optimization/55458] New: [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55458 Bug #: 55458 Summary: [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1212 with -fPIC -m32 and simple asm volatile Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28767 reduced testcase Compiler output: $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-193712-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-193712-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.8.0 20121121 (experimental) (GCC) $ gcc -fPIC -m32 testcase.c testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1212 } ^ 0x8e29a1 assign_by_spills /mnt/svn/gcc-trunk/gcc/lra-assigns.c:1212 0x8e493b lra_assign() /mnt/svn/gcc-trunk/gcc/lra-assigns.c:1364 0x8e05dd lra(_IO_FILE*) /mnt/svn/gcc-trunk/gcc/lra.c:2298 0x896aa8 do_reload /mnt/svn/gcc-trunk/gcc/ira.c:4624 0x896aa8 rest_of_handle_reload /mnt/svn/gcc-trunk/gcc/ira.c:4737 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. I don't have a x86 compiler, so I don't know if this ICEs the same way on an x86.
[Bug target/55448] using const-reference SSE or AVX types leads to unnecessary unaligned loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448 --- Comment #3 from Matthias Kretz kretz at kde dot org 2012-11-24 21:38:21 UTC --- BTW, the problem is just as well visible with only SSE. The __m128 case then compiles to movlps and movhps instead of the memory operand.
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 22:17:40 UTC --- Author: tkoenig Date: Sat Nov 24 22:17:35 2012 New Revision: 193784 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193784 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * gfortran.dg/allocate_error_4.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c/55459] New: Firefox 17: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55459 Bug #: 55459 Summary: Firefox 17: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: frag...@gmail.com I'm using gcc 4.7.2 and when trying to compile Firefox 17 with the following options: -march=native -O3 -mno-avx -pipe -floop-interchange -floop-strip-mine -floop-block It results in the following: make[5]: Entering directory `/home/fraga/src/firefox/media/webrtc/trunk/src/modules/modules_iSACFix' gcc -o audio_coding/codecs/iSAC/fix/source/fft.o -c -I../../../../../../dist/system_wrappers -include /home/fraga/src/mozilla/config/gcc_hidden.h -DMOZ_GLUE_IN_PROGRAM -D_FILE_OFFSET_BITS=64 -DCHROMIUM_BUILD -DUSE_NSS=1 -DTOOLKIT_USES_GTK=1 -DGTK_DISABLE_SINGLE_INCLUDES=1 -D_ISOC99_SOURCE=1 -DENABLE_REMOTING=1 -DENABLE_P2P_APIS=1 -DENABLE_CONFIGURATION_POLICY -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1 -DUSE_SKIA=1 -DENABLE_REGISTER_PROTOCOL_HANDLER=1 -DENABLE_WEB_INTENTS=1 -DENABLE_PLUGIN_INSTALLATION=1 -DWEBRTC_LINUX -DWEBRTC_THREAD_RR -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I. -I/home/fraga/src/mozilla/media/webrtc/trunk/src/modules/.. -I/home/fraga/src/mozilla/media/webrtc/trunk/src/modules/../.. -I/home/fraga/src/mozilla/media/webrtc/trunk/src/modules/audio_coding/codecs/iSAC/fix/interface -I/home/fraga/src/mozilla/media/webrtc/trunk/src/modules/../common_audio/signal_processing/include -fPIC -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wno-overlength-strings -Wcast-align -Wno-long-long -march=native -O3 -pipe -floop-interchange -floop-strip-mine -floop-block -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -march=native -O3 -mno-avx -pipe -floop-interchange -floop-strip-mine -floop-block -fomit-frame-pointer -include ../../../../../../mozilla-config.h -DMOZILLA_CLIENT -MD -MF .deps/fft.o.pp /home/fraga/src/mozilla/media/webrtc/trunk/src/modules/audio_coding/codecs/iSAC/fix/source/fft.c /home/fraga/src/mozilla/media/webrtc/trunk/src/modules/audio_coding/codecs/iSAC/fix/source/fft.c: In function ‘WebRtcIsacfix_FftRadix16Fastest’: /home/fraga/src/mozilla/media/webrtc/trunk/src/modules/audio_coding/codecs/iSAC/fix/source/fft.c:71:15: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [audio_coding/codecs/iSAC/fix/source/fft.o] Error 1 make[5]: Leaving directory `/home/fraga/src/firefox/media/webrtc/trunk/src/modules/modules_iSACFix' make[4]: *** [src/modules/modules_iSACFix_libs] Error 2 make[4]: Leaving directory `/home/fraga/src/firefox/media/webrtc/trunk' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/home/fraga/src/firefox/media/webrtc' make[2]: *** [libs_tier_platform] Error 2 make[2]: Leaving directory `/home/fraga/src/firefox' make[1]: *** [tier_platform] Error 2 make[1]: Leaving directory `/home/fraga/src/firefox' make: *** [default] Error 2 Here it's the ~/.mozconfig I use: . /home/fraga/src/mozilla/browser/config/mozconfig mk_add_options LDFLAGS=-L/usr/X11/lib64 mk_add_options CPPFLAGS=-I/usr/X11/include mk_add_options MOZ_CO_PROJECT=browser mk_add_options MOZ_OBJDIR=/home/fraga/src/firefox ac_add_options --enable-optimize=-march=native -O3 -mno-avx -pipe -floop-interchange -floop-strip-mine -floop-block ac_add_options --disable-debug ac_add_options --disable-tests ac_add_options --enable-svg ac_add_options --enable-safe-browsing ac_add_options --enable-update-packaging ac_add_options --x-libraries=/usr/X11/lib64 ac_add_options --disable-necko-wifi ac_add_options --disable-crashreporter
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 22:20:23 UTC --- Fixed on all affected branches, closing.
[Bug target/55277] [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1217
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
Antoine Balestrat antoine.balestrat at gmail dot com changed:
What|Removed |Added
CC||antoine.balestrat at gmail
||dot com
--- Comment #1 from Antoine Balestrat antoine.balestrat at gmail dot com
2012-11-24 22:20:46 UTC ---
I've got a simpler testcase that seems to trigger the same ICE, if this is of
any help.
$ cat lra.c
int a, c;
void f(long long p)
{
long long b;
if(b)
b = p ? : 0;
for (; p; p++)
p *= a (c = p *= !a 2);
a = b += !(b 3740917449);
}
$ xgcc -O1 -m32 -w lra.c
lra.c: In function ‘f’:
lra.c:14:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1217
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/55459] Firefox 17: internal compiler error: in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55459 --- Comment #1 from Dâniel Fraga fragabr at gmail dot com 2012-11-24 22:26:45 UTC --- My Parma Polyhedra Library version is: ppl-config --version 0.11.2 Should I updated to 1.0 version?
[Bug sanitizer/55289] darwin bootstrap fails due to missing libsanitizer/interception/mach_override directory and files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #50 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-24 22:37:22 UTC --- i386 and x86_64 darwin now supports libsanitizer with... Author: kcc Date: Sat Nov 24 18:24:13 2012 New Revision: 193781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193781 Log: [libsanitizer] add mach_override and enable libsanitizer on darwin Added: trunk/libsanitizer/interception/mach_override/ trunk/libsanitizer/interception/mach_override/LICENSE.txt trunk/libsanitizer/interception/mach_override/mach_override.c trunk/libsanitizer/interception/mach_override/mach_override.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/libsanitizer/ChangeLog trunk/libsanitizer/configure trunk/libsanitizer/configure.ac trunk/libsanitizer/configure.tgt trunk/libsanitizer/interception/Makefile.am trunk/libsanitizer/interception/Makefile.in
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 --- Comment #10 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-24 23:45:49 UTC --- Author: paolo Date: Sat Nov 24 23:45:45 2012 New Revision: 193785 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193785 Log: /cp 2012-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/55446 * init.c (build_vec_init): Do not early return error_mark_mode when integer_all_onesp (maxindex). /testsuite 2012-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/55446 * g++.dg/init/new41.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-24 23:55:26 UTC --- Author: paolo Date: Sat Nov 24 23:55:22 2012 New Revision: 193786 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193786 Log: /cp 2012-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/55446 * init.c (build_vec_init): Do not early return error_mark_mode when integer_all_onesp (maxindex). /testsuite 2012-11-24 Paolo Carlini paolo.carl...@oracle.com PR c++/55446 * g++.dg/init/new41.C: New. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/new41.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/init.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c++/55446] [4.7/4.8 Regression] array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-24 23:56:20 UTC --- Fixed.
[Bug c++/55460] New: Template-dependent name is not looked up at instantiation point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55460
Bug #: 55460
Summary: Template-dependent name is not looked up at
instantiation point
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: solo...@mail.com
Created attachment 28768
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28768
Code reproducing bug
Howdy,
I think this is a bug in G++. I have a call to a template function filter(T) in
a template context. filter() is further overloaded before the instantiation
point. G++ 4.6.1 and 4.5.2 (both under MinGW, sorry, I don't have access to a
more recent version) seems to resolve it at declaration point (see attachment
for the exact code reproducing bug):
namespace my
{
...
// A function template that by default behaves as identity
template typename P
typename std::remove_referenceP::type
filter(P p) throw() { return std::move(p); }
...
} // of namespace my
// Since this is unrestricted template, ADL won't work, so we have to stick
// this overloaded operator building an expression template into the global
scope
template typename P1
inline auto operator(P1 p1) throw()
- typename std::enable_if
my::is_mineP1::value,
my::addressdecltype(my::filter(std::forwardP1(p1)))
::type
{
// NOTE: call to filter depends on template argument, thus have to be
// resolved at instantiation point. But it doesn't!
return my::addressdecltype(my::filter(std::forwardP1(p1)))
(my::filter(std::forwardP1(p1)));
}
// We now declare few more classes modeling our concept: var and ref
namespace my
{
template typename T class var;
template typename T class ref;
...
// and specialize function filter on them
template typename T inline refvarT filter( varT t) throw()
{ return refvarT(t); }
} // of namespace my
int main()
{
my::varint h;
auto a = h; // Instantiate expression template via overloaded operator
std::cout typeid(a).name() std::endl;
}
GCC 4.6.1 output is:
N2my7addressINS_3varIi
which indicates that there is no ref applied to var in instantiation of
address. Visual C++ 10 and 11 produce:
struct my::addressstruct my::refstruct my::varint
which have ref in between and is what I was actually expecting to have.
If I move the definition of overloaded operator after the second namespace my
is closed, the ref does properly appear on top of the var.
Can you please have a look at this?
Thank you!
[Bug c++/55460] Template-dependent name is not looked up at instantiation point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55460 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-25 00:49:05 UTC --- // NOTE: call to filter depends on template argument, thus have to be // resolved at instantiation point. // BUG: But it doesn't! I don't think this is true if it was using ADL, then it would be true but there is no ADL here so it only depends on the overloaded set that is done at the definition time.
[Bug c++/55460] Template-dependent name is not looked up at instantiation point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55460 --- Comment #2 from Yuriy Solodkyy solodon at mail dot com 2012-11-25 01:07:36 UTC --- Not sure I understand your comment - ADL with respect to what: my::filter or the ::operator? Can you elaborate please?
[Bug c++/55460] Template-dependent name is not looked up at instantiation point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55460 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-25 01:56:20 UTC --- (In reply to comment #2) Not sure I understand your comment - ADL with respect to what: my::filter or the ::operator? Can you elaborate please? With respect to my::filter. Since it is a qualified name, the overloaded set is only considered at definition time rather than instantiation too.
[Bug target/55461] New: _mm_loadu_si128 generates wrong instruction on 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
Bug #: 55461
Summary: _mm_loadu_si128 generates wrong instruction on 4.8
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org
Following test case compiled with -Os -msse4.2 generates with 4.8:
.L3:
movups (%rdi), %xmm0 --- wrong data type, should
be movupd
pcmpistrm $24, (%rdi,%rsi), %xmm0
jna .L2
addq$16, %rdi
jmp .L3
4.7 gives the correct (although it makes a mess out of the loop):
L3:
movdqu (%rdi,%rsi), %xmm1
movdqu (%rdi), %xmm2
pcmpistrm $24, %xmm1, %xmm2
jna .L2
addq$16, %rdi
jmp .L3
A simpler test case gives the correct movupd, so it must be related to the
funky pointer arithmetic the test case does. But in any case it should not turn
an integer vector into a float vector
#include nmmintrin.h
int c_strcmp(char *a, char *b)
{
unsigned long diff = (unsigned long)b - (unsigned long)a;
int r = 16;
a -= r;
for (;;) {
if (_mm_cmpistra(_mm_loadu_si128((__m128i *)a),
_mm_loadu_si128((__m128i *)((unsigned long)a +
diff)),
0x18)) {
a += r;
continue;
}
/* check C here */
return 0;
}
return 0;
}
[Bug bootstrap/54795] [4.8 Regression] LTO miscompiled external array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #21 from H.J. Lu hjl.tools at gmail dot com 2012-11-25 07:33:50 UTC --- This was introduced between revision 191465 and revision 191714.
