On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > [...]
| >
| > | > As the PR you noted, it wasn't part of C++.
| > | >
| > |
| > | You are wrong.
| >
| > "the PR you noted" is
| >
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
[...]
| > As the PR you noted, it wasn't part of C++.
| >
|
| You are wrong.
"the PR you noted" is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
which you described as your favo
On Thu, 18 Jan 2007, Robert Dewar wrote:
| Gabriel Dos Reis wrote:
|
| > The pragma thing will be fixed; however, we will still be left with
| > unhelful warning for what has become idiomatic because of the way C++
| > tends to see sequences.
|
| In Ada, we changed things a while ago to give warni
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I just felt that the conversation was going in the direction of "we
| should shut the warnings of Wconversion up because people using it
| will get warnings for libstdc++".
I'm afraid you did not read the conversation carefully.
-- Gaby
Gabriel Dos Reis wrote:
The pragma thing will be fixed; however, we will still be left with
unhelful warning for what has become idiomatic because of the way C++
tends to see sequences.
In Ada, we changed things a while ago to give warnings ONLY on the
extended main unit being compiled, and no
On Thu, 18 Jan 2007, Paolo Carlini wrote:
| Manuel --
|
| > I read it and still don't get it. We know we should not warn about
| > system headers but we do and that is a known bug. So again, why is
| > libstdc++ using Wconversion at all?
|
| I appreciate your help with this issue, and I'm confiden
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
[...]
| > As the PR you noted, it wasn't part of C++.
| >
|
| You are wrong.
"the PR you noted" is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
which you described as your favorite. The PR starts with this
gcc reports the signedne
On 18/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Manuel --
> I read it and still don't get it. We know we should not warn about
> system headers but we do and that is a known bug. So again, why is
> libstdc++ using Wconversion at all?
I appreciate your help with this issue, and I'm confide
Manuel --
I read it and still don't get it. We know we should not warn about
system headers but we do and that is a known bug. So again, why is
libstdc++ using Wconversion at all?
I appreciate your help with this issue, and I'm confident that we'll
soon converge to a nice solution. Thanks, re
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes
On Wed, 17 Jan 2007, Andrew Pinski wrote:
| >
| > One use of -Wconversion is to draw attention to
| >
| >int x = 2.3; // warning: be careful, is this what you want?
| > // this is a potential bug as it is value altering.
| >
| > and in an upcoming revision to C++, it is ver
>
> One use of -Wconversion is to draw attention to
>
>int x = 2.3; // warning: be careful, is this what you want?
> // this is a potential bug as it is value altering.
>
> and in an upcoming revision to C++, it is very likely that implicit
> conversion that may lose info
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes.
| >
|
| Then, why Wconversion has warned about it at leas
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| Does that apply also to:
|
| unsigned int y = -10;
Yes.
Then, why Wconversion has warned about it at least since
http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11 ?
Moreover, mo
On Thu, 18 Jan 2007, Joseph S. Myers wrote:
[...]
| > Furthermore, elsewhere (in the overflow thread) it has been suggested
| > that people should convert to the unsigned variants, do computations there,
| > and convert back to the signed variants. We have just promised an
| > invariant that we
On Wed, 17 Jan 2007, Gabriel Dos Reis wrote:
> The specific cases I'm concerned about here (and if you have a chance
> to build firefox for example, you'll see) is when T and U differ only
> in signedness, that is
>
>T = int, U = unsigned
>T = long, U = unsigned long
>T = long long, U
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > | > ... thanks a lot Gaby both for your practical and theoretical
| > |
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > ... thanks a lot Gaby both for your practical and theoretical
| > investigations into this issue, both right to the point! Now, in
On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > ... thanks a lot Gaby both for your practical and theoretical
| > investigations into this issue, both right to the point! Now, in my
| > opinion, we should simply remove the bits about sign
On 17/01/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
I agree this warning is of questionable use and should be not enabled
with -Wall.
But... -Wconversion is not enabled by -Wall! It is not even enabled by
Wextra! It is only enabled by -Wconversion.
Getting confused,
Manuel.
On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
... thanks a lot Gaby both for your practical and theoretical
investigations into this issue, both right to the point! Now, in my
opinion, we should simply remove the bits about signed -> unsigned from
-Wconversion.
I am not sure I am follo
I wrote:
> | Careful. As you suggest, let's restrict ourselves to two's complement
> | platforms. I would want the compiler to warn if the identity holds for an
> | ILP32 machine but not an LP64 machine, even if I'm running on an ILP32.
> | But if the two types are going to be the same size ever
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
| > I just built firefox (CVS) with GCC mainline. The compiler spitted
| > avalanches of non-sensical warning about conversions signed ->
| > unsigned may alter values, when in fact the compil
Joe Buck wrote:
Careful. As you suggest, let's restrict ourselves to two's complement
platforms. I would want the compiler to warn if the identity holds for an
ILP32 machine but not an LP64 machine, even if I'm running on an ILP32.
But if the two types are going to be the same size everywhere
On Wed, 17 Jan 2007, Richard Guenther wrote:
| On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Paolo Carlini <[EMAIL PROTECTED]> writes:
| >
| > | Joe Buck wrote:
| > |
| > | >In the case of the containers, we are asserting/relying on the fact that
| > | >the pointer
On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
> I just built firefox (CVS) with GCC mainline. The compiler spitted
> avalanches of non-sensical warning about conversions signed ->
> unsigned may alter values, when in fact the compiler knows that
> such things cannot happen.
>
... thanks a lot Gaby both for your practical and theoretical
investigations into this issue, both right to the point! Now, in my
opinion, we should simply remove the bits about signed -> unsigned from
-Wconversion.
Paolo.
On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread idiom: people write their own code in the STL style. If STL
| >code now ha
Gabriel Dos Reis wrote:
The system_header pragma + template issue is separate, and I thought
it was resolved a long time ago -- apparently no. It is related to
our failure to copy a bit from a template _DECL.
Thanks, can you look a bit more into it?
Paolo.
On Mon, 15 Jan 2007, Paolo Carlini wrote:
| About the library itself, I'm also concerned by the weakness of our
| pragma system_header vs templates, which makes the whole warning game
| always very dangerous...
The system_header pragma + template issue is separate, and I thought
it was resolved a
Joe Buck wrote:
In the case of the containers, we are asserting/relying on the fact that
the pointer difference is zero or positive. But this has become a
widespread idiom: people write their own code in the STL style. If STL
code now has to be fixed to silence warnings, so will a lot of user
On Mon, Jan 15, 2007 at 10:24:40AM -0600, Gabriel Dos Reis wrote:
> Paolo Carlini <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Let's wait a bit more for other opinions, say one day or two, then I
> | will start the actual work. As far as I can see, other compilers do
> | not warn in such cases, an
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| In summary, for v3, one possibility could be combining the two
| quantities, consistently for all the containers, thus, essentially,
| compute container::max_size as min(allocator::max_size,
| numeric_limits::max) (all the computations modulo
| si
Paolo Carlini wrote:
So, yes, you can add the casts as a temporary work-around.
By the way, probably now I see why you consider the two issues related
and (some) casts temporary: in the case of vector, for example (not in
the case of deque) we are currently using in many places size_type,
w
Gabriel Dos Reis wrote:
| However, in order not to mix different issues, I think we should try
| first to resolve the much more limited issue at hand, which, I note,
| has to do with *deallocation*, not with *allocation*.
By the time we deallocate, any possible damage has already be done :-)
So
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| >My concern is for vectors whose size() exceeds
| > numeric_limits::max() -- even if we would like to
| > avoid the general discussion. My understanding -- and I would like
| > to hear of others' -- is that the
| >semantics description in the tab
Gabriel Dos Reis wrote:
| Coming to the specific issue, and *assuming* we agree about the
| usefulness of warning for signed -> unsigned, maybe we are "lucky", in
| this sense: Table 65 says *explicitely* that size_type can represent
| any non-negative value of difference_type. Thus, as I see th
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I vote against adding Wconversion to Wall before 4.3 is branched.
We are not in voting mode yet :-)
-- Gaby
On 15/01/07, Martin Sebor <[EMAIL PROTECTED]> wrote:
Paolo Carlini wrote:
>
> Anyway, note that our -Wconversion is not part of -Wall, not even
> -Wextra: are you maintaining that probably the bits having to do with
> float <-> integer should also be part of -Wall or at least -Wextra?
We use bot
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gaby,
|
| >There is something that we knoq about the code, that the compiler
| >does not have: we expect a sequence denoted by its first and last
| >element, so that the difference is always positive. However, the
| >difference of pointers is define
Paolo Carlini wrote:
Martin Sebor wrote:
FYI: HP aCC warns for some but not all of these types of lossy
initializations. For example, a double to int conversion emits
a warning but ptrdiff_t to size_t or other signed to unsigned
conversions do not, probably because they're so common. I find
thi
Hi Gaby,
There is something that we knoq about the code, that the compiler
does not have: we expect a sequence denoted by its first and last
element, so that the difference is always positive. However, the
difference of pointers is defined in the language as an ptrdiff_t (a
signed type). No wo
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| Let's wait a bit more for other opinions, say one day or two, then I
| will start the actual work. As far as I can see, other compilers do
| not warn in such cases, and adding casts (*) isn't the cleanest
| practice in the world, thus my caution..
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Manuel,
|
| >> in a nutshell, what is happening is that a difference of two pointers is
| >> assigned to an unsigned variable. First blush, the warning seems to me a
| >> bit overzealous, but if we concur that this is what we *really* want for
| >> 4
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gerald,
|
| >I noticed that -Wconversion now issues warnings in libstdc++.
| >
| in a nutshell, what is happening is that a difference of two pointers
| is assigned to an unsigned variable. First blush, the warning seems to
| me a bit overzealous, bu
Martin Sebor wrote:
FYI: HP aCC warns for some but not all of these types of lossy
initializations. For example, a double to int conversion emits
a warning but ptrdiff_t to size_t or other signed to unsigned
conversions do not, probably because they're so common. I find
this behavior useful.
T
Paolo Carlini wrote:
[...]
Let's wait a bit more for other opinions, say one day or two, then I
will start the actual work. As far as I can see, other compilers do not
warn in such cases, and adding casts (*) isn't the cleanest practice in
the world, thus my caution...
FYI: HP aCC warns for s
Gerald Pfeifer wrote:
On Mon, 15 Jan 2007, Paolo Carlini wrote:
All in all, I think we can definitely add casts to the library, would be only
a few tens of lines worth of patch, I think. Whether the warning is useful to
the entire GCC community, I cannot say... But I hope we can resolve the
On Mon, 15 Jan 2007, Paolo Carlini wrote:
> All in all, I think we can definitely add casts to the library, would be only
> a few tens of lines worth of patch, I think. Whether the warning is useful to
> the entire GCC community, I cannot say... But I hope we can resolve the issue
> rather quickly,
Manuel López-Ibáñez wrote:
The casts should avoid the warnings and using Wno-conversion also.
To be clear: we *cannot* ask the users to avoid Wconversion with the
library or whatever other warning only because our pragma system header
is weak with templates, or the compiler overzealous. I ag
On 14/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi Manuel,
Well, just have a look to Gerald' examples: it's old HP / SGI STL code,
we are assigning / initializing a size_t from a pointer difference, or
arithmetic, more generally. There are quite a few instances of the
issue, beyond that p
Hi Manuel,
in a nutshell, what is happening is that a difference of two pointers is
assigned to an unsigned variable. First blush, the warning seems to me a
bit overzealous, but if we concur that this is what we *really* want for
4.3, we can change the affected (very old, indeed) lines of code,
On 14/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi Gerald,
>I noticed that -Wconversion now issues warnings in libstdc++.
>
>
in a nutshell, what is happening is that a difference of two pointers is
assigned to an unsigned variable. First blush, the warning seems to me a
bit overzealous, b
On 14/01/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
I noticed that -Wconversion now issues warnings in libstdc++.
The purpose of Wconversion has changed. You can know more about it here:
http://gcc.gnu.org/wiki/NewWconversion
For now I have opened two bug reports, and I plan to continue t
Hi Gerald,
I noticed that -Wconversion now issues warnings in libstdc++.
in a nutshell, what is happening is that a difference of two pointers is
assigned to an unsigned variable. First blush, the warning seems to me a
bit overzealous, but if we concur that this is what we *really* want for
I noticed that -Wconversion now issues warnings in libstdc++.
For now I have opened two bug reports, and I plan to continue testing and
file further bug reports once these have been fixed but I wonder if anyone
plans to do a more systemastic set of checks?
libstdc++/30463 [regression] -Wconve
57 matches
Mail list logo
