Hi all,
I am currently adding floating point support for a private target (for
GCC 4.1.1). i am having some problems with register allocation.
In SF mode, i have specified to the compiler that it can use both
floating point registers as well as data registers. For all move
instructions in SF mod
On Mar 13, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> It treats only "/opt" as a common component of the two paths, rathe
> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
> the last argument, the answer is as I expected. This seems odd to me;
> is it the intended behav
On Mar 9, 2007, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> If I just run autoconf I get errors because I am not
> including the new ltoptions.m4, ltsugar.m4, and ltversion.m4 files.
I'd just prepend them to our local copy of libtool.m4, pretty much
like aclocal would have done into aclocal.m4.
>
On Tue, 13 Mar 2007, Andrew Pinski wrote:
> Anyways the best way to fix this is just to fix the bug. Someone
We should have 0 unexpected FAILs in 4.2.0 on common platforms (in
particular the primary release criteria ones for the testsuites of the
languages in the release criteria). How this is
On 3/13/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
It's true that in development we may not want to XFAIL them - but it's
also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be
released with it. And users installing GCC on common platfor
On Tue, 13 Mar 2007, Andrew Pinski wrote:
> On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote:
> > Hi Janis,
> >
> > While PR 28834 stays open, I'm thinking about XFAILing
> > gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
> > However, I am not having any luck with writing mayalia
Karthikeyan M wrote on 03/13/07 21:32:
> appears as x.j = 10 inside the GIMPLE dump of the function body . Is
> there some place from where I can get it in the following( or any
> other simpler ) form
No, we don't unnecessarily take addresses of variables. Structure
references are left intact.
Interestingly, while...
gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp
-lstdc++ -lm -m32 -o ./pr30703.exe
/usr/bin/ld: Undefined symbols:
__Unwind_Resume
collect2: ld returned 1 exit status
fails on powerpc-apple-darwin8
gcc-4 pr30703.C -fmessage-length=0 -f
[EMAIL PROTECTED] (Mike Stump) writes:
> ../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ:
> ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not
> occur when assuming that (X - c) >= X is always true
> ../../gcc/gcc/var-tracking.c:2961: warning: ass
On Mar 13, 2007, at 6:02 PM, Mike Stump wrote:
../../gcc/gcc/var-tracking.c: In function ‘variable_tracking_main’:
../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow
does not occur when assuming that (X - c) >= X is always true
../../gcc/gcc/var-tracking.c:2961: warning: assum
Hi ,
I am trying to convert GIMPLE representation of a program to XML.
GIMPLE does not seem to lower instances of struct variables
E.g.
struct T{int i, int j}x;
f(){ x.j = 10}
appears as x.j = 10 inside the GIMPLE dump of the function body . Is
there some place from where I can get it in th
../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ:
../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not
occur when assuming that (X - c) >= X is always true
../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not
occur when assum
On Tue, Mar 13, 2007 at 02:07:02PM -0800, Janis Johnson wrote:
> On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
> > Revital1 Eres wrote:
> > >ERROR: tcl error sourcing
> > >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
> > >ERROR: couldn't open
> > >"/ho
I am noticing one other issue with current gcc 4.2 branch
on powerpc-apple-darwin8. We seem to have failures for the
following libgomp testsuite tests...
FAIL: libgomp.c++/pr30703.C -O0 (test for excess errors)
WARNING: libgomp.c++/pr30703.C -O0 compilation failed to produce executable
FAI
The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
Comparing stages 2 and 3
Bootstrap comparison failure!
./java/parse.o differs
./java/parse-scan.o differs
Has anyone else seen this?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Wednesday 14 March 2007 00:36, Scott Brooks wrote:
> When I use &__bss_start, &_end, in a shared library I get the addresses of
> the __bss_start and _end of the main application that has loaded the
> library.
>
> I would like to get the address of the bss/text segments of the shared
> library i
When I use &__bss_start, &_end, in a shared library I get the addresses of the
__bss_start and _end of the main application that has loaded the library.
I would like to get the address of the bss/text segments of the shared library
itself.
Thanks
Scott Brooks
Jack Howarth <[EMAIL PROTECTED]> writes:
> The current gcc 4.2 branch is exhibiting some new
> testsuite failures in the gcc testsuite on powerpc-apple-darwin8.
> /sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/dct.c:6:
> warning: C99 inline functions are
The current gcc 4.2 branch is exhibiting some new
testsuite failures in the gcc testsuite on powerpc-apple-darwin8.
Specifically I now see...
Running
/sw/src/fink.build/gcc42-4.1.-20070312/gcc-4.2-20070312/gcc/testsuite/gcc.dg/vmx/vmx.exp
...
FAIL: gcc.dg/vmx/dct.c -O0 (test for excess
On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
> Revital1 Eres wrote:
> >ERROR: tcl error sourcing
> >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
> >ERROR: couldn't open
> >"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_m
Sunzir Deepur wrote:
I use -da to dump RTL files of the passes.
Is there a way to add the virtual addresses of each directive ?
You can't compute addresses reliably until after reload. Before reload,
the size of each rtl insn is unknown.
My wish is to generate a CFG in which I would know,
On Tue, Mar 13, 2007 at 12:28:22PM -0700, Kazu Hirata wrote:
> Hi Janis,
>
> While PR 28834 stays open, I'm thinking about XFAILing
> gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
> However, I am not having any luck with writing mayalias-2.x. I am
> wondering if you could help me
[EMAIL PROTECTED] wrote:
I was wondering if anyone knew how I could modify gcc to not use static
general purpose registers on an IA-64 machine?
Besides the -ffixed-reg option Vlad mentioned, there is also a
documented IA-64 specific option for this. See the docs. No reason why
this option n
Revital1 Eres wrote:
ERROR: tcl error sourcing
/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
ERROR: couldn't open
"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C":
Note that mainline got changed to xline. Also note that the d
On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
There
Andrew Haley wrote:
> I think removing trailing whitespace would be OK,
Please don't check it in, though! That would be really bad. It would
do horrible things to diffs, particularly between branches.
Not if you run the script on all active branches. Not to say it is
worth it, though.
On 13 March 2007 19:56, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> The intermediate cause is that lreg considers all the special-purpose reg
>> classes when allocating, and for some reason decides that several of the
>> special-purpose classes have equal cost (zero)
"Dave Korn" <[EMAIL PROTECTED]> writes:
> The intermediate cause is that lreg considers all the special-purpose reg
> classes when allocating, and for some reason decides that several of the
> special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I
> find strange about this is
On Tue, Mar 13, 2007 at 09:13:14AM +0200, Revital1 Eres wrote:
>
> Hello,
>
> I get the following error while running
> make check-gcc RUNTESTFLAGS="compat.exp"
> with mainline gcc version 4.3.0 20070312
> on PPC.
> ERROR: tcl error sourcing
> /home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/
Hello Gcc hackers,
I don't even know if what I'm doing is supposed to be possible, but I'm
trying it anyway!
To oversimplify the situation, I've got an external memory-mapped peripheral
that does multiply operations. It's got three SImode registers; you write a
word each to the multipli
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
When I try mayalias-2.x like so:
set torture_eval_before_e
On 3/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
My attempt to build GCC 4.2.0 RC1 failed with:
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899 yes, yes I
have bugzilla memorized.
-- Pinski
> On Mon, Mar 12, 2007 at 04:03:52PM -0700, Steve Ellcey wrote:
> > configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl
>
> Where'd that come from? Wherever it is, it's a bug. Maybe someone
> checked in a typo to the configure file. "dnl" is a comment start
> token in autoconf (tha
My attempt to build GCC 4.2.0 RC1 failed with:
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
This is coming from the G++ Make-lang.in, which does:
doc/g++.1: doc/gcc.1
cp doc/gcc.1 doc/g++.1
However, when we --enable-generated-files-in-srcdir (as we do fo
On 3/13/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> > On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > > Uh, since when did 4.1 support IPA GIMPLE?
> > >
> > >
> >
> > What d
Kai Tietz wrote:
> Ok, I will try for this. I have to find a different editor, which is not
> too smart as to remove trailing whitespaces ...
Or just add -w to the diff options when generating the patch.
Brian
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> > Uh, since when did 4.1 support IPA GIMPLE?
> >
> >
>
> What do you mean by that?
I'm pretty sure there were a number of cgraph and
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> Uh, since when did 4.1 support IPA GIMPLE?
>
>
What do you mean by that?
I'm pretty sure there were a number of cgraph and other related
changes necessary to make IPA work completely th
On 3/13/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Uh, since when did 4.1 support IPA GIMPLE?
What do you mean by that?
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Uh, since when did 4.1 support IPA GIMPLE?
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just ha
On 3/13/07, Jeffrey Law <[EMAIL PROTECTED]> wrote:
On Tue, 2007-03-13 at 18:09 +0100, Paolo Bonzini wrote:
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x,
On Tue, 2007-03-13 at 18:09 +0100, Paolo Bonzini wrote:
> > int x;
> > {
> > int y;
> > {
> > int z;
> > ...
> > }
> > ...
> > }
> >
> > just happens to have three statements, all VAR_DECL,x, y, z, without
> > any reference to the starting and
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side
On 3/13/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side
> int x;
> {
> int y;
> {
> int z;
> ...
> }
> ...
> }
>
> just happens to have three statements, all VAR_DECL,x, y, z, without
> any reference to the starting and ending blocks. As a side question,
> how can I get hand of where the blocks st
Hi all,
In #gcc, it was suggested to use referenced vars to get all the
referenced vars for a function. I added to my IPA pass props,
PROP_referenced_vars , used push_cfun and then
FOR_EACH_REFERENCED_VAR, however, it just segfaults in
tree-flow-inline.h:34 :
hti->slot = table->entries;
It was s
On Mar 13, 2007, at 9:31 AM, Eric Weddington wrote:
At the risk of extending this out further, can someone explain to
me why
using TABs is preferrable
That is just how to the world is.
On Tue, Mar 13, 2007 at 10:31:34AM -0600, Eric Weddington wrote:
> At the risk of extending this out further, can someone explain to me why
> using TABs is preferrable, as they are interpreted, while spaces are
> unambiguous?
If anyone wants to explain this to Eric, please do so off-list.
Let's n
> -Original Message-
> From: Dave Korn [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 13, 2007 9:59 AM
> To: 'Daniel Jacobowitz'
> Cc: 'Andrew Haley'; 'Kai Tietz'; gcc@gcc.gnu.org
> Subject: RE: Question for removing trailing whitespaces (not
> vertical tab) from source
>
> On 13 Ma
Daniel Jacobowitz wrote:
> On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote:
>> It treats only "/opt" as a common component of the two paths, rathe
>> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
>> the last argument, the answer is as I expected. This seems odd
Richard Guenther wrote on 03/13/07 05:57:
> Yes, this is a similar issue as PR30840 on the mainline, the CCP propagator
> goes
> up the lattice in some cases. This is something Diego promised me to look at
> ;)
> But we might be able to paper over this issue in 4.2 ...
I'll take a look later t
Hello,
I use -da to dump RTL files of the passes.
Is there a way to add the virtual addresses of each directive ?
I know that RTL is abstraction and virtual addresses are relevant only
when the actual opcodes are generated.
My wish is to generate a CFG in which I would know, for each basic blo
On Mar 13, 2007, at 8:01 AM, Ian Lance Taylor wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
I think removing trailing whitespace would be OK
Generally speaking, yes, but be aware, there are cases where it
should not be removed. To most, the spots that should not be changed
are obvious, o
Andrew Walrond <[EMAIL PROTECTED]> writes:
> On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
>> ... a little tip. Add this to your c-mode-hook:
>>
>>(set-variable 'show-trailing-whitespace t)
>>
>> And you'll see all the trailing whitespace. On my system it appears
>> bright red.
>>
>
>
On 13 March 2007 15:12, Daniel Jacobowitz wrote:
> On Tue, Mar 13, 2007 at 03:02:44PM -, Dave Korn wrote:
>> Can you explain that value? It's just that 1) I see vast acres and
>> acres of code where the tabstop size is two spaces 2) the coding standard
>> doesn't seem to /demand/ a specific
On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote:
> It treats only "/opt" as a common component of the two paths, rathe
> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
> the last argument, the answer is as I expected. This seems odd to me;
> is it the intended b
On Mon, Mar 12, 2007 at 04:03:52PM -0700, Steve Ellcey wrote:
> configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl
Where'd that come from? Wherever it is, it's a bug. Maybe someone
checked in a typo to the configure file. "dnl" is a comment start
token in autoconf (that's a very r
On Tue, Mar 13, 2007 at 03:02:44PM -, Dave Korn wrote:
> Can you explain that value? It's just that 1) I see vast acres and acres of
> code where the tabstop size is two spaces 2) the coding standard doesn't seem
> to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind o
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Which C type is HOST_WIDE_INT?
It can either be long, or long long depending on if the target needs
it to be 64bits and what size of long on the host.
Isn't the type of the constant always integer_type?
No, it can be POINTER_TYPE, ENUME
Ian Lance Taylor writes:
> I wonder if we could have some sort of svn trigger to check for
> trailing whitespace as a pre-commit check on .c and .h files?
It would be tricky, as we don't want it to barf on spaces that already
were there. The emacs magic works very well for me: I'm sure that I
Jakub Jelinek <[EMAIL PROTECTED]> wrote on 13.03.2007 16:37:34:
> On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote:
> > Feel free to do it to your local copy. Don't do it to the gcc source
> > code repository.
>
> Well, please do it on all your checkings - all lines you have changed
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> On 13 Mar 2007 07:58:41 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64
> > bits.
> >
> > > 1 - Should I use ints for these fields?
> >
> > I don't understand the question.
> >
Kai Tietz <[EMAIL PROTECTED]> writes:
> But I was questioned to do this stuff, for those files changed by a patch
> of mine. So I tought, if I should do, than do it for the complete gcc (not
> root) folder. How to process ?
I don't feel as strongly as Andrew about not removing trailing
whitespa
> Zero is completely acceptable for a null pointer constant in all
> circumstances *except* when passing to a varargs function, which can go
> badly wrong on platforms where the sizeof a pointer is larger than the
> sizeof an int.
This is a serious loophole on such platforms, since the com
On Tue, Mar 13, 2007 at 03:22:50PM +, Andrew Haley wrote:
> Feel free to do it to your local copy. Don't do it to the gcc source
> code repository.
Well, please do it on all your checkings - all lines you have changed
to fix some bug or add a new feature shouldn't have trailing whitespace
and
[EMAIL PROTECTED] wrote:
All-
I was wondering if anyone knew how I could modify gcc to not use static
general purpose registers on an IA-64 machine? Specifically, I only want
the compiler to allocate registers from the register stack engine (RSE)
and the system defined registers (e.g., stack po
Kai Tietz writes:
> Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57:
>
> > Ian Lance Taylor writes:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > > Kai Tietz writes:
> > > >
> > > > > I want to remove some trailing whitespaces from gcc
> > > > > source
On 13 March 2007 15:06, Andrew Haley wrote:
> Dave Korn writes:
> > On 13 March 2007 14:02, Andrew Haley wrote:
> >
> > > Kai Tietz writes:
> > >
> > > > I want to remove some trailing whitespaces from gcc source as coding
> > > style > demands. Also I wrote, while doing a small tool for t
Andrew Haley <[EMAIL PROTECTED]> wrote on 13.03.2007 16:03:57:
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > Kai Tietz writes:
> > >
> > > > I want to remove some trailing whitespaces from gcc source
> as coding style
> > > > demands. Also I wrote, w
All-
I was wondering if anyone knew how I could modify gcc to not use static
general purpose registers on an IA-64 machine? Specifically, I only want
the compiler to allocate registers from the register stack engine (RSE)
and the system defined registers (e.g., stack pointer, global pointer,
etc).
> Kai Tietz writes:
> Also I wrote, while doing a small tool for that, a
> feature to replace horiz. tabs by spaces. But the question is by which
> width should be used ?
Tabs always are equivalent to 8 spaces.
But please DO NOT replace tabs in the GCC sources with spaces.
Ei
On 13 Mar 2007 07:58:41 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH
> fields (tree.def). Each has 32 bits.
No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64
bi
On 3/13/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 13 March 2007 13:52, Paulo J. Matos wrote:
> Hello,
>
> When programming, due to my journeys through C++ recently, I've been
> using 0 instead of NULL. Strangely gcc compilation doesn't warn me
> about it. Is it ok to do this? (So far, I had no
On 3/13/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Dave Korn writes:
> On 13 March 2007 14:02, Andrew Haley wrote:
>
> > Kai Tietz writes:
> >
> > > I want to remove some trailing whitespaces from gcc source as coding
> > style > demands. Also I wrote, while doing a small tool for that,
Dave Korn writes:
> On 13 March 2007 14:02, Andrew Haley wrote:
>
> > Kai Tietz writes:
> >
> > > I want to remove some trailing whitespaces from gcc source as coding
> > style > demands. Also I wrote, while doing a small tool for that, a
> > feature to > replace horiz. tabs by spaces.
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Kai Tietz writes:
> >
> > > I want to remove some trailing whitespaces from gcc source as coding
> > style
> > > demands. Also I wrote, while doing a small tool for that, a feature to
> > > replace horiz. tabs
On 3/13/07, Andrew Walrond <[EMAIL PROTECTED]> wrote:
Doesn't seem to work on xemacs :(
xemacs != emacs
Anyways I was going to say:
Don't
But now we are getting into emacs vs vi vs xemacs which is getting offtopic.
-- Pinski
On 13 March 2007 14:02, Andrew Haley wrote:
> Kai Tietz writes:
>
> > I want to remove some trailing whitespaces from gcc source as coding
> style > demands. Also I wrote, while doing a small tool for that, a
> feature to > replace horiz. tabs by spaces. But the question is by which
> width s
Andrew Haley <[EMAIL PROTECTED]> writes:
> Kai Tietz writes:
>
> > I want to remove some trailing whitespaces from gcc source as coding style
> > demands. Also I wrote, while doing a small tool for that, a feature to
> > replace horiz. tabs by spaces. But the question is by which width shoul
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH
> fields (tree.def). Each has 32 bits.
No, each has type HOST_WIDE_INT. On a 64-bit host they will be 64
bits.
> 1 - Should I use ints for these fields?
I don't understand the questi
On Tuesday 13 March 2007 14:32:38 Andrew Haley wrote:
> ... a little tip. Add this to your c-mode-hook:
>
>(set-variable 'show-trailing-whitespace t)
>
> And you'll see all the trailing whitespace. On my system it appears
> bright red.
>
Doesn't seem to work on xemacs :(
Andrew Walrond
... a little tip. Add this to your c-mode-hook:
(set-variable 'show-trailing-whitespace t)
And you'll see all the trailing whitespace. On my system it appears
bright red.
Andrew.
Kai Tietz writes:
> I want to remove some trailing whitespaces from gcc source as coding style
> demands. Also I wrote, while doing a small tool for that, a feature to
> replace horiz. tabs by spaces. But the question is by which width should
> be used ?
8.
Andrew.
Hello,
I want to remove some trailing whitespaces from gcc source as coding style
demands. Also I wrote, while doing a small tool for that, a feature to
replace horiz. tabs by spaces. But the question is by which width should
be used ? The gcc source was written by using different tab widths :(
On 13 March 2007 13:52, Paulo J. Matos wrote:
> Hello,
>
> When programming, due to my journeys through C++ recently, I've been
> using 0 instead of NULL. Strangely gcc compilation doesn't warn me
> about it. Is it ok to do this? (So far, I had no problems). Is there
> anything I should be aware
Hello,
When programming, due to my journeys through C++ recently, I've been
using 0 instead of NULL. Strangely gcc compilation doesn't warn me
about it. Is it ok to do this? (So far, I had no problems). Is there
anything I should be aware when using 0 instead of NULL in gcc code?
Cheers,
--
Pau
Hello all,
INTEGER_CST seems to have TREE_INT_CST_LOW and TREE_INT_CST_HIGH
fields (tree.def). Each has 32 bits.
1 - Should I use ints for these fields?
2 - If the INTEGER_CST is negative, is the negative part only in one
of the high or low fields, i.e. low is always unsigned and high is
always s
On 3/12/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 3/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Here are some GCC 4.2.0 P1s which I think it would be good for GCC to
> have resolved before the release, together with names of people I'd like
> to volunteer to help. (Naturally, I have
88 matches
Mail list logo
