On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x,
1./3.)
-> cbrt(x) conversion because gfortran didn
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
My inclination is that if pow(x, 1./3.) (computed
correctly to the last bit) ever differs from cbrt(x) (computed
correctly to the last bit) then this substitution should not be done.
C99 7.12.7.1 says "The cbrt functions compute the real cu
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded "exact" cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
the example I showed the
At the risk of wading in too deep... there is one aspect of exception
specification checking that I've become absolutely convinced would
benefit greatly from static checking:
A::~A() static throw(); // or whatever syntax
That is, there is some code that you know should not throw anything,
I've been reviewing the age-old issue of interpreting
* as the end-of-line indicator as is the current
practice with gcc. For those not familiar with this issue, gcc takes
advantage of C99's 5.1.1.2p1b1 "implementation-defined manner" to
convert multibyte end-of-line indicators to newline
On Oct 25, 2005, at 6:22 PM, Andrew Pinski wrote:
We have people already complaining about removing extensions. Why
should we change
this implementionation defined documented behavior.
I'm not convinced that "extension" is a proper term for this
behavior. It is more like an incompatibili
On Oct 25, 2005, at 7:44 PM, Andrew Pinski wrote:
But this is not an extension at all. This is an implementation
defined
behavior which is different than what an extension would do.
People depending on this is not the correct thing do any ways as
there could be another compiler besides which
On Oct 25, 2005, at 8:11 PM, Joe Buck wrote:
// A poorly formatted comment \\
int x = 0;
int y = 1;
...
Howard,
Have you tested the sequence above with various compilers?
I only know of the results on gcc 4.x, MS, EDG-based, and Freescale
CodeWarrior.
I just
have. The behavior depen
On Oct 25, 2005, at 8:22 PM, Andrew Pinski wrote:
Why not get other compilers to change to what GCC does? Why does GCC
have to follow what other compilers do, maybe other compilers
would be in the best interest of following what GCC does.
Why not instead get the standard changed and then GCC w
On Oct 26, 2005, at 12:18 PM, Robert Dewar wrote:
Mike Stump wrote:
On Oct 25, 2005, at 9:28 PM, Joe Buck wrote:
Are you really saying that someone is using ASCII line art in
comments
that tweaks this behavior?
Yes, I'm sorry if previous message didn't make this clear.
Why would line
On Oct 26, 2005, at 1:16 PM, Andrew Pinski wrote:
What I am trying to say is that
the only reason why this was brought up was because of some little
ASCII art (ASCII art does have its place in comments, see rs6000.c for
an example of where ASCII art actually helps). If there was another
reason,
On Oct 26, 2005, at 4:58 PM, DJ Delorie wrote:
To add to that, Mac text files use a bare \r as a newline.
Just a nit: 5 years ago that was true. Now \n is "native" but most
Mac software is pretty tolerant of newline representation due to its
history.
-Howard
On Oct 26, 2005, at 5:17 PM, DJ Delorie wrote:
Just a nit: 5 years ago that was true. Now \n is "native"
Was that part of the OS/X migration, or otherwise? Just curious.
Part of the migration. OS X /is/ unix. Ok, I'm sure that's an
inaccurate statement and I trust the more experi
On Oct 26, 2005, at 6:50 PM, Robert Dewar wrote:
The problem is that it's portable to every other compiler we've
tested. I am curious what icc and xlc do, but those are the only
two not tested.
Sorry, I have a different meaning of portable, for me the term is
related to the standard, meaning
On Nov 6, 2005, at 6:03 AM, Paolo Carlini wrote:
So - can't you work with some preprocessor magic and a define, if
the builtins are available?
I don't really understand this last remark of yours: is it an
alternate solution?!? Any preprocessor magic has to rely on a new
preprocessor builtin
Hi All,
I'm wondering if the following behavior is:
1. An already reported bug.
2. Not reported, I need to file a bugzilla.
3. Disputed.
Here's the test case:
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us =
On Nov 25, 2005, at 9:28 AM, Phil Edwards wrote:
On Wed, Nov 23, 2005 at 07:42:35PM +0800, ?? wrote:
The C++ standard said Container::size() should have constant
complexity
(ISO/IEC 14882:1998, pp. 461, Table 65), while the std::list::size
() in
current STL of GCC is defined as { std::d
Hello,
Is there a document, or a discussion that someone can point me to
which explains why fvisibility-inlines-hidden applies to member
functions, but not non-member functions?
Thanks,
Howard
On Feb 3, 2006, at 11:22 AM, Benjamin Kosnik wrote:
Is there a document, or a discussion that someone can point me to
which
explains why fvisibility-inlines-hidden applies to member functions,
but not non-member functions?
AFAICT, there is very little documentation for any of the visibilit
Also see CWG issue 391:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
which will make our behavior non-conforming in C++0X.
-Howard
On Mar 13, 2006, at 4:02 PM, David Fang wrote:
Hi,
Didn't see a reply yet, so I'll chime in.
The relevant text appears in gcc-3.4's
On Jun 9, 2006, at 9:31 PM, Pedro Lamarão wrote:
Any feedback is welcome!
Thank you!
-Howard
On Oct 19, 2012, at 10:51 PM, Richard Smith wrote:
>
> On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth
> wrote:
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith wrote:
> [Crossposted to both GCC and Clang dev lists]
>
> Hi,
>
> One issue facing library authors wanting to use C++11's con
22 matches
Mail list logo
