--- Comment #2 from marc dot glisse at normalesup dot org 2010-09-06 07:12
---
(In reply to comment #1)
__is_iterator can be useful anyway,
Of course, they should use the same helper classes but they can coexist,
although the 2 current uses of is_iterator would disappear. I
--- Comment #4 from marc dot glisse at normalesup dot org 2010-09-06 11:01
---
(In reply to comment #3)
Well, I think we are comparing two changes of very different impact and size.
You are right.
I would argue tha,
in general, the way we are living the post-concepts era
--- Comment #6 from marc dot glisse at normalesup dot org 2010-09-06 12:21
---
(In reply to comment #5)
preparing a small prototype, using the hierarchy, attach it here
Just to make sure, does that mean you are writing the prototype, or do you want
me to? (my employer started
--- Comment #9 from marc dot glisse at normalesup dot org 2010-09-06 17:48
---
(In reply to comment #8)
Draft patch, tested x86_64-linux
Nice. Just to confirm, that's indeed what I had in mind, except that I was
going to rename __is_iterator_helper to __has_iterator_category and move
--- Comment #11 from marc dot glisse at normalesup dot org 2010-09-06
20:48 ---
(In reply to comment #10)
The aforementioned variant, again tested x86_64-linux
Wow, cool!
Sorry, I really didn't mean to give you more work...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: x86_64-linux-gnu
http
: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
--- Comment #1 from marc dot glisse at normalesup dot org 2010-07-17 13:48
---
Created an attachment (id=21235)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21235action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
--- Comment #3 from marc dot glisse at normalesup dot org 2010-07-17 18:49
---
In case it may help, let me mention that other test programs for our library
show:
internal compiler error: in refs_may_alias_p_1, at tree-ssa-alias.c:1023
or:
warning: '#'mem_ref' not supported
glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44949
--- Comment #3 from marc dot glisse at normalesup dot org 2010-07-14 14:08
---
Created an attachment (id=21199)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21199action=view)
extra testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
--- Comment #4 from marc dot glisse at normalesup dot org 2010-07-14 14:14
---
The patch (or another one committed recently) seems to have broken the attached
testcase (as you can see from the names, this comes from the same code),
including in C++98 mode. If it is unrelated, sorry
--- Comment #9 from marc dot glisse at normalesup dot org 2010-07-13 14:26
---
Ok, the 4 tests worked fine. I tested with gcc-4.5.0 because the snapshots
complained about the number of arguments to ggc_alloc_cleared_lang_type
(without any patch). I used --without-ppl (otherwise you get
--- Comment #11 from marc dot glisse at normalesup dot org 2010-07-13
15:01 ---
Sorry, no commit rights. I wrote the patch because it was a one-liner, but I
still don't even have a copyright assignment on file.
Can you handle the rest?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #7 from marc dot glisse at normalesup dot org 2010-07-12 20:34
---
(In reply to comment #5)
The patch is okay, but it should be tested with bootstrap, `make install' and
a
smoke test after install with:
- in-tree GMP, in-tree MPFR 2.3
- in-tree GMP, in-tree MPFR 3.0
: Copy constructors implicitly deleted
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot
--- Comment #4 from marc dot glisse at normalesup dot org 2010-07-07 07:44
---
Created an attachment (id=21121)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21121action=view)
Trivial patch
There doesn't seem to be much point using --with-gmp-build (it is mostly useful
to improve
in
gimplify_modify_expr
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host
--
Summary: Call GNU ld with -O1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup
--- Comment #70 from marc dot glisse at normalesup dot org 2010-04-29
10:27 ---
(In reply to comment #68)
(In reply to comment #63)
Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the
namespace std versions of functions, and not also the global scoped
--- Comment #9 from marc dot glisse at normalesup dot org 2010-02-06 17:52
---
(In reply to comment #8)
It seems this can be safely closed as invalid, there is no reason why
std::__cos should be wrong.
Marking this as invalid means that we can never include solaris libc headers
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42820
--- Comment #5 from marc dot glisse at normalesup dot org 2010-01-14 20:35
---
(In reply to comment #4)
It seems to me extremely unlikely that an implementation decides to provide
the
full-const version when called by a c++ compiler and nothing else, because C++
does *not* add
--- Comment #19 from marc dot glisse at normalesup dot org 2009-07-17
15:51 ---
(In reply to comment #18)
I've compiled and linked that code. It does not abort.
Bad point for this theory :-(
The result could still depend on the alignment of the pointer, so you could try
replacing buf
--- Comment #22 from marc dot glisse at normalesup dot org 2009-07-18
04:50 ---
(In reply to comment #20)
buf[n] = 6;
memset (buf+n, 0, i + j);
if (buf[0] != 6)
It looks like you forgot to replace the second buf[0] by buf[n].
--
http://gcc.gnu.org/bugzilla
--- Comment #12 from marc dot glisse at normalesup dot org 2009-07-16
20:34 ---
(In reply to comment #11)
for this memset call, which looks correct to me. The st %g1, [%i0+%l5] line
stores to %i0 a[n-1] and memset is called with memset (a, 0, (n + 0x3fffU)
2); So
--- Comment #18 from marc dot glisse at normalesup dot org 2009-06-05
04:22 ---
(In reply to comment #17)
I just checked, and the sunpro warning is overzealous. It is meant to catch
cases where the programmer writes a declaration with one linkage and later
provides a definition
name is too available
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host
--- Comment #3 from marc dot glisse at normalesup dot org 2009-01-30 20:38
---
Hello,
looking at the two last comments, I think we are speaking of slightly different
things, although they are related. I was asking for some const_cast of the
return value, in case the const version
--- Comment #5 from marc dot glisse at normalesup dot org 2008-11-12 16:19
---
This is not a bug (see previous comments).
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--- Comment #8 from marc dot glisse at normalesup dot org 2008-11-12 16:30
---
The comments already say this bug is a duplicate (of a now fixed bug), I am
just marking it for cleanup. Hope that is the right thing to do...
*** This bug has been marked as a duplicate of 27843
--- Comment #12 from marc dot glisse at normalesup dot org 2008-11-12
16:30 ---
*** Bug 30083 has been marked as a duplicate of this bug. ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--- Comment #2 from marc dot glisse at normalesup dot org 2008-08-10 09:42
---
(In reply to comment #1)
Hmm, the one that says HELLO1 is fully specialization and not a partial one.
Indeed, sorry for the wrong vocabulary. So the title should be something like:
partial specialization
--- Comment #3 from marc dot glisse at normalesup dot org 2008-08-10 10:50
---
Hmm apparently partial specialization of function does not exist. Depending on
the order, the full specialization is considered either as a specialization of
the first declaration or of the HELLO2 one. Now
--- Comment #4 from marc dot glisse at normalesup dot org 2008-08-10 14:20
---
This looks really close to the exemple explained here (near the end):
http://www.gotw.ca/publications/mill17.htm
except that there is no or ... after the name of the function in the
specialization (guess
of function depends on the order
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33518
nested type error has disappeared
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
--- Comment #64 from marc dot glisse at normalesup dot org 2007-03-29
12:29 ---
(In reply to comment #63)
However, I'm working on speculative fixes for newlib and linux, which are
predicated on the correct __cplusplus values. I may get to solaris too, if my
sanity stretches that far
--- Comment #3 from marc dot glisse at normalesup dot org 2007-02-22 16:20
---
Actually, the patch is not sufficient. With the patch, it works if the function
is in the global namespace or the pragma is before the declaration (or both),
but not for a function in the std namespace where
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla
--- Comment #2 from marc dot glisse at normalesup dot org 2007-01-08 14:27
---
Created an attachment (id=12870)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12870action=view)
patch to call the renaming function in any namespace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-12 18:40
---
In gcc/cp/decl.c, I see:
if (global_scope_p (current_binding_level))
asmspec_tree = maybe_apply_renaming_pragma (decl, asmspec_tree);
So if I understand correctly (it is the first time I have a look
--- Comment #5 from marc dot glisse at normalesup dot org 2006-12-08 12:19
---
(In reply to comment #4)
Except you did not read instructions so what is the difference?
Ok say you forget I mentionned solaris /bin/sh. I just believe it would be more
consistant to use single quotes
--- Comment #3 from marc dot glisse at normalesup dot org 2006-12-07 11:04
---
Sure, it works with a posix shell. But it would not hurt to use single quotes
around the constant string passed as an argument to sed, as is done in the rest
of the file, if only for consistancy. It seems
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
glisse at normalesup dot org
GCC host triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-06 18:01
---
Actually, the problem seems to be caused by the '^' character, which is the
equivalent of '|' for this shell. The solution is still the same, have single
quotes (or protect the '^' with '\'). There seems
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30062
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-04 15:54
---
*** This bug has been marked as a duplicate of 2316 ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
--- Comment #15 from marc dot glisse at normalesup dot org 2006-12-04
15:54 ---
*** Bug 30062 has been marked as a duplicate of this bug. ***
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
--- Comment #55 from marc dot glisse at normalesup dot org 2006-05-09
13:55 ---
A few remarks on (really) defining __cplusplus to 199711L on solaris.
One issue I already mentionned in libstdc++/27340 is some conflicts on names
like std::__cos.
An other issue is the fact that solaris
--- Comment #56 from marc dot glisse at normalesup dot org 2006-05-09
14:24 ---
(In reply to comment #30)
Defines __cplusplus to 199711L and overrides it in c++config.h for solaris 8
Out of curiosity, why not deal with __cplusplus the same way as __STDC__ (0 for
standard headers
--- Comment #2 from marc dot glisse at normalesup dot org 2006-04-28 10:33
---
(In reply to comment #1)
Both libc and libstdc++ are considered part of the implementation which means
both are valid to use this name space.
Which means both should take care not to use a name
--- Comment #4 from marc dot glisse at normalesup dot org 2006-04-28 20:43
---
(In reply to comment #3)
Well, I think Andrew has a point: suppose we rename all those functions to
_M_cos and co. Then, later, we discover that a third libc (not Solaris, not
GNU) conflicts with those
--- Comment #6 from marc dot glisse at normalesup dot org 2006-04-28 21:57
---
(In reply to comment #4)
Should all those private classes and functions be declared in some
specific namespace std::glibcxx_private to have a single point of failure?
Oups, I just noticed that was one
conflict with libm
functions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse
--- Comment #19 from marc dot glisse at normalesup dot org 2006-04-19
11:09 ---
(In reply to comment #18)
Probably this PR should be suspended, while waiting for the resolution of DR
456:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
Whether the situation
--- Comment #21 from marc dot glisse at normalesup dot org 2006-04-19
11:38 ---
(In reply to comment #20)
the
very same source code would not be be portable across those targets. I don't
think we would like that. Besides, more generally, I'm not at all sure that
all the users would
--- Comment #17 from marc dot glisse at normalesup dot org 2006-04-18
15:10 ---
(In reply to comment #15)
So there's a problem with the multiple-include-protection in glibc!
Yes, the way it is done in solaris is way more convenient. There, stdlib.h
includes a file iso/stdlib_iso.h
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marc dot glisse at normalesup dot org
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org
63 matches
Mail list logo
