http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #42 from Marc Glisse 2012-10-05
19:10:27 UTC ---
Author: glisse
Date: Fri Oct 5 19:10:22 2012
New Revision: 192138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192138
Log:
2012-10-05 Marc Glisse
PR libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #41 from Paolo Carlini 2012-10-05
17:08:52 UTC ---
Remove it, remove it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #40 from Marc Glisse 2012-10-05
17:04:35 UTC ---
(In reply to comment #38)
> Eh, eh, hard to reconstruct now what happened at the time. Looks like an svn
> pasto or a plain pasto. I suppose that entire block can be removed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #39 from Paolo Carlini 2012-10-05
17:02:34 UTC ---
Probably a plain pasto of mine dating back to when was copying stuff from tr1/*
in namespace std::tr1 to std:: protected by __GXX_EXPERIMENTAL_CXX0X__. Looks
like I didn't noti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #38 from Paolo Carlini 2012-10-05
16:57:56 UTC ---
Eh, eh, hard to reconstruct now what happened at the time. Looks like an svn
pasto or a plain pasto. I suppose that entire block can be removed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #37 from Marc Glisse 2012-10-05
16:47:33 UTC ---
I see the following in cstdlib:
namespace std
{
#if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
// types
using std::lldiv_t;
Is there a particular reason to import stuff in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #36 from Paolo Carlini 2012-10-05
16:39:27 UTC ---
What I know is that Linux by default uses c_global. There is configury
selecting the directory, but I didn't write the logic, Benjamin did, frankly I
don't know which specific
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #35 from Marc Glisse 2012-10-05
16:33:48 UTC ---
(In reply to comment #34)
> Looks like you forgot the include/c_global/cstdlib bits?
Hmm right, I patched the wrong directory. Maybe c_std/cstdlib should be
removed? It looks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #34 from Paolo Carlini 2012-10-05
16:24:57 UTC ---
Looks like you forgot the include/c_global/cstdlib bits?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Marc Glisse changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #32 from Marc Glisse 2012-10-05
16:20:59 UTC ---
Author: glisse
Date: Fri Oct 5 16:20:44 2012
New Revision: 192132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192132
Log:
2012-10-05 Marc Glisse
PR libs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|glis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Oleg Endo changed:
What|Removed |Added
Attachment #28257|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #28 from Paolo Carlini 2012-09-24
09:27:05 UTC ---
Indeed uglier ;) but I must say that overall I think we have to do something
like this. I'm still annoyed that because of the type we can't handle in the
same way div but I'm a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Marc Glisse changed:
What|Removed |Added
Attachment #28256|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #26 from Kazumoto Kojima 2012-09-24
00:16:19 UTC ---
(In reply to comment #6)
FYI, same on sh-linux, though my glibc for gcc tests is a bit dated. Ugh.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #25 from Paolo Carlini 2012-09-23
23:18:26 UTC ---
That's only internal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #24 from Marc Glisse 2012-09-23
23:16:19 UTC ---
(In reply to comment #23)
> That's fine, not an overload.
__lg?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #23 from Paolo Carlini 2012-09-23
23:11:40 UTC ---
That's fine, not an overload.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #22 from Marc Glisse 2012-09-23
23:08:53 UTC ---
(In reply to comment #21)
> I saw some other places in the library that used long
> long without any macro protection, so I did the same.
>
> Where, exactly?
numeric_limits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #21 from Paolo Carlini 2012-09-23
23:06:14 UTC ---
(In reply to comment #18)
> (In reply to comment #16)
> > I also note that so far we added the long long overloads only in C++11
> > mode. I
> > know that elsewhere in the li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #20 from Oleg Endo 2012-09-23
23:04:39 UTC ---
(In reply to comment #17)
>
> For llabs: why bother, it isn't like there is anything fancy llabs could be
> doing. Is the point that with -Os, a call to llabs is slightly shorter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #19 from Paolo Carlini 2012-09-23
23:03:30 UTC ---
Ok, let's leave llabs and lldiv alone, for now at least.
Otherwise, the lldiv_t issue is really annoying, I'm not sure (anymore) we want
to handle abs and div separately...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #18 from Marc Glisse 2012-09-23
23:01:40 UTC ---
(In reply to comment #16)
> I also note that so far we added the long long overloads only in C++11 mode. I
> know that elsewhere in the library we have long long overloads in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #17 from Marc Glisse 2012-09-23
22:54:47 UTC ---
(In reply to comment #15)
> Ok... thanks Marc for handling this. If we could handle in the same way
> div(long long, long long), it would be great and more consistent. Are we sur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #16 from Paolo Carlini 2012-09-23
22:52:50 UTC ---
I also note that so far we added the long long overloads only in C++11 mode. I
know that elsewhere in the library we have long long overloads in C++98 mode
too as extensions, b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #15 from Paolo Carlini 2012-09-23
22:43:02 UTC ---
Ok... thanks Marc for handling this. If we could handle in the same way
div(long long, long long), it would be great and more consistent. Are we sure
we can't?
Also, too bad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #14 from Oleg Endo 2012-09-23
22:34:09 UTC ---
(In reply to comment #13)
> Created attachment 28256 [details]
> always define abs(long long)
>
> This is what I had in mind (this abs(long long) is not a fallback, that's the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #13 from Marc Glisse 2012-09-23
22:21:35 UTC ---
Created attachment 28256
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28256
always define abs(long long)
This is what I had in mind (this abs(long long) is not a fallba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #12 from Marc Glisse 2012-09-23
22:10:56 UTC ---
(In reply to comment #11)
> You really scared me now.
> unsigned long is also a nop.
That's only because unsigned long has less bits than the mantissa of double on
your platf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #11 from Oleg Endo 2012-09-23
21:50:37 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Thanks god (or whoever)
>
> Would that make me a half-god? seems dangerous...
>
> > that the following:
> >
> > un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #10 from Marc Glisse 2012-09-23
21:37:54 UTC ---
(In reply to comment #8)
> Thanks god (or whoever)
Would that make me a half-god? seems dangerous...
> that the following:
>
> unsigned int test_xx (unsigned int a)
> {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Paolo Carlini changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #8 from Oleg Endo 2012-09-23 21:20:46
UTC ---
(In reply to comment #5)
> Er, abs is the exception there. signed integers have their own overloads of
> abs
> (in cstdlib). Seems like only unsigned integers get converted to doub
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #7 from Paolo Carlini 2012-09-23
21:15:30 UTC ---
Thanks for the message, Marc, I think we are both missing something here,
because abs (long long) apparently (I didn't write the code) has already a fall
back open coded impleme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #5 from Marc Glisse 2012-09-23 21:00:00
UTC ---
(In reply to comment #1)
> Note that the abs(long) and abs(long long) overloads, which you probably want
> around, are actually declared in , which you are not including
> (-std=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #4 from Paolo Carlini 2012-09-23
20:56:51 UTC ---
Sorry, forgot that only declares some types. Thus, all in all, the
issue is really that should provide abs (long) and abs (long long)
and it isn't because below it llabs is mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #3 from Paolo Carlini 2012-09-23
20:49:11 UTC ---
Actually, is normally included by as an implementation
detail, thus I suspect the C++11 bits in are also disabled for this
target. Looks like the target maintainers need some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Paolo Carlini changed:
What|Removed |Added
CC|paolo.carlini at oracle dot |
|com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
41 matches
Mail list logo
