Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Ok, so the mist is clearing. We produce assembly, including directives, etc, and target gputils initially (because it exists, and it works), and then later, do a port for binutils. Is there anyone thats familiar with any of the other microcontroller ports like the AVR port, so that we can try learn from mistakes there, and gain some experience? From: Mike Stump <[EMAIL PROTECTED]> To: "Colm O' Flaherty" <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller Date: Mon, 13 Mar 2006 11:16:38 -0800 On Mar 13, 2006, at 5:29 AM, Colm O' Flaherty wrote: I've been thinking a bit more about this (no code yet: I was busy trying to find and fix a bug in gpsim), and I'm still not sure what the optimal development mode is.. by this, I mean.. "what should the proposed PIC port of GCC produce"? If 100% of the ports produce assemble files, then, you'll want to produce assembly files. 100% of the ports produce assembly. There are pros and cons to both approaches. Producing a hex file is (a lot?) more work, and would duplicate the work of gputils, but would leave gcc as a standalone tool, which I presume is desirable! Nope. The issue here is that that gcc would then become "bound" to gputils, Not a problem, though, we'd prefer that you did up a binutils port as well. The reason is that those utilities have a certain feature set that other tools don't have, and that feature set is used and it useful to the compiler and users. Also, it is possible to do up a port first to gputils and then later to enhance it to target binutils, while retaining the ability to still target gputils, if people find that interesting. The real issue here, for me, is the level of duplication / overlap with the SDCC project. Don't worry, they can come join us and stop duplicating our work after you get a port going.
Re: r112028 - in /trunk: configure gcc/fortran/Chan...
On Mon, 2006-03-13 22:49:57 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: pault
> Date: Mon Mar 13 22:49:56 2006
> New Revision: 112028
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112028
> 2006-03-13 Paul Thomas <[EMAIL PROTECTED]>
>
> Modified:
> trunk/configure
[...]
-
# Guess values for system-dependent variables and create Makefiles.
-# Generated automatically using autoconf version 2.13
-# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
+# Generated by GNU Autoconf 2.59.
#
+# Copyright (C) 2003 Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.
[...]
It seems this broke building a cross-compiled native compiler for me
(vax-linux-uclibc target) during 'make all-gcc'
(target=host=vax-linux-uclibc, build=i686-linux):
gcc -c -DIN_GCC -static -DGENERATOR_FILE -I. -Ibuild
-I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc
-I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/build
-I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../include
-I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libcpp/include
-I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libdecnumber
-I../libdecnumber-o build/errors.o
/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/errors.c
gcc -DIN_GCC -static -DGENERATOR_FILE -o build/genmodes \
build/genmodes.o build/errors.o
../build-i686-pc-linux-gnu/libiberty/libiberty.a
/usr/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o):
Relocations in generic ELF (EM: 75)
/usr/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o):
Relocations in generic ELF (EM: 75)
../build-i686-pc-linux-gnu/libiberty/libiberty.a: could not read symbols: File
in wrong format
collect2: ld returned 1 exit status
make[1]: *** [build/genmodes] Error 1
make[1]: Leaving directory
`/tmp/build-temp-vax-linux-uclibc/build/gcc1-native/gcc'
make: *** [all-gcc] Error 2
#-Stop at 20060313-233751-UTC with ret=2 in
/tmp/build-temp-vax-linux-uclibc/build/gcc1-native: make all-gcc
It seems it is now building/linking libiberty compiled for the build
system, not for the host system:-)
Last known successfull build log:
http://lug-owl.de/~jbglaw/gcc-buildlog/build-vax-linux-uclibc.ack
Failed build:
http://lug-owl.de/~jbglaw/gcc-buildlog/build-vax-linux-uclibc.nack
This was configured with:
CC="vax-linux-uclibc-gcc" LDFLAGS=-static CFLAGS=-static\
ac_cv_func_strncmp_works=yes\
execute "${GCC_SRC}/configure" \
--disable-multilib \
--with-newlib \
--disable-nls \
--enable-threads=no \
--disable-threads \
--enable-symvers=gnu\
--enable-__cxa_atexit \
--disable-shared\
--host="vax-linux-uclibc" \
--build="`${BINUTILS_SRC}/config.guess`"\
--host="vax-linux-uclibc" \
--target="vax-linux-uclibc" \
--prefix=/usr \
--enable-languages="c"
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
signature.asc
Description: Digital signature
template class scoping rules
Hi
This cut down example does not compile with gcc 3.4.x / 4.0.x or 4.1.0.
test.cpp: In constructor 'Three::Three()':
test.cpp:20: error: 'm_Public' was not declared in this scope
It does compile with VS2005 / VS6
class One
{
public:
One();
~One();
public:
int m_Public;
};
template class Two : public One
{
public:
Two() {m_Public = 0;}
};
template class Three : public Two
{
public:
Three() {m_Public = 0;}
};
this fixes it.
template class Three : public Two
{
public:
Three() {Two::m_Public = 0;}
};
any ideas ?
regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com Admin: [EMAIL PROTECTED]
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.
This message has been checked by MessageLabs
**
Re: Ada subtypes and base types
On Tuesday 14 March 2006 03:16, Waldek Hebisch wrote: > Jeffrey A Law wrote: > > On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote: > > > > > What do you mean by "abuse"? TYPE_MAX_VALUE means maximal value > > > allowed by given type. > > As long as you're *absolutely* clear that a variable with a > > restricted range can never hold a value outside that the > > restricted range in a conforming program, then I'll back off > > the "abuse" label and merely call it pointless :-) > > > > The scheme you're using "promoting" to a base type before all > > arithmetic creates lots of useless type conversions and means > > that the optimizers can't utilize TYPE_MIN_VALUE/TYPE_MAX_VALUE > > anyway. ie, you don't gain anything over keeping that knowledge > > in the front-end. > > > > Pascal arithmetic essentially is untyped: operators take integer > arguments and are supposed to give mathematically correct result > (provided all intermediate results are representable in machine > arithmetic, overflow is treated as user error). OTOH for proper > type checking front end have to track ranges associated to > variables. So "useless" type conversions are needed due to > Pascal standard and backend constraints. > > I think that it is easy for back end to make good use of > TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment > > x := y + z * w; > > where variables y, z and w have values in the interval [0,7] and > x have values in [0,1000]. Pascal converts the above to the > following C like code: > > int tmp = (int) y + (int) z * (int) w; > x = (tmp < 0 || tmp > 1000)? (Range_Check_Error (), 0) : tmp; > > I expect VRP to deduce that tmp will have values in [0..56] and > eliminate range check. This is much the same in Ada. However the Ada runtime and compiler are compiled using a special flag (-gnatp) that turns all checks off. This is not conformant with Ada semantics. If you look at what the front end is generating during a bootstrap, you therefore see it happily converting between types and base types, and completely ignoring the possibility of out-of-range values. Someone inspecting the output of the front-end during a bootstrap could well wonder why it bothers setting TYPE_MIN_VALUE/TYPE_MAX_VALUE, and what the point of all the conversions to and from base types is. The point is that usually there would be range checks all over the place as in Waldek's example, but they have been suppressed. > Also, it should be clear that in the > assigment above artithmetic can be done using any convenient > precision. > > In principle Pascal front end could deduce more precise types (ranges), > but that would create some extra type conversions and a lot > of extra types. Moreover, I assume that VRP can do better job > at tracking ranges then Pascal front end. Duncan.
Re: template class scoping rules
Hi,
Since 3.4, (template-)dependent lookup has been changed to conform
to the standard. In particular, from http://gcc.gnu.org/gcc-3.4/changes.html:
"In a template definition, unqualified names will no longer find members
of a dependent base."
This allows lookups to be bound at template instantiation time.
(Consider the case where Two is specialized after Three is
defined, but before Three is instantiated.)
Two is a dependent base of Three. Another way of qualifying the
name to lookup is to use "this->m_Public".
HTH
Fang
> test.cpp: In constructor 'Three::Three()':
> test.cpp:20: error: 'm_Public' was not declared in this scope
>
> class One
> {
> public:
> One();
> ~One();
>
> public:
> int m_Public;
> };
>
> template class Two : public One
> {
> public:
> Two() {m_Public = 0;}
> };
>
> template class Three : public Two
> {
> public:
> Three() {m_Public = 0;}
> };
Re: bootstrap broken on tunk for combined source tree
Paolo Bonzini schrieb:
> I have a patch. Will keep you posted.
>
> Paolo
>
Now it's completly broken!!!
Configuring stage 1 in ./binutils
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking host system type... config.sub: missing argument
Try `config.sub --help' for more information.
checking target system type... config.sub: missing argument
Try `config.sub --help' for more information.
checking build system type... config.sub: missing argument
Try `config.sub --help' for more information.
checking for strerror in -lcposix... no
checking for a BSD compatible install...
/appl/shared/gnu/Linux/i686-pc-linux-gnu/bin/install -c
checking whether build environment is sane... yes
checking whether gmake sets ${MAKE}... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ld used by GCC...
/appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.1.0/bin/ld
checking if the linker
(/appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.1.0/bin/ld) is GNU ld... yes
checking for /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.1.0/bin/ld option to
reload object files... -r
checking for BSD-compatible nm... nm
checking whether ln -s works... yes
checking how to recognise dependant libraries... unknown
checking for object suffix... o
checking for executable suffix... no
checking for -ranlib... ranlib
checking for -strip... no
checking for strip... strip
updating cache ./config.cache
loading cache ./config.cache within ltconfig
ltconfig: you must specify a host type if you use `--no-verify'
Try `ltconfig --help' for more information.
configure: error: libtool configure failed
gmake[2]: *** [configure-stage1-binutils] Error 1
gmake[2]: Leaving directory
`/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory
`/disk1/SCRATCH/gcc-build/Linux/i686-pc-linux-gnu/gcc-4.2/gcc-4.2'
gmake: *** [all] Error 2
Rainer
--
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim
Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.: +49(0)6142/8272 49
Web: www.tecosim.com
Re: bootstrap broken on tunk for combined source tree
On Tue, 2006-03-14 11:37:07 +0100, Rainer Emrich <[EMAIL PROTECTED]> wrote: > Paolo Bonzini schrieb: > > I have a patch. Will keep you posted. > > > > Paolo > > > Now it's completly broken!!! ...in multiple ways. Using a cross-compiler to build a compiler running on some target is broken for me since r112028, see http://gcc.gnu.org/ml/gcc/2006-03/msg00462.html target=vax-linux-uclibc host=vax-linux-uclibc build=i686-linux-gnu But this seems to be a buglet/problem with newer automake/autoconf tools. MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Line insn notes in modulo-sched
Steven Bosscher <[EMAIL PROTECTED]> wrote on 14/03/2006 01:32:09: > Hi Ayal, > > The SMS implementation in GCC, in modulo-sched.c, uses line notes > to find insn locations, see find_line_note. Why are you using > line notes instead of insn locators? Line notes are on the list > of Things That Should Not Be, and insn locators replace them. Is > there a reason for modulo-sched to rely on loop notes, or is this > just an oversight? The idea was to reorder/duplicate each insn together with its line note (or rather, reorder/duplicate an interval of insns starting from node->first_note until the node->insn itself). Compared to haifa-sched's scheme of saving the notes, reordering the insns, then restoring the notes. The line notes are not used to find insn locations -- we carry them along because we had to. If we no longer need to worry about keeping each line note adjacent to its insn during scheduling, that would simplify things. Please advise. Line notes are also used to dump SMS statistics, but for that any locator will do. Not sure about "loop notes"? Ayal. > > Gr. > Steven
Re: gcc 4.1
On 14. Mrz 2006, at 01:53 Uhr, Mike Stump wrote:
Am I the only one who gets those:
DOMElement.m:283: warning: pointer type mismatch in conditional
expression
I doubt it.
;-)
For stuff like:
objs[1] = _ns ? _ns : (id)null;
or
return [pathes isNotNull] ? pathes : nil;
And here all information that I can use to answer the question has
been stripped.
I assume you refer to the types of the variables. Why would they
matter in the two given cases? Both "(id)null" and "nil" are of type
'id' which in turn should not conflict with any other typed ObjC
reference?
You can find the full source of the file at:
http://svn.opengroupware.org/SOPE/trunk/sope-xml/DOM/DOMElement.m
The relevant section for the first error:
"DOMElement.m:283: warning: pointer type mismatch in conditional
expression"
should be:
---snip---
...
static NSNull *null = nil;
...
- (BOOL)hasAttribute:(NSString *)_localName namespaceURI:(NSString *)
_ns {
id objs[2];
...
objs[1] = _ns ? _ns : (id)null;
...
}
---snap---
Thanks a lot,
Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
Re: bootstrap broken on tunk for combined source tree
Rainer Emrich wrote: Paolo Bonzini schrieb: I have a patch. Will keep you posted. Paolo Now it's completly broken!!! But I didn't commit anything, and not even posted it, because of the breakage... :-) Paolo
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Most existing GCC ports for microcontrollers rely on a matching Binutils port in order to provide an assembler (GAS) and linker (GNU ld). GCC itself always produces assembler output (which may or may not be saved to a file). Colm O' Flaherty wrote: All, I've been thinking a bit more about this (no code yet: I was busy trying to find and fix a bug in gpsim), and I'm still not sure what the optimal development mode is.. by this, I mean.. "what should the proposed PIC port of GCC produce"? .c -> .asm .c -> .hex (or .ihx) There are pros and cons to both approaches. Producing a hex file is (a lot?) more work, and would duplicate the work of gputils, but would leave gcc as a standalone tool, which I presume is desirable! Producing .asm files would also be viable. These files could then be fed into gputils (gpasm, gplink), which would produce the hex file. This is how SDCC operates. The issue here is that that gcc would then become "bound" to gputils, or some tool like it. An added advantage of this approach would be that the result could be visually simulated on a PIC in gpsim (a terrific advantage, if you ask me), with the knowledge of what line of C code is being executed (but running the assembly code). The real issue here, for me, is the level of duplication / overlap with the SDCC project. Any thoughts or preferences? What view would the gcc purists take of these two approaches? How does the existing gcc microcontroller ports operate? Do they produce hex files, or assembly? Colm From: François Poulain <[EMAIL PROTECTED]> To: Gabriele Caracausi <[EMAIL PROTECTED]> CC: 'Colm O' Flaherty' <[EMAIL PROTECTED]>,[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: RE: GCC Port (gcc backend) for Microchip PICMicro microcontroller Date: Wed, 08 Mar 2006 20:16:39 +0100 I am interested by your work, you can share it. What was your Gcc development version ? Le mercredi 08 mars 2006 à 18:56 +0100, Gabriele Caracausi a écrit : > Hi Francois, Colm, > > I've read your emails and I'd like to be involved in this project. > > As you can read in my past emails in the GCC ML, I've tried two years ago to create a porting of GCC to PIC 18FXXX. > > The project was developed when I was student without a truly and strong guide in all involved activities. > My proposal is: I could share the code I've developed but, keep in mind, that the code should contain some error. > > Starting from it, we could continue / modify / correct / improve the porting all together. What do you think about it ? > > Ciao! > Gabriele. > > > > > > > -Original Message- > From: Franзois Poulain [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 7:56 PM > To: Colm O' Flaherty > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller > > > Like you, I'm still studying the internals of gcc, but I'm close to > > being confident enough to start making some changes. > > Nice ! > > Le lundi 06 mars 2006 а 17:17 +, Colm O' Flaherty a йcrit : > > Francois, > > > > There are only 35 instructions in the 14 bit instruction set, and > > given that, in gcc, the main initial work seems to be in describing > > the targets instruction set, it might not take much to find out what > > implementation issues will occur, by just taking to the time to describe the instructions. > > For me, the things that I suspect to be issues are: > > > > -8 bit ALU > > -small memory space > > -limited stack space (8 levels on 16F) -the number of PIC devices > > (configurations) that would need to be supported (with the various > > number of banks, and memory configs) > > > > Like you, I'm still studying the internals of gcc, but I'm close to > > being confident enough to start making some changes. > > > > Colm >
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
Note that there is some interesting documentation regarding adding a new backend (PIC, for example), and general gcc development issues at: http://gcc.gnu.org/readings.html This section answers a couple of the questions I have already asked, or was about to ask! RTFM, I guess.. :) In the absence of a binutils package for PIC, we could use gputils initially to save time, and then, at a later point in time, add the binutils package. Most existing GCC ports for microcontrollers rely on a matching Binutils port in order to provide an assembler (GAS) and linker (GNU ld). GCC itself always produces assembler output (which may or may not be saved to a file). Colm O' Flaherty wrote: All, I've been thinking a bit more about this (no code yet: I was busy trying to find and fix a bug in gpsim), and I'm still not sure what the optimal development mode is.. by this, I mean.. "what should the proposed PIC port of GCC produce"? .c -> .asm .c -> .hex (or .ihx) There are pros and cons to both approaches. Producing a hex file is (a lot?) more work, and would duplicate the work of gputils, but would leave gcc as a standalone tool, which I presume is desirable! Producing .asm files would also be viable. These files could then be fed into gputils (gpasm, gplink), which would produce the hex file. This is how SDCC operates. The issue here is that that gcc would then become "bound" to gputils, or some tool like it. An added advantage of this approach would be that the result could be visually simulated on a PIC in gpsim (a terrific advantage, if you ask me), with the knowledge of what line of C code is being executed (but running the assembly code). The real issue here, for me, is the level of duplication / overlap with the SDCC project. Any thoughts or preferences? What view would the gcc purists take of these two approaches? How does the existing gcc microcontroller ports operate? Do they produce hex files, or assembly? Colm From: François Poulain <[EMAIL PROTECTED]> To: Gabriele Caracausi <[EMAIL PROTECTED]> CC: 'Colm O' Flaherty' <[EMAIL PROTECTED]>,[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] Subject: RE: GCC Port (gcc backend) for Microchip PICMicro microcontroller Date: Wed, 08 Mar 2006 20:16:39 +0100 I am interested by your work, you can share it. What was your Gcc development version ? Le mercredi 08 mars 2006 à 18:56 +0100, Gabriele Caracausi a écrit : > Hi Francois, Colm, > > I've read your emails and I'd like to be involved in this project. > > As you can read in my past emails in the GCC ML, I've tried two years ago to create a porting of GCC to PIC 18FXXX. > > The project was developed when I was student without a truly and strong guide in all involved activities. > My proposal is: I could share the code I've developed but, keep in mind, that the code should contain some error. > > Starting from it, we could continue / modify / correct / improve the porting all together. What do you think about it ? > > Ciao! > Gabriele. > > > > > > > -Original Message- > From: Franзois Poulain [mailto:[EMAIL PROTECTED] > Sent: Monday, March 06, 2006 7:56 PM > To: Colm O' Flaherty > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller > > > Like you, I'm still studying the internals of gcc, but I'm close to > > being confident enough to start making some changes. > > Nice ! > > Le lundi 06 mars 2006 а 17:17 +, Colm O' Flaherty a йcrit : > > Francois, > > > > There are only 35 instructions in the 14 bit instruction set, and > > given that, in gcc, the main initial work seems to be in describing > > the targets instruction set, it might not take much to find out what > > implementation issues will occur, by just taking to the time to describe the instructions. > > For me, the things that I suspect to be issues are: > > > > -8 bit ALU > > -small memory space > > -limited stack space (8 levels on 16F) -the number of PIC devices > > (configurations) that would need to be supported (with the various > > number of banks, and memory configs) > > > > Like you, I'm still studying the internals of gcc, but I'm close to > > being confident enough to start making some changes. > > > > Colm >
Build error on trunk due to new ./configure (was: r112028 - in /trunk: configure gcc/fortran/Chan...)
On Tue, 2006-03-14 09:56:40 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-03-13 22:49:57 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> # Guess values for system-dependent variables and create Makefiles.
> -# Generated automatically using autoconf version 2.13
> -# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
> +# Generated by GNU Autoconf 2.59.
> #
> +# Copyright (C) 2003 Free Software Foundation, Inc.
> # This configure script is free software; the Free Software Foundation
> # gives unlimited permission to copy, distribute and modify it.
> [...]
>
> It seems this broke building a cross-compiled native compiler for me
> (vax-linux-uclibc target) during 'make all-gcc'
> (target=host=vax-linux-uclibc, build=i686-linux):
>
> gcc -c -DIN_GCC -static -DGENERATOR_FILE -I. -Ibuild
> -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc
> -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/build
> -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../include
> -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libcpp/include
> -I/tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/../libdecnumber
> -I../libdecnumber-o build/errors.o
> /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/errors.c
> gcc -DIN_GCC -static -DGENERATOR_FILE -o build/genmodes \
> build/genmodes.o build/errors.o
> ../build-i686-pc-linux-gnu/libiberty/libiberty.a
> /usr/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o):
> Relocations in generic ELF (EM: 75)
> /usr/bin/ld: ../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o):
> Relocations in generic ELF (EM: 75)
> ../build-i686-pc-linux-gnu/libiberty/libiberty.a: could not read symbols:
> File in wrong format
> collect2: ld returned 1 exit status
> make[1]: *** [build/genmodes] Error 1
> make[1]: Leaving directory
> `/tmp/build-temp-vax-linux-uclibc/build/gcc1-native/gcc'
> make: *** [all-gcc] Error 2
> #-Stop at 20060313-233751-UTC with ret=2 in
> /tmp/build-temp-vax-linux-uclibc/build/gcc1-native: make all-gcc
[...]
> This was configured with:
>
> CC="vax-linux-uclibc-gcc" LDFLAGS=-static CFLAGS=-static \
> ac_cv_func_strncmp_works=yes \
> execute "${GCC_SRC}/configure"
> \
> --disable-multilib\
> --with-newlib \
> --disable-nls \
> --enable-threads=no \
> --disable-threads \
> --enable-symvers=gnu \
> --enable-__cxa_atexit \
> --disable-shared \
> --host="vax-linux-uclibc" \
> --build="`${BINUTILS_SRC}/config.guess`" \
> --host="vax-linux-uclibc" \
> --target="vax-linux-uclibc" \
> --prefix=/usr \
> --enable-languages="c"
Former version of the toplevel ./configure seem to have stripped the
CC variable when calling ./configure to build libiberty for the build
system.
When the new toplevel ./configure builds libiberty for the build
system:
mkdir -p -- build-i686-pc-linux-gnu/libiberty
Configuring in build-i686-pc-linux-gnu/libiberty
configure: creating cache ../config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo
checking for perl... perl
checking build system type... i686-pc-linux-gnu
checking host system type... vax-dec-linux-uclibc
checking for vax-linux-uclibc-ar... vax-linux-uclibc-ar
checking for vax-linux-uclibc-ranlib... vax-linux-uclibc-ranlib
checking for vax-linux-uclibc-gcc... vax-linux-uclibc-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether vax-linux-uclibc-gcc accepts -g... yes
checking for vax-linux-uclibc-gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... vax-linux-uclibc-gcc -E
checking whether vax-linux-uclibc-gcc accepts -Wc++-compat... yes
checking whether vax-linux-uclibc-gcc and cc understand -c and -o together...
yes
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No wonder that `genmode' cannot be linked with
../buil
Re: Build error on trunk due to new ./configure (was: r112028 - in /trunk: configure gcc/fortran/Chan...)
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote: Among other differences, it decides that we're cross-building, which isn't true in this case. This results in vax-linux-uclibc-gcc being used to build libiberty for the build system (which is i686-linux-gnu). No wonder that `genmode' cannot be linked with ../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a VAX-ELF file) :-) This was just fixed by: 2006-03-14 Richard Guenther <[EMAIL PROTECTED]> * configure: Regenerate with autoconf 2.13. Please update and try again. -- Pinski
Re: Build error on trunk due to new ./configure (was: r112028 - in /trunk: configure gcc/fortran/Chan...)
On Tue, 2006-03-14 08:56:38 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote: > >Among other differences, it decides that we're cross-building, which > >isn't true in this case. This results in vax-linux-uclibc-gcc being > >used to build libiberty for the build system (which is > >i686-linux-gnu). No wonder that `genmode' cannot be linked with > >../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a > >VAX-ELF file) :-) > > This was just fixed by: > 2006-03-14 Richard Guenther <[EMAIL PROTECTED]> > > * configure: Regenerate with autoconf 2.13. > > Please update and try again. Done, builds again. Thanks, Jan-Benedict -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: Line insn notes in modulo-sched
On 3/14/06, Ayal Zaks <[EMAIL PROTECTED]> wrote: > The line notes are not used to find insn locations -- we carry them along > because we had to. If we no longer need to worry about keeping each line > note adjacent to its insn during scheduling, that would simplify things. > Please advise. You should not have to carry them around. > Not sure about "loop notes"? They do not exist anymore. Gr. Steven
Re: Problem with pex-win32.c
>Here is a sample program which does the right thing (no spurious console >windows, all output visible) when run either from a console or from a >console-free environment, such as a Cygwin xterm. This is the code >we'll be working into libiberty -- unless someone has a better solution! The potential problem I see is in all the code you haven't written yet. There's a fair amount of work that the MSVCRT library does that isn't reflected in your code, like PATH searching, adding filename suffixes (eg. ".EXE"), and converting the argv array into a command tail. It even uses undocumented parameters to CreateProces() to pass file descriptor flags to the new process. While you can probably ignore the later behaviour, subtle differences in the other behaviours could cause problems. Is this really worth it? Could this whole problem be solved by you switching to rxvt? Maybe the only problem is that your xterm is broken. Ross Ridge
Re: gcc autovectorization question
Hello, On 3/13/06, Thomas Yeh <[EMAIL PROTECTED]> wrote: > > > Hi All, > > I am trying to use the latest autovectorization gcc code to generate > functionally correct SSE instructions, and I have the following questions: > > Where is the latest stable gcc version with autovector? (is this 4.1.0?) > and where is the latest development code for this? (off of the SVN?) Auto vectorization features are developed on autovect-branch. Once they are stable they are contributed to main GCC development branch. If you concentrate on released GCC only then GCC 4.1.0 has lastet auto vectorization features. And many more are being added into GCC 4.2.0, which is under development. See, http://gcc.gnu.org/projects/tree-ssa/vectorization.html for more info. > > Initially, I want to use code that will generate functional code for my > application. After I familiarize myself with the existing code, I plan to > contribute to this work. That's great! - Devang
RE: Problem with pex-win32.c
On 14 March 2006 18:52, Ross Ridge wrote: >> Here is a sample program which does the right thing (no spurious console >> windows, all output visible) when run either from a console or from a >> console-free environment, such as a Cygwin xterm. This is the code >> we'll be working into libiberty -- unless someone has a better solution! > > The potential problem I see is in all the code you haven't written yet. > There's a fair amount of work that the MSVCRT library does that isn't > reflected in your code, like PATH searching, adding filename suffixes > (eg. ".EXE"), and converting the argv array into a command tail. I don't understand why you think Mark's code needs to search the PATH or append '.exe', when it invokes CreateProcess that does all that for you? > Is this really worth it? Could this whole problem be solved by you > switching to rxvt? Maybe the only problem is that your xterm is broken. Nothing is "broken". The problem is that Cygwin applications run in a slightly special environment, where there may not be a console attached to the shell window. This is not a problem for cygwin apps, but it can be for non-cygwin-aware apps launched from inside cygwin's 'special' environment that may assume that the standard win32 assumptions hold. This is a consequence of cygwin providing features over and above the underlying OS: software written for the underlying OS can't be aware of every possible OS extension. cheers, DaveK -- Can't think of a witty .sigline today
Re: Build error on trunk due to new ./configure
Andrew Pinski wrote: On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote: Among other differences, it decides that we're cross-building, which isn't true in this case. This results in vax-linux-uclibc-gcc being used to build libiberty for the build system (which is i686-linux-gnu). No wonder that `genmode' cannot be linked with ../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a VAX-ELF file) :-) This was just fixed by: 2006-03-14 Richard Guenther <[EMAIL PROTECTED]> * configure: Regenerate with autoconf 2.13. Please update and try again. -- Pinski
Re: Build error on trunk due to new ./configure
Andrew (and everybody else), I upgraded autoconf because the build crashed when I tried to regenerate the fortran library. There were already symbols present that were not recognised by my autoconf (I kept no record of which - it was the default with FC3). I upgraded to the version recommended in the error message.. i686-linux-gnu). No wonder that `genmode' cannot be linked with ../build-i686-pc-linux-gnu/libiberty/libiberty.a (which is now a VAX-ELF file) :-) This was just fixed by: 2006-03-14 Richard Guenther <[EMAIL PROTECTED]> * configure: Regenerate with autoconf 2.13. ..thanks, Richard. I did not realise that there would be this fall-out from the upgrade - equally, though, the pollution was already there. Cheers Paul
Re: Problem with pex-win32.c
> > Is this really worth it? Could this whole problem be solved by you > > switching to rxvt? Maybe the only problem is that your xterm is broken. > > Nothing is "broken". The problem is that Cygwin applications run in a > slightly special environment, where there may not be a console attached to > the shell window. This is not a problem for cygwin apps, but it can be for > non-cygwin-aware apps launched from inside cygwin's 'special' environment > that may assume that the standard win32 assumptions hold. This is a > consequence of cygwin providing features over and above the underlying OS: > software written for the underlying OS can't be aware of every possible OS > extension. The problem isn't unique to cygwin. The same problems occur in any environment that doesn't run inside a win32 console window. eg. most IDEs, including Eclipse and MS Visual Studio. Paul
RE: Problem with pex-win32.c
On 14 March 2006 19:22, Paul Brook wrote: >>> Is this really worth it? Could this whole problem be solved by you >>> switching to rxvt? Maybe the only problem is that your xterm is broken. >> >> Nothing is "broken". The problem is that Cygwin applications run in a >> slightly special environment, where there may not be a console attached to >> the shell window. This is not a problem for cygwin apps, but it can be for >> non-cygwin-aware apps launched from inside cygwin's 'special' environment >> that may assume that the standard win32 assumptions hold. This is a >> consequence of cygwin providing features over and above the underlying OS: >> software written for the underlying OS can't be aware of every possible OS >> extension. > > The problem isn't unique to cygwin. The same problems occur in any > environment that doesn't run inside a win32 console window. eg. most IDEs, > including Eclipse and MS Visual Studio. > > Paul Well, cygwin knows about this, and takes steps when launching a new process to not let it get confused if it doesn't have a console attached. Eclipse and MSVC could do likewise. The problem really arises when cygwin has to launch a new non-cygwin process; then there's nothing it can do to stop the child getting confused and generating a new console. cheers, DaveK -- Can't think of a witty .sigline today
Re: Problem with pex-win32.c
Dave Korn writes: >I don't understand why you think Mark's code needs to search the PATH or >append '.exe', when it invokes CreateProcess that does all that for you? I've already answered that question: "subtle differences in the other behaviours could cause problems." The search behaviour and extension handling of CreateProcess() is actually quite a bit different than of MSVCRT's spawn functions. Also, because of the way he uses CreateProcess(), Mark's code as it is now won't search the PATH. >> Is this really worth it? Could this whole problem be solved by you >> switching to rxvt? Maybe the only problem is that your xterm is broken. > > Nothing is "broken". The problem is that Cygwin applications run in >a slightly special environment, where there may not be a console attached >to the shell window. Arguably, not having a console window attached a shell window is broken in the Cygwin environment. >This is not a problem for cygwin apps, but it can be for non-cygwin-aware >apps launched from inside cygwin's 'special' environment that may assume >that the standard win32 assumptions hold. So, in general you can't expect any Win32 console application to work correctly in such a enviroment. Why should Mark expect a Win32 console version gcc to be any different? Hmm... maybe that's best solution, Mark should be using a "native" Cygwin version of gcc and tools. Ross Ridge
Re: Problem with pex-win32.c
On Tuesday 14 March 2006 19:46, Ross Ridge wrote: > Dave Korn writes: > >I don't understand why you think Mark's code needs to search the PATH or > >append '.exe', when it invokes CreateProcess that does all that for you? > > I've already answered that question: "subtle differences in the other > behaviours could cause problems." The search behaviour and extension > handling of CreateProcess() is actually quite a bit different than > of MSVCRT's spawn functions. Also, because of the way he uses > CreateProcess(), Mark's code as it is now won't search the PATH. > > >> Is this really worth it? Could this whole problem be solved by you > >> switching to rxvt? Maybe the only problem is that your xterm is broken. > > > > Nothing is "broken". The problem is that Cygwin applications run in > >a slightly special environment, where there may not be a console attached > >to the shell window. > > Arguably, not having a console window attached a shell window is broken > in the Cygwin environment. How exactly do you suggest implementing this? I'm fairly sure the cygwin people have concluded this is impossible. IIUC the only thing windows considers to be a console is the butt ugly and functionally crippled text window we're trying to avoid. > >This is not a problem for cygwin apps, but it can be for non-cygwin-aware > >apps launched from inside cygwin's 'special' environment that may assume > >that the standard win32 assumptions hold. > > So, in general you can't expect any Win32 console application to work > correctly in such a enviroment. Why should Mark expect a Win32 console > version gcc to be any different? Hmm... maybe that's best solution, > Mark should be using a "native" Cygwin version of gcc and tools. By implication you're saying that you shouldn't able to use gcc from any GUI environment. Cygwin isn't any different to any other process (eg. Eclipse) that want to run and capture the output of "commandline" applications. Paul
gcc: poor log() performance on Intel x86_64
Greetings.
I am experiencing a major performance problem with the log() function on
the x86_64 platform. It can be illustrated with the following little
test program:
testlog.cxx===
#include
main()
{
float f = 0;
for ( int i = 0; i < 1e8; ++i )
f += log( i );
}
==
I compile this twice, on the same machine, once as a 64bit binary and
once as 32bits:
g++ -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog64 testlog.cxx
g++ -m32 -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog32 testlog.cx
Compiler config is:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
When I run the two binaries on the exact same box and time them, I get
the following outputs:
time ./testlog64
13.264u 0.000s 0:13.26 100.0% 0+0k 0+0io 0pf+0w
time ./testlog32
6.960u 0.004s 0:06.96 100.0%0+0k 0+0io 0pf+0w
In other words, the log function is approximately twice as fast in the
32bit binary as it is in the 64bit binary. Does anyone have any idea
what this is caused by or how I could further diagnose the problem? It
seems that using logf() I get approximately identical performance for
both targets, but unfortunately then the results I get are slightly
different for the two, and that's also not acceptable.
Thanks to everyone in advance for any insights you may be able to provide!
Torsten
--
Torsten Rohlfing, PhD SRI International, Neuroscience Program
Research Scientist 333 Ravenswood Ave, Menlo Park, CA 94025
Phone: ++1 (650) 859-3379 Fax: ++1 (650) 859-2743
[EMAIL PROTECTED]http://www.stanford.edu/~rohlfing/
"Though this be madness, yet there is a method in't"
Re: gcc: poor log() performance on Intel x86_64
I think it is a glibc issue.
H.J.
-
On Tue, Mar 14, 2006 at 01:18:34PM -0800, Torsten Rohlfing wrote:
> Greetings.
>
> I am experiencing a major performance problem with the log() function on
> the x86_64 platform. It can be illustrated with the following little
> test program:
>
> testlog.cxx===
> #include
>
> main()
> {
>float f = 0;
>for ( int i = 0; i < 1e8; ++i )
>f += log( i );
> }
> ==
>
> I compile this twice, on the same machine, once as a 64bit binary and
> once as 32bits:
>
> g++ -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog64 testlog.cxx
> g++ -m32 -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog32 testlog.cx
>
> Compiler config is:
>
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
>
> When I run the two binaries on the exact same box and time them, I get
> the following outputs:
>
> time ./testlog64
> 13.264u 0.000s 0:13.26 100.0% 0+0k 0+0io 0pf+0w
>
> time ./testlog32
> 6.960u 0.004s 0:06.96 100.0%0+0k 0+0io 0pf+0w
>
> In other words, the log function is approximately twice as fast in the
> 32bit binary as it is in the 64bit binary. Does anyone have any idea
> what this is caused by or how I could further diagnose the problem? It
> seems that using logf() I get approximately identical performance for
> both targets, but unfortunately then the results I get are slightly
> different for the two, and that's also not acceptable.
>
> Thanks to everyone in advance for any insights you may be able to provide!
> Torsten
>
> --
> Torsten Rohlfing, PhD SRI International, Neuroscience Program
> Research Scientist 333 Ravenswood Ave, Menlo Park, CA 94025
> Phone: ++1 (650) 859-3379 Fax: ++1 (650) 859-2743
> [EMAIL PROTECTED]http://www.stanford.edu/~rohlfing/
>
> "Though this be madness, yet there is a method in't"
Re: scripting interface to GCC ?
Daniel Berlin wrote: > On Mon, 2006-03-13 at 16:25 -0700, Tom Tromey wrote: >>> "Mike" == Mike Mattie <[EMAIL PROTECTED]> writes: >> Mike> Has anyone ever tried to build a scripting interface into the guts of >> Mike> GCC with something like SWIG ? >> >> I've heard of a couple efforts along these lines -- once with Scheme >> and once with Python. I don't know if either used SWIG. Neither one >> was submitted to GCC. Both were obscure enough that, even now, I >> can't really be sure they ever existed :-) > > I will admit i SWIG'd gcc, once, and generated python wrappers, but this > was before tree-ssa, so it wasn't all that useful. > > There is some appeal to being able to prototype passes, etc, in python. > It's a ton of work to get the bindings going though. > > Maybe SWIG is much better than it was, in which case, cool! That was my biggest question about the idea, gcc's internal data structures are very sophisticated. In either event I will find out for myself soon enough. It is good to know that someone else has tried , it would be bizarre if no one had thought of it before. >> Tom >> > >
Re: Problem with pex-win32.c
Ross Ridge wrote: > Arguably, not having a console window attached a shell window is broken > in the Cygwin environment. Paul Brook wrote: > How exactly do you suggest implementing this? The same way Cygwin rxvt implements this. >By implication you're saying that you shouldn't able to use gcc from any GUI >environment. Cygwin isn't any different to any other process (eg. Eclipse) >that want to run and capture the output of "commandline" applications. No, the implication is that I shouldn't expect use in gcc in any GUI enviroment that doesn't create a hidden console window to run console applications with. Fortunately for me, my favourite GUI development enviroment, GNU Emacs, does just that on Windows. I just tested MinGW gcc with Visual Studio 2005 Express, and it gets it right too. No console windows popping up, no output lost. I don't know about Eclipse, but other IDEs and kitchen sink editors, like Code::Blocks, Dev-C++ and gvim seem to work fine other people. If Eclipse doesn't work as well with MinGW and every other Win32 command line compiler or tool, then arguably Eclipse is broken too. Ross Ridge
Re: Problem with pex-win32.c
On Sun, Mar 12, 2006 at 09:16:47PM -0800, Mark Mitchell wrote: >Christopher Faylor wrote: > >> I don't see any reason why cygwin should be causing a console window to >> flash when spawn is used. >> >> Maybe this is something that should be pursued in the Cygwin list. The >> test cases will be useful but please also provide cygcheck output - as >> an attachment, please. > >What cygcheck output would be helpful? I've never run cygcheck until >just now, and it seems to have lots of options. The options as suggested at http://cygwin.com/problems.html . cgf
Re: Problem with pex-win32.c
On Sun, Mar 12, 2006 at 09:43:12PM -0800, Mark Mitchell wrote: >Mark Mitchell wrote: > >> What cygcheck output would be helpful? I've never run cygcheck until >> just now, and it seems to have lots of options. > >By the way, I don't see any reason to suspect that there's a Cygwin bug. > The situation is: > >1. A Cygwin xterm does not have an associated console. ptys are supposed to have invisible consoles associated with them. Since xterm uses an invisible console I still don't see why there should be a console popup. This still sounds like a cygwin problem to me. cgf
Re: Would like to use gcc source code to improve compiler development skills
> I have C/C++/Java programming skills. I have also studied a couple > of books on compiler development. I would like to start with a > project that will provide me with the experience of having > participated in a real compiler development effort. I am interested > in C/C++/Java. If you would like some ideas for some development activities, there is a list for beginners here: http://gcc.gnu.org/projects/beginner.html Cheers, Ben
Re: Problem with pex-win32.c
On Tue, Mar 14, 2006 at 07:59:22PM +, Paul Brook wrote: >On Tuesday 14 March 2006 19:46, Ross Ridge wrote: >> Dave Korn writes: >> >I don't understand why you think Mark's code needs to search the PATH or >> >append '.exe', when it invokes CreateProcess that does all that for you? >> >> I've already answered that question: "subtle differences in the other >> behaviours could cause problems." The search behaviour and extension >> handling of CreateProcess() is actually quite a bit different than >> of MSVCRT's spawn functions. Also, because of the way he uses >> CreateProcess(), Mark's code as it is now won't search the PATH. >> >> >> Is this really worth it? Could this whole problem be solved by you >> >> switching to rxvt? Maybe the only problem is that your xterm is broken. >> > >> > Nothing is "broken". The problem is that Cygwin applications run in >> >a slightly special environment, where there may not be a console attached >> >to the shell window. >> >> Arguably, not having a console window attached a shell window is broken >> in the Cygwin environment. > >How exactly do you suggest implementing this? I'm fairly sure the cygwin >people have concluded this is impossible. No, we haven't. We have, in fact, gone to great lengths to try to ensure that a console is always attached to a tty/pty. >>>This is not a problem for cygwin apps, but it can be for >>>non-cygwin-aware apps launched from inside cygwin's 'special' >>>environment that may assume that the standard win32 assumptions hold. >> >>So, in general you can't expect any Win32 console application to work >>correctly in such a enviroment. Why should Mark expect a Win32 console >>version gcc to be any different? Hmm... maybe that's best solution, >>Mark should be using a "native" Cygwin version of gcc and tools. > >By implication you're saying that you shouldn't able to use gcc from >any GUI environment. Cygwin isn't any different to any other process >(eg. Eclipse) that want to run and capture the output of "commandline" >applications. It is entirely possible that programs which look at their stdin/stdout will be confused when running under a cygwin pty but they should not, in theory, be confused if they try to detect if they have a console attached because there *should* be an invisible console attached to any process running in a pty. cgf
Re: Problem with pex-win32.c
Christopher Faylor wrote: > ptys are supposed to have invisible consoles associated with them. Since > xterm uses an invisible console I still don't see why there should be > a console popup. > > This still sounds like a cygwin problem to me. As a test case, I'd recommend the latest code I posted. If a MinGW application tries to open CONOUT$ with CreateFile, it gets INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is available. Perhaps the handle for the invisible console isn't inheritable? Even if this is a Cygwin problem, it will still make sense for to fix libiberty; we can't assume that all users are using either Cygwin or a console, so we still have to handle the case that there is no console available when we want to spawn another program, with that program's standard streams redirected. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Problem with pex-win32.c
Mark Mitchell wrote: > As a test case, I'd recommend the latest code I posted. If a MinGW > application tries to open CONOUT$ with CreateFile, it gets > INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is > available. I should have said "in a Cygwin xterm" somewhere in that sentence; it can of course open CONOUT$ from a console window. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
buglet in your recent change?
In:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02102.html
you add restrap unconditionally, and yet it was already defined
above, thus causing make to say:
mrs $ make
Makefile:13094: warning: overriding commands for target `restrap'
Makefile:12386: warning: ignoring old commands for target `restrap'
From Makefile.in::
@if gcc-no-bootstrap
# GCC has some more recursive targets, which trigger the old
# (but still current, until the toplevel bootstrap project
# is finished) compiler bootstrapping rules.
GCC_STRAP_TARGETS = bootstrap bootstrap-lean bootstrap2 bootstrap2-
lean bootstrap3 bootstrap3-leanbootstrap4 bootstrap4-lean bubblestrap
quickstrap cleanstrap restrap
.PHONY: $(GCC_STRAP_TARGETS)
$(GCC_STRAP_TARGETS): all-prebootstrap configure-gcc
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
$(HOST_EXPORTS) \
restrap:
@: $(MAKE); $(stage)
rm -rf stage1-$(TARGET_SUBDIR) stage2 stage3 stage4
stageprofile stagefeedback
$(MAKE) $(RECURSE_FLAGS_TO_PASS) all
?
Do you need an:
@if gcc-bootstrap
on the second one?
Re: Problem with pex-win32.c
On Tue, Mar 14, 2006 at 04:56:21PM -0800, Mark Mitchell wrote: >Mark Mitchell wrote: >>As a test case, I'd recommend the latest code I posted. If a MinGW >>application tries to open CONOUT$ with CreateFile, it gets >>INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is >>available. > >I should have said "in a Cygwin xterm" somewhere in that sentence; it >can of course open CONOUT$ from a console window. And, if it can't open CONOUT$ in cygwin's xterm, that's a bug... cgf
Re: Problem with pex-win32.c
Christopher Faylor wrote: > And, if it can't open CONOUT$ in cygwin's xterm, that's a bug... Great! But that's also irrelevant to the broader issue as to whether or not we try to get this right in libiberty. The issue isn't Cygwin; the issue is whether or not we operate correctly when gcc is running without a console and needs to invoke the assembler/linker. I love Cygwin, and if this is a Cygwin bug, I'm thrilled it will be fixed, but that's not the core issue. We can declare that every program that doesn't create invisible console windows to run console programs is broken, but such programs exist, and their users don't want to be told they're broken. Instead, they want GCC to behave correctly in this environment; in fact, our users have specifically reported this problem with 4.1 to us. Criticizing the code I posted because it doesn't handle command-line arguments, etc., is accurate -- but that code is just a test case. The version of libiberty shipped in our 3.4 products does handle quoting command-line arguments to hand them to CreateProcess, etc. We (CodeSourcery) don't particularly care if this code is in mainline libiberty; it's not a lot of code, and completely contained to pex-win32.c. We're just trying to do the right thing by contributing it. It's of course up to the FSF libiberty maintainers (after we get a patch posted, of course) to determine whether or not they want to accept the patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
aapcs apcs-gnu
Hi all, what is the difference beetween this abi? The standard arm procedure call is the first one. What is introduced in the apcs-gnu? Is there some documentation about the last one? Regards Michael This message was sent using IMP, the Internet Messaging Program.
Re: buglet in your recent change?
Mike Stump wrote: In: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02102.html you add restrap unconditionally, and yet it was already defined above, thus causing make to say: Yeah, I had delayed a bit the fix hoping that Dan J. would rip out the old bootstrap mechanism. He did not, so since I have two other small changes (restrap, Rainer Emrich's failure to bootstrap a combined tree, and an Ada fix I have discussed with Arnaud Charlet) and posting it now. I was ready to do so yesterday but the tree was broken. Paolo
