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
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/configu
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_Pub
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 variabl
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
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 a
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 m
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 Sh
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 in
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
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
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 abs
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
> -#
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
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 libiber
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 sh
>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 potent
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.
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 -
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
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 recommen
> > 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
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 environ
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 ex
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
> b
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 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:
>
> te
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 the
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
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 us
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 situat
> 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 lik
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 al
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 poste
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 sen
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
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.
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 ru
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
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
40 matches
Mail list logo
