--- 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
--- 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_cate
--- 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 #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
--- 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
++
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
--- 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' n
--- 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=21235&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
: 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
ReportedBy: marc dot glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44949
--- 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 for
--- 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=21199&action=view)
extra testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
--- 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_bu
--- 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 #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
>
--
Summary: 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
--- 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=21121&action=view)
Trivial patch
There doesn't seem to be much point using --with-gmp-build (it is most
cl 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
.html
--
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 norma
--- 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 function
--- 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 h
: gcc
Version: 4.5.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
--- 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++
> do
--- 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
--- 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
r
--- 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)
> <&
--- 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 with
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 triplet: i486
--- 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 of
--- 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 #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 #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 #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
sp
--- 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 #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 specializat
alization 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 or
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
ses perl, which I think has been part of the system for a very long
time, because I don't know how to do it with sed. I also don't know if the
files field accepts wildcards)
--
Summary: add casts to libc overloads
Product: gcc
Version: 4.3.0
Sta
--- 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
--- 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=12870&action=view)
patch to call the renaming function in any namespace
--
http://gcc.gnu.org/bugzilla/show_
--- 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 quo
gcc
Version: 4.3.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: i386-pc-solaris2.10
http://gcc
--- 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 to
--- 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 '^&#
t 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=30083
--- 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
--- 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
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: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30062
us: 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: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
--- 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 #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 #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 w
--- 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 w
--- 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 (i
__cos which may 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 g
--- 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 t
--- 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 t
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
--- 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/stdl
63 matches
Mail list logo
