> I am a student at the university of Mauritius and doing some research
> about C++ Programming language... Could you please help me on the
> source Code??? Could you give us the source code or perhaps help in
> finding how does the Compiler captures and outputs the errors???
You can find the sour
Dear Sir,
I am a student at the university of Mauritius and doing some research
about C++ Programming language... Could you please help me on the
source Code??? Could you give us the source code or perhaps help in
finding how does the Compiler captures and outputs the errors???
Thaking you in Advan
> Please read the _description_ that comes along with the code example.
I did.
> Anyways, the patch is there.
The one for ifcvt.c, yes; more will be needed though, see for example
http://gcc.gnu.org/ml/gcc/2007-10/msg00754.html
--
Eric Botcazou
On Tue, Oct 30, 2007 at 09:49:00 -0700, Ian Lance Taylor wrote:
> I don't know which suggestion you are referring to. The patch I wrote
> will retain the optimization in the case where the memory location is
> unconditionally written later in the function. This is most relevant
> in that the opti
Tomash Brechko <[EMAIL PROTECTED]> writes:
> > > if (condition) {
> > > *p = value;
> > > membarrier();
> > > } else {
> > > membarrier();
> > > }
> > >
> > > But this is the same as
> > >
> > > if (condition)
> > > *p = value;
> > > membarrier();
> >
> > No, it isn't.
Schipper, K. - SPLXM writes:
> > For information, services and offers, please visit our web site:
> > http://www.klm.com. This e-mail and any attachment may contain
> > confidential and privileged material intended for the addressee
> > only. If you are not the addressee, you are notified tha
Schipper, K. - SPLXM writes:
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no par
Hi, I have a question. We are in the process of building a cross
compiler for our system on Linux.
In the documentation I read that we need the GPL file:
"gpl-include.tar.bz2"
Do you perhaps know where this file can be obtained so that we can
proceed with our build?
Best regards,
Kees Schipper
On Tue, Oct 30, 2007 at 07:50:04 -0700, Ian Lance Taylor wrote:
> Tomash Brechko <[EMAIL PROTECTED]> writes:
>
> > Even if we put aside the fact that there's no such membarrier()
> > equivalent in POSIX bindings, this won't help.
>
> In POSIX, any mutex function must be a membarrier. For example
On Tue, Oct 30, 2007 at 15:33:56 +0100, Eric Botcazou wrote:
> We're not talking about locks, see the example you gave in your
> first message.
Please read the _description_ that comes along with the code example.
Anyways, the patch is there.
--
Tomash Brechko
Jason Merrill wrote:
> No. Previously we've branched at <100 regressions, but waited for the
> numbers to get better than that before making the release. I'm
> suggesting that the release criteria stay about the same as before, just
> that we delay the branch until the release is ready rather th
Tomash Brechko <[EMAIL PROTECTED]> writes:
> Even if we put aside the fact that there's no such membarrier()
> equivalent in POSIX bindings, this won't help.
In POSIX, any mutex function must be a membarrier. For example, on
x86, mutex lock and unlock more or less have to execute the mfence
inst
Benjamin Kosnik wrote:
Jason, any thoughts on how to translate "ready to make a .0 release"
into "made a .0 release," in terms of a firm schedule, with dates? I'm
assuming that the < 100 bugzilla count is an adequate milestone for the
release branch to be cut.
Or do you think < 100 implies branc
> volatile can be properly used _only_ if you also assume atomicity and
> cache-coherence, and this is beyond POSIX. But anyway, I'm proving
> the opposite: when you use POSIX locks, you don't have to use
> volatile, that it.
We're not talking about locks, see the example you gave in your first m
On Tue, Oct 30, 2007 at 09:34:07AM +0100, Andreas Krebbel wrote:
> Hi Ian,
>
> have you had time to look at this? Or does anyone else like to
> comment?
>
> http://gcc.gnu.org/ml/gcc/2007-10/msg00092.html
I have no opinion on the attribute functions which took an alternative
parameter. But the
On Tue, Oct 30, 2007 at 10:31:17AM +, Andrew Haley wrote:
> Jakub Jelinek writes:
> > On Tue, Oct 30, 2007 at 10:20:34AM +, Andrew Haley wrote:
> > > That's what the proposed standard language says, kinda-sorta. There's
> > > an informal description at
> > > http://www.open-std.org/jtc
Jakub Jelinek writes:
> On Tue, Oct 30, 2007 at 10:20:34AM +, Andrew Haley wrote:
> > That's what the proposed standard language says, kinda-sorta. There's
> > an informal description at
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html.
> >
> > Anyway, we have fixe
On Tue, Oct 30, 2007 at 10:20:34AM +, Andrew Haley wrote:
> That's what the proposed standard language says, kinda-sorta. There's
> an informal description at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html.
>
> Anyway, we have fixed this bug and are committing it to all
I'd like to answer one last argument, mostly for the sake of curious
reader, because Michael himself has agreed with (at least the part of)
the point.
On Mon, Oct 29, 2007 at 16:00:18 +0100, Michael Matz wrote:
> The issue is, that people want to write this:
>
> if (condition)
> *p = value
* FX Coudert <[EMAIL PROTECTED]> [2007-10-30 09:04]:
> Can you reduce one of these failures to a short example and file a
> PR (and CC me)?
PR33947
A simple:
program main
end program main
is enough to trigger it. Note that this doesn't happen with 4.1 and
4.2.
> Is there something target-spec
gfortran has 7442 unexpected failures. Most of them are due to
"test for
excess errors". Many are simply because of this:
| warning: 'const' attribute directive ignored
| warning: 'nothrow' attribute directive ignored
which seems to be mentioned in PR21185 (comment #20). Is that problem
sti
On Tue, Oct 30, 2007 at 09:20:28 +0100, Eric Botcazou wrote:
> No, I just wanted to point out that "volatile" has a well-defined semantics
> and can be properly used for shared accesses. In other words, it's not all
> or nothing like your earlier message[*] seemed to imply.
>
> [*] http://gcc.gn
Hi Ian,
have you had time to look at this? Or does anyone else like to
comment?
http://gcc.gnu.org/ml/gcc/2007-10/msg00092.html
Bye,
-Andreas-
I compile gcc trunk from two days ago on ARM (OABI, v3, Debian) for
all languages and looked at some of the testsuite failures. I wanted
to ask whether people are aware of these issues and working on them
before I file PRs.
Testsuite results:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01361
> Frankly, you realise the consequences of volatile access, you have
> this comment:
>
> /* Avoid reading __gthread_active twice on the main code path. */
> int __gthread_active_latest_value = __gthread_active;
>
>
> Now, do you really believe that every multithreaded program should use
> vola
On Tue, Oct 30, 2007 at 10:59:24 +0300, Tomash Brechko wrote:
> On Tue, Oct 30, 2007 at 08:56:08 +0100, Eric Botcazou wrote:
> > > The use doesn't become proper simply because it appears in the code,
> > > even if in the code of GCC. volatile might be used there for
> > > completely different reas
26 matches
Mail list logo
