With yesterday's SVN sources, the following source produces the same
result with -ftree-cselim and -fno-tree-cselim on x86:
#include
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
static int acquires_count = 0;
int
trylock()
{
int res;
res = pthread_mutex_trylock(&mutex);
if (
On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> With yesterday's SVN sources, the following source produces the same
> result with -ftree-cselim and -fno-tree-cselim on x86:
Because another patch does this optimization, the RTL if conversion
pass which implements conditional moves.
-- Pi
On 25/10, Andrew Pinski wrote:
| On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
| > With yesterday's SVN sources, the following source produces the same
| > result with -ftree-cselim and -fno-tree-cselim on x86:
|
| Because another patch does this optimization, the RTL if conversion
| pas
I use Gentoo Linux, Gcc 4.1.1 and Intel Celeron processor.
I compiled this file:
#include
#include
int main()
{
printf("\n %1.55f \n", sqrt(3.999));
return 0;
}
I get 1.999777955395074968691915273666381835 9375000
If you add one more 9 to sqrt you get 2.
#include
#
On 10/25/07, Samuel Tardieu <[EMAIL PROTECTED]> wrote:
> Is there any way to turn it off (other than using -O0) (see current
> thread-safeness discussion)?
-fno-if-conversion -fno-if-conversion2
>
> It looks like this particular optimization is duplicated, as the comment
> in tree-ssa-phiopt.c e
On 10/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Why does this return 2 ??
You should read: http://www.validlab.com/goldberg/paper.pdf which is
linked on http://gcc.gnu.org/readings.html .
Thanks,
Andrew Pinski
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote:
| > Richard Guenther wrote:
| > > 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
| > >
| > > Removal of pre-ISO C++ items from include/backwards.
| > > * include/Makefile.am (ba
[EMAIL PROTECTED] wrote:
>
> #include
> #include
>
> int main()
> {
> printf("\n %1.55f \n", sqrt(3.));
> return 0;
> }
>
> Result: 2
>
> Why does this return 2 ??
If you meant to use long double, you should have so specified. Decimal
digits beyond 17 aren't significant in
Hi,
once i have been reading lots of documents about SSA computing. I have
a few questions, conceptual ones, that stop me understanding the whole
goal of the method. Here i go:
* Why alias analysis? I mean, the pointers could be versioned like the
others vars. (I'm not saying it's not usefull, i
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> And it is not a new problem, if conversion has
> been with GCC since the 2.95 days so I don't understand why it is only
> being brought up now (except threading programming is becoming more
> popular). And really I still say these are thread safe, jus
On Wed, Oct 24, 2007 at 03:06:42PM -0700, Joe Buck wrote:
> On Wed, Oct 24, 2007 at 01:37:25PM -0700, Andrew Pinski wrote:
> > On 10/24/07, Jack Lloyd <[EMAIL PROTECTED]> wrote:
> > > Is there a reason it's not just an error, then? (As a user) I don't
> > > see the point of something being a warnin
On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
> 'deprecated' in the standard does not carry much semantics weight,
> unless the feature is also removed. But, even then we would have to
> worry about existing codes that were written using the feature. That
> is one of the reasons wh
skaller wrote:
I think this is the wrong idea. Deprecated does carry a lot
of weight. It allows a new compiler without a legacy
to elide the feature and specify it is ISO compliant
'minus' the deprecated features, which is quite different
from 'non-compliant'.
are you sure? I thought conforman
On Thu, Oct 25, 2007 at 11:25:52AM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 24, 2007 at 03:06:42PM -0700, Joe Buck wrote:
> > But the way that the object is passed in this case, and the stack layout,
> > are completely defined on any platform that obeys the cross-platform API
> > you will find
Ian Lance Taylor writes:
> perhaps we should implement the draft C++0x memory model for both C
> and C++.
Yes. I'm sure that's the right answer, given the way that
if-conversion breaks simple code such as
> res = pthread_mutex_trylock(&mutex);
> if (res == 0)
> ++acquires_count;
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> It would be nice to figure out how gcc could improve matters. The
> answer is not going to be to disable certain optimizations.
It's just very questionable this particular transformation is a
optimization at all. Turning a shared cache line into an
On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote:
> skaller wrote:
>
> > I think this is the wrong idea. Deprecated does carry a lot
> > of weight. It allows a new compiler without a legacy
> > to elide the feature and specify it is ISO compliant
> > 'minus' the deprecated features, which is
On Thu, Sep 27, 2007 at 10:34:50AM +0200, Paolo Bonzini wrote:
> Rask Ingemann Lambertsen wrote:
> > I'm having a look at building GCC with OpenWatcom to reduce build
> >times. There seems to be something wrong with the build machinery:
>
> Can you try this patch? RANLIB_FOR_BUILD was defined no
Andi Kleen <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>
> > It would be nice to figure out how gcc could improve matters. The
> > answer is not going to be to disable certain optimizations.
>
> It's just very questionable this particular transformation is a
> op
On Thu, Oct 25, 2007 at 08:44:26AM -0700, Joe Buck wrote:
> One of the purposes of the C++ ABI is to allow different compilers to
> interoperate. The freedom you describe would prevent gcc-compiled
> code from behaving correctly with icc-compiled code, for example.
> So yes, argument passing conve
> I agree that that is most likely an optimization bug that this
> conversion is being for a store to a variable which is not on the
> stack.
Even on the stack it might not be good -- e.g. if someone puts an 10MB
array on the stack and does something with it you don't want such random
stores insi
Is there a way of using a different ranlib for building the stage1 compiler
than for stage2 and stage3 (other than using a combined tree)?
I don't remember one. Remember though that when using a combined tree
you can drop in only the binutils directory, and use the system gas/ld.
Paolo
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
|
| > 'deprecated' in the standard does not carry much semantics weight,
| > unless the feature is also removed. But, even then we would have to
| > worry about existing codes that were written us
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote:
| > skaller wrote:
| >
| > > I think this is the wrong idea. Deprecated does carry a lot
| > > of weight. It allows a new compiler without a legacy
| > > to elide the feature and specify it is ISO comp
On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
> | I think this is the wrong idea. Deprecated does carry a lot
> | of weight. It allows a new compiler without a legacy
> | to elide the feature and specify it is ISO compliant
> | 'minus' the deprecated features, which is quite differen
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
|
| > | I think this is the wrong idea. Deprecated does carry a lot
| > | of weight. It allows a new compiler without a legacy
| > | to elide the feature and specify it is ISO compliant
| > | 'minu
* Andrew Pinski:
> Yes it is duplicated. And it is not a new problem, if conversion has
> been with GCC since the 2.95 days so I don't understand why it is only
> being brought up now (except threading programming is becoming more
> popular).
The cmov instruction is post-Pentium material, so it'
On Thu, 2007-10-25 at 13:41 -0500, Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> |
> | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
> |
> | > | I think this is the wrong idea. Deprecated does carry a lot
> | > | of weight. It allows a new compiler without a leg
I've noticed that the GCC changes pages
(http://gcc.gnu.org/gcc-4.2/changes.html and
http://gcc.gnu.org/gcc-4.3/changes.html ) are not usually updated for
Ada and/or GNAT. It anyone designated as a maintainer for this?
-- Britt
On Thu, 25 Oct 2007, Gabriel Dos Reis wrote:
> 'deprecated' in the standard does not carry much semantics weight,
> unless the feature is also removed. But, even then we would have to
> worry about existing codes that were written using the feature.
I have to admit I am also surprised about the u
On 10/25/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> I have to admit I am also surprised about the use of "deprecated" in
> the context of removing these headers. My previous understanding was
> that we'd announce deprecation (and issue warnings) for at least one
> major release before actuall
On Thu, 25 Oct 2007, Andrew Pinski wrote:
> Well technically these headers have been deprecated since at least 3.2
> (maybe even back in 3.0) with them producing a warning. So I don't
> know if we should move them or not but we have followed our own rules
> here.
Sorry, I misread the Subject: wha
Gerald Pfeifer wrote:
> On Thu, 25 Oct 2007, Andrew Pinski wrote:
>> Well technically these headers have been deprecated since at least 3.2
>> (maybe even back in 3.0) with them producing a warning. So I don't
>> know if we should move them or not but we have followed our own rules
>> here.
>
> S
On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Thu, 25 Oct 2007, Andrew Pinski wrote:
> > Well technically these headers have been deprecated since at least 3.2
> > (maybe even back in 3.0) with them producing a warning. So I don't
> > know if we should move them or not but we have
On Thu, 25 Oct 2007, Jonathan Wakely wrote:
| On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
| > On Thu, 25 Oct 2007, Andrew Pinski wrote:
| > > Well technically these headers have been deprecated since at least 3.2
| > > (maybe even back in 3.0) with them producing a warning. So I don'
On Thu, Oct 25, 2007 at 02:48:09PM -0700, Mark Mitchell wrote:
> Gerald Pfeifer wrote:
> > On Thu, 25 Oct 2007, Andrew Pinski wrote:
> >> Well technically these headers have been deprecated since at least 3.2
> >> (maybe even back in 3.0) with them producing a warning. So I don't
> >> know if we s
On 10/25/07, Fran Baena <[EMAIL PROTECTED]> wrote:
> * Why alias analysis? I mean, the pointers could be versioned like the
> others vars. (I'm not saying it's not usefull, i mean i don't
> understand the alias analisys goals)
SSA names of pointers are also pointers, when points-to sets are
compu
target: m32c-elf
test case: cc1 -O3 -mcpu=m32c dj.c
void
cyg_hal_plf_serial_write(void* __ch_data, const unsigned char* __buf,
unsigned long __len)
{
while(__len-- > 0)
cyg_hal_plf_serial_putc(__ch_data, *__buf++);
}
On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote:
> On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> The plan is to also move auto_ptr and the old bind1st/bind2nd function
> binders to backward, if/when they are deprecated in C++0x, which would
> give them the same status as (d
On Thu, 2007-10-25 at 15:49 -0700, Joe Buck wrote:
> People that put out distributions are rightly irritated when we pull stuff
> like this. It's not even good enough to change "ext" to "backward", now
> you need an autoconf test to find the fine header, so your program
> compiles with both olde
On Fri, 26 Oct 2007, skaller wrote:
| I should point out retaining 'old' features can create a
| significant maintenance burden for gcc developers,
In this specific case, what are they?
-- Gaby
Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> | I should point out retaining 'old' features can create a
> | significant maintenance burden for gcc developers,
>
> In this specific case, what are they?
The maintenance burden argument always used to remove stuff. I've used
it
On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> | I should point out retaining 'old' features can create a
> | significant maintenance burden for gcc developers,
>
> In this specific case, what are they?
You're in a better position than me to
Questions
=
Are there any major unreviewed patches for 4.3 that I could help to
review?
Quality Data
We're still in Stage 3 for GCC 4.3. As before, I think a reasonable
target for creating the release branch is less than 100 open
regressions. At present, we're at 184 -- a
On Thu, Oct 25, 2007 at 08:17:58PM -0700, Mark Mitchell wrote:
> The maintenance burden argument always used to remove stuff. I've used
> it myself plenty of times. Sometimes, it really is too painful. But,
> sometimes -- and, again, I consider myself guilty -- we've ripped things
> out under th
On Fri, Oct 26, 2007 at 11:06:43AM +1000, skaller wrote:
> The compiler is expected to conform to the specified standard
> and the standard libraries are an intrinsic part of the
> standard, and IMHO it would be good practice to allow
> 'strict' conformance to an older standard, whilst still
> reje
David Miller <[EMAIL PROTECTED]> writes:
> From: Ian Lance Taylor <[EMAIL PROTECTED]>
> Date: 25 Oct 2007 21:31:56 -0700
>
> > Samuel Tardieu <[EMAIL PROTECTED]> writes:
> >
> > > int
> > > trylock()
> > > {
> > > int res;
> > >
> > > res = pthread_mutex_trylock(&mutex);
> > > if (res ==
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: 25 Oct 2007 21:31:56 -0700
> Samuel Tardieu <[EMAIL PROTECTED]> writes:
>
> > int
> > trylock()
> > {
> > int res;
> >
> > res = pthread_mutex_trylock(&mutex);
> > if (res == 0)
> > ++acquires_count;
> >
> > return res;
> > }
...
> C
Samuel Tardieu <[EMAIL PROTECTED]> writes:
> #include
>
> static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> static int acquires_count = 0;
>
> int
> trylock()
> {
> int res;
>
> res = pthread_mutex_trylock(&mutex);
> if (res == 0)
> ++acquires_count;
>
> return res;
> }
The thread arguing about this has gone on for a while, so I think
it's time to gather some data to answer the question of just how bad
it will be if we accept the decision to move ext/hash_set and ext_hash_map
into a different directory and to deprecate them.
Any of you out there who put out distr
Joe Buck <[EMAIL PROTECTED]> writes:
> The thread arguing about this has gone on for a while, so I think
> it's time to gather some data to answer the question of just how bad
> it will be if we accept the decision to move ext/hash_set and ext_hash_map
> into a different directory and to deprecate
From: Ian Lance Taylor <[EMAIL PROTECTED]>
Date: 25 Oct 2007 21:50:16 -0700
> We could have a global variable "lock_is_held". The
> code could look like this:
>
> if (lock_is_held)
> ++still_holding;
>
> If the earlier code should work in a multi-threaded environment, then
> this code
On 10/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> SSA names of pointers are also pointers, when points-to sets are
> computed for SSA names, what you get is all the symbols that the
> particular SSA name has been found to point to. Eg,
>
> if (...)
> p_1 = &a;
> else
> p_2 = &b;
> endif
53 matches
Mail list logo
