[Bug c++/36741] New: [4.3,4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[Bug c++/36741] New: [4.3,4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[ian at airs dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

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.


-- 
           Summary: [4.3,4.4 regression] Bogus "large integer implicitly
                    truncated" passing size_t constant to new
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-07-07 02:53 -------
This is another sizetype issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
            Summary|[4.3,4.4 regression] Bogus  |[4.3/4.4 regression] Bogus
                   |"large integer implicitly   |"large integer implicitly
                   |truncated" passing size_t   |truncated" passing size_t
                   |constant to new             |constant to new
   Target Milestone|---                         |4.3.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-07-10 14:24 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P3                          |P2
   Last reconfirmed|0000-00-00 00:00:00         |2008-07-10 14:24:55
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-07-10 14:24:55         |2008-08-12 13:25:52
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #3 from dodji at gcc dot gnu dot org  2008-08-12 14:42 -------
Created an attachment (id=16058)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16058&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #4 from dodji at gcc dot gnu dot org  2008-08-12 16:10 -------
Created an attachment (id=16060)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16060&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16058|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #5 from dodji at gcc dot gnu dot org  2008-08-14 16:06 -------
Created an attachment (id=16074)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16074&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2008-08-15 20:16 -------
(In reply to comment #5)
> Created an attachment (id=16074)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16074&action=view) [edit]
> third fix candidate
> 
> This patch tries another approach.

Patches go to gcc-patches@. 


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #7 from dodji at gcc dot gnu dot org  2008-08-18 15:47 -------
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 :-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #8 from dodji at gcc dot gnu dot org  2008-08-18 15:52 -------
Created an attachment (id=16083)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16083&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16074|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[manu at gcc dot gnu dot org]

------- Comment #9 from manu at gcc dot gnu dot org  2008-08-18 16:03 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #10 from dodji at gcc dot gnu dot org  2008-08-19 11:00 -------
Created an attachment (id=16097)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16097&action=view)
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.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16060|0                           |1
        is obsolete|                            |
  Attachment #16083|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #11 from dodji at gcc dot gnu dot org  2008-08-20 12:33 -------
Created an attachment (id=16108)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16108&action=view)
6th patch

Another refinement.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16097|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #12 from dodji at gcc dot gnu dot org  2008-08-20 19:18 -------
Created an attachment (id=16117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16117&action=view)
7th patch

Another iteration :-)


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16108|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #13 from dodji at gcc dot gnu dot org  2008-08-22 17:34 -------
Created an attachment (id=16131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16131&action=view)
8th version


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16117|0                           |1
        is obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[jsm28 at gcc dot gnu dot org]

------- Comment #14 from jsm28 at gcc dot gnu dot org  2008-08-27 22:05 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #16 from dodji at gcc dot gnu dot org  2008-08-28 14:51 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #15 from dodji at gcc dot gnu dot org  2008-08-28 14:50 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[lopezibanez at gmail dot com]

------- Comment #17 from lopezibanez at gmail dot com  2008-08-28 14:56 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #18 from dodji at gcc dot gnu dot org  2008-08-28 15:29 -------
Fixed in trunk and gcc-4_3-branch.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dje at gcc dot gnu dot org]

------- Comment #19 from dje at gcc dot gnu dot org  2008-09-04 20:25 -------
The patch for this bug significantly degrades PowerPC performance.


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[dodji at gcc dot gnu dot org]

------- Comment #20 from dodji at gcc dot gnu dot org  2008-09-04 20:42 -------
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 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2008-09-16 11:50 -------
At least for the branch I'd very much prefer the second candidate patch, which
is much less intrusive.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741

[Bug c++/36741] [4.3/4.4 regression] Bogus "large integer implicitly truncated" passing size_t constant to new

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2008-09-16 22:59 -------
Created an attachment (id=16341)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16341&action=view)
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741