On Oct 19, 2012, at 10:51 PM, Richard Smith rich...@metafoo.co.uk wrote:
On Fri, Oct 19, 2012 at 10:50 PM, Chandler Carruth chandl...@google.com
wrote:
On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith rich...@metafoo.co.uk wrote:
[Crossposted to both GCC and Clang dev lists]
Hi,
One
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,
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't
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
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
On Jun 9, 2006, at 9:31 PM, Pedro Lamarão wrote:
Any feedback is welcome!
Thank you!
-Howard
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
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
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 {
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 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
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
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.
nod Part of the migration. OS X /is/ unix. Ok, I'm sure that's an
inaccurate statement and I trust the more
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 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
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
I've been reviewing the age-old issue of interpreting
whitespace*newline 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
20 matches
Mail list logo
