Compiling this simple C++ program with 4.3 or 4.4: #include <stddef.h> const char* foo() { return new char[~static_cast<size_t>(0)]; } gives this warning: foo.cc: In function ‘const char* foo()’: foo.cc:2: warning: large integer implicitly truncated to unsigned type The warning is bogus: there is no truncation here. It would be reasonable to give a warning that the new would fail, but the warning it actually gives is simply wrong. I haven't looked into this much, but it seems to be related to sizetype. 4.1 gives no warning. I don't have 4.2 handy.
This is another sizetype issue.
Confirmed.
Created attachment 16058 [details] primary candidate fix This minimal patch fixes the problem for me and regtests on x86_64. I have some questions though and would like to have you guys comments, if possible. My understanding is that the parameter of the new operator being size_t, its type should represented in GENERIC using an integer that is not signed. The issue here is that the type of the parameter of the new operator has the same time as 'sizetype', which has its flag TYPE_IS_SIZETYPE set. When TYPE_IS_SIZETYPE is set on an integer, some type checking machinery consider that integer to be signed. So the the representation of that integer is sign extended. So a quick fix was to make sure the type of the parameter of the new operator has the same time as 'size_type_node', instead of 'sizetype'. Maybe there is a better way of solving this. Also, maybe I should modify the other uses of 'sizetype' in the build_new_1() function and replace them with "size_type_node' instead. But that's maybe out of the strict scope of this bug. I am not sure.
Created attachment 16060 [details] second fix candidate This patch should be better than the previous one because it one must use size_binop() with a sizetype integer, not with a size_type_node one. regtested on x86_64.
Created attachment 16074 [details] third fix candidate This patch tries another approach. Basically it changes the low level function (shared with the C front-end) that tests if an integer value fits within a given type. It provides a special casing for integers of type sizetype.
(In reply to comment #5) > Created an attachment (id=16074) [edit] > third fix candidate > > This patch tries another approach. Patches go to gcc-patches@.
Manuel, yes I know that patches go to gcc-patches@ :-) I am stacking these here to not loose them, but at the same time, I am not sure if they are solid enough for submission to gcc-patches. I am still working on them. I will submit a patch to gcc-patches when I fill a bit more confident :-)
Created attachment 16083 [details] Fourth fix candidate The previous patch was broken for say cross-compilers addressing a 64 target on a 32 bits host. I hope this one is better. Bootstrapped and regtested on x86_64.
(In reply to comment #7) > > I am stacking these here to not loose them, but at the same time, I am not sure > if they are solid enough for submission to gcc-patches. I am still working on > them. s/loose/lose/ OK but if you are expecting comments you should send the patch to gcc-patches. If they bootstrap+regtest they are solid enough to get comments in gcc-patches. ;-) > I will submit a patch to gcc-patches when I fill a bit more confident :-) s/fill/feel/ Do as you please but gcc-patches is where you will get the highest visibility. Just say that you are asking for comments [RFC] or help [RFH] and be clear that you are unsure about your approach. This will give reviewers a hint that they must be extra-careful. Plus, you can ask for extra testing in different machines.
Created attachment 16097 [details] 5th patch This patch makes sure the integer type used in the conversion to a zero extended unsigned integral has a precision that is high enough. regtested on x86_64.
Created attachment 16108 [details] 6th patch Another refinement.
Created attachment 16117 [details] 7th patch Another iteration :-)
Created attachment 16131 [details] 8th version
4.3.2 is released, changing milestones to 4.3.3.
Subject: Bug 36741 Author: dodji Date: Thu Aug 28 14:49:25 2008 New Revision: 139711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139711 Log: 2008-08-28 Dodji Seketeli <dodji@redhat.com> PR c++/36741 * tree.c (int_fits_type_p): Don't forget unsigned integers of type sizetype which higher end word equals -1. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/new-size-type.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree.c
Subject: Bug 36741 Author: dodji Date: Thu Aug 28 14:49:48 2008 New Revision: 139712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139712 Log: 2008-08-28 Dodji Seketeli <dodji@redhat.com> PR c++/36741 * tree.c (int_fits_type_p): Don't forget unsigned integers of type sizetype which higher end word equals -1. Added: trunk/gcc/testsuite/g++.dg/other/new-size-type.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
Subject: Re: [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new 2008/8/28 dodji at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org>: > Log: > 2008-08-28 Dodji Seketeli <dodji@redhat.com> > > PR c++/36741 > * tree.c (int_fits_type_p): Don't forget unsigned integers > of type sizetype which higher end word equals -1. > > > Added: > trunk/gcc/testsuite/g++.dg/other/new-size-type.C You forgot to mention this file in the commit log. Please rectify the log. Thanks Manuel.
Fixed in trunk and gcc-4_3-branch.
The patch for this bug significantly degrades PowerPC performance.
Hello, It would be nice to provide a testcase that could help reproduce the performance degradation easily. Moreoever, I don't have access to a ppc box yet. How could I have that ?
At least for the branch I'd very much prefer the second candidate patch, which is much less intrusive.
Created attachment 16341 [details] gcc44-pr36741.patch Only lightly tested patch that reverts the tree.c change and instead does size computation in build_new_1 in size_t instead of sizetype.