Re: Uninitialized use warning message
Kean Johnston wrote:
>> A common situation would be:
>>
>> if (condition) {
>> flag = 1
>> msg = "Hello World";
>> } else
>> flag = 0;[1]
>> ...
>> if (flag)
>> printf ("I say, %s\n", msg);[2]
>>
>> Point [1] is where I "fail" to init 'msg', point [2] is where I
>> use it. I know that the program is safe, and if the flow analysis
>> can relate 'flag' and 'msg' then the warning would go away.
>>
>> Which one would we want listed in the proposed new warning, 1 or 2?
>
> Definately 2. I wont say it is *impossible*, but I think
> it is asking way too much of the compiler to warn about 1.
> It implies a level of understanding of the flow of the
> program that is completely unrealistic. However, warning at
> 2 should be trivial. Where this level of detail in the
> warning is useful is if you have a particularly large function,
> with the variables declared at the top (not at the top of, say,
> and enclosing if() block). Its even worse when the code is
> full of pre-processor conditionals. By telling me that 2
> (or all instances of type 2), it saves me looking at *every*
> usage of msg. It's just plain more useful, IMHO :)
>
> Kean
Yes, [2] tells you where the risk lies, yet in order to fix it [1]
will be very useful. And yes, [1] is harder to do, but that never
stopped any gcc project :-)
In short, let's have [2] now and hope for [1] in the future.
--
Eyal Lebedinsky ([EMAIL PROTECTED])
help: about enum
Hi, Plz help me I want to know, how enums are handled in gcc. How do we map an enum value to the corresponding integer size. What does the option -fshort-enums does. Plz explain me in detail. I could see the difference in the size of enums when I toggle the option. If the option is not given, then all the enum occupy the same 4 bytes irrespective of their value and 2147483647 is the maximum value that can fit in integer. But when I specify the option, the size varies and 2147483647 starts fitting in. Plz explain this behaviour and how does it confirms to standard. I want to know, given an enum value, how do we calculate or determine that what size should the enum occupy. Regards Gaurav
Problem building 3.3.6 (with 3.4.4): xgcc: cannot specify -o with -c or -S and multiple compilations
Can anybody explain what this error might mean? /tmp/gcc-3-3.heretix/work/gcc/xgcc "" -B/tmp/gcc-3-3.heretix/work/gcc/ -nostdinc++ -L/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/gcc-3-3.heretix/work/x86 _64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/bin/ -B/pkg/gcc-3-3/x86_64-unknown-linux-gnu/lib/ -isystem /pkg/gcc-3-3/x86_64-unknown-linux-gnu/in clude -I../../../../gcc-3.3.6/libstdc++-v3/../gcc -I../../../../gcc-3.3.6/libstdc++-v3/../include -I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unkno wn-linux-gnu -I/tmp/gcc-3-3.heretix/work/x86_64-unknown-linux-gnu/libstdc++-v3/include -I../../../../gcc-3.3.6/libstdc++-v3/libsupc++ -g -O2 -D_GNU_SOURCE -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c ../../../../gcc-3.3.6/libstdc++-v3/libsupc++/guard.cc -fPIC -DPIC -o guard.o xgcc: cannot specify -o with -c or -S and multiple compilations make[4]: *** [guard.lo] Error 1 Thanks Andrew Walrond
RE: help: about enum
Hi,
I am sorry, I wrote incorrectly in the earlier mail. That
"I could see the difference in the size of enums when I toggle the option. If
the option is not given, then all the enum occupy the same 4 bytes irrespective
of their value and 2147483647 is the maximum value that can fit in integer. But
when I specify the option, the size varies and 2147483647 starts fitting in".
But
I WANT TO KNOW, HOW ENUMS ARE HANDLED IN GCC. HOW DO WE MAP AN ENUM VALUE TO
THE CORRESPONDING INTEGER SIZE.
WHAT DOES THE OPTION -FSHORT-ENUMS DOES. PLZ EXPLAIN ME IN DETAIL.
I WANT TO KNOW, GIVEN AN ENUM VALUE, HOW DO WE CALCULATE OR DETERMINE THAT WHAT
SIZE SHOULD THE ENUM OCCUPY.
Does all the enum have a same size of 4 bytes or does it varies depending on
the initializing value?
I am not able to understand the behavior of this program
#include
int main()
{
enum abc{
a, b=125, c
};
enum pqr {
p, q=65537, r
};
enum xyz{
x, y=2147483646, z //---(X)
};
enum lmn{
l, m=4294967295, n //---(Y)
};
printf("a=%d %d\n", a, sizeof(a));
printf("c=%d %d\n", c, sizeof(c));
printf("p=%d %d\n", p, sizeof(p));
printf("r=%d %d\n", r, sizeof(r));
printf("x=%d %d\n", x, sizeof(x));
printf("z=%d %d\n", z, sizeof(z));
printf("l=%d %d\n", l, sizeof(l));
printf("n=%d %d\n", n, sizeof(n));
return 0;
}
Plz note that in the line marked (X) if I mension 2147483647 it gives
overflow error.
However it is able to compile with the higher value given in the next enum
(line marked).
The output of this tc is even when fsort-enums option is given.
a=0 4
c=126 4
p=0 4
r=65538 4
x=0 4
z=2147483647 4
l=0 4
n=0 8
However if I mension 2147483648 program compiles again. With output
a=0 4
c=126 4
p=0 4
r=65538 4
x=0 4
z=-2147483647 4
l=0 4
n=0 8
Regards
Gaurav
-Original Message-
From: Gaurav Gautam, Noida
Sent: Saturday, August 27, 2005 1:56 PM
To: 'gcc@gcc.gnu.org'
Subject: help: about enum
Hi,
Plz help me
I want to know, how enums are handled in gcc. How do we map an enum value to
the corresponding integer size.
What does the option -fshort-enums does. Plz explain me in detail.
I could see the difference in the size of enums when I toggle the option. If
the option is not given, then all the enum occupy the same 4 bytes irrespective
of their value and 2147483647 is the maximum value that can fit in integer. But
when I specify the option, the size varies and 2147483647 starts fitting in.
Plz explain this behaviour and how does it confirms to standard.
I want to know, given an enum value, how do we calculate or determine that what
size should the enum occupy.
Regards
Gaurav
Re: Uninitialized use warning message
Kean Johnston <[EMAIL PROTECTED]> writes:
>> A common situation would be:
>> if (condition) {
>> flag = 1
>> msg = "Hello World";
>> } else
>> flag = 0; [1]
>> ...
>> if (flag)
>> printf ("I say, %s\n", msg);[2]
>> Point [1] is where I "fail" to init 'msg', point [2] is where I
>> use it. I know that the program is safe, and if the flow analysis
>> can relate 'flag' and 'msg' then the warning would go away.
>> Which one would we want listed in the proposed new warning, 1 or 2?
>
> Definately 2. I wont say it is *impossible*, but I think
> it is asking way too much of the compiler to warn about 1.
> It implies a level of understanding of the flow of the
> program that is completely unrealistic. However, warning at
> 2 should be trivial.
Unfortunately, it isn't. This warning happens very late in the
processing, after a lot of mangling has been done. Take:
inline int f(int x) {
return x + 1; // 1
}
int g(int a) {
int b;
if (a)
b = 0;
return f(b);// 2
}
You probably want a warning at (2). However, that is long gone and has
been replaced by the code from (1), so at best we could warn at (1),
which would be pretty confusing. (Hmm. Mainline doesn't seem to warn
at all here, but I think this is already somewhere in bugzilla...)
--
Falk
Re: Uninitialized use warning message
program that is completely unrealistic. However, warning at 2 should be trivial. Unfortunately, it isn't. This warning happens very late in the processing, after a lot of mangling has been done. Take: I really mean't to sat trivial by comparison :) The point you raise about all the mangling and reordering and other things that happen to teh code is what I feared would cause the trouble. I just don't know enough about the data structures involved to know if producing the new warninging message is even possible. I dont know how the current warning message is even calculated, and I need to go stare at some code to find out how before I must either give up on this idea or start asking annoying intenals questions :) But at least I know people aren't opposed to the idea, so I wont be wasting my time trying. Kean
Re: Incoming Message
Your file is attached.
Re: 4.2 Project: "@file" support
On Aug 25, 2005, DJ Delorie <[EMAIL PROTECTED]> wrote: > If "@string" is seen, but "string" does not represent an existing > file, the string "@string" is passed to the program as-is. With the terrible side effect of letting people think their applications will just work, but introducing the very serious risk of security problems, leading to, say: gcc: dj:yourpassword:1234:567:DJ: invalid argument instead of gcc: @/etc/passwd: invalid argument Sure this is probably not so much of an issue for GCC (although remote compile servers are not totally unheard of), but it could easily become a very serious problem for other applications that might take filenames from the network and worry about quoting - but not @; those would then need fixing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Need help creating a small test case for g++ 4.0.0 bug
Hi Dan, Reply below. Best regards On Thu, 4 Aug 2005 02:05, Dan Kegel wrote: > "Paul C. Leopardi" <[EMAIL PROTECTED]> wrote: > > So I seem to be left with a large ( >2.5MB ) preprocessed source file. > > Should I try to report the bug using this large file as a test case? > > Sure. But you might want to try using an automated tool > to reduce the test case first. There's one called delta > (or maybe there are several by that name, I'm not sure) > that can do it. I haven't tried them myself yet, but see: > > Original implementation: > http://www.st.cs.uni-sb.de/dd/ > > http://programming.newsforge.com/article.pl?sid=05/06/30/1549248&from=rss > http://www.stanford.edu/class/cs295/asgns/asgn1/asgn.pdf > 2nd implementation?: > http://www.cs.berkeley.edu/~dsw/ I used Daniel S. Wilkerson's delta from http://www.cs.berkeley.edu/~dsw/ and succeeded in reducing my test case enough to file bug 23599. [4.0 Regression] Flag -fstrict-aliasing corrupts iterators http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23599 Thanks!
Re: Redundant limit check for switch
I know nothing about GCC internals, but it appears that it knows
which bits are used in expressions:
unsigned char foo(int x) {
return (x + 1) & 0x0f & 0x0c & 0x3ff;
}
.file "test.c"
.section .text
.p2align 4,,15
.globl _foo
_foo:
pushl %ebp
movl %esp, %ebp
movb 8(%ebp), %al
popl %ebp
incl %eax
andl $12, %eax
ret
.ident "GCC: (GNU) 4.0.0"
Why can't this information be used to optimize comparisons?
Does it work only for consecutive ands?
Or is it just an early constant folding:
return (x + 1) & (0x0f & 0x0c & 0x3ff & 0xff);
?
Piotr
- Original Message -
From: "Paolo Bonzini" <[EMAIL PROTECTED]>
To: "GCC Development" ; <[EMAIL PROTECTED]>; "Diego Novillo"
<[EMAIL PROTECTED]>; "Giovanni Bajo" <[EMAIL PROTECTED]>
Sent: Monday, August 22, 2005 2:24 PM
Subject: Re: Redundant limit check for switch
> >>void Switch4(int x) {
> >>switch (x & 7) {
> >>
> >>}
> >>}
> >>
> >>.globl _Switch4
> >>.def _Switch4; .scl 2; .type 32; .endef
> >>_Switch4:
> >>pushl %ebp
> >>movl %esp, %ebp
> >>movl 8(%ebp), %eax
> >>andl $7, %eax
> >>cmpl $7, %eax
> >>ja L12
> >>jmp *L11(,%eax,4)
> >
> >
> >>cmpl+ja are redundant in both cases.
> >>Do you think it is possible for gcc to optimize them away?
> >
> > I believe VRP could be taught about inferring ranges from bit_and_expr and
> > similar operations. Right?
>
> Yes, but the range check is not emitted until trees are expanded to RTL.
> combine does a lot of simplifications, but unfortunately not this one.
> It is also quite hard to teach combine to *remove* jumps, though it
> has some ability to turn conditional jumps into unconditional.
>
> The attached patch would at least cause simplify-rtx.c to realize that
> (gtu (reg:SI 61) (const_int 7)) is false, but not cause any code
> generation improvement.
>
> Paolo
>
