Re: Running GCC tests on installed compiler
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 the gfortran tests, I replaced g77 by gfortran everywhere (keeping the different capitalizations) and it worked. The script also ignores java tests. I looked again to the manual (http://gcc.gnu.org/install/test.html) and did not find this script documented anywhere. Am I missing something or is this a place where the manual can be improved? Note that I am installing gcc on Mac OSX/PPC through a fink script that does not keep the building directory, so my choices are either to make further changes to the script to include the appropriate "make check" (this will increase both the building time by several hours and the risk of failure after several hours) or to do a postinstall check (my choice, unless someone offers a better solution). Cheers Dominique
Unsure about a new warning in mainline
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: overflow in implicit constant conversion
In particular, what's the difference between line 3 and line 4? I'm
asking also because "another" compiler issues both:
warning.cc(3): warning #61: integer operation result is out of range
wchar_t wc = ((wchar_t)1 << 31) - 1;
^
warning.cc(4): warning #61: integer operation result is out of range
return ((wchar_t)1 << 31) - 1;
Thanks in advance,
Paolo.
Re: Unsure about a new warning in mainline
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.
Re: compile time enforcement of exception specification
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. >> The C++ standard ( 15.4/10) is very specific that the implemantion should >> not >> reject code just because of exception specification and calling other >> functions. > > Do you have a link to the standard some where? > > Will g++ not implement compile time enforcement until a standard says > it's OK to do so? This feature is obviously an improvement over doing > nothing. 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 personal opinion above on static vs. dynamic checking. Just noting that what you feel is "obviously an improvement" is controversial. > Wouldn't an option to g++ be only helpful here? Possibly to some people, but it would also be rather hard to specify and implement. Even Java ducked and made many exceptions unchecked. My feeling is that there's not much chance of seeing statically enforced ES in standard C++ anytime soon (not within the next decade, and probably never), and that its value doesn't match the specification, design, implementation, testing and documentation costs. -- James
Re: Unsure about a new warning in mainline
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 understand why anything should have changed. Perhaps the TREE_CONSTANT_OVERFLOW changes or my changes broke something for a while...
Re: compile time enforcement of exception specification
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 personal opinion above on static vs. dynamic checking. Just noting that what you feel is "obviously an improvement" is controversial. It is interesting to note that Ada, a language that implemented exception handling back in the early 80's, debated this issue and also decided that it was undesirable to introduce this feature. Probably it could make good sense in a small subset of one of these languages, but in the full language context it is dubious. Wouldn't an option to g++ be only helpful here? I think it would be inadvisable, g++ should not be in the business of second guessing well discussed language design decisions and generating variants by introducing features unlikely to ever be accepted by the standard.
Re: Unsure about a new warning in mainline
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 warning.cc:3: warning: overflow in implicit constant conversion warning.cc:4: warning: integer overflow in expression I don't understand why anything should have changed. Perhaps the TREE_CONSTANT_OVERFLOW changes or my changes broke something for a while... I don't know. I'm pretty sure I can exclude local changes... Thanks, Paolo.
Re: Unsure about a new warning in mainline
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 implicit constant conversion warning.cc:4: warning: integer overflow in expression 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 at it as soon as I can. Thanks, Manuel.
Re: Unsure about a new warning in mainline
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 at it as soon as I can. 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...) Paolo.
Re: Unsure about a new warning in mainline
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? > > Paolo, would you mind opening a bug report for this? I will look at it > as soon as I can. 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, if was just a bit broken, especially in C++. But in these cases in particular, nothing should have changed since we branched 4.2. Let me know the PR number please. Thanks, Manuel.
Re: Unsure about a new warning in mainline
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, 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... Let me know the PR number please. other/30465, thanks! Paolo.
-Wconversion versus libstdc++
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] -Wconversion triggers warnings for vector<>::push_back() libstdc++/30464 [regression] -Wconversion triggers warnings for deque<>::push_back() Technically, libstdc++ did not regress. However, from a user perspective this really are regressions, not the least as we make break -Werror builds due to these issues in our own libraries. There may be similar issues with some of the other warnings added or improved recently. Gerald
Re: -Wconversion versus libstdc++
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 4.3, we can change the affected (very old, indeed) lines of code, no problem at all. Thanks, Paolo.
Re: Unsure about a new warning in mainline
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 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... Paolo.
Re: compile time enforcement of exception specification
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,
and it would be most helpful if one could get compiler help on that.
If it throws an exception, it really doesn't matter what it throws.
If it doesn't throw an exception, that is a crucial property to
writing code with known exception safety guarantees (basic, strong,
nothrow).
If I write something like a destructor, move constructor or copy
constructor with an empty throw spec, it isn't because I want
unexpected() to be called just in case some exception is called. It
is because I want to broadcast that this function can't fail. But
that's not what C++ says an empty throw spec means.
For some code, it is essential that it have a "no fail" property.
That includes C++ destructors and "finally clauses" in other
languages. Automated help in this department would be incredibly
valuable. Being alerted that code you thought was nothrow has
suddenly become throwing because of a remote change in some function
you're calling would greatly aid robustness (much like const
correctness does today). Otoh if some remote function changes from
throwing X to throwing Y, that's really not going to impact the
client's fundamental design (though it is an API-breaking change).
In a nutshell, if I write:
struct A
{
int data_;
int get_data() const static throw() {return data_;} // or
whatever syntax for throw()
};
I'd like a diagnostic if get_data() generates code to call
std::unexpected().
-Howard
Re: fat binaries for FSF gcc on Darwin?
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, pro or con about this... I'm not wedded to either approach. I do know if mpfr and gmp built fat and installed that way, that I wouldn't have to configure with the, please select the 32 bit abi option. :-(
gcc-4.0-20070114 is now available
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/gcc-4_0-branch revision 120783 You'll find: gcc-4.0-20070114.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20070114.tar.bz2 C front end and core compiler gcc-ada-4.0-20070114.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20070114.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20070114.tar.bz2 C++ front end and runtime gcc-java-4.0-20070114.tar.bz2 Java front end and runtime gcc-objc-4.0-20070114.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20070114.tar.bz2The GCC testsuite Diffs from 4.0-20070107 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: -Wconversion versus libstdc++
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 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] -Wconversion triggers warnings for vector<>::push_back() libstdc++/30464 [regression] -Wconversion triggers warnings for deque<>::push_back() Thanks, please do it, and add me ([EMAIL PROTECTED]) to the CC list. Wconversion is new in GCC 4.3 and it hasn't been fully merge yet. Patches pending review are: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00799.html http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01508.html So testing and fine-tuning is needed (even more, since this is my first GCC project ever). Technically, libstdc++ did not regress. However, from a user perspective this really are regressions, not the least as we make break -Werror builds due to these issues in our own libraries. I was afraid something like that was going to happen. People have been using (the old) Wconversion without really bothering to read the manual. Even worse, they found quite interesting its undocumented warnings, so they recommended using it. Initially I proposed using a new name (Wcoercion) and keep the old Wconversion as it was. However, it was decided to rename the old Wconversion to Wconversion-traditional and put the new functionality in Wconversion. (There is no info yet on GCC 4.3 changes because there are patches pending review, I have a patch ready to document the changes that depends on which changes are finally implemented). There may be similar issues with some of the other warnings added or improved recently. Wextra is being modified at the moment, so watch also for that. Cheers, Manuel.
Re: -Wconversion versus libstdc++
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, 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, no problem at all. Hi Paolo, Wconversion is supposed to warn for conversions that may change a value. Can the resulting value change when converted to unsigned? If so, the warning is warranted (I think). Anyhow, Wconversion needs fine-tuning and I prefer for it to be useful rather than to literally follow its definition, so if this operation is quite frequent and safe, I could detect it and avoid the warning. I am no GCC or C++ expert, so please give me more information on the issue and feedback from others would be appreciated. Cheers, Manuel.
Re: Unsure about a new warning in mainline
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-branch, the last release branch... 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 responsibility of Woverflow. I will investigate and report back. If you find more cases or issues, please add [EMAIL PROTECTED] to the CC list of the PR. Cheers, Manuel
Re: Unsure about a new warning in mainline
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 responsibility of Woverflow. Of course I meant -Woverflow, just a typo, sorry. In short, in my limited experience, there is no way to convince either 4.1 or 4.2 to emit such warnings for that snippet (on the other hand, current 4.3 emits *two*) Paolo.
Re: -Wconversion versus libstdc++
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, no problem at all. Hi Paolo, Wconversion is supposed to warn for conversions that may change a value. Can the resulting value change when converted to unsigned? If so, the warning is warranted (I think). Anyhow, Wconversion needs fine-tuning and I prefer for it to be useful rather than to literally follow its definition, so if this operation is quite frequent and safe, I could detect it and avoid the warning. I am no GCC or C++ expert, so please give me more information on the issue and feedback from others would be appreciated. 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 pointed out by Gerald. Certainly, the HP / SGI engineers considered those assignment harmless, and I respect that kind of assessment, but on the other hand, at the time the compilers were probably weaker at warning, I'm not sure. 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, because, in case, I'd like to start the audit of the library as soon as possible and be done with the issue as far as we are concerned... Thanks, Paolo. PS: well, the issue reminds me the hyper-super-long-standing issue that pragma system headers doesn't suppress warnings from templates: as we can see, this behavior can be really annoying... probably also very hard to change, if I remember correctly... ;-/
Re: -Wconversion versus libstdc++
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 pointed out by Gerald. Certainly, the HP / SGI engineers considered those assignment harmless, and I respect that kind of assessment, but on the other hand, at the time the compilers were probably weaker at warning, I'm not sure. :-( But I need a reason to avoid warning and a way to detect that the implicit conversion is harmless. For example, someone may think that int i = 1.2 is harmless in their code but the whole point of Wconversion is to warn about this. I cannot help you without some help... 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, because, in case, I'd like to start the audit of the library as soon as possible and be done with the issue as far as we are concerned... The casts should avoid the warnings and using Wno-conversion also. But still I would like to solve the issue, if there is one, rather than work-around it. Cheers, Manuel.
Re: -Wconversion versus libstdc++
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 agree that we need a clean resolution of the issue. Paolo.
Re: RFC: Extending --help
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
Re: -Wconversion versus libstdc++
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, because, in case, I'd like to start the audit of the library > as soon as possible and be done with the issue as far as we are concerned... Would it make sense to add these case in any case, regardless of what we are going to do about the warning? (My rationale is that this would document that we are aware of the potential issue there and our assessment showed that this particular use is safe. But I may be wrong here...) Gerald
Re: -Wconversion versus libstdc++
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 issue rather quickly, because, in case, I'd like to start the audit of the library as soon as possible and be done with the issue as far as we are concerned... Would it make sense to add these case in any case, regardless of what we are going to do about the warning? (My rationale is that this would document that we are aware of the potential issue there and our assessment showed that this particular use is safe. But I may be wrong here...) Personally, I agree. 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. (*) Before someone asks, a cursory look at the code reveals that probably we really need casts, not a different kind of rework: allocator::deallocate naturally takes an unsigned quantity.
Re: -Wconversion versus libstdc++
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 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.
Martin
$ cat t.cpp && aCC -AA -V -c +w t.cpp
int foo (double d)
{
const int i = d;
return i;
}
aCC: HP ANSI C++ B3910B A.03.70
Warning (suggestion) 819: "t.cpp", line 3 # Initialization of type 'int'
with 'double' may result in truncation of value.
const int i = d;
^
Warning (suggestion) 818: "t.cpp", line 3 # Type 'double' is larger than
type 'int', truncation in value may result.
const int i = d;
^
Re: Jan Hubicka and Uros Bizjak appointed i386 maintainers
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. Gerald
Re: Unsure about a new warning in mainline
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. The first issue, is that although the C front-end has issued these warnings for years, a recent change to the C++ front-end means that it now emits them too. This is why Paolo hadn't seen them before, but from the C/middle-end perspective the code is unchanged. The second issue is that there are two different overflow related warnings. The first warning indicates that an overflow has occurred in an expression, and the second is that the overflowed result is used in a context required to be a compile-time constant. Apparently, the latter is more serious than the first, as an expression that overflows isn't considered a "constant" according to the/some standard. Manuel's confusion here is that recent changes mean that we now only emit one warning of the first kind in an expression. Previously, for suitably nasty expressions we'd generate multiple such warnings. As for example, in "- - - - - - INT_MIN". Formerly, we'd issue one "overflow warning" per negation. However, we still continue to generate one warning for any overflow in an expression, and another if the result of that expression is used in a context required to be a constant. Hopefully, these differences can be seen by compiling the problematic code given in PR 30465 with "gcc" then with "g++". I agree with Paolo that this is a change for C++, and should at least be documented in changes.html, and probably be tweaked to avoid warning in system headers. However, it's also odd that in this respect C has had stricter/better diagnostics that C++ for some time. Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined when T is a 32-bit signed type, but well-defined if T is unsigned or wider than 32-bits. I hope this helps. Roger --
