The MMX registers are aliased onto the x87 floating-point registers,
so they should be saved and restored correctly regardless.
Also, -lpthread is generally some POSIX threading library implemented
by the target OS or libc, not the unfortunately-named GNU Portable
Threads (GNU Pth), which confusin
On 11/19/07, Thomas Schwinge <[EMAIL PROTECTED]> wrote:
> I'm glad that nobody answered. I've been doing nothing wrong. And also
> it's not someone else's fault. But let me tell you what in fact was
> going wrong.
I think the reason why nobody answered is because we are all busy
doing real work
Tuesday 20 November 2007 Tarihinde 03:12:35 yazmıştı:
> Does someone provide a Git mirror of the GCC repository? Or a CVS
> mirror? (With CVS you at least know what to expect...)
Nice people over infradead.org does,
http://git.infradead.org/?p=gcc.git;a=summary .
To clone
git clone git://git.
Hello!
On Sun, Nov 18, 2007 at 08:57:43PM +0100, I wrote:
> What am I doing wrong if building the trunk natively on i686-pc-gnu-linux
> with ``--disable-nls --enable-languages=c --with-arch=i586'' has been
> failing as follows for several days already?
> In file included from ../../../trunk/libgc
Hello people, i've a question.
"Is it safe the code generation when GCC is using the options
-lpthread and -mmmx -msse -msse2 -msse3 -msse4?"
The GNU Portable Threads (of -lpthread) uses longjmp/setjmp that
saves general purpose registers but not SIMD registers.
GCC should to print warning or
On Nov 18, 2007 12:11 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> In particular, in the
> current implementation, none of the debug information for the bodies of
> functions (i.e., that describing local variables, line numbers for
> statements, etc.) is required for LTO processing. The LTO us
Snapshot gcc-4.1-20071119 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071119/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>In local-alloc.c, block_alloc():
>
> if (optimize
> && recog_data.n_operands > 1
> && recog_data.constraints[0][0] == '='
> && recog_data.constraints[0][1] != '&')
> {
>
>
Jason Merrill wrote:
> Jason Merrill wrote:
>> Note that when I fix build_duplicate_type to work properly, the C++
>> compiler rejects the first usage because U doesn't refer to the
>> original type, so it isn't used for linkage. Perhaps that's why
>> build_duplicate_type got broken.
>
> Actually
On Sun, Nov 18, 2007 at 09:33:16AM +0300, [EMAIL PROTECTED] wrote:
> Is this a thread safe operation for your Ptolomy project?
> Should you suspend the application in order to load 'new classes' there?
I answered this off-list, because it's off-topic.
Jason Merrill wrote:
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Actually, this happens regardless. So I g
"Development Schedule: A thing GCC does not have".
"Exactly what features will be in the next version of the compiler
depends on what is contributed, and when. For this, before every
stage1, the Release Manager collects candidate projects in a wiki page
and proposes a schedule for the selected proj
Paolo Bonzini wrote:
> > It would seem to me that if everything was moved to libada, this
> > would not be necessary anymore.
> Sorry, I wanted to write "everything related to the Ada RTS".
Oh, I see.
> Of course Gigi is not going to be moved into libada.
Right :-)
And even if "everything r
2007/11/19, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> http://gcc.gnu.org/wiki/DevelopmentSchedule
>
> On 19/11/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> > Here http://gcc.gnu.org/develop.html#timeline , it's not a future roadmap,
> >it's a past roadmap.
> >
> > Why doesn't it publi
http://gcc.gnu.org/wiki/DevelopmentSchedule
On 19/11/2007, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> Here http://gcc.gnu.org/develop.html#timeline , it's not a future roadmap,
>it's a past roadmap.
>
> Why doesn't it publish a "future roadmap", "ToDo", "plans",
>or "ideas to be improved" .
On Fri, Nov 16, 2007 at 12:05:06AM +0100, Michael_fogel wrote:
> (define_insn "iorsi3_internal1"
> [(set (match_operand:SI 0 "gp_reg_operand" "=r,r")
> (ior:SI (match_operand:SI 1 "reg_or_0_operand" "%rJ,rJ")
> (match_operand:SI 2 "uns_arith_operand" "r,K")))]
Oh, by t
>> It would seem to me that if everything was moved to libada, this
>> would not be necessary anymore.
>
> Besides our move to svn, a primary goal of the suggested change
> is to move this set of sources out of a more general grabbag, to
> clarify their specific purpose and simplify the grabba
Hello Paolo,
Paolo Bonzini wrote:
> Would it be possible to add a --enable-small option to libada, which
> would enable compilation of the subset used by GNAT? Then, one could
> make libada build twice: as a host module with --enable-small, and as a
> target module without the option.
Humm,
Hi,
The example code kept crashing because it lacks some context
initialized. Thus I have to call sched_init/sched_finish pair even I
don't need to run scheduler at all. This makes me a little
uncomfortable. IMHO, the depedennce analysis should be seperated from
scheduler itself.
struct sched
Gabriel Dos Reis wrote:
I have been able to build similar tool for at least two radically
different C++ front ends -- one being proprietary, the other one
being GCC (the most painful to work with). We call the representation
`IPR' (for Internal Program Representation). The interface is
compl
A number of these sources are indeed shared (some compiler sources
are used by the library and/or some tools) and moving them is not
straightforward.
Would it be possible to add a --enable-small option to libada, which
would enable compilation of the subset used by GNAT? Then, one could
On Sun, 18 Nov 2007, Robert Dewar wrote:
| Let's take an example, suppose we want to write a semantic analysis
| tool (e.g. the Mozilla style checker mentioned earlier). For Ada,
| we can write an ASIS application and we need to know NOTHING AT ALL
| about the internals of the compiler we are usin
On Sun, 18 Nov 2007, Robert Dewar wrote:
| Richard Kenner wrote:
| > > Robert Dewar <[EMAIL PROTECTED]> writes:
| > >
| > > | It's interestinng to note that in the Ada world, there is an ISO
| > > | standard for plugins, which is compiler/vendor neutral (at least
| > > | in theory, in practice the
23 matches
Mail list logo
