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
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 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
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 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, 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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
> 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
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 +
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, 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
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
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
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
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.
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 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
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)
>
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, 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,
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 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
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 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:
>
> 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: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
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
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
Please keep the discussion on a technical level and not about
someone's fluency with the English language.
Gracias, David
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
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
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
* 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
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
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
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 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
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 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.
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 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 >=
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 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: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
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 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
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 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
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:
> 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 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 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
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'
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.
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
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
68 matches
Mail list logo
