Re: preview of the tree-check pass (Re: gcc project)
It's an interesting system. I wonder if it's powerful enough to express the rather complicated constraints on objects of type va_list. Warnings for violations of those constraints would be valuable - there are common portability errors that could be caught - but it's never been important enough to write a custom check pass for it. If your system can handle it, we could consider (assuming it's included) providing the check file that defines them with GCC as a worked example, maybe even including it in -Wall (which would ensure that your pass got exercised and therefore didn't break through disuse). I describe the constraints in http://gcc.gnu.org/ml/gcc-patches/2002-06/msg01293.html and can explain further if they don't make sense. (I don't swear that I have them perfectly accurate, but I'm pretty sure.) zw
Re: [RFH] negate_expr_p bug?
On Mon, 3 Apr 2006, Roger Sayle wrote:
>
> On Mon, 3 Apr 2006, Richard Guenther wrote:
> >
> > || (TREE_CODE (type) == INTEGER_TYPE
> > && (TREE_CODE (arg1) == INTEGER_CST
> > || TYPE_UNSIGNED (type)
> > || (flag_wrapv && !flag_trapv)))
> >
> > Does this sound reasonable?
>
> Yes, this sounds reasonable. It was not the negate_expr_p call
> that's causing your problems but the overly restrictive guard
> on this transformation. Let me know the results of a bootstrap
> and regression test in case that points out something I've missed.
It didn't show up anything but some missed optimization that is because
a zero with overflow flag is not integer_zerop, but I see you are in
process of fixing this. Other than that I'm a bit nervous if we both
introduce signed overflow because it is undefined and at the same time
pretend it doesn't happen because it is undefined. Like given
a - INT_MIN < a
-> a + INT_MIN < a
-> INT_MIN < 0
which is true, even for a == INT_MIN for which the original expression
didn't contain an overflow. I.e. the following aborts
#include
extern void abort(void);
int foo(int a)
{
return a - INT_MIN < a;
}
int main()
{
if (foo(INT_MIN))
abort ();
return 0;
}
because we fold the comparison to 1. In an intermediate folding we have
return a + -08000 < a;
with
constant
invariant public static overflow -2147483648>
and we continue folding via
/* Transform comparisons of the form X +- C CMP X. */
if ((TREE_CODE (arg0) == PLUS_EXPR || TREE_CODE (arg0) ==
MINUS_EXPR)
&& operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0)
&& ((TREE_CODE (TREE_OPERAND (arg0, 1)) == REAL_CST
&& !HONOR_SNANS (TYPE_MODE (TREE_TYPE (arg0
|| (TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST
&& !TYPE_UNSIGNED (TREE_TYPE (arg1))
&& !(flag_wrapv || flag_trapv
{
...
which doesn't check for overflowed constants (you think the middle-end
shouldn't care for the overflow flag here, yes?) and folds the thing
to true. Note that my proposed patch for folding of X +- CST CMP Y +- CST
_does_ check for overflow flag on CSTs (unnecessarily?).
So, I'm a bit confused as of the whole singed overflow undefined-ness.
Richard.
Facing problem with bit fields, when i am compiling my code with GCC.
Hello,
ISSUE: Facing problem with bit fields, when i am compiling my code with
GCC. It was previously compiled with diab compiler and was working fine.
In our code Union definition is as follows...,
union
{
unsigned_8 indicator;
struct
{
unsigned_8 unused : 6;
unsigned_8 speed :1;
unsigned_8 time:1;
}bit;
}msg;
In code, speed and time bits are set as follows
msg.bit.speed=TRUE;
msg.bit.time=TRUE;
Some where in code there is check for indicator as follows
if(indicator==03) /* this is to check whether speed and time bits are set.
If yes go iside block */
{
}
unused 6 bits are initialized to 0.
This code previously compiled with diab compiler and working fine. Now i am
trying to compile with GCC compiler.
The problem here is
1. If speed and time bits are set, these bits are coming in MSB. That is it
is coming 1100 ( C0 ) instead of 0011 (03 ). That why eventhough
speed and time bits are set, condition is not satisfying because indicator
value is 'C0' not '03'.
2. Compiler is assigning the memory from bottom to top for bit fields in
the structure. Previously in diab compiler it is aligning bits from top to
bottom, with that our code was working fine.
2. I know that these bit fields are compiler dependent. Is there any option
in GCC to set the bit fields from top to bottom ( MSB to LSB )
in structure.
3. As per the client requirement we are not supposed to change the code. I
am looking for any option or any other way to solve this problem.
Please help me in this
Thanks
Mulakkayala
Re: Facing problem with bit fields, when i am compiling my code with GCC.
On 4/5/06, Devendra Mulakkayala <[EMAIL PROTECTED]> wrote: > 2. I know that these bit fields are compiler dependent. Is there any option > in GCC to set the bit fields from top to bottom ( MSB to LSB ) > in structure. > 3. As per the client requirement we are not supposed to change the code. I > am looking for any option or any other way to solve this problem. > > Please help me in this You can use -mms-bitfields on x86 I think. Richard.
Microchip GNU-CC PIC port - script licencing question..
Theres an interesting discussion going on as to whether Microchip Inc is allowed by the GPL to licence linker scripts and some other scripts (their code, not based on a GPL'ed code) when these scripts are all distributed as part of the MPLAB C30, which is a C compiler, based on the GNU CC (gcc) 3.3, which obviously *is* covered by the GPL. Can someone knowledgeable cut to the chase and put us right on what the situation is in this case? How about Richard Stallman? Is he available? (Just kidding, but it would be nice to hear from the man himself). http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1 Thanks, Colm
GCC port for V8-uRISC (8 bit CPU)
Hi, Can somebody please explain to me is it reasonable and possible to port gcc (version 4.xx) to 8 bit cpu architecture. I would appreciate precise explanation why it is possible or not. CPU is V8-uRISC. V8-uRISC Features are: 8-bit ALU 64K byte addressing capability Accumulator (R0) Seven 8-bit General Purpose Registers (R1-R7) Multiple register banks are easily implemented 16-bit Program Counter and Stack Pointer Thanks in advance for all informations. Regards, Nemanja Popov
RE: Microchip GNU-CC PIC port - script licencing question..
On 05 April 2006 13:57, Colm O' Flaherty wrote: > Theres an interesting discussion going on as to whether Microchip Inc is > allowed by the GPL to licence linker scripts and some other scripts (their > code, not based on a GPL'ed code) when these scripts are all distributed as > part of the MPLAB C30, which is a C compiler, based on the GNU CC (gcc) 3.3, > which obviously *is* covered by the GPL. > > Can someone knowledgeable cut to the chase and put us right on what the > situation is in this case? How about Richard Stallman? Is he available? > (Just kidding, but it would be nice to hear from the man himself). > > http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1 > > Thanks, > > Colm A linker script is source code, input to the linker in the same fashion as a .C file is source code input to the compiler. Hence it is not subject to the GPL (unless it constitutes a derived work from an original GPL'd linker script). I don't know what license applies to the built-in and default linker scripts that a binutils compilation generates, so in the lack of any precise information I would advise to assume the GPL covers them by default, since they are derived from templates in the binutils source itself. However if Microchip have written their own entirely new linker scripts, they hold the copyright and may license them however they please. PS: IANARMS! cheers, DaveK -- Can't think of a witty .sigline today
RE: Microchip GNU-CC PIC port - script licencing question..
On 05 April 2006 13:57, Colm O' Flaherty wrote: Addressing specifically the questions in that post you linked to: > > http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/1 > It is a clear case of "mere aggregation". Putting two things into a zip file or tarball together does not suddenly turn one of them into a work derived from the other. The "derived work" refers to the version of gcc derived from the GPL version of gcc. A bunch of scripts delivered alongside that derived work are not part of it; they are not statically linked into gcc at compile time, nor dynamically loaded into it as shared libs, so there can be no question of them being a part of it; they are entirely separate works in their own right. C30 is not "a work that contains gnu CC"; it is a collection of works, only one of which is a work that contains gnu CC in its entirety (with some degree of modifications); the remaining things stand separately. cheers, DaveK -- Can't think of a witty .sigline today
Re: Microchip GNU-CC PIC port - script licencing question..
* Dave Korn <[EMAIL PROTECTED]> [060405 16:19]: > However if Microchip have written their own entirely new linker scripts, > they hold the copyright and may license them however they please. Unless they are used to compile the derivative of gcc. If they are they are most likely "scripts used to control compilation and installation of the executable" and thus need to be available under GPL-compatible terms. Hochachtungsvoll, Bernhard R. Link
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Yes, I have the source code of this backend. It's based on gcc-3.3. You can find an URL to download the source code on the GCC mailing, else I can put it on a FTP server. PoluX
mips-elf target
Hi, Until now i have only build cross toolchains for linux systems. Usually i build crossgcc in 2 parts, one is before glibc is built , the other is after glibc is built. Is there any way where i can skip the step glibc and build the whole gcc compiler. If yes how do i build the whole gcc without glibc. I have binutils for the target already installed. I only need c and c++ languages. I doing it for vr4131 (mips-elf) target. Regards Nik
Re: GCC port for V8-uRISC (8 bit CPU)
I participated in a port to an 8-bit internet toaster 4 years ago (the Ubicom IP2k chip). It's distributed as part of the gcc-3.x releases, but has been dropped from the gcc-4.x distributions. The IP2k was a very restrictive environment, and it took a lot of work to get it to generate really tight code. I'd definely suggest looking at gcc/config/ip2k to see how we did it -Original Message- >From: Nemanja Popov <[EMAIL PROTECTED]> >Sent: Apr 5, 2006 9:50 AM >To: gcc@gcc.gnu.org >Subject: GCC port for V8-uRISC (8 bit CPU) > >Hi, > >Can somebody please explain to me is it reasonable and possible to port gcc >(version 4.xx) to 8 bit cpu architecture. >I would appreciate precise explanation why it is possible or not. > >CPU is V8-uRISC. > >V8-uRISC Features are: > > 8-bit ALU > 64K byte addressing capability > Accumulator (R0) > Seven 8-bit General Purpose Registers (R1-R7) > Multiple register banks are easily implemented > 16-bit Program Counter and Stack Pointer > >Thanks in advance for all informations. >Regards, >Nemanja Popov >
RE: Microchip GNU-CC PIC port - script licencing question..
On 05 April 2006 16:41, Bernhard R. Link wrote: > * Dave Korn <[EMAIL PROTECTED]> [060405 16:19]: >> However if Microchip have written their own entirely new linker scripts, >> they hold the copyright and may license them however they please. > > Unless they are used to compile the derivative of gcc. If they are they are > most likely "scripts used to control compilation and installation of the > executable" and thus need to be available under GPL-compatible terms. Yes, agreed; I was speaking under the assumption (which I didn't check first, naughty me!) that the scripts are for end-users to link the end-user applications that they have compiled /with/ the supplied gcc; it's very common practice to supply custom linker scripts with these toolchains for small embedded hardware boards. If not, then indeed, as you point out, they would be part of the gcc compile infrastructure, and the GPL would apply to them for the same reason it does to the makefiles and configure scripts. Thanks for pointing out the missed assumption in my post! cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC port for V8-uRISC (8 bit CPU)
FWIW we did get really great code generation for the IP2k in the end although it took some rather unpleasant machine-dependent-reorg stuff to work around the fact almost every instruction used a singe 8-bit accumulator registerr :-) Other ports to look at would be the AVR (8-bit RISC with 32 registers) and 68HC11 (more traditional accumulator-style 8-bit CPU). The AVR is a pretty nice clean port. Regards, Dave * -Original Message- * From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On * Behalf Of Alan Lehotsky * Sent: 05 April 2006 17:49 * To: Nemanja Popov; gcc@gcc.gnu.org * Subject: Re: GCC port for V8-uRISC (8 bit CPU) * * I participated in a port to an 8-bit internet toaster 4 years * ago (the Ubicom IP2k chip). * * It's distributed as part of the gcc-3.x releases, but has * been dropped from the gcc-4.x distributions. * * The IP2k was a very restrictive environment, and it took a * lot of work to get it to generate really tight code. * I'd definely suggest looking at gcc/config/ip2k to see how we * did it * * -Original Message- * >From: Nemanja Popov <[EMAIL PROTECTED]> * >Sent: Apr 5, 2006 9:50 AM * >To: gcc@gcc.gnu.org * >Subject: GCC port for V8-uRISC (8 bit CPU) * > * >Hi, * > * >Can somebody please explain to me is it reasonable and * possible to port * >gcc (version 4.xx) to 8 bit cpu architecture. * >I would appreciate precise explanation why it is possible or not. * > * >CPU is V8-uRISC. * > * >V8-uRISC Features are: * > * > 8-bit ALU * > 64K byte addressing capability * > Accumulator (R0) * > Seven 8-bit General Purpose Registers (R1-R7) Multiple register * > banks are easily implemented 16-bit Program Counter and * Stack Pointer * > * >Thanks in advance for all informations. * >Regards, * >Nemanja Popov * > * * *
Re: Microchip GNU-CC PIC port - script licencing question..
On Apr 5, 2006, at 5:57 AM, Colm O' Flaherty wrote: Theres an interesting discussion going on as to whether Microchip Inc is allowed by the GPL Wrong list. gnu.misc.discuss is the right list.
gimplification---gimple tree for C and C++
I have two (maybe dummy) question here: 1) For C programs, gimplification is done in gimplify_function_tree(), which is called (through several caller layers) from toplev_main(). Can someone explain how gimplification is done for C++? Maybe another way to ask it is: I understand cc1 is generated from toplev_main(). But what is the "main entrance" for the compiler for C++ (cc1plus)? 2) If I want to have a procedure to walk the gimple tree for both C and C++ program, i.e., after the tree has been lowered to GIMPLE, where should I add it? I guess this question may be automatically explained after answering above question. Thanks, Sean _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
re hairiness
- Back to look YOUNGER again with your real Hair http://www.hairinesscenter.com * hair loss reduce * gray hair reduce * dandruff reduce and more http://www.hairinesscenter.com/en
re hairiness
- Back to look YOUNGER again with your real Hair http://www.hairinesscenter.com * hair loss reduce * gray hair reduce * dandruff reduce and more http://www.hairinesscenter.com/en
