On Mon, Oct 22, 2007 at 00:07:50 +0100, Dave Korn wrote:
> Because of the 'as-if' rule. Since the standard is neutral with regard to
> threads, gcc does not have to take them into account when it decides whether
> an optimisation would satisfy the 'as-if' rule.
If this would be true, then the c
On Mon, Oct 22, 2007 at 01:36:17PM +0400, Tomash Brechko wrote:
> On Mon, Oct 22, 2007 at 00:07:50 +0100, Dave Korn wrote:
> > Because of the 'as-if' rule. Since the standard is neutral with regard to
> > threads, gcc does not have to take them into account when it decides whether
> > an optimis
Erik Trulsson wrote:
It is also worth noting that just declaring a variable 'volatile' does not
help all that much in making it safer to use in a threded environment if you
have multiple CPUs. (There is nothing that says that a multi-CPU system has
to have any kind of automatic cache-coherence.
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 00:07:50 +0100, Dave Korn wrote:
> > Because of the 'as-if' rule. Since the standard is neutral
> > with regard to threads, gcc does not have to take them into
> > account when it decides whether an optimisation would satisfy the
> > 'as-if'
On 22 October 2007 02:20, skaller wrote:
> On Mon, 2007-10-22 at 00:07 +0100, Dave Korn wrote:
>
>> If you really want all externally-visible accesses to v to be made
>> exactly as the code directs, rather than allowing gcc to optimise them in
>> any way that (from the program's POV) it's just
On Mon, Oct 22, 2007 at 11:19:31 +0100, Andrew Haley wrote:
> Please have a read of [1]. Let us know if anything you have observed
> isn't covered in that paper.
>
> [1] Hans-Juergen Boehm. Threads cannot be implemented as a library. In
> Proc. of the ACM SIGPLAN 2005 Conf. on Programming Languag
On 22 October 2007 11:51, Tomash Brechko wrote:
> On Mon, Oct 22, 2007 at 11:19:31 +0100, Andrew Haley wrote:
>> Please have a read of [1]. Let us know if anything you have observed
>> isn't covered in that paper.
>>
>> [1] Hans-Juergen Boehm. Threads cannot be implemented as a library. In
>> P
On Mon, Oct 22, 2007 at 14:50:44 +0400, Tomash Brechko wrote:
> Can't agree less!
Can't agree more!, that's what it was supposed to say, think you've
got it right ;).
--
Tomash Brechko
On 22 October 2007 11:51, Tomash Brechko wrote:
> Can't agree less! That's why for _practical_ reasons I'd say GCC
> should be thread-aware, even if _theoretically_ it doesn't have to.
> And AFAIU it already _is_, for the most part of it. That's why I want
> to see Bug#31862 be confirmed, accept
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 11:19:31 +0100, Andrew Haley wrote:
> > Please have a read of [1]. Let us know if anything you have observed
> > isn't covered in that paper.
> >
> > [1] Hans-Juergen Boehm. Threads cannot be implemented as a library. In
> > Proc. of the ACM
On Mon, Oct 22, 2007 at 11:54:47 +0100, Dave Korn wrote:
> http://www.google.com/search?q=Threads+cannot+be+implemented+as+a+library&sour
> ceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org
> .mozilla:en-GB:official
Thanks!
--
Tomash Brechko
Hi all,
this is my first post in this mailing list. I'm trying to understand
GCC 4 as part of my research, but I'm finding questions which are
difficult to answer just with online documentation.
I understand that the whole process of compiling a C file involves
GENERIC->GIMPLE->SSA->GIMPLE->RTL
On Mon, Oct 22, 2007 at 12:07:20 +0100, Dave Korn wrote:
> And even volatile wouldn't help if the code said
>
> if (i > x)
> var += i;
>
> instead of a simple assignment. The race in fact *does* exist in the original
> program, but is hidden by the fact that you don't care which of
On 22 October 2007 12:17, Tomash Brechko wrote:
> On Mon, Oct 22, 2007 at 12:07:20 +0100, Dave Korn wrote:
>> And even volatile wouldn't help if the code said
>>
>> if (i > x)
>> var += i;
>>
>> instead of a simple assignment. The race in fact *does* exist in the
>> original progr
On Mon, Oct 22, 2007 at 12:08:02 +0100, Andrew Haley wrote:
> Well, that's a big job: you'd have to decide on what a memory model
> really should be, and then implement that model.
Wouldn't the following rule of thumb work?: GCC is allowed to inject
additional store operations on some execution pa
On Mon, Oct 22, 2007 at 12:19:40 +0100, Dave Korn wrote:
> *What* mutex are you referring to? There is no mutex in that code.
I was talking about the code in the comment#7. For the code in the
comment#1, the piece is simply incomplete. For it, mutex should be
used if x < 99, not clear if x >=
I don't want to spam, but i have an interesting program.
It is on the http://procbench.sourceforge.net/
It is only for linux, with pb_gcc (or pb_g++) you can execute,
and compile programs with the best optimization flags. It helps
me a lot! (But, sometimes it doesn't generates the best flags)
On 22 October 2007 12:27, Tomash Brechko wrote:
> On Mon, Oct 22, 2007 at 12:19:40 +0100, Dave Korn wrote:
>> *What* mutex are you referring to? There is no mutex in that code.
>
> I was talking about the code in the comment#7. For the code in the
> comment#1, the piece is simply incomplete.
Jose wrote:
> Hi all,
>
> this is my first post in this mailing list. I'm trying to understand
> GCC 4 as part of my research, but I'm finding questions which are
> difficult to answer just with online documentation.
>
> I understand that the whole process of compiling a C file involves
> GENERIC->
On 20 October 2007 16:40, J.C. Pizarro wrote:
> * Was it useful the implementation of the complicated tree-ssa code
> waited for long time (many years)?
>
> * Was it better the optimization without tree-ssa code?
Why in a style like Yoda these questions you are asking?
> If doesn't exist a me
On 22/10/2007, numpszi <[EMAIL PROTECTED]> wrote:
>
> I don't want to spam, but i have an interesting program.
> It is on the http://procbench.sourceforge.net/
> It is only for linux, with pb_gcc (or pb_g++) you can execute,
> and compile programs with the best optimization flags. It helps
> me a l
On Mon, Oct 22, 2007 at 14:53:41 +0100, Dave Korn wrote:
> The optimisation the compiler is making here is a big win in normal
> code, you wouldn't want to disable it unless absolutely necessary;
> to be precise, you wouldn't want to automatically disable it for
> every loop and variable in a progr
J.C. Pizarro wrote:
Are they mixed into a single
variable declaration? Are they treated as separate variables and
handled later by the register allocator?
If possible, the former. If not possible, they are kept as separate
variables. This happens if the subscripted variables have overlappi
* Was it useful the implementation of the complicated tree-ssa code
waited for long time (many years)?
* Was it better the optimization without tree-ssa code?
Why in a style like Yoda these questions you are asking?
He not speaks like Yoda, uses the order for words that is in Spanish (no
On 22 October 2007 15:37, Paolo Bonzini wrote:
>>> * Was it useful the implementation of the complicated tree-ssa code
>>> waited for long time (many years)?
>>>
>>> * Was it better the optimization without tree-ssa code?
>>
>> Why in a style like Yoda these questions you are asking?
>
> He n
Dear Mr. Pizzaro,
> Is not it easy to write 3 stages GENERIC->GIMPLE->RTL instead of 5 stages?
>
> Is meaningful the optimization of the complex bi-transformation
> GIMPLE->SSA->GIMPLE?
>
> Is more powerful GENERIC->GIMPLE->RTL + "trial-and-error" local optimization?
>
>Sincerely, J.C. Piza
Hi Dear,
I write you this mail with utmost sincerity and truth,
hoping you will be of great help to me. I am Pete Fitz,
a 61yrs old man living with Cancer. My condition at home
is so bad that my doctor said I don't have time left.
I have a daughter, who is just in high school,
with nobody
Please keep the discussion on a technical level and not about
someone's fluency with the English language.
Gracias, David
Hi,
On Mon, 22 Oct 2007, Tomash Brechko wrote:
> On Mon, Oct 22, 2007 at 14:53:41 +0100, Dave Korn wrote:
> > The optimisation the compiler is making here is a big win in normal
> > code, you wouldn't want to disable it unless absolutely necessary;
> > to be precise, you wouldn't want to automati
On 22 October 2007 17:16, Michael Matz wrote:
>> I'd rather wish the optimization would be done differently. Currently we
>> have:
>>
>> mem -> reg;
>>loop loop
>> if (condition)=> optimize => if (condi
On Mon, Oct 22, 2007 at 18:15:35 +0200, Michael Matz wrote:
> > I'd rather wish the optimization would be done differently. Currently
> > we have:
> >
> > mem -> reg;
> >loop loop
> > if (condition)=> optimize
Tomash Brechko writes:
>
> Several people already suggested to use volatile for shared data.
> Yes, it will help because we know it will disable all access
> optimizations, including thread-unaware ones. But I don't want to
> disable _all_ optimizations, I rather vote for thread-aware
> op
On Mon, Oct 22, 2007 at 18:33:37 +0100, Andrew Haley wrote:
> We do understand what you're saying, and simply repeating the same
> thing doesn't help.
>
> I think we should wait to see what the C++ working group comes up with
> and consider implementing that, rather than some ad-hoc gcc-specific
>
Tomash Brechko writes:
> On Mon, Oct 22, 2007 at 18:33:37 +0100, Andrew Haley wrote:
> > We do understand what you're saying, and simply repeating the same
> > thing doesn't help.
> >
> > I think we should wait to see what the C++ working group comes up with
> > and consider implementing tha
On 22 October 2007 18:34, Andrew Haley wrote:
> > Again, we are not discussing some particular code sample, and how it
> > might be fixed, but the problem in general. Should GCC do
> > thread-unsafe optimizations, or not?
>
> We do understand what you're saying, and simply repeating the same
On Mon, 2007-10-22 at 12:09 +0200, Erik Trulsson wrote:
> My own conclusion from this discussion (and others) is that shared memory is
> a lousy paradigm for communication between different threads of execution,
> precisely because it is so hard to specify exactly what should happen or not
> happ
On Mon, Oct 22, 2007 at 18:48:02 +0100, Andrew Haley wrote:
> Err, not exactly. :)
>
> See http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/why_undef.html
Why, I'd say that page is about original races in the program, not
about what compiler should do with races that it introduces itself.
Still,
Andrew Haley <[EMAIL PROTECTED]> writes:
> Tomash Brechko writes:
>
> >
> > Several people already suggested to use volatile for shared data.
> > Yes, it will help because we know it will disable all access
> > optimizations, including thread-unaware ones. But I don't want to
> > disable _a
On Mon, 2007-10-22 at 18:32 +0400, Tomash Brechko wrote:
> But it could use additional register and be:
>
> 0 -> flag_reg;
> loop
>if (condition)
>
On 10/22/07, skaller <[EMAIL PROTECTED]> wrote:
> Registers are a limited resource.
Everything is limited, some processors are more limited than others :).
Seriously, I think this should be discussed in a language standards
comittee area rather than inside GCC's development since right now GCC
is
Hi Dave,
On x86-64, no regression in 4.2 with the patch.
So both 4.2 and mainline patches are OK.
I'd appreciate it if you can add the testcase
- it's up to you whether to add it in a separate patch or with this patch.
Thanks for fixing it.
Seongbae
On 10/19/07, Seongbae Park (박성배, 朴成培) <[EMAIL
On Mon, 2007-10-22 at 16:32 +0200, Paolo Bonzini wrote:
> I don't know what you mean, but yes, there is value in going to SSA and
> back. SSA makes global optimization much easier, and that's the main
> improvement introduced in GCC 4.0 and later refined.
IMHO gcc was pretty crappy until 4.
On 22 October 2007 19:32, skaller wrote:
> On Mon, 2007-10-22 at 16:32 +0200, Paolo Bonzini wrote:
>
>> I don't know what you mean, but yes, there is value in going to SSA and
>> back. SSA makes global optimization much easier, and that's the main
>> improvement introduced in GCC 4.0 and later r
At EMC we have a version of GCC which targets the x86 with a non
standard ABI -- it produces code for 64 bit mode mode, but with types
having the 32 bit ABI sizes. So, ints, longs, and pointers are 32
bits -- that is, it's ILP32 rather than LP64 -- but with the chip in
64 bit mode.
Actually, poin
I think that the release process for recent releases has given undue
priority to bugs marked as regressions. I agree that it's important for
things that worked in the previous release to keep working in the new
release. But the regression tag is used for much more trivial things.
For instanc
2007/10/22, David Edelsohn <[EMAIL PROTECTED]> wrote:
> Please keep the discussion on a technical level and not about
> someone's fluency with the English language.
>
> Gracias, David
>
>
Thanks David,
i'm very bad english speaker but i'm a good person.
If SSA was made to permit to elimi
2007/10/22, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote:
> > Are they mixed into a single
> >> variable declaration? Are they treated as separate variables and
> >> handled later by the register allocator?
>
> If possible, the former. If not possible, they are kept as separate
>
2007/10/22, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Dear Mr. Pizzaro,
>
> > Is not it easy to write 3 stages GENERIC->GIMPLE->RTL instead of 5 stages?
> >
> > Is meaningful the optimization of the complex bi-transformation
> > GIMPLE->SSA->GIMPLE?
> >
> > Is more powerful GENERIC->GIMPLE->RTL +
> J C Pizarro writes:
JC> In the future, GCC will no be the best compiler, the best compiler
JC> could be a powerful compiler with inferences's machines, learning
JC> machines, logic machines, etc where the men don't think in the
JC> specific algorithms.
There are a few research effor
Dave Korn wrote:
> On 22 October 2007 19:32, skaller wrote:
>
> > On Mon, 2007-10-22 at 16:32 +0200, Paolo Bonzini wrote:
> >
> >> I don't know what you mean, but yes, there is value in going to SSA and
> >> back. SSA makes global optimization much easier, and that's the main
> >> improvement in
2007/10/22, David Edelsohn <[EMAIL PROTECTED]> wrote:
> > J C Pizarro writes:
>
> JC> In the future, GCC will no be the best compiler, the best compiler
> JC> could be a powerful compiler with inferences's machines, learning
> JC> machines, logic machines, etc where the men don't think in the
>
J.C. Pizarro wrote:
> IMHO, in the future, GCC as a base an experimal compiler IS NOT good
> because of enormeous complexities to design this optimizing compiler.
>
> My reasons to select a good base are:
>
> * the programming language to develop a complex optimizing compiler
> MUST TO be high-le
On Mon, Oct 22, 2007 at 09:48:24PM +0200, J.C. Pizarro wrote:
> why is hard to optimize unrolling loop, inlining code, instructions
> scheduling, etc because of the SSA's presence?
There's nothing about SSA that makes any of those things harder.
In any case, the use of SSA is fairly fundamental t
Snapshot gcc-4.1-20071022 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071022/
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
From: Jason Merrill <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 15:42:50 -0400
> For instance, Bug 32252 is an ice-on-valid bug in a new C++ feature,
> variadic templates. But since 4.2 gave a syntax error instead of an
> ICE, this gets marked as a regression.
I agree that the regression marker i
From: "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 11:31:18 -0700
> On x86-64, no regression in 4.2 with the patch.
> So both 4.2 and mainline patches are OK.
Thank you for doing this extra regression testing.
> I'd appreciate it if you can add the testcase
> - it's up t
Hi, list.
Right now I'm building new toolchain using old one provided by our vendor. I
have built binutils and gcc-4.1.1 successfully. However while building
glibc-2.4 it always told me:
running configure fragment for nptl/sysdeps/pthread
checking for forced unwind support... no
configure: er
hi, I have some code using __builtin_frame_address(0) to get
the current stack pointer in a 'portable' way.
Unfortunately, this appears not to work if -fomit-frame-pointer
is used on an x86. My system sets that automatically, since
the x86 is a bit short on registers and this is reputed
to help wi
On Mon, 2007-10-22 at 15:42 -0400, Jason Merrill wrote:
> I think that the release process for recent releases has given undue
> priority to bugs marked as regressions. I agree that it's important for
> things that worked in the previous release to keep working in the new
> release. But the r
Jason Merrill wrote:
Similarly, bugs marked as 4.1/4.2/4.3 regression don't seem like a
high priority to me. If a bug wasn't a blocker for 4.2, it shouldn't
be a blocker for 4.3. It makes sense to give such a bug a higher
priority than it would normally (say, one point higher), but it seems
David Miller wrote:
But wouldn't you agree that it's not all that great to ship a new
feature in GCC that users have already found ways to ICE?
Oh, absolutely, it's just not a regression.
Jason
skaller wrote:
But Jason, the compiler worked properly in rejecting invalid syntax.
Now you're suggesting it fails to do so. This suggests a real regression
and a real bug: the new feature should have an enabling flag
that couldn't have been set before it was implemented, and without
that flag s
On 10/22/07, Jason Merrill <[EMAIL PROTECTED]> wrote:
> David Miller wrote:
>
> > But wouldn't you agree that it's not all that great to ship a new
> > feature in GCC that users have already found ways to ICE?
>
> Oh, absolutely, it's just not a regression.
Except it is still ICEing. There was a
On 10/22/07, skaller <[EMAIL PROTECTED]> wrote:
> Unfortunately, this appears not to work if -fomit-frame-pointer
> is used on an x86.
What version of GCC? Since this was fixed for 4.1.0, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8335 .
Thanks,
Andrew Pinski
On 10/22/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> I think this is a very important point. If it didn't block a previous
> release, it shouldn't block the current release.
Yes it is but does a regression that is just found to be a regression
is considered a blocking one, it should block the
On Tue, 2007-10-23 at 00:00 -0400, Jason Merrill wrote:
> skaller wrote:
> > But Jason, the compiler worked properly in rejecting invalid syntax.
> > Now you're suggesting it fails to do so. This suggests a real regression
> > and a real bug: the new feature should have an enabling flag
> > that
Jason Merrill <[EMAIL PROTECTED]> writes:
> I think that the release process for recent releases has given undue
> priority to bugs marked as regressions. I agree that it's important
> for things that worked in the previous release to keep working in the
> new release. But the regression tag is
On Mon, 2007-10-22 at 22:58 -0700, Andrew Pinski wrote:
> On 10/22/07, skaller <[EMAIL PROTECTED]> wrote:
> > Unfortunately, this appears not to work if -fomit-frame-pointer
> > is used on an x86.
>
> What version of GCC? Since this was fixed for 4.1.0, see
> http://gcc.gnu.org/bugzilla/show_bug
68 matches
Mail list logo
