gcc problem for help
My GNU Tools version information is:
binutils-2.16.92
gcc-4.1-20060407
newlib-1.14.0
My test program is :
class A
{
public:
private:
char string[SIZEOFOBJ];
};
void test(void)
{
A obj;
try
{
throw obj;
}
catch ( A &e )
{
printf("exception !\n");
}
}
when SIZEOFOBJ <= 68, the result is correct,however,when SIZEOFOBJ > 68,the
program crashed.
I spent more than one month to attemp to solve the problem,but I failed.
Can anyone give me a hand on the problem?
Thank you very much!
yours
David Wong
_
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
Re: gcc problem for help
David,
This list is for the development of GCC. It is more likely that you
obtain an answer to your problem if you ask in [EMAIL PROTECTED]
Good luck,
Manuel.
On 10/01/07, 王 刚伟 <[EMAIL PROTECTED]> wrote:
My GNU Tools version information is:
binutils-2.16.92
gcc-4.1-20060407
newlib-1.14.0
My test program is :
class A
{
public:
private:
char string[SIZEOFOBJ];
};
void test(void)
{
A obj;
try
{
throw obj;
}
catch ( A &e )
{
printf("exception !\n");
}
}
when SIZEOFOBJ <= 68, the result is correct,however,when SIZEOFOBJ > 68,the
program crashed.
I spent more than one month to attemp to solve the problem,but I failed.
Can anyone give me a hand on the problem?
Thank you very much!
yours
David Wong
_
免费下载 MSN Explorer: http://explorer.msn.com/lccn/
Re: proposal to clean up @node Warning Options in invoke.texi
On 10 Jan 2007 05:47:19 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Chris Pickett <[EMAIL PROTECTED]> writes: | 1. Create a default section, at the top, and put all options enabled | by default there. | | 2. Try to group options so that they are closer to other connected | nodes in the graph. | 3. Get rid of the -Wno-xxx option listings, since it is not always | the case that -Wxxx is enabled by "default", and this just ends up | being rather confusing. Instead, explain in the default section that | everything there can be disabled with -Wno-xxx. Actually, I would put first a general paragraph: explaining that any -W* is a warning option, any W* option can be disabled, what is Werror and -w. After that, I would start listing options. First, a default section with just names, then pedantic, -fsyntax-only and similar (special options). Then, Wall and Wextra and other super-options but just listing which warnings they activate. Finally, a ordered list (perhaps divided in different sections for each language) of all warning options with their descriptions and a short sentence saying which super-options enable it or whether it is enabled by default. I assume the -Wno-xxx that are set by default would be moved to the "default" section? No. Warnings that are not active by default are obviously disabled, there is no need to mention them. Actually, we should be more specific saying that using Wno-* disables a warning no matter what you put on the commandline, so, strictly speaking, it is false that warnings that are not enabled by default are equivalent to -Wno-* | # A <-- B && C option A is implied by options B and C together Do you have an example of this? | # A --> Boption A implies option B | # A ==> Boption A enables option B What is the difference between "implies" and "enables" ? | default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar | -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of | -Wint-to-pointer-cast -Wpointer-to-int-cast plus others that are not controlled by named flags. Should all warnings be controlled by some or other flag? | -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign plus others that are not controlled by named flags. It is not obvious whether some of the warning should become hard errors or stay pedwarns as some of the pedwarns were introduced as transitional paths logn time ago. Yes, pedantic also needs a cleanup but that is going to be tough | -pedantic <-- -pedantic-errors -ansi (and corresponding -std= options) also implies pedwarns or errors but not all. Moreoverm, g++ -fpermissive issues warnings where it should be issueing hard errors. Why pedantic issues warnings in C and errors in C++ and fpermissive converts the errors back to warnings? This is something that has always confused me. [...] | -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) I believe the correct understanding is that it depends on optimization level different from -O0. It seems to me that the only reason for Winit-self to exists is that people try to silence the -Wuninitialized warnings using the init-self hack and then other people have to work-around that hack. Really sad and one of the culprits is the deficiencies in -Wuninitialized itself. Perhaps we should divide -Wuninitialized into -Wuninitialized-sure and -Wuninitialized-may. | -Wimplicit <-- -Wall # redundant implication Hmm, I don't understand what you mean here. Me neither. Also, you missed -Werror-implicit-function-declaration which is a weird and useless option. I have to investigate its history. | -W --> -Wextra We would like "-W" not to be mentioned anymore. Yes, sometimes is better to forget somethings... Manuel.
gcc trunk 20070110 build failure (--enable-targets=all i486-linux-gnu)
trunk configured on i486 (on x86_64 hardware) with --enable-targets=all i486-linux-gnu fails to configure the first 64bit library (libiberty), not finding the correct libgcc. /scratch/packages/gcc/snap/gcc-snapshot-20070110/build/i486-linux-gnu/64/libiberty$ /scratch/packages/gcc/snap/gcc-snapshot-20070110/build/./gcc/xgcc -B/scratch/packages/gcc/snap/gcc-snapshot-20070110/build/./gcc/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/i486-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/include -isystem /usr/lib/gcc-snapshot/i486-linux-gnu/sys-include -m64 -o conftest -O2 -g -O2 foo.c /usr/bin/ld: skipping incompatible /scratch/packages/gcc/snap/gcc-snapshot-20070110/build/./gcc/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status $ ls build/i486-linux-gnu/64 libiberty $ ls build/gcc/64 ls: build/gcc/64: No such file or directory so the 64bit libgcc doesn't seem to be built and the multilib directory not created.
Tricky(?) aliasing question.
Hello,
[I apologize for posting this question here, but I've tried to ask at
gcc-help, got no response, and don't actually know where else to ask]
Below are two example functions foo() and boo(), that I think both are
valid from the POV of strict aliasing rules. GCC 4.2 either warns about
both (with -Wstrict-aliasing=2) or doesn't warn about any (with
-Wstrict-aliasing), and generates the assembly as if the functions don't
violate the rules, i.e, both functions return 10.
I'm still in doubt, especially w.r.t. the boo() function. Could anybody
clarify the issue please (see comments in the functions for my own
thoughts)?
$ cat alias.c
typedef struct { int i; } S;
int i;
int foo()
{
S const sc = { 10 };
i = 20;
// Accessing object 'i' of type 'int' through 'S' containing 'int'
// field. Should be OK from C99 standard POV?
*(S*)&i = sc;
return i;
}
S s;
int boo()
{
s.i = 20;
// Accessing 's' of type 'S' through 'int'. Is it aliasing rules
// violation? Maybe yes, but on the other hand this could be
// considered as accessing 's.i' of type 'int' through 'int' that
// should be OK from C99 standard POV?
*(int*)&s = 10;
return s.i;
}
$ gcc-4.2 -O3 -W -Wstrict-aliasing=2 -c alias.c -o alias.o
alias.c: In function 'foo':
alias.c:9: warning: dereferencing type-punned pointer might break
strict-aliasing rules
alias.c: In function 'boo':
alias.c:19: warning: dereferencing type-punned pointer might break
strict-aliasing rules
-- Sergei.
Re: gcc trunk 20070110 build failure (--enable-targets=all i486-linux-gnu)
On Wed, Jan 10, 2007 at 12:07:28PM +0100, Matthias Klose wrote: > trunk configured on i486 (on x86_64 hardware) with > > --enable-targets=all i486-linux-gnu > > fails to configure the first 64bit library (libiberty), not finding > the correct libgcc. libgcc uses the same config-ml.in to enable multilibs that libiberty does. You're going to have to figure out why that's decided that we shouldn't build multilibs. It starts by checking xgcc -print-multi-lib; that works, right? Could it have picked up a bad setting for $CC? -- Daniel Jacobowitz CodeSourcery
Build shared libraries with -Bsymbolic-functions
With the new linker switches, -Bsymbolic-functions and --dynamic-list-cpp-new, we can improve shared library performance in gcc. This change will build libstdc++.so with -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it to other libraries. H.J. -- --- gcc/libstdc++-v3/acinclude.m4.symbolic 2007-01-09 16:43:09.0 -0800 +++ gcc/libstdc++-v3/acinclude.m4 2007-01-09 17:10:30.0 -0800 @@ -299,6 +299,22 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES] AC_MSG_RESULT($ac_ld_relro) fi + # Set --dynamic-list-cpp-new and -Bsymbolic-functions + # Note this is only for shared objects. + ac_ld_symbolic_functions=no + if test x"$with_gnu_ld" = x"yes"; then +AC_MSG_CHECKING([for ld that supports --dynamic-list-cpp-new and -Bsymbolic-functions]) +cxx_symbolic_functions=`$LD -v --help 2>/dev/null | grep "dynamic-list-cpp-new"` +if test -n "$cxx_symbolic_functions"; then + cxx_symbolic_functions=`$LD -v --help 2>/dev/null | grep "Bsymbolic-functions"` +fi +if test -n "$cxx_symbolic_functions"; then + OPT_LDFLAGS="$OPT_LDFLAGS -Wl,--dynamic-list-cpp-new,-Bsymbolic-functions" + ac_ld_symbolic_functions=yes +fi +AC_MSG_RESULT($ac_ld_symbolic_functions) + fi + # Set linker optimization flags. if test x"$with_gnu_ld" = x"yes"; then OPT_LDFLAGS="-Wl,-O1 $OPT_LDFLAGS"
Enforcing order of execution for function arguments
Apologises for the slightly off-topic message. One thing which comes up regularly in various C and C++ messageboards is that statements like "f() + g()" and "a(f(), g())" do not declare which order f() and g() will be executed in. How hard would it be to fix the order of execution in gcc/g++? Could someone point me to the piece of code which must change, or if it is only a very small change, the actual change required? I would very much like to be able to benchmark this, as I can find no previous case where someone has tried fixing the order of execution to see if it actually makes any measureable difference. Would anyone be interested in this being added as a command line argument? Thank you, Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Manuel López-Ibáñez wrote: On 10 Jan 2007 05:47:19 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Chris Pickett <[EMAIL PROTECTED]> writes: I assume the -Wno-xxx that are set by default would be moved to the "default" section? No. Warnings that are not active by default are obviously disabled, there is no need to mention them. Actually, we should be more specific saying that using Wno-* disables a warning no matter what you put on the commandline, so, strictly speaking, it is false that warnings that are not enabled by default are equivalent to -Wno-* I agree. But if Gaby actually meant the -Wxxx that are set by default, which currently means -Wno-xxx is listed, then yes, those -Wxxx would be listed in the default section. | # A <-- B && C option A is implied by options B and C together Do you have an example of this? -Wunused-parameter <-- -Wextra && -Wunused | # A --> Boption A implies option B | # A ==> Boption A enables option B What is the difference between "implies" and "enables" ? Implies: turning on A turns on B. Enables: turning on A means that turning on B will have an effect. There is probably a better wording, maybe "enables" instead of my "implies", and "is required by" instead of my "enables". | default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar | -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of | -Wint-to-pointer-cast -Wpointer-to-int-cast plus others that are not controlled by named flags. Should all warnings be controlled by some or other flag? I think so, but there is doc-only work that can be done first. Insisting on each option being either a super-option or a real option but never both would fix this. | -Wimplicit <-- -Wall # redundant implication Hmm, I don't understand what you mean here. Me neither. Also, you missed -Werror-implicit-function-declaration which is a weird and useless option. I have to investigate its history. My original graph had: -Wimplicit-int <-- -Wall -Wimplicit-function-declaration <-- -Wall -Werror-implicit-function-declaration -Wimplicit --> -Wimplicit-int -Wimplicit-function-declaration -Wimplicit <-- -Wall # redundant implication The reason I said this last one is redundant is that -Wall is already documented as turning on both sub-options of the -Wimplicit super-option. I don't know what to do about it, but my intuition is that -Wimplicit should go away altogether. For now it seems not documenting the last line above would be good. Cheers, Chris
Re: Tricky(?) aliasing question.
Sergei Organov <[EMAIL PROTECTED]> writes:
> Below are two example functions foo() and boo(), that I think both are
> valid from the POV of strict aliasing rules. GCC 4.2 either warns about
> both (with -Wstrict-aliasing=2) or doesn't warn about any (with
> -Wstrict-aliasing), and generates the assembly as if the functions don't
> violate the rules, i.e, both functions return 10.
-Wstrict-aliasing=2 is documented to return false positives. Actually
both current versions of -Wstrict-aliasing are pretty bad.
> $ cat alias.c
> typedef struct { int i; } S;
>
> int i;
> int foo()
> {
> S const sc = { 10 };
> i = 20;
> // Accessing object 'i' of type 'int' through 'S' containing 'int'
> // field. Should be OK from C99 standard POV?
> *(S*)&i = sc;
C99 says that you can access an object via "an aggregate or union type
that includes one of the aforementioned [basically, compatible] types
among its members (including, recursively, a member of a subaggregate
or contained union)" (section 6.5, paragraph 7). So on that basis
this looks OK to me.
> S s;
> int boo()
> {
> s.i = 20;
> // Accessing 's' of type 'S' through 'int'. Is it aliasing rules
> // violation? Maybe yes, but on the other hand this could be
> // considered as accessing 's.i' of type 'int' through 'int' that
> // should be OK from C99 standard POV?
> *(int*)&s = 10;
> return s.i;
> }
I think this should also be OK.
The main point is that you are accessing the object with the correct
type (int). The use of the struct wrapper does not change that. If
you used a struct for which the type of the field was not the same as
the type of the variable, then this usage would be an aliasing
violation.
It is possible that somebody else will disagree with me.
Ian
Re: Build shared libraries with -Bsymbolic-functions
"H. J. Lu" <[EMAIL PROTECTED]> writes: > With the new linker switches, -Bsymbolic-functions and > --dynamic-list-cpp-new, we can improve shared library > performance in gcc. This change will build libstdc++.so with > -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > to other libraries. To be clear, this will prevent programs from overriding functions defined in libstdc++.so which are called by other functions in libstdc++.so. Are we sure this is desirable? Note in particular that libstdc++.so includes several functions defined as extern "C", the __cxa functions. In particular I've seen programs which override __cxa_pure_virtual in order to give a more informative error message. Ian
Re: Enforcing order of execution for function arguments
Chris Jefferson writes: > One thing which comes up regularly in various C and C++ > messageboards is that statements like "f() + g()" and "a(f(), g())" > do not declare which order f() and g() will be executed in. > > How hard would it be to fix the order of execution in gcc/g++? > Could someone point me to the piece of code which must change, or > if it is only a very small change, the actual change required? I > would very much like to be able to benchmark this, as I can find no > previous case where someone has tried fixing the order of execution > to see if it actually makes any measureable difference. The easiest way is during gimplification: you'd walk over the arglist from left to right, calling gimplify_expr (&arg, pre_p, post_p, is_gimple_formal_tmp_var, fb_rvalue); on each arg. > Would anyone be interested in this being added as a command line argument? That would be a Bad Thing. Andrew.
Re: Enforcing order of execution for function arguments
"Chris Jefferson" <[EMAIL PROTECTED]> writes: > One thing which comes up regularly in various C and C++ messageboards > is that statements like "f() + g()" and "a(f(), g())" do not declare > which order f() and g() will be executed in. > > How hard would it be to fix the order of execution in gcc/g++? Could > someone point me to the piece of code which must change, or if it is > only a very small change, the actual change required? I would very > much like to be able to benchmark this, as I can find no previous case > where someone has tried fixing the order of execution to see if it > actually makes any measureable difference. It would be a bit tedious but not especially difficult. My idea would be to rewrite c = a + b into t1 = a; t2 = b; c = t1 + t2. Of course this rewriting could be skipped where a and b are constants or simple variables. This would be done in the frontend. In fact you could do this rewriting outside of the compiler in a source-to-source transformation tool. > Would anyone be interested in this being added as a command line argument? No. We should only create a variant language for a good reason. This is not a good reason. Ian
Re: Build shared libraries with -Bsymbolic-functions
On Wed, Jan 10, 2007 at 07:19:17AM -0800, Ian Lance Taylor wrote: > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > > With the new linker switches, -Bsymbolic-functions and > > --dynamic-list-cpp-new, we can improve shared library > > performance in gcc. This change will build libstdc++.so with > > -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > > to other libraries. > > To be clear, this will prevent programs from overriding functions > defined in libstdc++.so which are called by other functions in > libstdc++.so. Are we sure this is desirable? Note in particular that > libstdc++.so includes several functions defined as extern "C", the > __cxa functions. What does C++ standard say? If standard doesn't say we have to support it, I don't see there is a problem. > > In particular I've seen programs which override __cxa_pure_virtual in > order to give a more informative error message. Can user override those symbols on all platforms? H.J.
Re: proposal to clean up @node Warning Options in invoke.texi
> "Chris" == Chris Pickett <[EMAIL PROTECTED]> writes: Chris> For one reason or another, I have spent a fair amount of time Chris> reading and getting confused by the warnings documentation. Chris> 3. Get rid of the -Wno-xxx option listings, since it is not always Chris> the case that -Wxxx is enabled by "default", and this just ends up Chris> being rather confusing. Instead, explain in the default section that Chris> everything there can be disabled with -Wno-xxx. Recently I tried searching the docs for '-Wdeprecated'. There's only one hit... you have to think to search for '-Wno-deprecated' to find the actual warning. So, one cleanup I would like to see is an @opindex for *every* flag. In particular both -Wfoo and -Wno-foo should both be in the index, so that a search for either one yields a useful result. (The underlying idea being that you should be able to copy any option from a command line into info, and find docs for it.) Tom
Re: Build shared libraries with -Bsymbolic-functions
> "H.J." == H J Lu <[EMAIL PROTECTED]> writes: H.J.> With the new linker switches, -Bsymbolic-functions and H.J.> --dynamic-list-cpp-new, we can improve shared library H.J.> performance in gcc. This change will build libstdc++.so with H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it H.J.> to other libraries. I prefer to see semi-generic helper code like this in a new .m4 file in config. That makes it somewhat simpler for other target libraries to reuse it. Tom
Re: Tricky(?) aliasing question.
It is possible that somebody else will disagree with me. FWIW, our currently aliasing set implementation agrees with you on both counts :)
Re: Enforcing order of execution for function arguments
Andrew Haley wrote: Chris Jefferson writes: > One thing which comes up regularly in various C and C++ > messageboards is that statements like "f() + g()" and "a(f(), g())" > do not declare which order f() and g() will be executed in. > > How hard would it be to fix the order of execution in gcc/g++? > Could someone point me to the piece of code which must change, or > if it is only a very small change, the actual change required? I > would very much like to be able to benchmark this, as I can find no > previous case where someone has tried fixing the order of execution > to see if it actually makes any measureable difference. The easiest way is during gimplification: you'd walk over the arglist from left to right, calling gimplify_expr (&arg, pre_p, post_p, is_gimple_formal_tmp_var, fb_rvalue); on each arg. But would it be sufficient? I guess you would also have to make sure that further passes (i.e. out-of-ssa) do not revert what you have just done. > Would anyone be interested in this being added as a command line argument? That would be a Bad Thing. Good that a bad thing is hard to implement, that's morality. Cheers, Roberto
Aliasing error in man page?
This is "man dlopen" ;
#include
#include
int main(int argc, char **argv) {
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("libm.so", RTLD_LAZY);
if (!handle) {
fprintf (stderr, "%s\n", dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
---
*(void **) (&cosine) = dlsym(handle, "cos");
---
if ((error = dlerror()) != NULL) {
fprintf (stderr, "%s\n", error);
exit(1);
}
printf ("%f\n", (*cosine)(2.0));
dlclose(handle);
return 0;
}
That is a strict-aliasing error, is it?
Andrew.
Re: Enforcing order of execution for function arguments
Roberto COSTA writes: > Andrew Haley wrote: > > Chris Jefferson writes: > > > > > One thing which comes up regularly in various C and C++ > > > messageboards is that statements like "f() + g()" and "a(f(), g())" > > > do not declare which order f() and g() will be executed in. > > > > > > How hard would it be to fix the order of execution in gcc/g++? > > > Could someone point me to the piece of code which must change, or > > > if it is only a very small change, the actual change required? I > > > would very much like to be able to benchmark this, as I can find no > > > previous case where someone has tried fixing the order of execution > > > to see if it actually makes any measureable difference. > > > > The easiest way is during gimplification: you'd walk over the arglist > > from left to right, calling > > > > gimplify_expr (&arg, pre_p, post_p, > > is_gimple_formal_tmp_var, fb_rvalue); > > > > on each arg. > > But would it be sufficient? I think so. > I guess you would also have to make sure that further passes (i.e. > out-of-ssa) do not revert what you have just done. If any arg had side-effects that would be a bug. Andrew.
Re: Enforcing order of execution for function arguments
Andrew Haley wrote: Roberto COSTA writes: > Andrew Haley wrote: > > Chris Jefferson writes: > > > > > One thing which comes up regularly in various C and C++ > > > messageboards is that statements like "f() + g()" and "a(f(), g())" > > > do not declare which order f() and g() will be executed in. > > > > > > How hard would it be to fix the order of execution in gcc/g++? > > > Could someone point me to the piece of code which must change, or > > > if it is only a very small change, the actual change required? I > > > would very much like to be able to benchmark this, as I can find no > > > previous case where someone has tried fixing the order of execution > > > to see if it actually makes any measureable difference. > > > > The easiest way is during gimplification: you'd walk over the arglist > > from left to right, calling > > > > gimplify_expr (&arg, pre_p, post_p, > > is_gimple_formal_tmp_var, fb_rvalue); > > > > on each arg. > > But would it be sufficient? I think so. > I guess you would also have to make sure that further passes (i.e. > out-of-ssa) do not revert what you have just done. If any arg had side-effects that would be a bug. Actually, I was thinking about the case "g(a(), b());". Let's imagine the gimplified code (because of your change) looks like: t1 = a(); t2 = b(); g(t1, t2); Are we always sure that t1 and t2 will not be pushed again in the CALL_EXPR by further transformations? Roberto
Re: Aliasing error in man page?
Andrew Haley <[EMAIL PROTECTED]> writes: > --- > *(void **) (&cosine) = dlsym(handle, "cos"); > --- > That is a strict-aliasing error, is it? Yes, and a seemingly pointless one at that. Ian
Re: proposal to clean up @node Warning Options in invoke.texi
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: [...] | > I assume the -Wno-xxx that are set by default would be moved to the | > "default" section? | > | | No. Why? | Warnings that are not active by default are obviously disabled, | there is no need to mention them. I don't understand. Please explain further. [...] | > | -pedantic <-- -pedantic-errors | > | > -ansi (and corresponding -std= options) also implies pedwarns or | > errors but not all. | > Moreoverm, g++ -fpermissive issues warnings where it should be | > issueing hard errors. | > | | Why pedantic issues warnings in C and errors in C++ Please, consult the archive; we have been through that many times. [...] | > | -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) | > | > I believe the correct understanding is that it depends on optimization | > level different from -O0. | > | | It seems to me that the only reason for Winit-self to exists is that | people try to silence the -Wuninitialized warnings using the init-self | hack and then other people have to work-around that hack. I don't believe that explanation. -- Gaby
Re: proposal to clean up @node Warning Options in invoke.texi
Tom Tromey <[EMAIL PROTECTED]> writes: | > "Chris" == Chris Pickett <[EMAIL PROTECTED]> writes: | | Chris> For one reason or another, I have spent a fair amount of time | Chris> reading and getting confused by the warnings documentation. | | Chris> 3. Get rid of the -Wno-xxx option listings, since it is not always | Chris> the case that -Wxxx is enabled by "default", and this just ends up | Chris> being rather confusing. Instead, explain in the default section that | Chris> everything there can be disabled with -Wno-xxx. | | Recently I tried searching the docs for '-Wdeprecated'. There's only | one hit... you have to think to search for '-Wno-deprecated' to find | the actual warning. Hi Tom, I was specifically thinking of that PR you filled and I wrote the above :-) -- Gaby
Re: proposal to clean up @node Warning Options in invoke.texi
Gabriel Dos Reis wrote:
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| > I assume the -Wno-xxx that are set by default would be moved to the
| > "default" section?
My guess is that there is a misunderstanding here.
| Warnings that are not active by default are obviously disabled,
| there is no need to mention them.
I don't understand. Please explain further.
I'll try (since I agree). The default section should only list those
options that are enabled by default. Anything not listed there is
clearly not enabled by default.
All that I'm proposing is that:
-Wno-multichar
Do not warn if a multicharacter constant ('FOO') is used.
...
becomes:
The following options are enabled by default:
...
-Wmultichar
...
...
-Wmultichar
Warn if a multicharacter constant ('FOO') is used.
...
This option is enabled by default.
(using "enabled" for my original "implies").
If you meant something else in addition, can you give an example?
As far as I can tell, Manuel's original response was saying that one
should not list -Wno-strict-prototypes in the default section on the
basis of -Wstrict-prototypes not being default.
Thanks,
Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett wrote: Gabriel Dos Reis wrote: | > I assume the -Wno-xxx that are set by default would be moved to the | > "default" section? If you meant something else in addition, can you give an example? I'm not subscribed to the list and so I missed Tom's message: http://gcc.gnu.org/ml/gcc/2007-01/msg00350.html "Recently I tried searching the docs for '-Wdeprecated'. There's only one hit... you have to think to search for '-Wno-deprecated' to find the actual warning. So, one cleanup I would like to see is an @opindex for *every* flag. In particular both -Wfoo and -Wno-foo should both be in the index, so that a search for either one yields a useful result. (The underlying idea being that you should be able to copy any option from a command line into info, and find docs for it.)" Just to clarify, I think that would be useful as well, but I also think we should avoid duplicating the entire index in the default section. (For space reasons, and also because it is technically not correct either, at least according to Manuel's reponse.) Cheers, Chris
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| > [...]
| > | > I assume the -Wno-xxx that are set by default would be moved to
| > the
| > | > "default" section?
|
| My guess is that there is a misunderstanding here.
most probably :-)
| > | Warnings that are not active by default are obviously disabled,
| > | there is no need to mention them.
| > I don't understand. Please explain further.
|
| I'll try (since I agree). The default section should only list those
| options that are enabled by default. Anything not listed there is
| clearly not enabled by default.
|
| All that I'm proposing is that:
|
| -Wno-multichar
| Do not warn if a multicharacter constant ('FOO') is used.
| ...
|
| becomes:
|
| The following options are enabled by default:
| ...
| -Wmultichar
| ...
|
| ...
|
| -Wmultichar
| Warn if a multicharacter constant ('FOO') is used.
| ...
| This option is enabled by default.
|
| (using "enabled" for my original "implies").
I agree with this. However, I also agree with Tom's point that we
must have cross-references/index of all options (both the
affirmative and the negative forms).
See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30330
-- Gaby
PATCH: Build shared libraries with -Bsymbolic-functions
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote: > > "H.J." == H J Lu <[EMAIL PROTECTED]> writes: > > H.J.> With the new linker switches, -Bsymbolic-functions and > H.J.> --dynamic-list-cpp-new, we can improve shared library > H.J.> performance in gcc. This change will build libstdc++.so with > H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > H.J.> to other libraries. > > I prefer to see semi-generic helper code like this in a new .m4 file > in config. That makes it somewhat simpler for other target libraries > to reuse it. > Here it is. If it is OK, I will extend it to Java and Fortran. H.J. --- config/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * lib-ld.m4 (AC_LIB_PROG_LD_GNU_SYMBOLIC): New. (AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW): Likewise. libstdc++-v3/ 2007-01-10 H.J. Lu <[EMAIL PROTECTED]> * aclocal.m4: Include ../config/lib-ld.m4. * configure.ac: Use AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW. * configure: Regenerated. * Makefile.in: Likewise. * src/Makefile.am (CXXLINK): Add $(DYNAMIC_LIST_CPP_NEW_LDFLAGS). * src/Makefile.in: Regenerated. --- gcc/config/lib-ld.m4.symbolic 2005-11-01 13:56:29.0 -0800 +++ gcc/config/lib-ld.m42007-01-10 10:49:49.0 -0800 @@ -108,3 +108,43 @@ fi test -z "$LD" && AC_MSG_ERROR([no acceptable ld found in \$PATH]) AC_LIB_PROG_LD_GNU ]) + +dnl Substitute SYMBOLIC_LDFLAGS with -Bsymbolic-functions for GNU linker +dnl if it is supported. +AC_DEFUN([AC_LIB_PROG_LD_GNU_SYMBOLIC], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports -Bsymbolic-functions], +acl_cv_prog_gnu_ld_symbolic, [ +acl_cv_prog_gnu_ld_symbolic=no +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_symbolic=yes + fi +fi]) +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes"; then + SYMBOLIC_LDFLAGS="-Wl,-Bsymbolic-functions" +else + SYMBOLIC_LDFLAGS='' +fi +AC_SUBST(SYMBOLIC_LDFLAGS) +]) + +dnl Substitute DYNAMIC_LIST_CPP_NEW_LDFLAGS with --dynamic-list-cpp-new +dnl for GNU linker if it is supported. +AC_DEFUN([AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW], +[AC_CACHE_CHECK([if the GNU linker ($LD) supports --dynamic-list-cpp-new], +acl_cv_prog_gnu_ld_dynamic_list_cpp_new, [ +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=no +if test x"$with_gnu_ld" = x"yes"; then + if $LD --help 2>&1 &5; then +acl_cv_prog_gnu_ld_dynamic_list_cpp_new=yes + fi +fi]) +AC_LIB_PROG_LD_GNU_SYMBOLIC +if test x"$acl_cv_prog_gnu_ld_symbolic" = x"yes" -a \ + x"$acl_cv_prog_gnu_ld_dynamic_list_cpp_new" = x"yes"; then + DYNAMIC_LIST_CPP_NEW_LDFLAGS="$SYMBOLIC_LDFLAGS -Wl,--dynamic-list-cpp-new" +else + DYNAMIC_LIST_CPP_NEW_LDFLAGS='' +fi +AC_SUBST(DYNAMIC_LIST_CPP_NEW_LDFLAGS) +]) --- gcc/libstdc++-v3/Makefile.in.symbolic 2006-10-17 07:33:04.0 -0700 +++ gcc/libstdc++-v3/Makefile.in2007-01-10 10:33:04.0 -0800 @@ -50,9 +50,10 @@ am__aclocal_m4_deps = $(top_srcdir)/../c $(top_srcdir)/../config/multi.m4 \ $(top_srcdir)/../config/no-executables.m4 \ $(top_srcdir)/../config/unwind_ipinfo.m4 \ - $(top_srcdir)/../libtool.m4 $(top_srcdir)/crossconfig.m4 \ - $(top_srcdir)/linkage.m4 $(top_srcdir)/acinclude.m4 \ - $(top_srcdir)/../config/tls.m4 $(top_srcdir)/configure.ac + $(top_srcdir)/../config/lib-ld.m4 $(top_srcdir)/../libtool.m4 \ + $(top_srcdir)/crossconfig.m4 $(top_srcdir)/linkage.m4 \ + $(top_srcdir)/acinclude.m4 $(top_srcdir)/../config/tls.m4 \ + $(top_srcdir)/configure.ac am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \ @@ -129,6 +130,7 @@ CYGPATH_W = @CYGPATH_W@ C_INCLUDE_DIR = @C_INCLUDE_DIR@ DEBUG_FLAGS = @DEBUG_FLAGS@ DEFS = @DEFS@ +DYNAMIC_LIST_CPP_NEW_LDFLAGS = @DYNAMIC_LIST_CPP_NEW_LDFLAGS@ ECHO_C = @ECHO_C@ ECHO_N = @ECHO_N@ ECHO_T = @ECHO_T@ @@ -193,6 +195,7 @@ SECTION_LDFLAGS = @SECTION_LDFLAGS@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ STRIP = @STRIP@ +SYMBOLIC_LDFLAGS = @SYMBOLIC_LDFLAGS@ SYMVER_FILE = @SYMVER_FILE@ TOPLEVEL_INCLUDES = @TOPLEVEL_INCLUDES@ USE_NLS = @USE_NLS@ --- gcc/libstdc++-v3/aclocal.m4.symbolic2006-10-17 07:33:04.0 -0700 +++ gcc/libstdc++-v3/aclocal.m4 2007-01-10 10:19:35.0 -0800 @@ -585,6 +585,7 @@ m4_include([../config/lead-dot.m4]) m4_include([../config/multi.m4]) m4_include([../config/no-executables.m4]) m4_include([../config/unwind_ipinfo.m4]) +m4_include([../config/lib-ld.m4]) m4_include([../libtool.m4]) m4_include([crossconfig.m4]) m4_include([linkage.m4]) --- gcc/libstdc++-v3/configure.ac.symbolic 2006-11-16 09:57:24.0 -0800 +++ gcc/libstdc++-v3/configure.ac 2007-01-10 10:20:44.0 -0800 @@ -403,5 +403,7 @@ _EOF SUBDIRS="$SUBDIRS" ]) +AC_LIB_PROG_LD_GNU_DYNAMIC_LIST_CPP_NEW + dnl And this actually makes things happen: AC_OUTPUT
RFC: Add BID as a configure time option for DFP
Both AMD and Intel like to have BID as a configure time option for DFP. Intel is planning to contribute a complete BID runtime library, which can be used by executables generate by gcc. As the first step, we'd like to contribute a BID<->DPD library so that BID can be used with libdecnumber by executables generate by gcc before the complete BID runtime library is ready. Any comments? H.J.
Re: RFC: Add BID as a configure time option for DFP
On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote: > Both AMD and Intel like to have BID as a configure time option > for DFP. Intel is planning to contribute a complete BID runtime > library, which can be used by executables generate by gcc. > > As the first step, we'd like to contribute a BID<->DPD library so that > BID can be used with libdecnumber by executables generate by gcc > before the complete BID runtime library is ready. > > Any comments? Since most readers of the gcc list aren't specialists in decimal floating point representations, it would be polite to ease up on the acronym soup a bit. DFP = "decimal floating point" BID = "binary integer decimal" DPD = "densely packed decimal"
Re: proposal to clean up @node Warning Options in invoke.texi
On 10/01/07, Chris Pickett <[EMAIL PROTECTED]> wrote: As far as I can tell, Manuel's original response was saying that one should not list -Wno-strict-prototypes in the default section on the basis of -Wstrict-prototypes not being default. Correct.
java building
I tried to build java yesterday: ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ GnuCrypto.java: In class 'gnu.j avax.crypto.jce.GnuCrypto$1': ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ GnuCrypto.java: In method 'gnu. javax.crypto.jce.GnuCrypto$1.run()': ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ GnuCrypto.java:410: error: cann ot find file for class gnu.javax.crypto.jce.key.TripleDESKeyGeneratorImpl :-( Is it just me?
Mis-handled ColdFire submission?
I know Andrew replied privately, but I hope he doesn't mind me raising the issue on-list. I just wanted to guage the general feeling as to whether I'd screwed up, and whether I should have submitted the patches in a different way. Richard --- Begin Message --- [off-list] Posting sixty patches at once? This isn't going to be a new trend, is it? Because it really sucks... Andrew. --- End Message --- --- Begin Message --- On Wed, 2007-01-10 at 18:03 +, Andrew Haley wrote: > [off-list] > > Posting sixty patches at once? This isn't going to be a new trend, is > it? Because it really sucks... I don't think it's that bad. It certainly makes the review a lot easier. jeff --- End Message --- --- Begin Message --- Jeffrey Law writes: > On Wed, 2007-01-10 at 18:03 +, Andrew Haley wrote: > > [off-list] > > > > Posting sixty patches at once? This isn't going to be a new trend, is > > it? Because it really sucks... > I don't think it's that bad. It certainly makes the review a lot > easier. Mm, but it has the effect that only the first couple of patches are lookd at by anyone other than the poster and the reviewer. I suppose you could argue that in the case of ColdFire that would be true anyway. It also discourages outsiders from contributing. Andrew. --- End Message --- --- Begin Message --- On Wed, 2007-01-10 at 18:59 +, Andrew Haley wrote: > Jeffrey Law writes: > > On Wed, 2007-01-10 at 18:03 +, Andrew Haley wrote: > > > [off-list] > > > > > > Posting sixty patches at once? This isn't going to be a new trend, is > > > it? Because it really sucks... > > I don't think it's that bad. It certainly makes the review a lot > > easier. > > Mm, but it has the effect that only the first couple of patches are > lookd at by anyone other than the poster and the reviewer. I suppose > you could argue that in the case of ColdFire that would be true > anyway. It also discourages outsiders from contributing. There'll likely be some that I won't/can't review. More likely than not those will have to be ping'd if nobody notices them. What else would you suggest? Jeff. --- End Message ---
Re: proposal to clean up @node Warning Options in invoke.texi
Gerald Pfeifer wrote: 5. Fix what I have labelled as errors. That we definitely should do. I believe some things have been changed in our current development tree (to become GCC 4.3) already. It would be great could you have a look and perhaps produce a patch for one or more of these; is this something you could consider? I updated my graph to the trunk version, and will slowly start sending patches per the discussion we've had. It's attached in case I disappear for whatever reason. I have a question: does -Wextra now imply -Wconversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? Thanks, Chris # A --> Boption A implies option B # A --> B C option A implies options B and C # A && B --> C options A and B together imply C # A <-- Boption A is implied by option B. # A <-- B || C option A is implied by either option B or option C # A <-- B && C option A is implied by options B and C together # A ==> Boption A enables option B # A ==> B C option A enables options B and C # A <== Boption A requires option B (depends on B) default --> -Wimport -Wdiv-by-zero -Wendif-labels -Wattributes -Wmultichar -Wnormalized=nfc -Wdeprecated-declarations -Winvalid-offset-of -Wint-to-pointer-cast -Wpointer-to-int-cast -Woverflow default (C++) --> -Wwrite-strings -fsyntax-only -pedantic --> -Wlong-long -Wvariadic-macros -Wpointer-sign -Woverlength-strings -pedantic <-- -pedantic-errors -pedantic-errors --> -pedantic -w -Wimport <-- default -Wchar-subscripts <-- -Wall -Wcomment <-- -Wall -Wfatal-errors -Wformat --> -Wnonnull -Wformat-extra-args -Wformat-zero-length -Wformat <-- -Wformat=2 || -Wall -Wformat ==> -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wformat-y2k <== -Wformat -Wno-format-extra-args <== -Wformat # false dependency -Wno-format-zero-length <== -Wformat # false dependency -Wformat-nonliteral <== -Wformat -Wformat-security <== -Wformat -Wformat=2 --> -Wformat -Wformat-y2k -Wformat-nonliteral -Wformat-security -Wnonnull <-- -Wall || -Wformat -Winit-self <== -Wuninitialized # depends not only on -O1, but -O(1|2|3|s) -Wimplicit-int <-- -Wall -Wimplicit-function-declaration <-- -Wall -Werror-implicit-function-declaration -Wimplicit --> -Wimplicit-int -Wimplicit-function-declaration -Wimplicit <-- -Wall # redundant implication -Wmain <-- -Wall -Wmissing-braces <-- -Wall -Wmissing-include-dirs -Wparentheses <-- -Wall -Wsequence-point <-- -Wall -Wreturn-type <-- -Wall -Wswitch <-- -Wall -Wswitch-default -Wswitch-enum -Wtrigraphs <-- -Wall -Wunused-function <-- -Wall -Wunused-label <-- -Wall -Wunused-parameter <-- -Wextra && -Wunused -Wunused-parameter <-- -Wextra && -Wall # redundant implication -Wunused-variable <-- -Wall -Wunused-value <-- -Wall -Wunused --> -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused <-- -Wall # redundant implication -Wuninitialized <-- -Wall -Wuninitialized ==> -Winit-self -Wuninitialized <== -O(1|2|3|s) -Wunknown-pragmas <== -Wsystem-headers # undocumented -Wpragmas <-- -Wall # missing "This warning is enabled by `-Wall'". -Wstrict-aliasing <-- -Wall || -Wstrict-aliasing=2 -Wstrict-aliasing=2 --> -Wstrict-aliasing -Wstrict-aliasing=2 <== -fstrict-aliasing -Wall --> -Walways-true -Wchar-subscripts -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit-function-declaration -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-variable -Wunused-value -Wunused -Wuninitialized -Wpragmas -Wstrict-aliasing -Wpointer-sign -Wstring-literal-comparison # clearly not "All of the above -W options combined." # note that -Wpointer-sign is also below this point. -W --> -Wextra -Wextra --> -Wsign-compare -Wold-style-declaration -Woverride-init -Wmissing-parameter-type -Wmissing-field-initializers -Wempty-body -Wclobbered # do we have -Wextra --> -Wconversion now too? -Wextra && -Wunused --> -Wunused-parameter # s/arguments/parameters/ -Wextra && -Wall --> -Wunused-parameter # redundant implication -Wdiv-by-zero <-- default -Wsystem-headers ==> -Wunknown-pragmas -Wfloat-equal -Wtraditional -Wtraditional-conversion -Wdeclaration-after-statement -Wundef -Wendif-labels <-- default -Wshadow -Wlarger-than-LEN -Wunsafe-loop-optimizations -Wpointer-arith -Wbad-function-cast -Wc++-compat -Wcast-qual -Wcast-align -Wwrite-strings <-- default (C++) -Wclobbered <-- -Wextra -Wconversion # do we have -Wconversion <-- -Wextra now? -Wempty-body <-- -Wextra -Wsign-compare <-- -Wextra -Waggregate-return -Walways-true <-- -Wall -Wattributes <-- default -Wstrict-prototypes -Wold-style-declaration <-- -Wextra -Wold-style-definition -Wmissing-parameter-type <-- -Wextra -Wmissing-prototypes -Wmissing-de
Re: proposal to clean up @node Warning Options in invoke.texi
Chris Pickett wrote: I have a question: does -Wextra now imply -Wconversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? I mistakenly thought it was under -Wextra. So the question should be, does -Wtraditional now imply -Wtraditional-conversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? The documentation does not say so, I just wanted to check. Chris
Re: Mis-handled ColdFire submission?
> I know Andrew replied privately, but I hope he doesn't mind me raising > the issue on-list. I just wanted to guage the general feeling as to > whether I'd screwed up, and whether I should have submitted the patches > in a different way. I guess one should rather thank you for taking time to split patch into well described pieces! I think it actually is good way for allowing good review of bigger merge. Perhaps it would make sense to hold patches that depend or earlier or are similar in nature to those already posted so the changes requirested during review can be applied to them without too many re-posts, but I tend to believe that many patches are a lot better than single big merge patch doing many different changes. Honza
Re: proposal to clean up @node Warning Options in invoke.texi
On 10/01/07, Chris Pickett <[EMAIL PROTECTED]> wrote: Chris Pickett wrote: > I have a question: does -Wextra now imply -Wconversion since > -Wconversion was split into -Wconversion and -Wtraditional-conversion? I mistakenly thought it was under -Wextra. So the question should be, does -Wtraditional now imply -Wtraditional-conversion since -Wconversion was split into -Wconversion and -Wtraditional-conversion? The documentation does not say so, I just wanted to check. No, it doesn't. Some of the warnings produced by Wtraditional are also produced by Wtraditional-conversion but none of them produce all the warnings enabled by the other.
Re: Mis-handled ColdFire submission?
On Jan 10, 2007, at 1:13 PM, Richard Sandiford wrote: I just wanted to guage the general feeling as to whether I'd screwed up, and whether I should have submitted the patches in a different way. I don't see a trivial way that is strictly better. The problem is that some folks don't want the huge patch and some folks don't like the spray of 60. Hard to please both at once. One strategy that might be better would be to do them up on a development branch and submit one patch at a time as you develop them and then when all is said and done and all reviewed and approved, just merge it in. I'm used to this style from the Ada folks, and I've managed to find the 1 or 2 patches I was interested in taking a closer look at, so I don't think the spray of 60 is all that unreasonable. I do think trying to avoid patch spray is a noble goal... though, I do think it is easier to review as 60 as opposed to 1 compressed tar file. I too look forward to what others might say on the matter, as I'm going to be contributing lots of Objective-C patches at some point in the near feature I hope. I'll probably just do it as a few, larger combo patches (1-5) to ease the pain of it all for me. :-( People can take this opportunity to complain in advance if they wish.
Re: java building
> "Mike" == Mike Stump <[EMAIL PROTECTED]> writes: Mike> I tried to build java yesterday: Mike> ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ Mike> GnuCrypto.java: In class 'gnu.j Mike> avax.crypto.jce.GnuCrypto$1': Mike> ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ Mike> GnuCrypto.java: In method 'gnu. Mike> javax.crypto.jce.GnuCrypto$1.run()': Mike> ../../../../../../gcc/libjava/classpath/gnu/javax/crypto/jce/ Mike> GnuCrypto.java:410: error: cann Mike> ot find file for class Mike> gnu.javax.crypto.jce.key.TripleDESKeyGeneratorImpl Can you provide more context? That isn't enough. Mike> :-( Is it just me? For this problem, yes, afaik. Tom
Re: RFC: Add BID as a configure time option for DFP
On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote: > Both AMD and Intel like to have BID as a configure time option > for DFP. Intel is planning to contribute a complete BID runtime > library, which can be used by executables generate by gcc. > > As the first step, we'd like to contribute a BID<->DPD library so that > BID can be used with libdecnumber by executables generate by gcc > before the complete BID runtime library is ready. > > Any comments? libdecnumber doesn't use DPD (densely packed decimal), it uses the decNumber format. Functions in libgcc convert from DPD to decNumber, call into libdecnumber to do computations, and then convert the result back to DPD. It's all parameterized in dfp-bit.[ch], so replacing conversions between decNumber structs and DPD with conversions between decNumber structs and BID (binary integer decimal) should be straightforward; I don't think there's any need to convert between BID and DPD to use libdecnumber. If all x86* targets will use BID then there's no need for a configure option. Initial support using DPD for x86* was a proof of concept, I doubt that anyone would care if you replace it with BID support. Janis
Re: Mis-handled ColdFire submission?
Richard Sandiford <[EMAIL PROTECTED]> writes: > I know Andrew replied privately, but I hope he doesn't mind me raising > the issue on-list. I just wanted to guage the general feeling as to > whether I'd screwed up, and whether I should have submitted the patches > in a different way. IMHO this is a good example of how to split a big change into smaller, functionally more or less independent parts. The only problem I see is that one can easily lose track of which patches were already reviewed. Perhaps it would have been better to send them in smaller batches. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: RFC: Add BID as a configure time option for DFP
On Wed, Jan 10, 2007 at 02:10:58PM -0800, Janis Johnson wrote: > On Wed, Jan 10, 2007 at 11:40:46AM -0800, H. J. Lu wrote: > > Both AMD and Intel like to have BID as a configure time option > > for DFP. Intel is planning to contribute a complete BID runtime > > library, which can be used by executables generate by gcc. > > > > As the first step, we'd like to contribute a BID<->DPD library so that > > BID can be used with libdecnumber by executables generate by gcc > > before the complete BID runtime library is ready. > > > > Any comments? > > libdecnumber doesn't use DPD (densely packed decimal), it uses the > decNumber format. Functions in libgcc convert from DPD to decNumber, > call into libdecnumber to do computations, and then convert the result > back to DPD. It's all parameterized in dfp-bit.[ch], so replacing > conversions between decNumber structs and DPD with conversions between > decNumber structs and BID (binary integer decimal) should be > straightforward; I don't think there's any need to convert between BID > and DPD to use libdecnumber. libdecnumber is used by both gcc and DFP executables. We only want to use BID for DFP executables. That means we will need BID<->decNumber for gcc to generate DFP executables which use the BID library. Since the real BID library won't be ready for a while and in the meantime, we like to enable BID for gcc now, that is why we propose the BID<->DPD<->libdecnumber approach as a stopgap measure. We can plug in the real BID library later. > > If all x86* targets will use BID then there's no need for a configure > option. Initial support using DPD for x86* was a proof of concept, I > doubt that anyone would care if you replace it with BID support. Glad to hear that. We can make it BID only for x86. H.J.
Re: Mis-handled ColdFire submission?
On Wed, 2007-01-10 at 21:13 +, Richard Sandiford wrote: > I know Andrew replied privately, but I hope he doesn't mind me raising > the issue on-list. I just wanted to guage the general feeling as to > whether I'd screwed up, and whether I should have submitted the patches > in a different way. Its certainly preferable to a single giant patch. I personally don't have a problem with 60+ patches. I haven't looked at the so I don't know how much dependency there is between them. It might be a little less overwhelming if they were submitted 10 or 15 one day. Then a similar amount the next day or 12 hours later, and so on until they are all submitted. Perhaps submitting them in clumps which are related somehow, maybe functional area of the compiler/likely to be reviewed by the same maintainer would be a good idea. It might (maybe, maybe not :-) get faster attention so a maintainer doesn't have to paw through all of them to see if there is anything relevant to their component(s). It must have been a pain to organize that many separate patches :-) I thought I was doing well when I submitted the new out-of-ssa as 5 patches! :-) Andrew
gcc-4.2-20070110 is now available
Snapshot gcc-4.2-20070110 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070110/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 120651 You'll find: gcc-4.2-20070110.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070110.tar.bz2 C front end and core compiler gcc-ada-4.2-20070110.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070110.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070110.tar.bz2 C++ front end and runtime gcc-java-4.2-20070110.tar.bz2 Java front end and runtime gcc-objc-4.2-20070110.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070110.tar.bz2The GCC testsuite Diffs from 4.2-20070102 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: Mis-handled ColdFire submission?
> I know Andrew replied privately, but I hope he doesn't mind me raising > the issue on-list. I just wanted to guage the general feeling as to > whether I'd screwed up, and whether I should have submitted the patches > in a different way. The only problem I personally have is that you apparently successively replied to the previous post, which means that all the patches are tied to a single gigantic thread in my mailer. :-( -- Eric Botcazou
main(), registers and gdb
I have an issue (I hesitate to say a problem) related to register
saving and debugging on the linux/x86 platform using gdb 4.1.0.
If the following code is compiled with 'gcc -g -O0 -o test test.c',
the address of argc is passed into func() in the ecx register. Since
ecx is not preserved after the call to printf(), the address of argc
is corrupted on return from func(). Normally this would not be a
problem, since argc is never used in the code.
#include
#include
int func(int *x)
{
printf("in func\n");
return 0;
}
int main(int argc, char *argv[])
{
func(&argc);
//func(&argc);;
printf("hello\n");
return 0;
}
However, when run under gdb, commands that view the stack frame
produce strange results, and some commands (e.g. -var-update)
actually crash the debugger.
Breakpoint 1, main (argc=1, argv=0xbffcef14) at test.c:14
12 func(&argc);
(gdb) n
in func
14 printf("hello\n");
(gdb) where
#0 main (argc=Cannot access memory at address 0x4
) at test.c:16
(gdb)
If line 13 is uncommented the problem goes away, apparently because
the compiler recognizes that argc is used and so must be preserved.
Also, this problem is not apparent on other x86 platforms (at least
Darwin), because eax is used instead of ecx.
This problem is of concern when debugging programs because it
introduces unexpected behavior, even with optimization disabled.
I would appreciate any comments from the gcc and gdb communities on
this issue, and would be interested to know if there are any compiler
options and/or other means of disabling this behavior.
Thanks,
Greg
Re: proposal to clean up @node Warning Options in invoke.texi
On 10 Jan 2007 18:48:58 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | | It seems to me that the only reason for Winit-self to exists is that | people try to silence the -Wuninitialized warnings using the init-self | hack and then other people have to work-around that hack. I don't believe that explanation. Anybody is free to believe whatever they wish. As for facts to make up your mind, here there are a few: * Some excerpts from the thread that originated the official blessing on the init-self hack and the subsequent warning to work-around it: (Joe Buck discovers the init-self hack and proposes to disable it and require an option to enable it. That wasn't the option implemented.) "Someone evidently discovered that if one writes "int a = a" it suppresses uninitialized variable warnings! This seems to be an accidental feature of gcc" "The reason people seem to be motivated to do things like this has to do with weaknesses in the current uninitialized variable analysis." "Alternatively, I'd like to require the user to explicitly say that s/he is intentionally using this warning-suppressing idiom, by saying something like -Wno-self-assign" http://gcc.gnu.org/ml/gcc/2002-02/msg00401.html "So the idea of excluding this from -Wall would make sense ONLY if you make the effect of suppressing warnings an official part of the gcc semantics. In short only the following make sense: 1. Make this an official construct for the purpose of suppressing warnings for uninitialized variables, and document that it has no other (ill) effect. You can then decide whether to put the warning for this non-standard construct in -Wall or not. 2. Leave this as it is now, undefined, in which case there can be no objection to it being in -Wall, and indeed those people injudiciously using this consruct to suppress warnings will be warned that this usage is neither blessed nor guaranteed. Frankly I would be surprised if you could get a consensus for approach 1." http://gcc.gnu.org/ml/gcc/2002-02/msg00410.html (Ironically, approach 1 was indeed the one implemented). (Some people argued against the hack. Others argued in favour due to the deficiencies in Wuninitialized) "What is relevant, is that there obviously are people who think it's usefull [sic] for that purpose. Perhaps you can suggest an equivalent alternative to suppress the warning in question in certain circumstances." http://gcc.gnu.org/ml/gcc/2002-02/msg00288.html "Such usage is explicitly allowed in the C and C++ Standards. I'll grant you it's of dubious use, but one of the legal uses I can think for it is to avoid getting a warning about a variable being used uninitialized when you know for sure that it is not, but the compiler can't tell as much." http://gcc.gnu.org/ml/gcc/2002-02/msg00288.html * The bug that requested Winit-self "int x = x; is a gcc extension, but I could indeed not find a place in the manual that talks about a warning option that gives a message when this extension is used." "Sure. IIRC the extension is that this reliably calms down warnings about uninitialized variables." http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5582 * The patch that added this option: "This fixes PR 5582 only when pedantic is on because it as a GCC extension to do int i = i; to turn off the uninitialized warnings for that variable." http://gcc.gnu.org/ml/gcc-patches/2003-08/msg00952.html I hope this is sufficient for anyone to decide by themselves why Winit-self exists and why int i=i; is not warned by Wuninitialized. Cheers, Manuel.
Re: main(), registers and gdb
On Wed, Jan 10, 2007 at 04:32:48PM -0700, Greg Watson wrote:
> If the following code is compiled with 'gcc -g -O0 -o test test.c',
> the address of argc is passed into func() in the ecx register. Since
> ecx is not preserved after the call to printf(), the address of argc
> is corrupted on return from func(). Normally this would not be a
> problem, since argc is never used in the code.
This is a typical problem. There is not much that can be done about
it, although I remember once hearing a proposal that GCC should
forcibly extend the live ranges of local variables (or at least
arguments) at -O0 to improve debugging. That seems sensible to me.
> However, when run under gdb, commands that view the stack frame
> produce strange results, and some commands (e.g. -var-update)
> actually crash the debugger.
A crash is always a bug.
> Breakpoint 1, main (argc=1, argv=0xbffcef14) at test.c:14
> 12 func(&argc);
> (gdb) n
> in func
> 14 printf("hello\n");
> (gdb) where
> #0 main (argc=Cannot access memory at address 0x4
> ) at test.c:16
And honestly, I have no idea how that happened. Does it happen
with a current GDB? I suspect from the error message that this
one is not too recent.
--
Daniel Jacobowitz
CodeSourcery
Re: main(), registers and gdb
On Jan 10, 2007, at 4:38 PM, Daniel Jacobowitz wrote:
On Wed, Jan 10, 2007 at 04:32:48PM -0700, Greg Watson wrote:
If the following code is compiled with 'gcc -g -O0 -o test test.c',
the address of argc is passed into func() in the ecx register. Since
ecx is not preserved after the call to printf(), the address of argc
is corrupted on return from func(). Normally this would not be a
problem, since argc is never used in the code.
This is a typical problem. There is not much that can be done about
it, although I remember once hearing a proposal that GCC should
forcibly extend the live ranges of local variables (or at least
arguments) at -O0 to improve debugging. That seems sensible to me.
That would be nice. Although this seems like a trivial issue, it can
potentially effect debugging all MPI programs since they always start
with 'MPI_Init(&argc, &argv)'.
However, when run under gdb, commands that view the stack frame
produce strange results, and some commands (e.g. -var-update)
actually crash the debugger.
A crash is always a bug.
I believe it's gdb bug #2188.
Breakpoint 1, main (argc=1, argv=0xbffcef14) at test.c:14
12 func(&argc);
(gdb) n
in func
14 printf("hello\n");
(gdb) where
#0 main (argc=Cannot access memory at address 0x4
) at test.c:16
And honestly, I have no idea how that happened. Does it happen
with a current GDB? I suspect from the error message that this
one is not too recent.
It's gdb 6.5, so reasonably recent.
Greg
Re: Mis-handled ColdFire submission?
> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: Andreas> The only problem I see is that one can easily lose track of Andreas> which patches were already reviewed. Perhaps it would have Andreas> been better to send them in smaller batches. The patch tracker would help with that. I noticed recently that contribute.html doesn't seem to mention the patch tracker. Is there a reason for this omission? Tom
Re: Mis-handled ColdFire submission?
Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes: > Andreas> The only problem I see is that one can easily lose track of > Andreas> which patches were already reviewed. Perhaps it would have > Andreas> been better to send them in smaller batches. On Wed, Jan 10, 2007 at 02:56:48PM -0700, Tom Tromey wrote: > The patch tracker would help with that. > > I noticed recently that contribute.html doesn't seem to mention the > patch tracker. Is there a reason for this omission? I guess no one submitted a patch to the web page yet (hint, hint).
Re: Mis-handled ColdFire submission?
Richard Sandiford wrote: I know Andrew replied privately, but I hope he doesn't mind me raising the issue on-list. I just wanted to guage the general feeling as to whether I'd screwed up, and whether I should have submitted the patches in a different way. I wish everyone did things this thoroughly. Bernd
Re: proposal to clean up @node Warning Options in invoke.texi
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 10 Jan 2007 18:48:58 +0100, Gabriel Dos Reis | <[EMAIL PROTECTED]> wrote: | > | | > | It seems to me that the only reason for Winit-self to exists is that | > | people try to silence the -Wuninitialized warnings using the init-self | > | hack and then other people have to work-around that hack. | > | > I don't believe that explanation. | > | | Anybody is free to believe whatever they wish. It was a polite way of phrasing something. I did not anticipate that would have been too subtile. | As for facts to make up your mind, here there are a few: | | * Some excerpts from the thread that originated the official blessing | on the init-self hack and the subsequent warning to work-around it: | | (Joe Buck discovers the init-self hack and proposes to disable it and | require an option to enable it. That wasn't the option implemented.) | | "Someone evidently discovered that if one writes "int a = a" it suppresses | uninitialized variable warnings! This seems to be an accidental feature | of gcc" I'm well aware of the history of "-Winit-self". The issue is more subtile that you would like to make it appear. You would have to study more carefully the threads relating to this issue. If you dig the archive, you should be able to find example of circular_buffer buf = buf; [ or void* p = &p; ] -- Gaby
why Winit-self (was Re: proposal to clean up @node Warning Options in invoke.texi)
On 11 Jan 2007 02:08:48 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: I'm well aware of the history of "-Winit-self". The issue is more subtile that you would like to make it appear. You would have to study more carefully the threads relating to this issue. If you dig the archive, you should be able to find example of circular_buffer buf = buf; [ or void* p = &p; ] Sorry for being so slow but I don't get it. neither Winit-self nor Wuninitialized warn for void *p=&p; so how that example justifies the existence of Winit-self ? Anyway, we are way off-topic here, but I am truly interested on how the current situation was reached so I changed the subject. If still this thread is too off-topic for gcc, I would be glad if you wished to finish it by private email. Cheers, Manuel.
Re: proposal to clean up @node Warning Options in invoke.texi
On Thu, Jan 11, 2007 at 02:08:48AM +0100, Gabriel Dos Reis wrote: > I'm well aware of the history of "-Winit-self". The issue is more > subtile that you would like to make it appear. You would have to study > more carefully the threads relating to this issue. If you dig the > archive, you should be able to find example of > >circular_buffer buf = buf; > > [ or void* p = &p; ] There isn't really a subtlety; void* p = &p is well-defined, and the same is true for other cases where only the address, but not the (undefined) value of the initializer is used. I consider 'int i = i;' a botch that somehow evolved into a promise. I'm not going to re-open the war of 2002, but I was never happy with it.
RFC: Wextra digest (fixing PR7651)
The goal is to fix PR7651 and convert Wextra into a super-option, that
is an -W* option that just enables other options but it doesn't emit
warnings by itself (other super-options are Wall and Wunused).
This is a summary of the current status of Wextra for mainline to the
best of my knowledge. I welcome comments on how to group and name the
new -W* options that will take over the warnings produced by Wextra.
In Java, Wextra warns for unreachable bytecode.
(maybe this should be warned by -Wunreachable-code or by a new option
-Wunreachable-bytecode)
In C++, it warns for
* Subscripting an array which has been declared register.
* Taking the address of a variable which has been declared register.
* A base class is not initialized in a derived class' copy constructor.
* A non-static reference or non-static const member appears in a class
without constructors.
* Ambiguous virtual bases (virtual base inaccessible due to
ambiguity). (There is also an unconditional warning for direct base
inaccessible due to ambiguity)
* An enumerator and a non-enumerator both appear in a conditional
expression. (There is also an unconditional warning for two different
enumeral types used in a conditional expression).
Only for C, it enables:
* -Wmissing-parameter-type : A function parameter is declared without
a type specifier in K&R-style functions.
* -Wold-style-declaration : Storage-class specifiers like static are
not the first things in a declaration.
For both C and C++:
* A function can return either with or without a value.
* An expression-statement or the left-hand side of a comma expression
contains no side effects. For example, an expression such as x[i,j].
This is also warned by Wunused-value. In addition, Wextra enables
Wunused-value but this is not documented (and -Wunused-value is
already enabled by -Wall).
* If -Wunused or -Wall is given, it enables -Wunused-parameter.
(manual could be more explicit here)
* -Wuninitialized is enabled if -Ox is given. (not documented)
* A pointer is compared against integer zero with <, <=, >, or >=.
This is a pedwarn and it can also be enabled by using -pedantic. If
the pointer is the rightmost operator, there is no warning for Wextra
(surely a bug).
* -Wclobbered : A variable might be changed by longjmp or vfork.
* -Wempty-body : An empty body occurs in an if or else statement.
* -Wsign-compare : A comparison between signed and unsigned values
could produce an incorrect result when the signed value is converted
to unsigned.
* -Wmissing-field-initializers : An aggregate has an initializer which
does not initialize all members.
* -Woverride-init : An initialized field without side effects is
overridden when using
designated initializers.
* An unsigned value is compared against zero with < or >=.
Walways-true claims to warn for this but it doesn't. There is also an
unconditional warning for expressions that are always true or false
due to the range of types.
In ./gcc/config/sh/symbian.c:158 there is a warning enabled by Wextra
with the following code (notice the OPT_Wattributes) :
/* We ignore the dllimport attribute for inline member functions.
This differs from MSVC behavior which treats it like GNUC
'extern inline' extension. */
else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_INLINE (decl))
{
if (extra_warnings)
warning (OPT_Wattributes, "inline function %q+D is declared as "
"dllimport: attribute ignored",
decl);
return false;
}
Finally, the manual page claims that Wextra warns for any of several
floating-point events that often indicate errors, such as overflow,
underflow, loss of precision, etc. I wasn't able to find any instance
of this. I am fairly sure that Wextra doesn't do such thing.
Cheers,
Manuel.
Re: main(), registers and gdb
On Wed, Jan 10, 2007 at 04:50:59PM -0700, Greg Watson wrote: > That would be nice. Although this seems like a trivial issue, it can > potentially effect debugging all MPI programs since they always start > with 'MPI_Init(&argc, &argv)'. See my reply to the bug. This is specific to i686 32-bit compilers, arguments, and functions named "main". > >And honestly, I have no idea how that happened. Does it happen > >with a current GDB? I suspect from the error message that this > >one is not too recent. > > It's gdb 6.5, so reasonably recent. Please try a current snapshot. Thanks. -- Daniel Jacobowitz CodeSourcery
Re: proposal to clean up @node Warning Options in invoke.texi
Joe Buck <[EMAIL PROTECTED]> writes: | On Thu, Jan 11, 2007 at 02:08:48AM +0100, Gabriel Dos Reis wrote: | > I'm well aware of the history of "-Winit-self". The issue is more | > subtile that you would like to make it appear. You would have to study | > more carefully the threads relating to this issue. If you dig the | > archive, you should be able to find example of | > | >circular_buffer buf = buf; | > | > [ or void* p = &p; ] | | There isn't really a subtlety; void* p = &p is well-defined, and the same | is true for other cases where only the address, but not the (undefined) | value of the initializer is used. I believe you're interpreting "subtlety" as applying to a different thing than I intended. The subtlety I'm refering to is not that "void* p = &p" is not well-defined, but rather the fact that when we see T t = some-expression-involving-t; we would like to warn for cases where there is a high probability that the *initialization* of "t" *results in undefined behaviour*, as opposed to leaving "t" undefined. -Wunintialized was not designed to handle those cases. That matter is compounded by the fact that some constructs such as circular_buffer buf = buf; are well-formed and not attempt to work around agreed deficiency of -Wunitialized. To do that, it is not clear -- without seeing the body of the copy constructor -- whether only the address is used or not. Please, contrast that with the explanation offered earlier: # It seems to me that the only reason for Winit-self to exists is that # people try to silence the -Wuninitialized warnings using the init-self # hack and then other people have to work-around that hack. | I consider 'int i = i;' a botch that somehow evolved into a promise. I believe most (all?) people agree on that. | I'm not going to re-open the war of 2002, but I was never happy with it. I hope nobody is proposing that. My initial message was an answer to an inaccuracy in a statement. -- Gaby
Re: why Winit-self (was Re: proposal to clean up @node Warning Options in invoke.texi)
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | On 11 Jan 2007 02:08:48 +0100, Gabriel Dos Reis | <[EMAIL PROTECTED]> wrote: | > I'm well aware of the history of "-Winit-self". The issue is more | > subtile that you would like to make it appear. You would have to study | > more carefully the threads relating to this issue. If you dig the | > archive, you should be able to find example of | > | >circular_buffer buf = buf; | > | > [ or void* p = &p; ] | | Sorry for being so slow but I don't get it. neither Winit-self nor | Wuninitialized warn for void *p=&p; so how that example justifies the | existence of Winit-self ? Consider again circular_buffer buf = buf; That is an example of code that is not written to work around -Wunitialized. In parenthesis, I offered "void* p = &p" as an ultimate reduction when the body of the copy constructor of circual_buffer is known, but apparently that had teh side effect of side track many :-( -- Gaby
Making gcc read from the standard input
Hello, Is there a way I can make GCC read a C or C++ code from the standard input instead of from a file? In my application software, I am generating some C code on the fly, writing it to a file, then using GCC to compile it. Instead of that, I want to invoke GCC through a pipe, and write the C code directly into GCC, instead of writing it into a file and then calling GCC. Is this possible? Regards, Tathagato Rai Dastidar Prinicipal Software Engineer, National Semiconductor Corp.
Re: proposal to clean up @node Warning Options in invoke.texi
On Thu, Jan 11, 2007 at 04:09:16AM +0100, Gabriel Dos Reis wrote: > The subtlety I'm refering to is not that "void* p = &p" is not well-defined, > but rather the fact that when we see > > T t = some-expression-involving-t; > > we would like to warn for cases where there is a high probability that > the *initialization* of "t" *results in undefined behaviour*, as opposed > to leaving "t" undefined. -Wunintialized was not designed to handle > those cases. That matter is compounded by the fact that > some constructs such as > >circular_buffer buf = buf; > > are well-formed and not attempt to work around agreed deficiency of > -Wunitialized. To do that, it is not clear -- without seeing the body > of the copy constructor -- whether only the address is used or not. There are three cases: either you can be certain that an uninitialized value will be used, or you can be certain that it won't be used, or you don't know because you don't see the body of the copy constructor. Case 1: int i = i; or SomeClass p = p; // compiler-generated copy constructor Case 2: void* p = &p; Case 3: SomeClass p = p; // user-defined copy constructor, can't see the body Case 2 is completely valid. In Case 1 we have uninitialized variables. In Case 3 we cannot tell. There's an argument for not warning in case 3, though unfortunately in my early days of C++ programming I often managed to make mistakes similar to this, and the compiler would not warn.
