https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #61 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #60)
> There's no wiggle room, we're definitely non-conforming.
>
> Maybe the changes could be limited to -std=gnu++NN modes only, although
> Paolo argued strongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #60 from Jonathan Wakely ---
There's no wiggle room, we're definitely non-conforming.
Maybe the changes could be limited to -std=gnu++NN modes only, although Paolo
argued strongly against that in this bug report.
It doesn't seem to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Shafik Yaghmour changed:
What|Removed |Added
CC||yaghmour.shafik at gmail dot
com
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #57 from Paolo Carlini 2011-08-11
17:33:01 UTC ---
Any objections to adding to the Wiki a list of the intrinsics not yet folded by
the middle-end as an open project? Or we do already have such a list somewhere
(beyond inspecting built
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #56 from paolo at gcc dot gnu.org
2011-08-01 19:26:42 UTC ---
Author: paolo
Date: Mon Aug 1 19:26:39 2011
New Revision: 177070
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177070
Log:
2011-08-01 Paolo Carlini
PR c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #55 from Jason Merrill 2011-08-01
18:27:58 UTC ---
I've changed the compiler to allow all builtins in constexpr functions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #54 from Jason Merrill 2011-08-01
18:14:32 UTC ---
Author: jason
Date: Mon Aug 1 18:14:29 2011
New Revision: 177066
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177066
Log:
PR c++/49813
* semantics.c (potential_cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #53 from Steve Ellcey 2011-07-28 20:59:15
UTC ---
Author: sje
Date: Thu Jul 28 20:59:11 2011
New Revision: 176899
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176899
Log:
2011-07-28 Paolo Carlini
PR c++/49813
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #52 from rguenther at suse dot de
2011-07-28 09:26:40 UTC ---
On Wed, 27 Jul 2011, ghazi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #50 from Kaveh Ghazi 2011-07-27
> 23:13:18 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #51
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #50 from Kaveh Ghazi 2011-07-27 23:13:18
UTC ---
(In reply to comment #46)
> Another note, about std::nextafter, std::nexttoward, & co: I see mpfr provides
> an mpfr_nexttoward, which likely could be exploited in builtins.c pretty
> e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #49 from Paolo Carlini 2011-07-27
22:56:10 UTC ---
Thanks for your feedback Kaveh. Note, however, that, as I mentioned only today
in Comment #45, with -m32 we have problems also with the overload for double, I
have no idea how to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #48 from Kaveh Ghazi 2011-07-27 22:32:57
UTC ---
(In reply to comment #41)
> The testcase in Comment #30 has the types wrong, the below is a corrected
> version (the substance of the issue doesn't change at all). I'm also thinking
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #47 from paolo at gcc dot gnu.org
2011-07-27 19:33:55 UTC ---
Author: paolo
Date: Wed Jul 27 19:33:51 2011
New Revision: 176847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176847
Log:
2011-07-27 Paolo Carlini
PR c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Paolo Carlini changed:
What|Removed |Added
CC||ghazi at gcc dot gnu.org
--- Comment #46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #45 from Paolo Carlini 2011-07-27
16:48:55 UTC ---
I have just noticed that with -m32 the isinf overloads for float and double are
also affected, that is:
constexpr bool
isinf(float __x)
{ return __builtin_isinf(__x); }
constexpr bo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #44 from Paolo Carlini 2011-07-26
00:29:22 UTC ---
Please.. ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #43 from Jason Merrill 2011-07-26
00:26:26 UTC ---
(In reply to comment #42)
> Seems like we should add BUILT_IN_ISINF and its variants to
> builtin_valid_in_constant_expr_p.
Actually, we seem to ignore the arguments when a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #42 from Jason Merrill 2011-07-26
00:10:20 UTC ---
(In reply to comment #34)
> (we *do* have PRs about constexpr vs diagnostics)
Notably 45923, which I have just closed as fixed by my June 29 patch.
The comment 8 testcase results in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #41 from Paolo Carlini 2011-07-25
19:58:52 UTC ---
The testcase in Comment #30 has the types wrong, the below is a corrected
version (the substance of the issue doesn't change at all). I'm also thinking
of checking in the library bits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #40 from Paolo Carlini 2011-07-25
11:57:58 UTC ---
Created attachment 24826
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24826
Library bits, passes testing, the isinf overload for long double cannot be
marked constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #39 from Paolo Carlini 2011-07-25
11:49:33 UTC ---
(however, the issue in Comment #30, isinf vs long double, seems a real glitch
somewhere, the intrinsic works fine)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #35 from Paolo Carlini 2011-07-25
11:41:57 UTC ---
Also, something seems wrong with nextafter, but for the intrinsic too this
time, thus maybe is a middle-end issue (eg, not optimized at all?). Try:
constexpr float na = __builtin_n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #37 from rguenther at suse dot de
2011-07-25 11:44:12 UTC ---
On Mon, 25 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #35 from Paolo Carlini
> 2011-07-25 11:4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #38 from Paolo Carlini 2011-07-25
11:46:00 UTC ---
Ah Ok, maybe I will be able to work on that. Just wanted to make sure we
understand where the problem is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #36 from Paolo Carlini 2011-07-25
11:43:02 UTC ---
Or, more correctly:
constexpr float na = __builtin_nextafterf(0.0f, 0.0f);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #34 from Paolo Carlini 2011-07-25
11:17:24 UTC ---
Better diagnostic would be always welcome, but probably we should deal with
that elsewhere (we *do* have PRs about constexpr vs diagnostics), because it's
a generic problem, isn't spe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #33 from vincenzo Innocente
2011-07-25 11:02:26 UTC ---
indeed
as noted in comment 8
20 static constexpr float nan1 = std::asin(1.45);
21 static constexpr float nan2 = std::sqrt(-1.45);
produces the quite confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #32 from rguenther at suse dot de
2011-07-25 10:59:30 UTC ---
On Mon, 25 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #31 from Paolo Carlini
> 2011-07-25 10:5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #31 from Paolo Carlini 2011-07-25
10:54:24 UTC ---
Richard, as far as I can see, if we don't fold, we don't fold, that line of
user code with, eg constexpr data, will simply not compile. I don't think this
is a major issue...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Paolo Carlini changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #30 from Paolo Carlini 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #25 from Daniel Krügler
2011-07-24 14:55:04 UTC ---
(In reply to comment #21)
As far as I could follow this discussion, LWG 2013 seems to be the right
location from the library view of point. But a compiler should not allow for
funct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #24 from Paolo Carlini 2011-07-22
17:16:43 UTC ---
As far as I can see, Vincenzo, in that case the problem is a bit different,
because those functions aren't ISO: should Intel issue an updated document
describing the builtins and ackn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #23 from vincenzo Innocente
2011-07-22 16:48:35 UTC ---
would http://lwg.github.com/issues/lwg-active.html#2013 allow gcc to declare
constexpr the x86 builtins (and corresponding wrapper functions)?
I would be interested to have cons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #22 from Jason Merrill 2011-07-22
16:06:13 UTC ---
Author: jason
Date: Fri Jul 22 16:06:08 2011
New Revision: 176635
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176635
Log:
PR c++/49813
* c-opts.c (set_std_cxx0x): S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #21 from Paolo Carlini 2011-07-22
15:31:15 UTC ---
Hum (Jason and Daniel, in particular) I'm wondering if the issue could fall
under http://lwg.github.com/issues/lwg-active.html#2013 but then, we would be
able to assume / do it only f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #20 from Paolo Carlini 2011-07-22
15:07:53 UTC ---
I see, everything makes sense now. And OK, I'll raise the issue (in fact, we
have Daniel in CC, in this bug... ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #18 from Paolo Carlini 2011-07-22
12:31:05 UTC ---
Before any other discussion (I believe we want to hear Jason now) I only want
to add this: I think the whole discussion about -std=c++0x vs -std=gnu++0x can
only possibly be useful in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #17 from rguenther at suse dot de
2011-07-22 11:43:57 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #16 from Paolo Carlini
> 2011-07-22 11:4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #16 from Paolo Carlini 2011-07-22
11:40:07 UTC ---
(In reply to comment #14)
> There is also a using ::asinhf but still std:: provides an overload.
So? This is what C++0x says we should have.
As regards a complete testcase, I gave t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #15 from Richard Guenther 2011-07-22
11:30:38 UTC ---
Also works with
namespace std {
constexpr double asinh (double x) { return __builtin_asinh (x); }
}
int main()
{
constexpr double das = std::asinh(1.0);
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #14 from rguenther at suse dot de
2011-07-22 11:29:04 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #11 from Paolo Carlini
> 2011-07-22 11:2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #13 from Paolo Carlini 2011-07-22
11:24:21 UTC ---
... and let's decide to look at mainline, first at least.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #12 from rguenther at suse dot de
2011-07-22 11:20:52 UTC ---
On Fri, 22 Jul 2011, rguenther at suse dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #10 from rguenther at suse dot de
> 2011-07-22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #11 from Paolo Carlini 2011-07-22
11:20:36 UTC ---
It does *not* Richi, there is an using ::asinh above. Exactly the same for
sinh.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #10 from rguenther at suse dot de
2011-07-22 11:17:38 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #9 from Paolo Carlini
> 2011-07-22 11:09
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #9 from Paolo Carlini 2011-07-22
11:09:55 UTC ---
Yes, Vincenzo, all the other C99-only functions should be audited. I suppose a
clean fix will automatically deal with all of them.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #8 from vincenzo Innocente
2011-07-22 11:06:41 UTC ---
what about other "new C99 functions" such as
cexprMath.cpp:16:64: error: 'float std::nextafter(float, float)' is not
'constexpr'
cexprMath.cpp:17:58: error: 'float std::trunc(floa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #7 from Paolo Carlini 2011-07-22
11:02:01 UTC ---
I just tried. This:
#include
int main()
{
double ds = sinh(1.0);
double das = asinh(1.0);
}
this compiles fine with -std=c++0x for me. On Linux of course, other targets
have s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #6 from rguenther at suse dot de
2011-07-22 10:56:51 UTC ---
On Fri, 22 Jul 2011, paolo.carlini at oracle dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
>
> --- Comment #5 from Paolo Carlini
> 2011-07-22 10:52:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #5 from Paolo Carlini 2011-07-22
10:52:03 UTC ---
We don't want this to depend on -std=gnu++0x vs -std=c++0x!!
The function is there, declared and callable, as removing constexpr reveals,
the behavior wrt constexpr data cannot depend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Paolo Carlini changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
--- Comment #2 from Richard Guenther 2011-07-22
10:41:36 UTC ---
With C++ I get
> ./cc1plus -quiet t.c -fdump-tree-original -std=c++0x
t.c: In function 'int main()':
t.c:6:39: error: 'asinh' was not declared in this scope
without -std=c++0x the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49813
Richard Guenther changed:
What|Removed |Added
Target|x86_64-linux|
--- Comment #1 from Richard Guenther
58 matches
Mail list logo
