On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough wrote:
> Richard Guenther wrote:
>>
>> On Sun, Jan 11, 2009 at 7:59 PM, Raoul Gough
>> wrote:
>>
>
> [snip]
>>>
>>> I guess the situation is more complicated in C++, which has explicit
>>> destructors. Consider the following example, which is getting
Here's some code attached that actually works, but is far from perfect.
The 'msvc_prologue' attribute is limited to 32 bit. None of the applications
that try to place hooks are ported to Win64 yet, so it is impossible to tell
what they'll need. Besides, maybe I am lucky that when they appear I can
> movl.s %edi, %edi
> pushl %ebp
> movl.s %esp, %ebp
Have you thought about making .s an assembler command-line flag, so that
this flag could be passed automatically by the compiler under mingw?
Paolo
> Have you thought about making .s an assembler command-line flag, so
> that
> this flag could be passed automatically by the compiler under mingw?
Yes.
For my purposes it is not really suitable, because we have to make sure that
the push %ebp and mov %esp, %ebp are there, no matter what the compi
> For my purposes it is not really suitable, because we have to make sure that
> the push %ebp and mov %esp, %ebp are there, no matter what the compiler
> arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't
> enough, and while I'm at it I can add the .s to the insns anyway.
Quoting Stefan Dösinger :
Here's some code attached that actually works, but is far from perfect.
The 'msvc_prologue' attribute is limited to 32 bit. None of the applications
that try to place hooks are ported to Win64 yet, so it is impossible to tell
what they'll need. Besides, maybe I am luck
Hi everyone,
HEAD isn't building for me right now. Since I haven't tried building
graphite-enabled GCC before, I may be doing something wrong, so I figured I'd
ask questions before opening any PR. (The actual questions are numbered for
those who want to skip the detail.)
I followed the
Hi,
With the help of Janis, the ppc405 tests can
now detect when the scan assembler won't pass.
I moved on to do the same with the ppc440 tests
and noticed that there is no cpp predefine
to know when you are compiled for a ppc440.
$ powerpc-rtems4.10-gcc -mcpu=440 -E - -dM 440
$ powerpc-rtems4.1
On Mon, Jan 12, 2009 at 10:10:18AM -0600, Joel Sherrill wrote:
> The unfortunate thing is that I think these
> tests are really ensuring that MASK_DLMZB is
> used as expected. If this is right, then
> shouldn't there be a cpp predefine similar
> to __NO_LWSYNC__ for dlmzb? And the tests use
> tha
On Mon, 12 Jan 2009, Joel Sherrill wrote:
> The unfortunate thing is that I think these
> tests are really ensuring that MASK_DLMZB is
> used as expected. If this is right, then
> shouldn't there be a cpp predefine similar
> to __NO_LWSYNC__ for dlmzb? And the tests use
> that rather than testin
Hello Dave,
Thanks for testing Graphite on i686-pc-cygwin.
On Mon, Jan 12, 2009 at 9:52 AM, Dave Korn
wrote:
>Hi everyone,
>
> HEAD isn't building for me right now. Since I haven't tried building
> graphite-enabled GCC before, I may be doing something wrong, so I figured I'd
> ask question
Sebastian Pop wrote:
Q3) Why is there C++ in my libppl? Have I done something wrong to get it
there in the first place, or is it supposed to work somehow?
At the end of stage 1, I can work around the problem by manually running
the final link command, but using the (native compiler's) g++ dri
Joseph S. Myers wrote:
On Mon, 12 Jan 2009, Joel Sherrill wrote:
The unfortunate thing is that I think these
tests are really ensuring that MASK_DLMZB is
used as expected. If this is right, then
shouldn't there be a cpp predefine similar
to __NO_LWSYNC__ for dlmzb? And the tests use
that r
On Mon, 12 Jan 2009, Roberto Bagnara wrote:
> I am not sure I understand the question (and I am not familiar with Cygwin).
> The answer to the question "Why is there C++ in my libppl" is that libppl
> is written in C++. The C interface to the PPL, libppl_c, is also written
> in C++. Your descrip
Sebastian Pop wrote:
Hi Seb,
>> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
>> patches for the first two bugs if desired,
>
> I would highly appreciate this.
Righto, will get cracking.
>> but the third part has me totally confused, I don't know what to do
>>
Joseph S. Myers wrote:
> On Mon, 12 Jan 2009, Roberto Bagnara wrote:
>
>> I am not sure I understand the question (and I am not familiar with Cygwin).
>> The answer to the question "Why is there C++ in my libppl" is that libppl
>> is written in C++. The C interface to the PPL, libppl_c, is also wr
On Mon, Jan 12, 2009 at 2:25 PM, Dave Korn
wrote:
> Yep. It particularly shows up on win32 because i) all references have to
> be resolved at final link time in an executable - perhaps by reference to a
> DLL, but they can't just be left dangling to be filled in at runtime by the
> loader as th
Dave Korn wrote:
Roberto, what does ldd show on the various cc1 binaries in the different
stage directories of your most recent bootstrap? I'm guessing you'll see that
the stage 2 cc1 is linked against the system libstdc++ rather than the
newly-bootstrapped one.
$ find . -name cc1
./prev-gcc
Richard Guenther wrote:
On Mon, Jan 12, 2009 at 12:03 AM, Raoul Gough wrote:
Richard Guenther wrote:
[snip]
This is also invalid. You have to use placement new to change the dynamic
type of memory.
Yes, I guess that makes sense. I've modified the example like this:
#includ
On Sat, Jan 10, 2009 at 07:06:48PM +0100, Toon Moene wrote:
> L.S.,
>
> I have kept this under wraps for some weeks because I wanted to be sure
> all Steering Committee members had a chance to review this request - in
> spite of the holiday season.
>
> Now, however, I want to congratulate Danie
20 matches
Mail list logo
