Thanks to Steve Ellcey for having asked the question I did not care (dare)
to ask and to those who answered.
> So please use contrib/test_installed
This script seems quite outdated: it tests g77 and not gfortran, even with
the latest 4.3.0 snapshot (20070112). As I was primarily interested in
Hi,
i'd like to ask the help of the list in clarifying a new warning in
mainline. Let's assume x86-linux (so 32-bits, signed wchar_t, etc...)
For this snipped I get a new warning:
int main()
{
wchar_t wc = ((wchar_t)1 << 31) - 1;
return ((int)1 << 31) - 1;
}
warning.cc:3: warning: overfl
Paolo Carlini wrote:
In particular, what's the difference between line 3 and line 4? ...
Sorry, please disregard my message: I was inadvertently using an old
compiler (2007-01-06)
Paolo.
Bob Rossi wrote:
> On Sun, Jan 14, 2007 at 12:16:32AM -0500, Andrew Pinski wrote:
>>> Hi,
>>>
>>> Will g++ ever add a compile time enforcement of the exception
>>> specification like the Java compiler does?
>>>
>>> I find the exception specification almost useless with out this
>>> functionality.
>
On 14/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Paolo Carlini wrote:
> In particular, what's the difference between line 3 and line 4? ...
Sorry, please disregard my message: I was inadvertently using an old
compiler (2007-01-06)
So now you are getting both warning messages?
I don't u
James Dennett wrote:
There has been much debate, and a large fraction of those
involved feel that static checking of exceptions in C++ is
*not* an improvement from the current situation. There
has also been much written on the weaknesses of the Java
approach.
Note: I'm not expressing my person
Manuel López-Ibáñez wrote:
Sorry, please disregard my message: I was inadvertently using an old
compiler (2007-01-06)
So now you are getting both warning messages?
Definitely I'm getting both:
warning.cc: In function 'int main()':
warning.cc:3: warning: integer overflow in expression
warnin
On 14/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote:
>
> So now you are getting both warning messages?
Definitely I'm getting both:
warning.cc: In function 'int main()':
warning.cc:3: warning: integer overflow in expression
warning.cc:3: warning: overflow in implici
Manuel López-Ibáñez wrote:
You are getting two overflow warnings for the same expression? That
should not happen (TM). The TREE_OVERFLOW bit should have been noticed
and prevent giving another warning. Roger, do you agree on this?
Paolo, would you mind opening a bug report for this? I will look
On 14/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Manuel López-Ibáñez wrote:
> You are getting two overflow warnings for the same expression? That
> should not happen (TM). The TREE_OVERFLOW bit should have been noticed
> and prevent giving another warning. Roger, do you agree on this?
>
> P
Manuel López-Ibáñez wrote:
Sure. In fact, I was scratching my head about that. To be honest, I'm
still not completely acquainted with the new warning (and I'm
particularly interested because -Wsystem-headers triggers quite a few
from the library...)
New? Woverflow is not new, as far as I know,
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
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
Paolo Carlini wrote:
New? Woverflow is not new, as far as I know, if was just a bit broken,
especially in C++. But in these cases in particular, nothing should
have changed since we branched 4.2.
Well, certainly new wrt 4_1-branch, the last release branch...
By the way, "new" also wrt curren
At the risk of wading in too deep... there is one aspect of exception
specification checking that I've become absolutely convinced would
benefit greatly from static checking:
A::~A() static throw(); // or whatever syntax
That is, there is some code that you know should not throw anything,
On Jan 13, 2007, at 6:13 AM, Jack Howarth wrote:
Do the Darwin gcc developers ever intend to replicate the use of
fat binaries for FSF gcc (in gcc 4.3 perhaps) or will we always use
separate subdirectories for 32-bit and 64-bit shared libraries?
I'd be curious to hear what people might say,
Snapshot gcc-4.0-20070114 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20070114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
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, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Paolo Carlini wrote:
>> New? Woverflow is not new, as far as I know, if was just a bit broken,
>> especially in C++. But in these cases in particular, nothing should
>> have changed since we branched 4.2.
>
> Well, certainly new wrt 4_1-branc
Manuel López-Ibáñez wrote:
By the way, "new" also wrt current 4_2-branch, in the sense that the
latter doesn't emit *any* overflow warning for the snippet in 30465,
with explicit -Wconversion too...
And it does with Wconversion? Wconversion should not emit any overflow
warning, that is respons
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 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
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 Fri, 12 Jan 2007, Nick Clifton wrote:
> What do you think ?
I like this idea. (Not the least because it will help verify
answers/questions that are coming up regularily among users and
in discussions on the gcc lists even.)
Gerald
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,
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
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
On Mon, 8 Jan 2007, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has appointed
> Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port.
That's good timing. ;-)
i386 (but not i686) has started failing to bootstrap a few days ago
-- bootstrap/30467.
Ge
Hi Manuel and Paolo,
On Sun, January 14, 2007 3:59 pm, Paolo Carlini wrote:
>>> By the way, "new" also wrt current 4_2-branch, in the sense that the
>>> latter doesn't emit *any* overflow warning for the snippet in 30465,
>>> with explicit -Wconversion too...
I think I can explain everything. T
30 matches
Mail list logo
