Re: Error in -Wuninitialized? Should this be reported?

On Sun, Dec 7, 2008 at 4:21 AM, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Hi, > > After spending the better part of the evening finding a bug caused by > an uninitialized pointer I would love to get a Warning about > uninitialized variables from g++ in cases like Foo, Bar and Baz below: > >

Re: Error in -Wuninitialized? Should this be reported?

> In Foo the variable is just uninitialized, in Bar it is definetly used > uninitialized and in Baz it might be used uninitialized. Is there any > -W switch to make g++ detect such errors or is that a shortcomming of > -Wuninitialized? No, there isn't any such switch. It may be a shortcomming of -

Re: Error in -Wuninitialized? Should this be reported?

Goswin von Brederlow wrote: > In Foo the variable is just uninitialized, in Bar it is definetly used > uninitialized and in Baz it might be used uninitialized. Is there any > -W switch to make g++ detect such errors or is that a shortcomming of > -Wuninitialized? Your example is just not what -Wu

Feedback request.

I'm curious as to why I didn't get any responses to my last posts here on 29 / 11 / 2008. http://gcc.gnu.org/ml/gcc/2008-11/ Is it that there's just no interest in my additions here? Or that there's so few people here or that they're dedicated to their own projects? Or did I somehow not get sent o

Re: Feedback request.

On Sun, Dec 7, 2008 at 3:29 PM, Simon Hill <[EMAIL PROTECTED]> wrote: > I'm curious as to why I didn't get any responses to my last posts here > on 29 / 11 / 2008. > http://gcc.gnu.org/ml/gcc/2008-11/ > > Is it that there's just no interest in my additions here? No, both ideas (-Wres and your exte

views on an old subject"--with-sysroot"

Hi All: About "--with-sysroot" option, I got some understanding following but not sure about it. All words are based on gcc-3.4.2. For a native gcc, There are three important macro LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR and STANDARD_INCLUDE_DIR. Gcc built will search headers in directori

Where is DESTDIR got defined in gcc makefile?

Hi all: I am reading gcc's makefile and got such a puzzle. I checked the makefile and found following rules used to install compiler: # Install the compiler executables built during cross compilation. install-common: native $(EXTRA_PARTS) lang.install-common installdirs for file in $

Re: Feedback request.

Steven Bosscher wrote: Don't let yourself be discouraged by a lack of response. This is unfortunately not uncommon in free/open source software projects. Actually I think this is less common in floss projects. In both cases, the best driver is a customer with money, but in the case of FLOSS pr

Re: Where is DESTDIR got defined in gcc makefile?

"Amker.Cheng" wrote: > Here the destination directory is $(DESTDIR)$(libexecsubdir)/, but > where is DESTDIR defined? > I did not find any definition of this variable in both toplevel and > gcc's makefile. It's intentionally not defined anywhere as it's expected to remain unset unless the user ov

Re: Reload generating memory ref in memory ref

Ian Lance Taylor wrote: Michael Eager <[EMAIL PROTECTED]> writes: I'm running into a situation where reload is replacing a pseudo-register in an insn with a memory reference. The problem is that this is happening in a memory ref. The initial pattern is something like (set (reg/v:SI 1) (mem/s:

Re: Reload generating memory ref in memory ref

Richard Henderson wrote: Ian Lance Taylor wrote: Michael Eager <[EMAIL PROTECTED]> writes: I'm running into a situation where reload is replacing a pseudo-register in an insn with a memory reference. The problem is that this is happening in a memory ref. The initial pattern is something like

Re: views on an old subject"--with-sysroot"

Hello： Thanks Kai Ruottu very much for the detailed explanation. At first glance I thought that I might go too far in wrong direction, fortunately, not so bad. Firstly I have to admit that I made a mistake. I will show it by listing codes from cppdefault.c and gcc makefile. All are based on gc

FRAME_GROWS_DOWNWARD and expand_stack_vars

I am working on FRAME_GROWS_DOWNWARD for MIPS and I am seeing two performance issues with the code generated. The first one has to do with the order how expand_stack_vars places locals on the stack. Consider this function (simplified from CSiBE's replaypc-0.4.0.preproc:find-GOPs): f () {

Re: Feedback request.

2008/12/8 Simon Hill <[EMAIL PROTECTED]>: > I'm curious as to why I didn't get any responses to my last posts here > on 29 / 11 / 2008. > http://gcc.gnu.org/ml/gcc/2008-11/ > Hi Simon, I have found in the past that larger posts do not get many if any responses. One thing that might help is to ask

questions about "find_if_case"

Hi, For if-conversion pass (pass_if_after_combine), we can see there're some IF-THEN-ELSE cases which we try to transform. Let's say find_if_case_1, for an example. (1) if (test) goto over; // x not live x = a; goto label; over: becomes x = a;