Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user
A, who just types g++ foo.cpp and expects to get a program that works
well on a typical machine, and user B, who types g++ -march=i386
foo.cpp,
On Fri, 22 Aug 2008, Richard Henderson wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers
[EMAIL PROTECTED] wrote:
On Fri, 22 Aug 2008, Richard Henderson wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor?
Hi,
One significant case is where atomic operations are available with kernel
help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed
patch to do the same for ARM GNU/Linux; both use kernel help in those
implementations, and more targets may do this in future. (It's been
Paolo Carlini:
Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user A,
who just types g++ foo.cpp and expects to get a program that works well
on a typical machine, and user B, who types g++
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers
glibc has certainly required -march=i486 or greater for some time to build
for IA32; it will fail to link for -march=i386 because of missing atomic
On Wed, Aug 27, 2008 at 10:26:32AM -0700, H.J. Lu wrote:
Given that glibc requires
On Wed, 27 Aug 2008, Paolo Carlini wrote:
Hi,
One significant case is where atomic operations are available with kernel
help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed
patch to do the same for ARM GNU/Linux; both use kernel help in those
implementations, and
On Wed, 27 Aug 2008, Joe Buck wrote:
Joseph again:
operations. (And I hold that i686-* should mean -march=i686 default not
-mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64,
subject to --with-arch etc. in both cases.)
I'm not keen on moving the default -march
Joseph S. Myers wrote:
The test will always compile, but sometimes the result will have
references to the __sync_* functions in the output. Then, for certain
targets where these functions are defined in a library, the result will
link. (The only targets where these are defined in a library
Joseph S. Myers wrote:
Users of those systems should configure for i586-linux-gnu or
i486-linux-gnu not i686-linux-gnu. config.guess should select such a
target automatically in the case of a native build. (If you configure
glibc for i686-linux-gnu, it will use assembly sources that
On Wed, Aug 27, 2008 at 05:55:19PM +, Joseph S. Myers wrote:
On Wed, 27 Aug 2008, Joe Buck wrote:
Joseph again:
operations. (And I hold that i686-* should mean -march=i686 default not
-mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64,
subject to
On Wed, Aug 27, 2008 at 11:02 AM, Mark Mitchell [EMAIL PROTECTED] wrote:
Joseph S. Myers wrote:
Users of those systems should configure for i586-linux-gnu or
i486-linux-gnu not i686-linux-gnu. config.guess should select such a
target automatically in the case of a native build. (If you
H.J. Lu wrote:
For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should
be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ...
x86-64. Is someone working on such a patch?
IMHO making this Linux specific just replaces one confusing and
arbitrary decision
On Wed, 27 Aug 2008, Brian Dessent wrote:
H.J. Lu wrote:
For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should
be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ...
x86-64. Is someone working on such a patch?
IMHO making this Linux specific
Richard Henderson wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum these days.
I agree.
Mark Mitchell wrote:
Obviously, distributors can do whatever they please, but the C++
run-time library needs to tolerate CPUs without this feature. It can of
course offer reduced functionality (at compile-time or at run-time) on
CPUs without the necessary support.
As far as I'm concerned, I
Mark Mitchell:
Richard Henderson wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum these
Paolo Carlini wrote:
Paolo Carlini wrote:
I'm going to revert again the whole thing and wait for a different,
safe, approach, sorry.
In the short time frame, i.e., something solid for 4.4.0, I would
suggest two possible strategies:
1- Try to re-organize the new code in order to make possible
Hi,
1- Try to re-organize the new code in order to make possible using in
*few* selected places _GLIBCXX_ATOMIC_BUILTINS_4 to enable / disable
the new feature completely.
The necessary code changes for this are in the attached patch. Most of
the code doesn't need to be touched, because the
Hi,
apparently, between Revisions 139407 and 139411, this test started
failing the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post the error?
Thanks,
Paolo.
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini [EMAIL PROTECTED] wrote:
Hi,
apparently, between Revisions 139407 and 139411, this test started failing
the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post the error?
H.J. Lu wrote:
On Fri, Aug 22, 2008 at 8:59 AM, Paolo Carlini [EMAIL PROTECTED] wrote:
Hi,
apparently, between Revisions 139407 and 139411, this test started failing
the build:
FAIL: abi/cxx_runtime_only_linkage.cc (test for excess errors)
Any idea what's going wrong? Maybe HJ can post
H.J. Lu wrote:
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o):
In function `__exchange_and_add_dispatch':^M
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/ext/atomicity.h:84:
undefined
Sebastian Redl wrote:
That's my exception_ptr code again (indirectly, this time).
Apparently, __exchange_and_add has exactly the same problem as
__sync_add_and_fetch_4: it's just not implemented on i386 targets.
Not really, it would be too easy ;) It is implemented of course, but it
is
Paolo Carlini wrote:
H.J. Lu wrote:
/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_throw.o):
In function `__exchange_and_add_dispatch':^M
Paolo Carlini wrote:
Anwyay, one way or the other, l porpose for now let's just support the
new facility only for targets providing the sync builtins and be done
with it. Agreed?
I have no objection to doing that in principle, but it basically means
programming effort in order to remove
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle. However, sorry, I don't feel like doing that,
it's a non trivial change, because *anything* related
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle.
Well, thinking more about it, I don't see how you can do it without
breaking
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building blocks
in my opinion.
I agree, in principle. However, sorry, I don't feel like doing that,
it's a non trivial change,
Hi,
What macro do I switch on? _GLIBCXX_ATOMIC_BUILTINS_4?
Yes, should be safe for static switching. I think you should consider
also the option of having less stuff exported from libsupc++: if you
somehow manage to have the different code paths in the headers, then you
can dynamically switch
Sebastian Redl wrote:
The other weird thing is that the 32-bit target of the x86_64 compiler
doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults
to a i386 profile. Now, I understand that for the 32-bit x86 compiler,
but the 64-bit compiler is not a cross-compiler and
Paolo Carlini wrote:
I think you should consider also the option of having less stuff
exported from libsupc++: if you somehow manage to have the different
code paths in the headers
That's impossible without exposing unwind-cxx.h to the public, and
that's a can of worms I don't even want to
On Fri, Aug 22, 2008 at 10:06 AM, Richard Henderson [EMAIL PROTECTED] wrote:
Sebastian Redl wrote:
The other weird thing is that the 32-bit target of the x86_64 compiler
doesn't have _GLIBCXX_ATOMIC_BUILTINS_4 defined - apparently it defaults to
a i386 profile. Now, I understand that for the
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Even if we do that, we'll still get errors if someone forces i386. And
the people doing that are more likely to want to link against the
standalone libsupc++, too, since i386 is mostly used in embedded systems
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Yes, but again, I have to remind you that the problem is with *any*
target or subtarget not implementing the atomic builtins.
Paolo.
On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl
[EMAIL PROTECTED] wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Even if we do that, we'll still get errors if someone forces i386. And the
people doing that are more likely to want to link against the
Sebastian Redl wrote:
Paolo Carlini wrote:
I think you should consider also the option of having less stuff
exported from libsupc++: if you somehow manage to have the different
code paths in the headers
That's impossible without exposing unwind-cxx.h to the public, and
that's a can of worms I
On Fri, Aug 22, 2008 at 11:05:12AM -0700, H.J. Lu wrote:
On Fri, Aug 22, 2008 at 10:53 AM, Sebastian Redl
[EMAIL PROTECTED] wrote:
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
Even if we do that, we'll still get errors if someone forces i386. And the
Paolo Carlini wrote:
Ok, then, we declare here, that, for gcc4.4.0 this C++0x feature is
available only for targets unconditionally implementing the atomic
builtins. I'll take care of the configury bits.
And even this, given the current structure of the patch, we don't want
to do, because
Paolo Carlini wrote:
Paolo Carlini wrote:
Sebastian Redl wrote:
Could we simply export __exchange_and_add and __atomic_add from
libsupc++ instead of libstdc++? They are pretty basic building
blocks in my opinion.
I agree, in principle.
Well, thinking more about it, I don't see how you can do
Sebastian Redl wrote:
What part, exactly? libstdc++.so still exports the symbol, since the
supc++ and stdc++ libraries are both in there.
So, essentially, you want to *duplicate* all the exports now in
libstdc++ also in libsupc++? Because certainly you can't remove the
exports from libstdc++.
Paolo Carlini wrote:
So, essentially, you want to *duplicate* all the exports now in
libstdc++ also in libsupc++? Because certainly you can't remove the
exports from libstdc++. No, no, I don't think we want to do that.
Disregard the above. Anyway, I'm not at all convinced that your plan is
H.J. Lu wrote:
Can we declare that Linux/ia32 generates i486 insn by default?
We the gcc team? I'm not sure. For now I'll say no.
We an individual linux distributor? Certainly.
In fact I would be surprised if i586 wasn't a
decent minimum these days.
r~
Paolo Carlini wrote:
I'm going to revert again the whole thing and wait for a different,
safe, approach, sorry.
In the short time frame, i.e., something solid for 4.4.0, I would
suggest two possible strategies:
1- Try to re-organize the new code in order to make possible using in
*few*
44 matches
Mail list logo
