Problem - compiling Xerces -C++ by GCC 3.4.6 on HPUX

Hi All, I was trying to compile Xerces-C++ source code by GCC 3.4.6 compiler on HP-UX 11.11 platform. I received the following error messages from hp linker. I don't know this is a problem with hplinker , gcc or Xerces. Please see the part of the error message: HPUX/ASCIIRangeFactory.o and HPUX/s

Re: Increment Operator

Hi Mike I tried searching through and got the info like...Expression evaluation depends upon sequence point as well. So if a varibale is getting changed more than once between two adjacent sequence points then it is undefined behaviour and becomes compiler dependent. I tried to convert sourc

Re: 'xxx' may be used uninitialized in this function

As you probably know by now, one can't look at a bug of this sort without a compilable test case. Andrew correctly pointed out that this optimization is affected by (for instance) inlining. Hi Daniel, The function referenced is in a separate compilation unit and even if it were in the same uni

Re: 'xxx' may be used uninitialized in this function

On Wed, Aug 09, 2006 at 09:09:56AM -0700, Bruce Korb wrote: > Here is the real code. The complaint is about pOptTitle. > The compiler is GCC 4.1.1. Both "set*OptFmts" functions > *WILL* set pOptTitle to something. Option level is -O4, so > flow analysis is being done: As you probably know by no

pl1gcc 0.0.12 released

August 2006 This is the twelfth code drop of the GCC front-end for the PL/I programming language. PL/I for GCC is released under the terms of the GNU Public License; version 2. This is mostly a technical release, with some visible user changes. Most notably, the compiler output will now show the

Re: Increment Operator

On Aug 7, 2006, at 2:31 AM, Kapil Dhawan wrote: I am very much confused about Increment Operator implementation. Can somebody send me a link about the gcc implementation. If you don't get any response, please see the source code and the svn history and the mailing list archievs for additiona

Re: 'xxx' may be used uninitialized in this function

> > > There's more to it than that, unless your compiler is very broken. > GCC should not warn for "int x; foo (&x);". Or inlining happened and foo got inlined and really there is a path which could leave x uninitialized. -- Pinski

Re: 'xxx' may be used uninitialized in this function

Here is the real code. The complaint is about pOptTitle. The compiler is GCC 4.1.1. Both "set*OptFmts" functions *WILL* set pOptTitle to something. Option level is -O4, so flow analysis is being done: void optionOnlyUsage( tOptions* pOpts, int ex_code ) { const char * pOptTitle;

Re: 'xxx' may be used uninitialized in this function

On Wed, Aug 09, 2006 at 08:35:42AM -0700, Bruce Korb wrote: > or else: > > extern void yyy( int* zzz __sets_value__ ); > > void foo(void) { >int xxx; > yyy( &xxx ); > > > Where "__sets_value__" implies both that the current value is not > accessed and that it will be set before ret

Re: Followup: [g++] RFH: Is there a way to make gcc place global const class objects in .rodata ?

On 8/9/06, Haase Bjoern (PT-BEU/EMT) <[EMAIL PROTECTED]> wrote: I realized just a bit too late that there is an open bug report for the issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 > Bjoern Haase wrote >Hello, > >Is there a way to place global const objects in .rodata, thus avoiding

'xxx' may be used uninitialized in this function

Hi, I've added `` xxx = 0'' to my code, but nevertheless it would be nice if there were a way to tell the compiler to not worry. If I could not find the right way, I apologize in advance. So, two suggestions: int xxx = __random__; or else: extern void yyy( int* zzz __sets_value__ ); vo

Followup: [g++] RFH: Is there a way to make gcc place global const class objects in .rodata ?

I realized just a bit too late that there is an open bug report for the issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131 > Bjoern Haase wrote >Hello, > >Is there a way to place global const objects in .rodata, thus avoiding construction at program start? So: Sorry for the noise on the li

Re: algol 60 for gcc

Hi Petr, from my experience with copyright assignment and such, the best you can do is to email [EMAIL PROTECTED] and request a personal copyright assignment for GCC. They will send you some forms and a copyright disclaimer for your university. You print this copyright disclaimer, and fill everyt

[OT] RE: algol 60 for gcc

On 08 August 2006 19:57, David Nicol wrote: > On 8/8/06, Petr Machata <[EMAIL PROTECTED]> wrote: > >> I'm trying to make the university to GPL the code and documentation, and >> give up their copyright, so that it could be used without restriction, >> but won't know the outcome until later this y

Re: How gcov handles untested files, prior and after GCC 3.4

Fredrik Johansson wrote: Nathan, if done properly do you think a patch (that again makes it possible to extract the number of source lines in a untested lines) would be accepted? And which way would be the most sutable: to make it the standard behaviour to assume zero counts if no .gcda file are

Re: A question about cp/pt.c:type_unification_real

Kazu Hirata wrote: Hi, I have a question about cp/pt.c:type_unification_real. However, "args" appears to be a parameter list, too. For example, type_unification_real contains code like: Even more confusing is: arg = TREE_VALUE (args); : : if (!TYPE_P (arg)) C

[g++] RFH: Is there a way to make gcc place global const class objects in .rodata ?

Hello, Is there a way to place global const objects in .rodata, thus avoiding construction at program start? The background is that I am trying to develop a fractional number class template for more efficient numerics on targets that don't natively support fast floating point (namely the arm-elf

Re: How gcov handles untested files, prior and after GCC 3.4

Nathan, if done properly do you think a patch (that again makes it possible to extract the number of source lines in a untested lines) would be accepted? And which way would be the most sutable: to make it the standard behaviour to assume zero counts if no .gcda file are found or to enable that fe