[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 "||is_pointer" from the helper to __is_iterator (and then use __has_iterator_category for __iterator_traits). But it is equivalent. Now to the hardest part: deciding whether to apply it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 the assignment papers in 2009, but the FSF hasn't had time yet) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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, this is more or less > something the user looking inside headers of C++ library implementations is > going to find in *many* more places than those where the Standard explicitly > talks about "does not participate to overload resolution". I can also add that > this very thing makes me a little nervous, but I didn't raise the issue > explicitly anywhere, thus... I completely agree here. After the removal of concepts, the library is in need of more concept-related work in the standard, it shouldn't be up to the implementers. > Anyway, in the other case, we are talking about > changing a fundamental building block of the library. Certainly we would do > that only in C++0x mode, agreed, still we are diverging more from C++03 in an > area where the Standard is *not* diverging at all: as far as I can see, either > we could use a defaulted template parameter with the enable_if on > __is_iterator > for the default; or we could create a small hierarchy, without enable_if. This > is not something I would deliver for C++03 too, after so many years with a > straightforward implementation, definitely not. Ok. It seemed safe enough to me (especially since some other implementations do it), so I thought I should ask. > Do you have in mind a simpler > way to implement the "smart" iterator_traits? No, I was going with the small hierarchy (ie keep the partial specializations for pointers, and have the generic implementation derive from helper::value> where helper is empty by default and has a partial specialization for T,true that contains 5 typedefs). It looked like the safest option. Feel free to close the bug if you think it is a bad idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] merge is_iterator into iterator_traits
--- 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 was personally in favor of having is_iterator in the standard... > Anyway, are you sure that, given the current wording in C++0x, such > iterator_traits is strictly conforming? Howard seems to think so. The first paragraph of [iterator.traits] is good, the second one not so good (but it could be argued that the definition is provided for exposition, that it doesn't have to be copied verbatim to every implementation). It doesn't seem less conforming than what is used for next/prev. But then in some sense it is an extension, as it lets not strictly conforming code work (but doesn't break any conforming code). Which is why I am asking about an opinion on a possible enhancement, not calling it a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
[Bug libstdc++/45549] New: merge is_iterator into iterator_traits
Hello, after bug 40497, an is_iterator machinery was added to restrict the C++0x prototypes of std::next and std::prev. An alternative solution seems to be to use this same machinery in the definition of iterator_traits so that when a class T is not a pointer and does not provide iterator_category (and possibly the 4 other types), iterator_traits is empty (instead of containing 5 broken typedefs). This way iterator_traits can work with sfinae. It allows reverting the prototypes of next and prev to the standard ones. It is also more or less what Howard recommends (see http://groups.google.com/group/comp.lang.c++/browse_thread/thread/54b1537c08997e10/5006b7e443ef0c62 ). Now, this would incidentally let code with user-defined distance functions work as people expect, which has been argued against strongly in the past by Gaby (but then his arguments would likely forbid the resolution of bug 40497). What is your current opinion on this? -- Summary: merge is_iterator into iterator_traits Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ 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
[Bug c++/45418] New: [C++0x] can't initialize array of non-trivial type with brace-init
Hello,
this may just not be implemented yet, but in case it was missed:
struct A1 {
};
struct A2 {
A2(){}
};
template struct B {
T tab[1];
B(T const& t):tab({t}) {} // here
};
int main(){
int i=2;
B b{i};
A1 a1;
B e1{a1};
A2 a2;
A2 c[1]{{a2}};
B e2{a2}; // fails
}
complains about a "bad array initializer", whereas with a trivial type A1 or a
builtin int, it works fine.
--
Summary: [C++0x] can't initialize array of non-trivial type with
brace-init
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=45418
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- 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 by dump_expr#' may be used uninitialized in this function (the tests are 1 million lines each, so I'll only try to reduce them if fixing this one doesn't fix all of them) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug tree-optimization/44972] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- 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
[Bug tree-optimization/44972] New: ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
(the choice of component is random) When I compile this code (I am going to attach it immediatly) with g++ -O1 -c test_api.cpp, I get: test_api.cpp: In function boost::optional construct_normal_offset_lines_isecC2(): test_api.cpp:129:15: internal compiler error: in load_assign_lhs_subreplacements, at tree-sra.c:2475 Without -O1 the compiler is happy. g++-4.4 is happy as well. -- Summary: ICE: in load_assign_lhs_subreplacements, at tree- sra.c:2475 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: 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
gcc-bugs@gcc.gnu.org
This is about both C and C++.
gcc warns about a construction like i&2==0, and this helped us find bugs. But
we noticed, in the same code, occurrences of: i&=2==0. This code suffers from
the same problem, but gcc doesn't warn about it. Would it be a good idea to
extend the warning to this case?
--
Summary: extend Wparentheses from & to &=
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
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=44949
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- 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 adding it to this bug instead of creating a new one. (I am not reopening the bug, you probably know better than me what the appropriate action is) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug c++/44909] [C++0x] Copy constructors implicitly deleted
--- 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
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- 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?id=44455
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- 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 gmp through it). MPC was in-tree for all tests for the same reason. ldd on cc1 never showed mpfr, and only showed libgmp.so.3 when it was out of tree. strings on cc1 also confirmed that the right one was used (the system versions of gmp and mpfr are different from the one I tested in-tree). The versions of mpfr I tested are the latest (3.0.0) and the oldest on which configure only warns and doesn't fail (2.3.1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- 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 > - out-of-tree GMP, in-tree MPFR 2.3 > - out-of-tree GMP, in-tree MPFR 3.0 Is it enough to test with --enable-languages=c? What is a smoke test, gcc -v? Does it matter if the system has gmp and mpfr installed, even when doing the in-tree tests (I hope not, because I won't remove them)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug c++/44909] New: Copy constructors implicitly deleted
The following code compiles fine in C++98 with any version of g++, compiles
fine in C++0X with g++-4.4, but fails in C++0X with g++-4.6 with the error
message:
bug.cc: In function void ouin(const Ray&):
bug.cc:35:9: error: use of deleted function Ray::Ray(const Ray&)
bug.cc:28:8: error: Ray::Ray(const Ray&) is implicitly deleted because the
default definition would be ill-formed:
I hope I didn't remove anything essential while reducing the example (started
with 500k lines...).
struct Coord
{
Coord();
Coord(const Coord&);
};
template
struct array
{
array();
_Tp _M_instance[1];
};
struct Ray;
struct Vector
{
array base;
Vector();
Vector(const Ray &) ;
};
struct Point
{
Vector base;
};
struct Ray
{
array base;
};
void ouin (Ray const& r1)
{
Ray r2=r1;
}
--
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 normalesup dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44909
[Bug bootstrap/44455] GCC fails to build if MPFR 3.0.0 (Release Candidate) is used
--- 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 mostly useful to improve performance a bit, but gcc explicitly tells GMP to be slow), so let's just use the same options as MPC. It works with mpfr 2.3.1 and 3.0.0. Any particular trap I am missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
[Bug c++/44808] New: ICE: tree check: expected var_decl, have result_decl in gimplify_modify_expr
The following code produces the error:
$ c++-c triangles_test.cpp -O9
triangles_test.cpp: In member function virtual Halfedge_handle
Ovl_visitor::insert_at_vertices():
triangles_test.cpp:12:24: internal compiler error: tree check: expected
var_decl, have result_decl in gimplify_modify_expr, at gimplify.c:4571
Please submit a full bug report,
I checked with a snapshot from the 3rd of July, so this shouldn't be the same
as bug 44706 (the closest thing I could find in bugzilla).
struct Halfedge_handle
{
void *a,*b;
int c;
};
struct Ovl_visitor
{
virtual Halfedge_handle insert_at_vertices ()
{
Halfedge_handle res;
Halfedge_handle he = res;
return res;
}
};
Ovl_visitor visitor ;
--
Summary: ICE: tree check: expected var_decl, have result_decl 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 triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44808
[Bug other/44080] New: Call GNU ld with -O1
When gcc is called with -O3, it could add -O1 to the options it passes to the linker, when it knows that it is GNU ld. For now this is only useful with -shared, but I don't see any reason not to also pass it without -shared. Reference: http://gcc.gnu.org/ml/gcc/2010-05/msg00193.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 normalesup dot org GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44080
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- 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 ones. > > This > > is a problem. The way I read ISO C++, cstdlib should only have std:: scoped > > bits. The C++ compatibility include stdlib.h should then re-scope to :: > > (global). Solaris tries to smash these two concepts together. Boo. > > This is no longer a problem: > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456 It was not so hard to work around in any case (see rest of the discussion). > Can we consider defining __cplusplus to the correct value in C++0x mode, even > if we leave it at 1 for 98/03 mode? The reason for not defining it to the correct value is not that it would yield an unclean situation (which is already the case). There are several issues: - breaks the ABI because tm and a couple other structs move from the global namespace to namespace std. This can be worked around by forcing the mangling of std::tm to be that of ::tm, but it is ugly. - needs to remove the overloads on linkage (like bsearch, qsort) in the solaris headers because g++ is broken there. - needs to adapt redefine_extname to remove its limitation to the global namespace. - needs to conditionally remove the overloads from libstdc++ that are already in the solaris headers (like the math functions) and deal with the fact that afterwards, including math.h instead of cmath will mean that cos(int) fails, at least until Oracle writes C++0X headers (might take a few years). Or fixinclude out almost anything that __cplusplus enables... I had a proof of concept in some PR some time ago, but the fixinclude part was a bit heavy... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- 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 with __cplusplus >= 199711 (which declare std::__cos as a function) without fixincluding them beyond recognition. Even without this problem on solaris, using in libstdc++ names as generic as std::__cos for a functionality limited to valarray doesn't seem like an ideal naming convention. But then, the choice is yours, I am not ticking the "reopen" box. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug c++/42820] New: ICE in tree-check, accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9868
The following code causes the error:
internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in
tsubst, at cp/pt.c:9868
(I am using the debian gcc-snapshot 20100117)
It compiles fine with g++-4.4. I have seen similar bug reports in bugzilla, but
they are all marked either as fixed or as not-a-regression, so I am adding this
here, sorry if this is a duplicate.
template struct vector{};
struct Traits{struct Primitive{struct Id{};};};
template struct Tree_vs_naive
{
typedef typename Tree::Primitive Primitive;
void f() const
{
typedef vector Id_vector;
}
};
template void test_hint_strategies()
{
vector v;
}
int main(void)
{
test_hint_strategies();
}
--
Summary: ICE in tree-check, accessed elt 2 of tree_vec with 1
elts in tsubst, at cp/pt.c:9868
Product: 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=42820
[Bug libstdc++/30928] add casts to libc overloads
--- 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 an overload, *replaces both*. Thus it seems definitely > premature. As mentionned in the original bug report, on solaris, it is quite easy to get this behavior. However, I agree that it is not the right way to do it, and the apparition of macros like __CORRECT_ISO_CPP_WCHAR_H_PROTO seems like a much better way to handle things. In some sense the main interest of this bug is to show one way to get c* headers that don't pollute the global namespace on solaris. But "resolved invalid" is right. #33935 (shouldn't that one be unmerged?) is a better place to track the incomplete resolution of DR456 wrt strchr. > About the unrelated point at the beginning, the const_cast in wcschr, that is > *essential* otherwise how can the forwarding to the *other* overload happen? Er, yes, that's obvious. I have no idea what I was thinking when I wrote that (3 years ago). Maybe just that it is a cast in the direction non-const->const (not that it matters). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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[0] by buf[4] and calling memset(buf+4,...) (try several small values instead of 4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- 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, if this doesn't work (and you see the same), you hit a bug in > Solaris memset implementation, which doesn't handle properly length with > garbage in upper 32-bits, guess it could use brz,pn %o2, do_nothing or > something similar, which is fine for 64-bit code, but certainly not for 32-bit > code. The sun4v implementation in opensolaris looks fine (but may not have been backported to solaris 10). The following one on the other hand seems to use the same brnz for 32 and 64 bit code: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/sparc_hwcap1/common/gen/memset.s#88 It would be good to know which implementation is used... -- marc dot glisse at normalesup dot org changed: What|Removed |Added CC| |marc dot glisse at | |normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c++/2316] g++ fails to overload on language linkage
--- 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 some other linkage, which ends up as an overload and not a definition of the first function (this is a valid use, but may not be what the programmer intended). It is hard to warn about such wrong cases without also catching perfectly normal uses... http://forums.sun.com/thread.jspa?threadID=5390323 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/39924] New: injected class name is too available
When I declare a class A, gcc injects the class name A in this class a little
too strongly.
C++0X explicitly lists this example as invalid (and it is also invalid in
C++03, just not explicitly given as an example):
struct A {};
void f(){ A::A a; }
This is only a failure to emit an error/warning, but I found several libraries
developed with g++ that use the following non-portable construct:
template struct A {
A(double d){}
};
template struct B : A {
B(double d):A::A(d){}
};
A diagnostic would be really helpful. Sun Studio for instance rejects the code
as soon as you try to instantiate it.
The most relevant part of the standard is 3.4.3 (and 3.4.3.1). These sections
were expanded quite a bit from C++03 to C++0X, and have become quite confusing,
but this last example was invalid in C++03 and I hope it still is in C++0X.
--
Summary: injected class 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 triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39924
[Bug libstdc++/30928] add casts to libc overloads
--- 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 wcschr (or other) we are forwarding to (from the non-const overload) has the official C++ prototype. In any case, it can't hurt and makes the code a bit cleaner with respect to the intended behaviour. I was then planning to ask glibc to insert a macro in the declaration: extern MYMACRO void* memchr(const void*,int,size_t); where MYMACRO could be defined as "const" by a C++ implementation, but apparently an even better fix was adopted, cool :-) The fix mentionned by Jakub is the right way to do things for a well-behaved libc (solaris with __cplusplus>=199711L, or apparently a very recent glibc). Hopefully the same thing will be done for the other headers (cstdlib or cmath for instance), although the interaction with C99/C++0X may require 2 macros instead of just one. Bug 33935 asks that g++ ship a string.h that is equivalent to cstring when __CORRECT_ISO_CPP_STRING_H_PROTO is not defined. Obviously it is not that easy because standard headers including each other may end up including the wrappers, but now that glibc and its multiply included headers are out of the way it may be easier (or not). Too bad there is no easy way to distinguish libc headers from other headers. Anyway, I want to thank you both because you did not consider these issues negligible. I'd love to help, I know how to fix most of the bugs I have filed related to solaris headers, but I still haven't managed to get the legal paperwork done (keep changing employers, and the FSF disclaimer is not a paper they have ever signed before). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30928
[Bug other/27843] gcc-4.2-20060527 make install fails on alphaev68-dec-osf5.1b
--- 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 CC||marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27843
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- 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 *** -- marc dot glisse at normalesup dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug c++/37066] partial specialization of function depends on the order
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37066
[Bug c++/37066] partial specialization of function depends on the order
--- 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 it is implicit). So it looks like this is not a g++ bug. Sorry for the noise. If you agree with this, please close the bug, I'll see about reporting the bug to the other compiler and getting gmpxx fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37066
[Bug c++/37066] partial specialization of function depends on the order
--- 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 the question is whether the existence of a full specialization of the first declaration should give it priority over an overload (that is more specific than the declaration but less than the specialization). I'll need to look at the standard for the answer (if someone knows it...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37066
[Bug c++/37066] partial specialization of function depends on the order
--- 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 overrides earlier full specialization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37066
[Bug c++/37066] New: partial specialization of function depends on the order
In the following code, adapted from gmpxx, the output is HELLO2. If however I
change the order of the two partial specializations, the output becomes HELLO1.
At least one other compiler I tried outputs HELLO1 in both cases. I know that I
can remove the "template<>" and overload the function instead of partially
specializing it, but I would like to understand why the current code is
failing.
#include
struct mpz_t{};
template
class __gmp_expr{};
template
void __gmp_set_expr(const __gmp_expr &);
typedef __gmp_expr mpz_class;
template <>
void __gmp_set_expr(const __gmp_expr &expr)
{
std::cerr << "HELLO1\n";
}
template
void __gmp_set_expr(const __gmp_expr &expr)
{
std::cerr << "HELLO2\n";
}
int main(){
mpz_class a;
mpz_t t;
__gmp_set_expr(a);
}
--
Summary: partial specialization 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
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37066
[Bug c++/33518] New: unused code changes the result of name lookup
Hello,
I know this may look like issue #15910, but please read still. g++ refuses to
compile the following code because it wants to use std::distance. But if I
remove the code about "class Wx", which is not used anywhere, g++ now uses
::distance without complaining. Whichever the right answer is, g++ is not being
consistent here. Note that comeau and sunCC both use ::distance in both cases.
#include
namespace boost
{
namespace detail {
struct empty_base {};
using std::distance;
}
template
struct ordered_field_operators1 {};
}
namespace CGAL {
template
class Quotient
: boost::ordered_field_operators1< Quotient >
{
};
class MP_Float{};
namespace INTERN_MP_FLOAT {
double to_double(const MP_Float&);
double to_double(const Quotient&);
}
template class Wx{};
template <> class Wx< MP_Float >
{
public:
class To_double
{
public:
double operator()( const MP_Float& x ) const {
return INTERN_MP_FLOAT::to_double( x );
}
};
};
}
typedef CGAL::Quotient NT;
namespace C{
template struct TutorialR{};
template struct Point{};
}
typedef C::Point > Point;
double distance(const Point & p, const Point & q)
{
return 3;
}
int main()
{
Point p1;
Point p2;
distance(p1,p2);
return 0;
}
--
Summary: unused code changes the result of name lookup
Product: gcc
Version: 4.2.2
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=33518
[Bug c++/32997] New: duplicate nested type error has disappeared
Code like:
struct A {
struct B {};
typedef int B;
};
does not cause an error or even a warning (even if the type A::B is used
later), it seems like the typedef is silently ignored. It used to be detected
by g++-2.95 and g++-3.3 but not since 3.4.
--
Summary: duplicate 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
GCC host triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32997
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- 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, or I may fail entirely, everywhere. Weird, when solaris is the easiest one. > 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 ones. #include (this is how sun studio compiler does it) If you also want the C99 functions, then you have to wait for the next c++ standard to actually exist before solaris changes its headers accordingly. > My RFC message about C++0x headers had the details on my implementation plan, > I think. Sorry for the dumb question, but where is it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/30928] New: add casts to libc overloads
Headers like cwchar add overloads to libc functions. Here I am interested in
the functions for which the standard C version takes a const pointer and
returns a non-const pointer and in C++ this version is replaced by one with
const everywhere and one with no const anywhere. For this, in c_std mode, g++
takes the libc version (instead of the full-const version) and adds an overload
which looks like:
inline wchar_t*
wcschr(wchar_t* __p, wchar_t __c)
{ return wcschr(const_cast(__p), __c); }
The const_cast does not look very useful, but that is not the issue (it makes
it easier to understand, which is good). I was wondering whether it would be
acceptable to add a const_cast to the returned value? For the current
uses, it would do nothing. But now if a libc decided to provide the full-const
version when called by a c++ compiler, this would make it work.
Is there any real case where it would help? Well if bugs 27340 (trivial) and
30112 get fixed, with the following fixinclude rule, it would be the last thing
preventing from being able to set __cplusplus to either 1 or 199711L with no
testsuite regression (except for breaking the ABI) on solaris (I only checked
with 8). Of course this is only one way to achieve this (not the best one, but
it requires very little patching).
I will understand if you say no, I am just hoping for a "why not? It doesn't
hurt." (remember that in this bug I am only talking about adding some
const_casts, the __cplusplus value is an other issue)
The fixinclude rule, for info (I am not proposing it here, just mentionning it
for completeness)
/*
* Remove extern "C++" parts of solaris libc
*/
fix = {
hackname = solaris_no_extern_cpp;
mach = '*-*-solaris*';
files = "iso/ctype_iso.h";
files = "iso/limits_iso.h";
files = "iso/locale_iso.h";
files = "iso/math_iso.h";
files = "iso/setjmp_iso.h";
files = "iso/signal_iso.h";
files = "iso/stdarg_iso.h";
files = "iso/stddef_iso.h";
files = "iso/stdio_iso.h";
files = "iso/stdlib_iso.h";
files = "iso/string_iso.h";
files = "iso/time_iso.h";
files = "iso/wchar_iso.h";
files = "iso/wctype_iso.h";
select= 'extern[ \t]*"C\+\+"';
shell = "perl -e 'undef $/;$_=<>;s/extern[ \t]*\"C\\\+\\\+\"[
\t]*{([^{}]*{[^{}]*})*[^{}]*}//gs;print'";
test_text = 'extern "C++" {void f();}';
};
(this uses 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
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/show_bug.cgi?id=30928
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
--- 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 the pragma is after the declaration, as is the case for wcsftime in solaris iso/wchar_iso.h. The little I understand: it seems that in c-pragma.c, for some reason, identifier_global_value(oldname) returns 0 in this case, so the renaming is not done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
--- 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_bug.cgi?id=30112
[Bug c++/30112] pragma redefine_extname fails when namespaces are involved
--- 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 at the gcc internals), there is an explicit test that means the renaming function is only called for the global namespace. Simply removing the test (and so always executing the next line) seems to solve my problem, but I don't know if it breaks other things or slows everything down. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30112
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- 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 instead of double quotes everywhere a constant string is passed to sed (now it is done everywhere except in 3 places) in this file. The fact that it makes solaris /bin/sh work is a mere coincidence. It is just code cleanup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug c++/30112] New: pragma redefine_extname fails when namespaces are involved
If I compile the following piece of code with g++ -c, and examine the resulting
object file, it references symbols "myfoo" and "bar", so the second pragma
failed because of the namespace.
extern "C" {
#pragma redefine_extname foo myfoo
void foo(double);
namespace A {
#pragma redefine_extname bar mybar
void bar(double);
}
}
void f(double x){foo(x);A::bar(x);}
A relevant example is wcsftime when __cplusplus is 199711L.
--
Summary: pragma redefine_extname fails when namespaces are
involved
Product: 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.gnu.org/bugzilla/show_bug.cgi?id=30112
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- 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 be the only thing that fails now with this /bin/sh, and it used to work with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- 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 to be two other occurences of an unprotected '^' line 3246 and 3856 in the same file, don't know if it may cause problems as well, but it would be safer to modify those too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug other/30083] New: double quotes in Makefile confuse solaris /bin/sh
Hello,
gmake install currently fails for me on mainline on solaris 10 if I use the
default /bin/sh shell. The problem is with this line of gcc/Makefile.in:
SYSTEM_HEADER_DIR = `echo @SYSTEM_HEADER_DIR@ | sed -e :a -e "s,[^/]*/\.\.\/,,"
-e ta`
this variable is used inside double quotes, and solaris /bin/sh parses "`""`"
as two strings containing a backquote (or something else, but not what you
would expect anyway). I believe using single quotes in this line would help (I
did not redo the whole configure+bootstrap, but I checked that solaris sh
understood the modified line).
--
Summary: double quotes in Makefile confuse solaris /bin/sh
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
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=30083
[Bug c++/2316] g++ fails to overload on language linkage
--- 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 CC||marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
[Bug c++/30062] g++ does not distinguish functions with C and C++ linkage
--- 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 |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30062
[Bug c++/30062] New: g++ does not distinguish functions with C and C++ linkage
Hello,
I noticed that if I give g++ the prototypes for bsearch as listed in the 2003
standard, it errors out saying that the 2 declarations conflict:
extern "C" void *bsearch(const void *key, const void *base, size_t nmemb,
size_t size, int (*compar)(const void *, const void *));
extern "C++" void *bsearch(const void *key, const void *base, size_t nmemb,
size_t size, int (*compar)(const void *, const void *));
The same is true for qsort. I believe the compiler is supposed to distinguish
between the 2 versions according to the linkage of compar.
Even if you don't want to distinguish functions according to linkage, g++
should be able to accept a declaration that is written in the standard.
--
Summary: g++ does not distinguish functions with C and C++
linkage
Product: gcc
Version: 4.1.2
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
[Bug libstdc++/27579] New: no warning for the non-standard integral overloads of math functions
As a solution to "bug" 3181, integral overloads of many math functions (like
sqrt) were introduced. Would it be possible to add a warning when such
overloads are instantiated? I don't know how to do that with g++ (if it is not
possible, then it would be a nice feature to add). It would help people write
more portable code.
See also:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#213
--
Summary: no warning for the non-standard integral overloads of
math functions
Product: gcc
Version: 4.0.3
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: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27579
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- 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 and 1 elsewhere IIRC) instead, or even defining it to 1 directly for this platform? If I include stdlib.h (not cstdlib), I won't include c++config.h first, and it should cause trouble with this approach. (although I don't like the approach, which considers as broken the only platform that has correct headers, but that is a different issue) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- 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 (>=9) headers have (when __cplusplus is
at least 199711L) already the correct c++ declarations for functions like
wcschr or wcspbrk, so we would need a macro to disable all the extra
definitions like:
inline wchar_t*
wcschr(wchar_t* __p, wchar_t __c)
{ return wcschr(const_cast(__p), __c); }
that are provided in the c* headers. This means all the overloaded math
functions as well (except the non-standard integer versions, for which I always
wished g++ would at least emit a warning).
The headers (like stddef.h) provided by gcc and that take precedence over the
solaris headers need to be patched to look more like the headers they are
replacing.
An other problem is that it breaks the ABI (a c++ function that takes a struct
tm won't be mangled the same as one that takes a std::tm).
It will break bad code that declares struct tm in the global namespace instead
of including the standard headers (gtk+-1.2).
If this were done, it would become quite easy to chose, each time we call g++,
whether we want to use the gcc headers or headers that keep the global
namespace clean, which is good :-)
--
marc dot glisse at normalesup dot org changed:
What|Removed |Added
CC| |marc dot glisse at
| |normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- 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 of the roles of __gnu_cxx (although I don't
understand why this namespace is not a subnamespace of std:: as tr1 (or at
least contains a using namespace std;), which would at the same time fix things
like getenv not being prefixed by std:: in ext/mt_allocator.h). So in this case
it would seem reasonable to move the classes to that namespace.
(In reply to comment #5)
> Again, I
> encourage you to post on the libstdc++ list a careful analysis of the issue,
> complete of mini-patch (fixing only one header, for example). At this point
> what you mean by "playing around" is not at all clear.
I had posted this bug report because I found it quite independant from the
rest. It is easy to see on solaris that __cplusplus>=199711L declares a
function __cos in namespace std, and I think I read somewhere that changing tha
value of __cplusplus was being considered.
I will eventually post something on the libstdc++ mailing list, but I am slowed
down by several things:
- I have only limited access to solaris 8 and 9, and several things would
require solaris 10 to work properly (at least it would be less work)
- the _GLIBCPP_USE_NAMESPACES in glibc has dozens of bugs (besides design
issues), to the point that doing: namespace std { #include } actually
works better than defining the macro right now...
- tracking why and where all the macros like __USE_GNU are defined is a
nightmare
- it may not be possible to work on each header independantly, because headers
include other headers
But I haven't quite given up hope yet. Depends how much time I will get to work
on this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- 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 names too... The point is that there is no *robust* > concept of less-conflict prone name: I thought about a name that contains gcc or glibcxx or something like that, but now I understand Andrew's point, thank you. > if such conflicts happen then something is > wrong in the design, something profound is wrong, somewhere. So something is wrong in the design. If the wrong thing is in that the libc and compiler are separate entities, there is little we can do about it. So what can be done? Should all those private classes and functions be declared in some specific namespace std::glibcxx_private to have a single point of failure? The current names (__cos and similar) do conflict, and unless a better solution is proposed, renaming (and re-renaming if there still are problems) seems like the easy way to fix it. > We already > discussed this issue in another context (header guards names), and, not having > looked very closely into this specific issue, I'm pretty convinced. Convinced of what? (sorry about my slow understanding of these conversations, I am quite new to gcc, and I guess the style needs some time to sink in) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/27340] valarray uses __cos which may conflict with libm functions
--- 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 (in this name space) already used by the other one. I actually don't understand what your point is. -- marc dot glisse at normalesup dot org changed: What|Removed |Added CC| |marc dot glisse at | |normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/27340] New: valarray uses __cos which may conflict with libm functions
valarray defines structs with names like __cos, __sin, etc. It is often the
case (glibc, solaris) that the libc declares functions with those same names.
In the current situation we are lucky because the structs are in namespace std
and the functions in the global namespace. But playing around with namespace
std soon brings something like this:
namespace std {
double __cos(double);
struct __cos
{
template
_Tp operator()(const _Tp& __t) const;
};
}
template struct A {};
int main(){
A a;
}
which results in:
error: type/value mismatch at argument 1 in template parameter list for
'template struct A'
error: expected a type, got 'std::__cos'
error: invalid type in declaration before ';' token
It would be preferable to use a less conflict-prone name.
--
Summary: valarray uses __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 glisse at normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27340
[Bug libstdc++/6257] C-library symbols enter global namespace
--- 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 actually *like* the new behavior. I meant proposing it as a choice, with a flag like -fclean-global-namespace (better than a macro since it probably means changing the include path and redefining a few macros), which needs not be the default. The current implementation would have to be kept for some platforms anyway, so it could be kept for all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug libstdc++/6257] C-library symbols enter global namespace
--- 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 remains the same or the g++ implementation becomes legal does not change the fact that it would be nice (and not at all out of reach) to use the features of glibc and solaris (any others?) that allow a cleaner global namespace when including a header, it would just lower the priority of this from bug to wishitem. And for platforms where it is not possible, then the current implementation will have to remain, whatever the committee decides. But if you want to suspend it, it is your call... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
[Bug libstdc++/27199] New: ptrdiff_t and size_t outside of namespace std
In ext/new_allocator.h and a few other files that declare things in namespace __gnu_cxx, size_t and ptrdiff_t are missing a std::. I know it does not break anything for a standard use, but such corrections will be necessary in order to clean the global namespace for systems like glibc or solaris where it is possible. Besides, there are files like bitmap_allocator.h where half the occurences of size_t have std:: in front and not the others. Thanks to people who work on g++, great tool. -- Summary: ptrdiff_t and size_t outside of namespace std Product: gcc 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/bugzilla/show_bug.cgi?id=27199
[Bug libstdc++/6257] C-library symbols enter global namespace
--- 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 that has all the meat, and then stdlib.h does all the using std::foo; stuff, so cstdlib can just include iso/stdlib_iso.h directly. On solaris, I get quite satisfactory results with: g++ -I/opt/SUNWspro/prod/include/CC/std -D__cplusplus=199711L -U__EXTENSIONS__ -D__STDC__=0 (the include directory contains the cstd headers from sunpro, but they are just one or 2 #include lines) > But we can't do this in any manner because they have multiple-include > protection which can't tell the difference. gcc could come with its own stdlib.h. Both this stdlib.h and cstdlib would include /usr/include/stdlib.h (always with _GLIBCPP_USE_NAMESPACES) and the gcc provided stdlib.h would additionally contain the appropriate using std::foo; lines. The 2 problems I see with this approach are: 1) it means having 2 files with the same name in the search path, and inclusion of the glibc file has to be done with an explicit path of /usr/include (or some other compile time constant) 2) This will do what we want for standard functions, but what about extensions that are declared in stdlib.h in glibc (protected by __USE_ISOC99 or __USE_GNU for example), what happens to them? It might work well, I have not tested. > At the beginning of stdio.h, instead of: > #ifndef _STDIO_H > #define _STDIO_H > we would have: > #if ( ( defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES ) \ > && ! defined _STDIO_H_WITH_NAMESPACES ) \ >|| ( (! defined __cplusplus || ! defined _GLIBCPP_USE_NAMESPACES )\ > && ! defined _STDIO_H ) > #if defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES > # define _STDIO_H_WITH_NAMESPACES > #else > # define _STDIO_H > #endif This way you get 2 declarations instead of one and a using directive, I am not sure it won't cause problems (but I don't know). -- marc dot glisse at normalesup dot org changed: What|Removed |Added ------------ CC| |marc dot glisse at ||normalesup dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
