On Thu, 2013-08-01 at 14:42 -0500, Peter Bergner wrote:
> Jakub & richi,
>
> This bug also affects GCC 4.8. Is it appropriate to backport this patch
> to the FSF 4.8 branch? I can bootstrap and regtest it there too before
> committing if you think it's ok.
FYI, I tested the patch on the FSF 4.8
On Thu, 2013-08-01 at 11:33 +0200, Paolo Carlini wrote:
> On 07/31/2013 10:01 PM, Peter Bergner wrote:
> > Can you tell me what the status of the following patch that
> > removes the pow() overload from tr1 is? Specifically:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html
> >
Hi,
On 07/31/2013 10:01 PM, Peter Bergner wrote:
Hi Fabien,
Can you tell me what the status of the following patch that
removes the pow() overload from tr1 is? Specifically:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html
It seemed to have been approved and you were going to do
Hi Fabien,
Can you tell me what the status of the following patch that
removes the pow() overload from tr1 is? Specifically:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html
It seemed to have been approved and you were going to do some
additional testing before committing the patch l
Hi,
"Fabien Chêne" ha scritto:
>Then, It seems to me that such a change should ideally go in a separate
>patch.
Yes. Frankly I thought it was already clear that for the purpose of fixing this
c++ issue we weren't inventing anything new in the library. Just in case isn't
fully clear to every
Hi,
2013/5/23 Jason Merrill
>
> On 05/22/2013 04:53 PM, Fabien Chêne wrote:
>>
>> Ah, I see, it works. Then we end up with three solutions:
>> 1) remove the pow(double,double) overload
>> 2) add a specialization template <> pow(double,double)
>> 3) add an extern "C" declaration to refer to the C
On 05/22/2013 04:53 PM, Fabien Chêne wrote:
Ah, I see, it works. Then we end up with three solutions:
1) remove the pow(double,double) overload
2) add a specialization template <> pow(double,double)
3) add an extern "C" declaration to refer to the C library function
I don't have a strong prefere
Hi,
Again sorry for such a delay. Paolo subtly ping'ed me on DR39
(c++/13590), and I remember that this bug (c++/54537) was blocking the
patch I wrote last year for DR39.
2012/11/15 Jason Merrill :
[...]
> I was only thinking of the primary signature; putting
>
> extern "C" double pow (double, do
On 11/15/2012 03:33 AM, Fabien Chêne wrote:
2012/11/14 Jason Merrill :
I'll just note that another solution would be to change non-template
forwarding pows to be extern "C" declarations. But it sounds like you folks
have this issue in hand.
I'm a bit puzzled by your suggestion, altough I have
Hi,
2012/11/14 Jason Merrill :
> I'll just note that another solution would be to change non-template
> forwarding pows to be extern "C" declarations. But it sounds like you folks
> have this issue in hand.
I'm a bit puzzled by your suggestion, altough I have not tried it yet,
how can it work gi
2012/11/14 Paolo Carlini :
[...]
> Since we came to the conclusion that removing the overload for (double,
> double) worked, let's just do that and be done with it. Then we have a few
> months before the release to make sure that we aren't regressing, safe
> enough for this legacy TR1 stuff, IMO.
I'll just note that another solution would be to change non-template
forwarding pows to be extern "C" declarations. But it sounds like you
folks have this issue in hand.
Jason
Hi,
On 11/14/2012 10:04 PM, Fabien Chêne wrote:
My apologize to come back after such a delay. The patch is almost
ready, I was just wondering if we could add the specialization
template<> inline double pow(double __x, double __y) { return
std::pow(__x, __y); } (in tr1/math.h) instead of relyin
hi,
2012/9/19 Paolo Carlini :
> Hi Fabien,
>
>
> On 09/19/2012 07:29 PM, Fabien Chêne wrote:
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
the latter drags again in namespace std:
Hi Fabien,
On 09/19/2012 07:29 PM, Fabien Chêne wrote:
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
the latter drags again in namespace std::tr1 the overloads pow
(*, int) which we don't want ther
Hi Paolo,
2012/9/19 Paolo Carlini :
> On 09/19/2012 01:24 AM, Paolo Carlini wrote:
>>
>> On 09/19/2012 01:12 AM, Paolo Carlini wrote:
>>>
>>> Hi again,
>>>
>>> On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected, *IF*
(please
The compiler changes are OK.
Jason
On 09/19/2012 01:24 AM, Paolo Carlini wrote:
On 09/19/2012 01:12 AM, Paolo Carlini wrote:
Hi again,
On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected,
*IF* (please check) TR1 says that those three overloads, for float,
double an long
On 09/19/2012 01:12 AM, Paolo Carlini wrote:
Hi again,
On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected,
*IF* (please check) TR1 says that those three overloads, for float,
double an long double, must be declared in std::tr1 (likewis
Hi again,
On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected, *IF*
(please check) TR1 says that those three overloads, for float, double
an long double, must be declared in std::tr1 (likewise for all the
other math functions) Now, give
Hi,
"Fabien Chêne" ha scritto:
>2012/9/18 Paolo Carlini :
>
>> I don't understand: what's wrong - exactly - with the std::tr1::pow
>(double, double) overload above? Now I can't immediately check, but do
>the EDG and CLANG front ends accept it or not?
>
>They don't. The problem is that it conflic
2012/9/18 Paolo Carlini :
> I don't understand: what's wrong - exactly - with the std::tr1::pow (double,
> double) overload above? Now I can't immediately check, but do the EDG and
> CLANG front ends accept it or not?
They don't. The problem is that it conflicts with ::pow(double,double).
// i
Hi,
"Fabien Chêne" ha scritto:
>2012/9/11 Fabien Chêne :
>> Oops, not sure how I test that change initially, or I must be blind,
>> because it triggers an error in tr1/cmath about pow. I'll see what I
>> can do...
>
>Well, as summarized in the code below, the problem seems to be the
>redundant o
... And the patch.
2012/9/18 Fabien Chêne :
> 2012/9/11 Fabien Chêne :
>> Oops, not sure how I test that change initially, or I must be blind,
>> because it triggers an error in tr1/cmath about pow. I'll see what I
>> can do...
>
> Well, as summarized in the code below, the problem seems to be the
2012/9/11 Fabien Chêne :
> Oops, not sure how I test that change initially, or I must be blind,
> because it triggers an error in tr1/cmath about pow. I'll see what I
> can do...
Well, as summarized in the code below, the problem seems to be the
redundant overload of std::tr1::pow(double,double).
Oops, not sure how I test that change initially, or I must be blind,
because it triggers an error in tr1/cmath about pow. I'll see what I
can do...
2012/9/10 Jason Merrill :
> OK.
>
> Jason
--
Fabien
OK.
Jason
Hi,
The problem here is the misused of the OVL_USED macro. It should only
be applied on OVERLOAD, this patch forces that by checking the
OVL_USED macro. As a result, we need to make sure that we have an
overload by checking its tree code.
Tested x86_64-unknown-linux-gnu. OK to commit ?
2012-09-
28 matches
Mail list logo
