[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #3 from pcarlini at suse dot de 2008-04-25 10:35 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01064.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #8 from pcarlini at suse dot de 2008-04-24 17:05 --- Fixed for 4.4.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #3 from pcarlini at suse dot de 2008-04-21 08:24 --- Many thanks Roger for your further help on nth_element, excellent news. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug libstdc++/35968] nth_element fails to meet its complexity requirements
--- Comment #1 from pcarlini at suse dot de 2008-04-20 17:30 --- Roger, can you have a look? Thanks in advance. -- pcarlini at suse dot de changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #6 from pcarlini at suse dot de 2008-04-21 00:46 --- According to the resolution of DR 250, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250 indeed splicing doesn't really invalidate iterators. Therefore, the debug-mode merge should be consistent with that behavior. The fix seems easy... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-21 00:46:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35935] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 --- *** This bug has been marked as a duplicate of 35934 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35935
[Bug libstdc++/35934] abi breakage in search (4.0.0 - 4.2.1)
--- Comment #1 from pcarlini at suse dot de 2008-04-14 18:02 --- *** Bug 35935 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35934
[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file
--- Comment #1 from pcarlini at suse dot de 2008-04-13 09:39 --- CC-ing Benjamin... -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35915
[Bug libstdc++/35922] std::unordered_map missing in debug mode
--- Comment #3 from pcarlini at suse dot de 2008-04-13 15:17 --- Benjamin, can you have a look? Seems just an extension of libstdc++/30085: it seems we can certainly have debug mode for std::unordered_* too (besides std::tr1::unordered_*) -- pcarlini at suse dot de changed: What|Removed |Added CC||bkoz at redhat dot com Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-13 15:17:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35922
[Bug c++/28239] [4.2 regression] ICE in gimple_add_tmp_var, at gimplify.c:720
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28239
[Bug libstdc++/35914] missing int std::abs(int)
--- Comment #1 from pcarlini at suse dot de 2008-04-12 19:29 --- You want to include cstdlib: cmath only provides overloads for floating point types (see 26.5 for details). -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35914
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #2 from pcarlini at suse dot de 2008-04-10 17:05 --- Seems doable... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug c++/35884] defining __need_size_t before including cstddef causes error
--- Comment #1 from pcarlini at suse dot de 2008-04-09 11:22 --- Names starting with __ and _ (see 17.4.3.1 for details) are reserved. That's exactly the reason why the library uses everywhere and only such names (why, otherwise?) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35884
[Bug libstdc++/35763] std::cout loses whole blocks of output if interrupted by signal without SA_RESTART
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:24 --- This is tightly coupled to libstdc++/35353: in the current design, when sync_with_stdio is false (by default), the stream is non-converting and synced with C stdio, simply forwards to stdio functions. Unfortunately, the fix is not forthcoming, there are very serious performance implications, and binary compatibility issues (which probably can be solve only by breaking the ABI). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
[Bug libstdc++/35622] Cannot declare vector of unordered_maps
--- Comment #3 from pcarlini at suse dot de 2008-03-30 09:27 --- Really, this is a WORKSFORME, code in Comment #2 is fine everywhere. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35622
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
--- Comment #6 from pcarlini at suse dot de 2008-03-29 22:43 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35725] ambiguous std::fill with character array
--- Comment #2 from pcarlini at suse dot de 2008-03-28 00:37 --- Argh. Easy to fix, will do ASAP. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-28 00:37:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
--- Comment #3 from pcarlini at suse dot de 2008-03-28 00:47 --- Created an attachment (id=15392) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15392action=view) Draft patch I'm finishing testing something along these lines... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35725] [4.3/4.4 Regression] ambiguous std::fill with character array
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35725
[Bug libstdc++/35656] std::stable_sort unusable with _GLIBCXX_DEBUG
--- Comment #2 from pcarlini at suse dot de 2008-03-21 21:15 --- *** This bug has been marked as a duplicate of 35541 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35656
[Bug libstdc++/35541] [4.3 Regression] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #8 from pcarlini at suse dot de 2008-03-21 21:15 --- *** Bug 35656 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||Andrew_Pollard at amat dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug c++/35637] tr1::function fails with const member function pointer
--- Comment #1 from pcarlini at suse dot de 2008-03-20 15:42 --- Interestingly, current mainline is not affected. Thus, either the mainline compiler regressed (that is the library is actually buggy and the mainline compiler should reject the code, like the 4_3-branch compiler does), or something should be backported from mainline to the 4_3-branch compiler. In either case, it seems to me the C++ compiler should be checked first, both in mainline and 4_3-branch. -- pcarlini at suse dot de changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug c++/35637] tr1::function fails with const member function pointer
--- Comment #2 from pcarlini at suse dot de 2008-03-20 15:49 --- In mainline, -pedantic-errors is needed. That seems weird to me, maybe Maunel can help here. On the other hand, a problem with library code seems also likely. -- pcarlini at suse dot de changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] tr1::function fails with const member function pointer
--- Comment #3 from pcarlini at suse dot de 2008-03-20 19:57 --- I'm fixing the library bits. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Component|c++ |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-20 19:57:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #7 from pcarlini at suse dot de 2008-03-20 23:49 --- (In reply to comment #6) Again, from GCC 4.4 on, -pedantic/-pedantic-errors should work the same as for the C front-end, that is, -pedantic enables warnings, -pedantic-errors converts those warnings into errors. What is the problem then? The problem I was noticing was simply that the behavior of 4_3 was not the same as the behavior of 4_4: the former, as noticed by submitter, errors with -pedantic, the latter errors with -pedantic-errors. You are explaining that this is really the behavior we want, Ok with me! -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #10 from pcarlini at suse dot de 2008-03-21 00:01 --- Thanks. Note, I cannot really use -Wsystem-headers in library testcases, because in that way other, completely, unrelated warnings are always triggered. I think we should not do much more at this stage for 4_3-branch (in particular in the library side), for 4_4 certainly there are many options. If the present issue gets fixed we can for instance revert completely the library change, testcase included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()
--- Comment #1 from pcarlini at suse dot de 2008-03-14 22:54 --- Hi Johannes, can you have a look? Many thanks. -- pcarlini at suse dot de changed: What|Removed |Added CC||singler at gcc dot gnu dot ||org Summary|parallel std::sort and |[parallel mode] parallel |bind() |std::sort and bind() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35588
[Bug libstdc++/35566] multiset constructor uses insert_unique instead of insert_equal!
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-13 16:59:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35566
[Bug libstdc++/35541] [4.3 Regression] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #7 from pcarlini at suse dot de 2008-03-13 17:38 --- Fixed for 4.3.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Legal C++ program can't be |[4.3 Regression] Legal C++ |compiled with - |program can't be compiled |D_GLIBCXX_DEBUG |with -D_GLIBCXX_DEBUG Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug libstdc++/35566] [4.3 Regression] multiset constructor uses insert_unique instead of insert_equal!
--- Comment #5 from pcarlini at suse dot de 2008-03-13 17:49 --- Fixed for 4.3.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35566
[Bug libstdc++/35557] including iostream pulls symbols from unistd.h in global namespace
--- Comment #1 from pcarlini at suse dot de 2008-03-12 19:47 --- Really, we know about this type of annoying situations, very hard to deal with within the requirements of C++03, because implementors often do not have control on the contents of the underlying C library headers. The standard itself is being improved for C++0x. *** This bug has been marked as a duplicate of 11196 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35557
[Bug libstdc++/11196] parse error before numeric constant M_PI is defined in C++
--- Comment #8 from pcarlini at suse dot de 2008-03-12 19:47 --- *** Bug 35557 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||arnaud dot boulan at ||esterel-technologies dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
[Bug libstdc++/35541] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #4 from pcarlini at suse dot de 2008-03-11 21:52 --- Yes, it's a trivial issue, sorry about that. I think the third parameter of the *_sorted_set_aux functions can be simply removed. Anyway, I'll fix it ASAP. -- pcarlini at suse dot de changed: What|Removed |Added CC|pcarlini at suse dot de | AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-11 21:52:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug c++/35525] function in template can depend on superclass
--- Comment #2 from pcarlini at suse dot de 2008-03-10 18:28 --- *** Bug 35527 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35525
[Bug c++/35527] function in template can depend on superclass
--- Comment #1 from pcarlini at suse dot de 2008-03-10 18:28 --- *** This bug has been marked as a duplicate of 35525 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35527
[Bug libstdc++/33628] unary_function and pointer_to_unary_function issues with void template arguments
--- Comment #3 from pcarlini at suse dot de 2008-03-09 11:21 --- I agree ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33628
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #2 from pcarlini at suse dot de 2008-03-06 16:27 --- Frankly, I'm not 100% sure we want an error here: I mean, we have a Requires violation in the case at issue, which, in general, in my reading of the standard, certainly doesn't mean the code must not compile, means something like user, anything can happen, you are on your own. Certainly it would be easy to add in the TR1 version, an __enable_if, but I would be more willing to do that change to the TR1 version in case eventually the C++0x version will get a concept enforcing equality of the sizes. Doug, is that in the plan? -- pcarlini at suse dot de changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com, pcarlini at suse dot de Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #4 from pcarlini at suse dot de 2008-03-06 16:53 --- (In reply to comment #3) To me, if geti(t) fails to compile under the assumption of ill formed, then by the definitions of 6.1.3.5, geti(t) == geti(u) should also fail to compile. Although it is not explicitly stated in N1836=05-0096. My exact point was that all the wording about get etc belongs to a **Requires** clause, which is a *precondition*. In other terms, nothing says that the implementation actually attempts those operations. On an aside, it would certainly be useless to have something compile and run with no side effects (as it does) when the construct is clearly erroneous. Sure. But note that this problem also exists in O(1) other places in the Standard, in particular with templates (when there are substantive hopes to finally catch a bit more at compile-time in C++0x) but also without templates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:00 --- By the way, in the meanwhile I checked N2322 and C++0x will simply enforce EqualityComparableTTypes, UTypes... We are presently trying to figure out whether in the meanwhile we want to explicitly enforce sizeof...(TTypes) == sizeof...(UTypes) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #7 from pcarlini at suse dot de 2008-03-06 17:18 --- Cool, if everything can be dealt with right now by simply fixing that, then let's do it! Really, in these times, I dislike the idea of robustify templates here and there (without a global neat strategy) with old-times __enable_ifs... -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-06 17:18:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug c++/35338] [4.3 regression] Broken diagnostics for fixed-point types
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:52 --- Fixed for 4.3.1 too. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
[Bug c++/35333] [4.1/4.2 regression] Broken diagnostic for complex builtin
--- Comment #5 from pcarlini at suse dot de 2008-03-06 17:53 --- Fixed for 4.3.1 too. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Broken |Broken diagnostic for |diagnostic for complex |complex builtin |builtin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
[Bug c++/35323] [4.3 regression] ICE calling functions with fixed-point type parameter
--- Comment #4 from pcarlini at suse dot de 2008-03-06 17:53 --- Fixed for 4.3.1 too. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #10 from pcarlini at suse dot de 2008-03-06 18:37 --- Fixed for 4.4.0 and 4.3.1. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #17 from pcarlini at suse dot de 2008-03-04 11:04 --- (In reply to comment #16) Sorry, I had two versions of patch and managed to commit the wrong copy. Sent correct one to ML. It should be fixed now. Indeed, it's fixed! Many, many thanks! The point I wanted to make is that inliner when knowing to be inlining a cold call (because it was hinted so by __builtin_expect) is correctly a lot more sellective. Basically anything that expands to function call and some extra code around is a loss for code size inlining. I see now. I was missing the cold call (__builtin_expect) specifics. Thanks for the explanation. -- pcarlini at suse dot de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #13 from pcarlini at suse dot de 2008-03-03 19:04 --- Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux machines I'm not seeing any progress :( -- pcarlini at suse dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #15 from pcarlini at suse dot de 2008-03-04 00:09 --- (In reply to comment #14) Hi, this is what I get from our thester: Differences: Tests that now work, but didn't before: abi_check so it ought to make differnece for i686-linux. Note however, that the patch also didn't help Geoff's i686-linux tester, just have a look to gcc-testresults. It is quite possible that things differ on 64bit hosts, we are staying on quite fragile ground here because in the current cost metric the benefits of inlining are very close to costs. Given the nature that function call of the wrapped function is a bit chepaer than call of the wrapper is quite correct. The decision on whether function should be inlined or not depends on many things, like overall size, ABI details etc. I see it is quite irritating for ABI checking. I think we should not mix the two issues, here. The first issue is that, IMO, the function we are discussing should be inlined, it's very small and we always inlined it until recently. The other issue is the ABI check failure. I said issue, but actually it's really trivial, just matter of tweaking a bit the linker script, making it a little more tight. I don't think much more is necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #9 from pcarlini at suse dot de 2008-03-02 17:35 --- Confirmed, of course. Honza, any news on the inlining issue? -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-02 17:35:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35374] ICE during instanciation of a template expr. with typeof()
--- Comment #1 from pcarlini at suse dot de 2008-02-26 10:57 --- *** This bug has been marked as a duplicate of 13740 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35374
[Bug c++/13740] ICE when mangling template which uses typeof
--- Comment #15 from pcarlini at suse dot de 2008-02-26 10:57 --- *** Bug 35374 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||philippe dot hoogvorst at ||neuf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13740
[Bug libstdc++/35353] C++ wide character locale doesn't work
--- Comment #9 from pcarlini at suse dot de 2008-02-25 12:44 --- Maybe we can improve the behavior when the stdio is synced, that is we can transcode each wchar_t and sync after each transcoding. Very likely, you can also simulate that behavior right now by using sync_with_stdio(false) + a custom single-char I/O buffer. In any case, any enhancement will be implemented only when the binary compatibility will be broken. -- pcarlini at suse dot de changed: What|Removed |Added Severity|major |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-25 12:44:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug libstdc++/35353] C++ wide character locale doesn't work
-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug libstdc++/35353] C++ wide character locale doesn't work
--- Comment #10 from pcarlini at suse dot de 2008-02-25 13:11 --- Note, anyway, that there is a serious blocker to any enhancement in this area (and of course it explains the current behavior): if wcin co are converting, they deal with the underlying stream as a narrow-character oriented stream. But when the stream is synced it must be possible to mix char-by-char with wchar_t C stdio operations, which require a wide-character orientation of the stream, whereas, per C99 7.19.2, the orientation of a stream cannot be changed after opening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug libstdc++/35353] C++ wide character locale doesn't work
--- Comment #11 from pcarlini at suse dot de 2008-02-25 14:18 --- About my last reply: I checked, and within the current implementation of the underlying I/O the last issue (per libstdc++/9662) doesn't exist anymore, in other terms, when sync_with_stdio(false), C++ I/O on wcin/wcout doesn't change the orientation of the stream to byte (i.e, fwide 0). Good. We have re-investigate all the other reasons that led to the separate non-converting synced (default) implementation of wcin co... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug c++/35338] [4.3/4.4 regression] Broken diagnostics for fixed-point types
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:03 --- Seems simple. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
[Bug c++/35333] [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex builtin
--- Comment #2 from pcarlini at suse dot de 2008-02-25 17:18 --- Also simple. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
[Bug libstdc++/33612] make check -jN should fully use N cores
--- Comment #3 from pcarlini at suse dot de 2008-02-25 18:10 --- Eh! I think we should only double check that tests creating / writing files use unique names... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
[Bug c++/35370] Visibility of member of base template class lacking in derived template class
--- Comment #1 from pcarlini at suse dot de 2008-02-25 19:47 --- Yes it is. This change dates back to the 3.4 series: http://gcc.gnu.org/gcc-3.4/changes.html -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35370
[Bug c++/35323] [4.3/4.4 regression] ICE calling functions with fixed-point type parameter
--- Comment #1 from pcarlini at suse dot de 2008-02-25 21:28 --- Seems easy. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-25 21:28:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
[Bug libstdc++/35351] FAIL: abi_check
--- Comment #1 from pcarlini at suse dot de 2008-02-24 13:45 --- *** This bug has been marked as a duplicate of 35262 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35351
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #8 from pcarlini at suse dot de 2008-02-24 13:45 --- *** Bug 35351 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||jrp at dial dot pipex dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug libstdc++/35352] XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors)
--- Comment #1 from pcarlini at suse dot de 2008-02-24 13:49 --- You are mistaken: just have a look to the results posted to gcc-testresults, the test XPASSes, as usual. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35352
[Bug c++/35353] C++ wide character locale doesn't work
--- Comment #3 from pcarlini at suse dot de 2008-02-24 14:18 --- Not a bug, given our implementation-defined behavior: the various cin / wcin, streams are by default synced with stdio (per the standard requirements) and thus not converting. You can either call sync_with_stdio(false) before any I/O or use converting stream, like fstreams. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug c++/35353] C++ wide character locale doesn't work
--- Comment #6 from pcarlini at suse dot de 2008-02-24 14:40 --- sync_with_stdio(false) works, and is tested dozens of times a day in our testsuites. And that is only half of my answer. Please understand what I said, study the details of the ISO C++ Standard and then come back. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35353
[Bug c++/35275] Operator for embedded class of templetized class isn't found
--- Comment #2 from pcarlini at suse dot de 2008-02-23 17:00 --- *** This bug has been marked as a duplicate of 13399 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
[Bug c++/13399] G++ 3.3 fails to match the templatized, overloaded operator for subtypes defined in the class template
--- Comment #3 from pcarlini at suse dot de 2008-02-23 17:00 --- *** Bug 35275 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13399
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #4 from pcarlini at suse dot de 2008-02-22 09:48 --- Ok, I'm going to post a patch reverting completely the fix for 28743, and then we'll see... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/28743] [4.1/4.2/4.3/4.4 regression] ICE with invalid specialization
--- Comment #13 from pcarlini at suse dot de 2008-02-22 11:07 --- Unfortunately, back to a 4.3 (and 4.4) regression. -- pcarlini at suse dot de changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE|[4.1/4.2/4.3/4.4 regression] |with invalid specialization |ICE with invalid ||specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #10 from pcarlini at suse dot de 2008-02-22 11:05 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug libstdc++/34797] [parallel mode] Settings are separated for each compilation unit
--- Comment #7 from pcarlini at suse dot de 2008-02-21 17:06 --- I understand this is fixed now. Otherwise, please reopen (and sorry ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34797
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #1 from pcarlini at suse dot de 2008-02-21 22:25 --- Please double check, but I don't think it's my patch: I tried quickly reverting it and interestingly nothing changes: 28743 doesn't ICE and this one is rejected. It seems something new is going on in this area... Maybe Janis can help with a regression hunt. -- pcarlini at suse dot de changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/35282] [4.3/4.4 regression] Template specialization rejected
--- Comment #2 from pcarlini at suse dot de 2008-02-21 23:13 --- Never mind, I did something wrong in my quick check. I can confirm it's my patch. I'll try to look a bit into it, but beyond reverting it, I cannot promise to be able to fix the present issue without regressing on 28743... -- pcarlini at suse dot de changed: What|Removed |Added CC|janis at gcc dot gnu dot org| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-21 23:13:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35282
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #4 from pcarlini at suse dot de 2008-02-20 21:13 --- I'm not sure there is a substantive bug here, in that the problem can be easily fixed by simply tweaking gnu.ver to explicitely hide ZSt13__check_facetISt7codecvtIcc11__mbstate_tEERKT_PS4_ and the wchar_t counterpart: certainly would not be the first time exports must be tweaked because of a changing inlining decision. My concern, however, is whether it's ok not to inline such a tiny function (fyi, the function is defined in basic_ios.h all the uses are in fstream.tcc). First blush, I don't think it's ok... -- pcarlini at suse dot de changed: What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #6 from pcarlini at suse dot de 2008-02-21 00:07 --- (In reply to comment #5) Subject: Re: [4.4 Regression]: FAIL: abi_check OK, if it really is just inlining decision difference then we are fine. I guess we can either update symbol list or mark always_inline Yes, from a robustness of the set of exported symbols point of view eventually we should anyway specify in the linker script to hide such symbols. However... I can look into the reason why it is not getting inlined. It would help to have preprocessed testcase as I am travelling now :) ... many thanks! Because I think 4.3.0 is right here, I think that small function should be indeed inlined. I'm going to add a trivial preprocessed file, which just instantiates std::basic_filebufchar: at -O2 the object contains the __check_facetcodecvt symbol, at variance with 4.3. Many thanks again for looking into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug c++/35262] [4.4 Regression]: FAIL: abi_check
--- Comment #7 from pcarlini at suse dot de 2008-02-21 00:08 --- Created an attachment (id=15189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15189action=view) Pre-processed instantiation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35262
[Bug libstdc++/35221] [4.3 Regression] libstdc++ broken
--- Comment #3 from pcarlini at suse dot de 2008-02-17 10:59 --- The problem is just that stdint isn't available everywhere (I don't think the configure checks can be weakened). Probably we should just keep the old by hand typedefs. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-17 10:59:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug libstdc++/35221] [4.3 Regression] libstdc++ broken
--- Comment #5 from pcarlini at suse dot de 2008-02-17 11:33 --- Thanks Eric. I'm not sure that rework is appropriate for 4.3.0, though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug libstdc++/35221] [4.3 Regression] libstdc++ broken
--- Comment #7 from pcarlini at suse dot de 2008-02-17 14:43 --- Ok, I'm taking care of that. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug libstdc++/35221] [4.3 Regression] libstdc++ broken
--- Comment #9 from pcarlini at suse dot de 2008-02-17 15:49 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35221
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebufchar constructor isn't exported by the DSO
--- Comment #3 from pcarlini at suse dot de 2008-02-16 19:34 --- On it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebufchar constructor isn't exported by the DSO
--- Comment #5 from pcarlini at suse dot de 2008-02-16 23:41 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug c++/28743] [4.1/4.2 regression] ICE with invalid specialization
--- Comment #9 from pcarlini at suse dot de 2008-02-14 12:37 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with invalid specialization |with invalid specialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug libstdc++/33983] stdexcept and ostream invalid_argument name clash with -std=gnu++0x
--- Comment #5 from pcarlini at suse dot de 2008-02-14 15:40 --- *** This bug has been marked as a duplicate of 34538 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33983
[Bug libstdc++/34538] [DR 697] combination of sstream, invalid_argument and -std=c++0x breaks valid code
--- Comment #9 from pcarlini at suse dot de 2008-02-14 15:40 --- *** Bug 33983 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||cppljevans at suddenlink dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34538
[Bug c++/35077] [4.3 regression] ICE with attribute in broken class declaration
--- Comment #4 from pcarlini at suse dot de 2008-02-11 09:31 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35077
[Bug libstdc++/16251] bogus default constructor for std::basic_iostream
--- Comment #5 from pcarlini at suse dot de 2008-02-10 14:36 --- On it. I think we can safely implement submitter' suggestion. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16251
[Bug libstdc++/16251] bogus default constructor for std::basic_iostream
--- Comment #7 from pcarlini at suse dot de 2008-02-10 15:51 --- Nothing will be done in older branches (by the way, I'm coming to the conclusion that adding the default constructor was probably an error, but unfortunately is *exported* and in any case we can't just remove it now :( -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16251
[Bug libstdc++/35104] cmath do not undef log2
--- Comment #2 from pcarlini at suse dot de 2008-02-07 12:07 --- Just wanted to add that we are also providing a tr1/cmath, conforming to the TR1 specifications, which indeed makes available std::tr1::log2, and also, in the forthcoming 4.3.0, std::log2, as part of cmath, enabled in the experimental C++0x mode, -std=c++0x: in fact the next C++0x standard will know about all the C99 math functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35104
[Bug c++/35087] g++ fails to compile local class which is passed to template function
--- Comment #1 from pcarlini at suse dot de 2008-02-05 10:00 --- This is illegal in C++03, per 14.3.1/2, and no strictly conforming compiler accepts it. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35087
[Bug c++/35077] [4.3 regression] ICE with attribute in broken class declaration
--- Comment #2 from pcarlini at suse dot de 2008-02-04 14:59 --- Seems simple. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35077
[Bug c++/35007] [4.3 Regression] Firefox fails to build with affentry.cpp:94: error: ISO C++ forbids subscripting non-lvalue array
--- Comment #4 from pcarlini at suse dot de 2008-01-29 02:05 ---
This is a reduced snippet (-pedantic). I suspect the problem may have to do
with the fix for c++/27177, let's CC Jason...
struct AffEntry
{
union {
char base[256];
} conds;
};
struct PfxEntry
: public AffEntry
{
PfxEntry()
{
sizeof(conds.base[0]);
}
};
--
pcarlini at suse dot de changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-29 02:05:06
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35007
[Bug c++/26099] support for type traits is not available
--- Comment #12 from pcarlini at suse dot de 2008-01-27 11:44 --- Yes, I noticed. Frankly, I'm not really worried because of the nature of the tests: the checks can give different answers depending on whether the compiler is able or not to figure out that a given function cannot throw. For some reason (which I agree would be interesting to understand in better detail), -fpic/PIC makes makes more difficult for the compiler to assess that a function cannot really throw. I'm not sure about the best way to fix that: we could just zap those specific tests which have such instability, or condition the result on -fpic/PIC via macros, or something better. I would probably be tempted to go the first route, for 4.3.0., at least. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #14 from pcarlini at suse dot de 2008-01-27 13:34 --- (In reply to comment #13) If a function isn't marked nothrow and the function can be overridden by a shared library (that is, it doesn't bind locally), the compiler cannot derive such property from its body. Thanks for the details. (I didn't look at the tests, but usually marking the affected functions nothrow or making them bind locally works around this problem). Well, the functions in those specific tests aren't marked no throw on purpose (we do have other tests for the no throw variants), because I was exactly testing that in some specific cases the C++ front-end is able to figure out by itself that the function doesn't really throw. All in all I'm now thinking that it's good to have such tests, we should only conditionalize the result of the tests on -fpic/PIC, I suppose we do have a macro for that?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #17 from pcarlini at suse dot de 2008-01-27 18:54 --- Hi Kaveh. One problem I can see is that we are dealing with special member functions, like constructors and assignment operators. Can you see anything wrong with the straightforward implementation of idea per the attached patchlet? If it looks ok to you, it would be matter of doing the same for the other 2 files... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #16 from pcarlini at suse dot de 2008-01-27 18:51 --- Created an attachment (id=15030) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15030action=view) Draft idea for the -fpic/-fPIC fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #20 from pcarlini at suse dot de 2008-01-27 20:40 --- Hi Kaveh. I just checked darwin and indeed, we have an issue there, which, AFAICS, is not worked around with -fpie. I say, let's just skip the test when __PIC__ is defined, and be done with it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #22 from pcarlini at suse dot de 2008-01-27 20:49 --- Created an attachment (id=15031) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15031action=view) New draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug c++/26099] support for type traits is not available
--- Comment #21 from pcarlini at suse dot de 2008-01-27 20:47 --- Since you are already set for this extended kind of testing, can you run the new patch? Thanks a lot in advance! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
