On 2010-02-22 05:23:39 +0100, Vincent Lefevre wrote:
> On 2010-02-22 02:58:19 +, Joseph S. Myers wrote:
> > For example, N1421 (Markham minutes) has a discussion that's clearly
> > presuming that a conditional
> >
> > #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1)
> >
> > may hold.
On 2010-02-22 02:58:19 +, Joseph S. Myers wrote:
> For example, N1421 (Markham minutes) has a discussion that's clearly
> presuming that a conditional
>
> #if defined(__STDC_IEC_559__) && (FLT_EVAL_METHOD == 1)
>
> may hold.
Well, this is a bit unclear. I think this is OK, as long as roundi
Jon writes:
> Good point. Updated patch attached for review.
I suppose this counts as a functionality change, and as such should
not be committed until after the release branch is made.
This is OK when we are back in stage 1, with a ChangeLog entry,
assuming it passes bootstrap (you didn't say)
On Mon, 22 Feb 2010, Vincent Lefevre wrote:
> On 2010-02-22 01:57:48 +, Joseph S. Myers wrote:
> > I know some people have claimed (e.g. glibc bug 6981) that you can't
> > conform to Annex F when you have excess precision, but this does not
> > appear to be the view of WG14.
>
> I wonder wh
On Feb 21, 2010, at 20:57, Joseph S. Myers wrote:
> I know some people have claimed (e.g. glibc bug 6981) that you can't
> conform to Annex F when you have excess precision, but this does not
> appear to be the view of WG14.
That may be the case, but I really wonder how much sense it
can make t
On 2010-02-22 01:57:48 +, Joseph S. Myers wrote:
> I know some people have claimed (e.g. glibc bug 6981) that you can't
> conform to Annex F when you have excess precision, but this does not
> appear to be the view of WG14.
I wonder what their view is. Annex F says:
The +, −, *, and / ope
On 2010-02-22 00:02:39 +0100, Erik Trulsson wrote:
> On the other hand code compiled for an older CPU that is run a newer
> CPU will run just fine, if slightly slower than they could have due to
> not making use of new instructions in the newer CPU.
It will run, but may give unexpected or even inc
On Sun, 21 Feb 2010, Geert Bosch wrote:
> On Feb 21, 2010, at 17:42, Erik Trulsson wrote:
> > Newer compilers usually have better generic optimizations that are not
> > CPU-dependent. Newer compilers also typically have improved support
> > for new language-features (and new languages for that ma
On Feb 21, 2010, at 07:13, Richard Guenther wrote:
> The present discussion is about defaulting to at least 486 when not
> configured for i386-linux. That sounds entirely reasonable to me.
I fully agree with the "at least 486" part. However,
if we only change the default once every 20 years, it
On Feb 21, 2010, at 12:34, Joseph S. Myers wrote:
> Correct - I said API, not ABI. The API for C programs on x86 GNU/Linux
> involves FLT_EVAL_METHOD == 2, whereas that on x86 Darwin involves
> FLT_EVAL_METHOD == 0 and that on FreeBSD involves FLT_EVAL_METHOD == 2
> but with FPU rounding prec
On Feb 21, 2010, at 17:42, Erik Trulsson wrote:
> Newer compilers usually have better generic optimizations that are not
> CPU-dependent. Newer compilers also typically have improved support
> for new language-features (and new languages for that matter.)
This is exactly where CPU dependence com
On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
> On 21/02/2010 22:42, Erik Trulsson wrote:
>
> > Yes, it does if the user is using binaries compiled by somebody else,
> > and that somebody else did not explicitly specify any CPU-flags.
> >
> > I believe that is the situation when inst
On Mon, Feb 22, 2010 at 12:28 AM, Martin Guy wrote:
> On 2/21/10, Steven Bosscher wrote:
>> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson
>> wrote:
>> > One of the great advantages of much free/open software is the way it
>> > will work just fine even on older hardware.
>> And, let's face i
Status
==
The trunk is still in regression and documentation fixes only mode, we
still have several P1 regressions that need to be fixed before
branching. There will be a release candidate made available when
there are no remaining P1 regressions on the trunk.
In reviewing the bug list, I s
Yes, it is statically linked. In any case, there is very
little usage of external libraries here.
Jon
Alan Modra wrote:
On Sun, Feb 21, 2010 at 12:27:04PM -0600, Jon Turner wrote:
The program in question has been compiled with -pg for all
source code files.
Linked statically too? If not, th
On 2/21/10, Dave Korn wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
> > The point about defaults is that the GCC default tends to filter down
> > into the default for distributions;
> I'd find it surprising if that was really the way it happens; don't
> distributions make deliberate and con
On 21/02/2010 22:42, Erik Trulsson wrote:
> Yes, it does if the user is using binaries compiled by somebody else,
> and that somebody else did not explicitly specify any CPU-flags.
>
> I believe that is the situation when installing most
> Linux-distributions for example.
No, surely not. The
On Sun, Feb 21, 2010 at 12:27:04PM -0600, Jon Turner wrote:
> The program in question has been compiled with -pg for all
> source code files.
Linked statically too? If not, the missing time is probably spent in
libc.so or other shared libraries.
--
Alan Modra
Australia Development Lab, IBM
On Sun, Feb 21, 2010 at 10:59:05PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson
> wrote:
> >> There is nothing which stops them from using -march=i386. It just may not
> >> be the default.
> >
> > That argument cuts both ways you know. There is nothing stopping
Snapshot gcc-4.3-20100221 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100221/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Sun, Feb 21, 2010 at 10:53:54PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson wrote:
> > One of the great advantages of much free/open software is the way it
> > will work just fine even on older hardware.
>
> Yes, but that doesn't change if the compiler change
On 21/02/2010 21:53, Steven Bosscher wrote:
> Yes, of course -- but what is the advantage of using the latest GCC
> for such an older processor?
Tree-SSA? LTO? Fixed bugs? New languages? Etc? I can see plenty of good
reasons for it.
> The newer compilers usually add nothing much more tha
On Sun, Feb 21, 2010 at 9:27 AM, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch wrote:
>
>>> As I understand it, whether -mfpmath=387 (with excess precision) or
>>> -mfpmath=sse is the default is also considered part of the platform API
>>> (like whether char is signed or unsigned
On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson wrote:
>> There is nothing which stops them from using -march=i386. It just may not
>> be the default.
>
> That argument cuts both ways you know. There is nothing stopping
> people with the latest CPUs from using -march= to get code optimised
> for
On Sun, Feb 21, 2010 at 9:44 PM, Dave Korn
wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
>
>> The point about defaults is that the GCC default tends to filter down
>> into the default for distributions;
>
> I'd find it surprising if that was really the way it happens; don't
> distributions make
On Sun, Feb 21, 2010 at 1:07 PM, Erik Trulsson wrote:
> On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
>> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson
>> wrote:
>> >>
>> >> I agreed that gcc for x86 should choose a sensible default for 95% of
>> >> current x86 processors in use. Peo
On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson wrote:
> One of the great advantages of much free/open software is the way it
> will work just fine even on older hardware.
Yes, but that doesn't change if the compiler changes the default
target processor.
And, let's face it, most users of gcc don'
On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson
> wrote:
> >>
> >> I agreed that gcc for x86 should choose a sensible default for 95% of
> >> current x86 processors in use. People with those old processors can
> >> use older gcc or -march
Maucci, Cyrille wrote:
Hello Jon,
I'm used to gprof on HPUX and can tell you that on HPUX when we gprof
an executable, its only works on all the objects present in the
executable but not the shared libs. Actually on HPUX, either you
choose to gprof the exe or the libs but not both. When you want
On Sun, 2010-02-21 at 20:44 +, Dave Korn wrote:
> On 21/02/2010 20:03, Martin Guy wrote:
>
> > The point about defaults is that the GCC default tends to filter down
> > into the default for distributions;
>
> I'd find it surprising if that was really the way it happens; don't
> distributio
On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson wrote:
>>
>> I agreed that gcc for x86 should choose a sensible default for 95% of
>> current x86 processors in use. People with those old processors can
>> use older gcc or -march=.
>>
>> Default to SSE2 is a good first step.
>
> I think you vastly
On 21/02/2010 20:03, Martin Guy wrote:
> The point about defaults is that the GCC default tends to filter down
> into the default for distributions;
I'd find it surprising if that was really the way it happens; don't
distributions make deliberate and conscious decisions about binary standards
On Sun, Feb 21, 2010 at 09:27:13AM -0800, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch wrote:
>
> >> As I understand it, whether -mfpmath=387 (with excess precision) or
> >> -mfpmath=sse is the default is also considered part of the platform API
> >> (like whether char is signed
On Sun, Feb 21, 2010 at 11:45:49AM -0800, Martin Guy wrote:
> > You want to cater for a minority with old hardware. I
> > actually expect you'll find that those users are less naive than the
> > average gcc user.
> I want to cater for everyone, especially youngsters, learners and the
> poor strug
On 2/21/10, Dave Korn wrote:
> I too am having a hard time envisaging exactly who would be in this class of
> users who are simultaneously so naive that they don't know about -march or
> -mcpu or think to read the manual, and yet so advanced that they are trying
> to
> write programs for and
On 21/02/2010 19:45, Martin Guy wrote:
> On 2/21/10, Steven Bosscher wrote:
>> Your naive users (and mine) don't even know about -mcpu and -march.
> Exactly, so they go "cc hello.c; a.out" and get "Illegal instruction"
> unless they have a relatively new first-world PC.
So learning to program
On 2/21/10, Steven Bosscher wrote:
> It is interesting how this conflicts with your signature:
> > "You can't buy a computer these days with less that a gigabyte."
> > -- A.S.Tanenbaum, trying to defend Minix's fixed-size kernel arrays
> > at FOSDEM 2010
> I take it you disagree with this? B
On 21/02/2010 19:09, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy wrote:
>> As an example of the results of that kind of thinking, we've had years
>> of pain and wasted time in the ARM world due to the default
>> architecture being armv5t instead of armv4t. The results are
On Sun, Feb 21, 2010 at 7:25 PM, Martin Guy wrote:
> I disagree with the "default cpu should 95% of what is currently on
> sale" argument.
>
> The default affects naive users most strongly, so it should "just
> work" on as many processors as is reasonable, not be as fast as
> possible on most of t
Hello Jon,
I'm used to gprof on HPUX and can tell you that on HPUX when we gprof an
executable, its only works on all the objects present in the executable but not
the shared libs. Actually on HPUX, either you choose to gprof the exe or the
libs but not both. When you want both you go to more a
On 2/21/10, Dave Korn wrote:
> It makes perfect sense that configuring for i686-*-* should
> get you an i686 compiler and configuring for i586-*-* should get you an i586
> compiler and so on, rather than that you get an i386 compiler no matter what
> you asked for.
Agreed
M
I have recently encountered a gross inaccuracy in gprof that
I can't explain. Yes, I know gprof uses a sampling technique
so I should not expect a high level of precision, but the results
I am getting clearly reflect a more fundamental issue.
The program in question has been compiled with -pg for
I disagree with the "default cpu should 95% of what is currently on
sale" argument.
The default affects naive users most strongly, so it should "just
work" on as many processors as is reasonable, not be as fast as
possible on most of the majority of the processors currently on sale.
Naive users mi
On 21/02/2010 11:21, Paolo Carlini wrote:
> On 02/19/2010 01:46 AM, Joseph S. Myers wrote:
>> On Thu, 18 Feb 2010, Jason Merrill wrote:
>>
>>> I periodically get bitten by bug 34115: a compiler configured without
>>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would
>>>
On Sun, 21 Feb 2010, Richard Guenther wrote:
> We could very well enable -mfpmath=sse as a side-effect of -ffast-math though.
Yes, or sse+387 if that helps. As documented:
@option{-fexcess-precision=standard} is not implemented for languages
other than C, and has no effect if
@option{-fun
On Sun, Feb 21, 2010 at 6:34 PM, Joseph S. Myers
wrote:
> On Sun, 21 Feb 2010, Geert Bosch wrote:
>
>> > As I understand it, whether -mfpmath=387 (with excess precision) or
>> > -mfpmath=sse is the default is also considered part of the platform API
>> > (like whether char is signed or unsigned by
On Sun, 21 Feb 2010, Geert Bosch wrote:
> > As I understand it, whether -mfpmath=387 (with excess precision) or
> > -mfpmath=sse is the default is also considered part of the platform API
> > (like whether char is signed or unsigned by default, for example), in
> > addition to the ABI issues th
On Sun, Feb 21, 2010 at 6:15 PM, Geert Bosch wrote:
>
> On Feb 21, 2010, at 09:58, Joseph S. Myers wrote:
>> On Sun, 21 Feb 2010, Richard Guenther wrote:
The biggest change we need to make for x86 is to enable SSE2,
so we can get proper rounding behavior for float and double,
as wel
On Sun, Feb 21, 2010 at 9:15 AM, Geert Bosch wrote:
>> As I understand it, whether -mfpmath=387 (with excess precision) or
>> -mfpmath=sse is the default is also considered part of the platform API
>> (like whether char is signed or unsigned by default, for example), in
>> addition to the ABI iss
On Sun, Feb 21, 2010 at 6:58 AM, Joseph S. Myers
wrote:
> On Sun, 21 Feb 2010, Richard Guenther wrote:
>
>> > The biggest change we need to make for x86 is to enable SSE2,
>> > so we can get proper rounding behavior for float and double,
>> > as well as significant performance increases.
>>
>> I t
On Feb 21, 2010, at 09:58, Joseph S. Myers wrote:
> On Sun, 21 Feb 2010, Richard Guenther wrote:
>>> The biggest change we need to make for x86 is to enable SSE2,
>>> so we can get proper rounding behavior for float and double,
>>> as well as significant performance increases.
>>
>> I think Josep
On Sun, 21 Feb 2010, Richard Guenther wrote:
> > The biggest change we need to make for x86 is to enable SSE2,
> > so we can get proper rounding behavior for float and double,
> > as well as significant performance increases.
>
> I think Joseph fixed the rounding behavior for 4.5. Also without a
On 02/21/2010 01:13 PM, Richard Guenther wrote:
> The present discussion is about defaulting to at least 486 when not
> configured for i386-linux. That sounds entirely reasonable to me.
>
Again for the record, I like this too, if we can't do what Joseph suggests.
Paolo.
On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch wrote:
>
> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>> My point: gcc may fail to attract users (and/or may be losing users)
>> when it tries to tailor to the needs of minorities.
>>
>> IMHO it would be much more reasonable to change the default
On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
> My point: gcc may fail to attract users (and/or may be losing users)
> when it tries to tailor to the needs of minorities.
>
> IMHO it would be much more reasonable to change the defaults to
> generate code that can run on, say, 95% of the compu
On 02/19/2010 01:46 AM, Joseph S. Myers wrote:
> On Thu, 18 Feb 2010, Jason Merrill wrote:
>
>> I periodically get bitten by bug 34115: a compiler configured without
>> --with-arch on i686-pc-linux-gnu doesn't support atomics. I think we would
>> only need to bump the default to i486 to get ato
On Fri, Feb 19, 2010 at 6:31 PM, Joe Buck wrote:
> On Thu, Feb 18, 2010 at 06:00:07PM -0800, Tim Prince wrote:
>> On 2/18/2010 4:54 PM, Joe Buck wrote:
>> >
>> > But maybe I didn't ask the right question: can any x86 experts comment on
>> > recently made x86 CPUs that would not function correctly
57 matches
Mail list logo
