--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-15 01:45
---
I think this can be closed: now the system header pragma is pretty solid and I
don't think warnings can be triggered from library headers, by any -W option.
--
paolo dot carlini at oracle dot com changed
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-13 23:45
---
I gather that SUN fixed this problem more than 2 years ago, in Solaris 10
Update 4, see eg:
http://blogs.sun.com/mandalika/entry/solaris_workaround_to_stdio_s
Given that, I'm going to mark this as WONTFIX
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-13 23:55
---
Any progress on this? Should be really kept open after almost 6 years of
inactivity? Thanks for any update.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15047
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-12 10:43
---
Ok, so this is resolved as WONTFIX. Anyway, the PR remains in the database, of
course, and if somebody has ideas, partial solutions, whatever, those are of
course welcome, but let's not keep the PR
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-12 20:15
---
Many thanks Jason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054
--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-12 22:34
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-13 01:44
---
Actually, this is a feature, not a bug:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-11 13:16
---
I can reproduce it, but seems just a low priority ice on *invalid*, or you can
see something anomalous also when Equation is declared?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43028
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-11 15:36
---
Frankly, without a testcase, it's really unlikely that somebody can work on
this issue. You don't have to provide the exact code causing the problem, of
course, you can reduce it, shorten it, obfuscate
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-11 15:59
---
Frankly, I don't believe you, I mean, I don't believe that *each single line*
counts, I bet that you can remove a substantive percentage of it while still
triggering the problem.
--
http://gcc.gnu.org
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-11 18:13
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-11 23:52
---
Feedback not forthcoming. If you have a self-contained reproducer for gcc4.4.x,
please re-open, thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #30 from paolo dot carlini at oracle dot com 2010-02-11 23:54
---
I'm looking for an update on its status: how do we stand? What is still
missing? Thanks in advance.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #32 from paolo dot carlini at oracle dot com 2010-02-12 00:03
---
Yes, that was also my guess. If somebody disagrees please explain and re-open,
thanks a lot.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-12 00:08
---
Gaby, any chance you can give me some guidance about this issue? What do you
think should we do now? The PR remained in limbo for way too much time, in my
opinion. Thanks in advance.
--
paolo dot carlini
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-12 00:22
---
Thanks. Thus, would you support closing this as WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-10 10:16
---
There are many details to this, but note that if you stay away from c_str(),
and const char*, thus you consistently use C++ style strings, nothing
unexpected happens, *ever*.
--
http://gcc.gnu.org
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-10 10:18
---
To be sure: is is fully clear to you that a mapconst char*, int stores a pair
of *pointer to const char* and an int? It does *not* store a full string, it
stores an *address* (and an int)!
--
http
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-10 18:40
---
Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #29 from paolo dot carlini at oracle dot com 2010-02-11 01:59
---
Thanks to the recent fixes and all the good work Jason did, I'm pretty sure
that now a normal enable_if or decltype on the return type would work just
fine. I'm wondering if we should just do that, for 4.5.0
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-09 09:45
---
Before anything else, you should try a current compiler, because 4.0.x isn't
maintained anymore, thus either 4.3.x or, better, 4.4.x. Then, if you are still
seeing something strange, we need a complete self
--- Comment #18 from paolo dot carlini at oracle dot com 2010-02-09 11:14
---
Ok, I changed Summary and Severity. Somebody should also double check whether
VLAs are still triggering warnings or not.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-09 13:51
---
Nonetheless, please try with a maintained compiler and, in case, please provide
a complete self-contained reproducer, otherwise no action will be possible,
this bug will be closed for lack of feedback
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-09 16:09
---
Looks like there is a strong consensus in the LWG for the proposed resolution,
that is returning void, and LWG 579 now is [Tentatively Ready]. We could even
implement it in time for 4.5.0, but, if I'm
--- Comment #26 from paolo dot carlini at oracle dot com 2010-02-09 21:20
---
Fine, let's suspend this, then.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #27 from paolo dot carlini at oracle dot com 2010-02-09 21:43
---
Jon, about the proposed resolution, do you think that simple is enough? I mean,
it doesn't say anything about the problem I had to address with SFINAE in my
tentative patch...
--
http://gcc.gnu.org
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-09 23:20
---
The surprising behavior is ultimately due to the fact that our string is
reference counted, thus 'string aux = sElement' is a shallow copy, but then,
when sElement = ab3 is performed a deep copy takes place
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-09 23:40
---
Oops, read because in this case the address as THUS in this case the
address, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-09 23:51
---
Grr, I noticed another typo in my reply, I meant of course third find, not
first find. Only the outcome of the third find was at issue, anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43014
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-08 11:07
---
Can be closed (of course std::is_convertible needs front-end support, but
that's another story)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-08 11:08
---
DR 585 has been resolved to NAD
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #16 from paolo dot carlini at oracle dot com 2010-02-08 11:19
---
Can we review this issue? Two comments: 1- Now I can see only dynamic memory
allocations via new / delete everywhere, thus, no __builtin_alloca; 2- *If* one
really wanted to use VLAs, now it should
--- Comment #13 from paolo dot carlini at oracle dot com 2010-02-08 11:24
---
Is this still an issue? To be honest I have no idea if this target is still in
good shape or not...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-08 12:57
---
Interesting. Thus I get Core 906 [Ready] as meaning that this snippet is just
illegal, and should be rejected, in other terms, this is an accept invalid,
right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-08 14:36
---
Basing on Core 906, seems rather straightforward that the snippet is
ill-formed, the only problem is that neither 4.4 nor current mainline reject
it. If that's the complete analysis, the issue is pretty low
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-07 11:43
---
*** This bug has been marked as a duplicate of 42983 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-07 11:43
---
*** Bug 42992 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-07 18:37
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-06 10:15
---
Your testcase doesn't even compile:
42983.C: In function int main():
42983.C:15:15: error: cannot convert B to A* in initialization
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-06 19:07
---
I'll re-open this only if Gaby, maintainer of valarray, thinks it's the right
thing to do.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-06 19:42
---
I totally agree. Anyway, ok, I can do that, it will require a bit of tweaking
to the valarray_after.h macros, no big deal.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-06 20:15
---
Jason, can you have a look? Just in case it's a wrong code bug... Thanks in
advance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-06 20:44
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-06 21:21
---
Oops, there is a typo in the linker script, fixing momentarily.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-06 21:32
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-05 12:52
---
Thus I'm resolving this as duplicate, if somebody disagrees, please re-open,
thanks.
*** This bug has been marked as a duplicate of 29131 ***
--
paolo dot carlini at oracle dot com changed
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-05 12:52
---
*** Bug 31816 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|[C++0x] condition_variable|[DR 887
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-05 12:55
---
Jon, do we have some sort of reference / pointer for this issue? Are we sure
Lawrence is aware of it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-05 12:57
---
At this point, I don't think we are going to do change the deprecated auto_ptr,
so closing as WONTFIX.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-05 13:07
---
It seems this can be safely closed as invalid, there is no reason why
std::__cos should be wrong.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #19 from paolo dot carlini at oracle dot com 2010-02-05 13:11
---
So, this is fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-05 13:12
---
Benjamin, any opinion about this issue?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #29 from paolo dot carlini at oracle dot com 2010-02-05 13:16
---
Given the resolution of DR 456 [CD1], this is invalid, that is, the snippet can
well compile (and does, with libstdc++-v3).
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-05 13:20
---
Eric, Rainer, do you have any comment on this? For sure it's very hard to
provide an implementation working around the reported Solaris limitation
without breaking the binary compatibility. Does the limitation
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-05 17:04
---
Kaveh, you are comparing apples to oranges: in the first case the GNU locale
model is used, a complete set of locale data is installed, thus the testcase is
run and it fails. In the second case, evidently one
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-05 17:30
---
So you have to investigate why on your machine the GNU locale model is not
used, the configury falls back to the generic model. Certainly nothing changed
lately in this area, and, as you can see
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-05 18:46
---
I see, great, just wanted to make sure the issue is recorded somewhere besides
this v3 PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42819
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-05 21:06
---
DR 342 has been resolved as NAD: time to return to this issue...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-04 14:26
---
Please follow the instructions here
http://gcc.gnu.org/bugs/#report
provide a preprocessed file. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-04 18:02
---
It seems to me that if DR887 is indeed resolved per the discussion in Santa
Cruz, thus the wait_for functions removed, the wait_until functions use
system_clock, then this issue could be immediately resolved
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
Reopen...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
... to close as duplicate.
*** This bug has been marked as a duplicate of 22634 ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #22 from paolo dot carlini at oracle dot com 2010-02-04 18:36
---
*** Bug 42943 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2010-02-03 20:52
---
Great!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-03 20:56
---
Thanks. Jason, I was adding [DR 225] to the Subject when I noticed *another* DR
225, PR29131. Do we want to keep both or not?
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-02 21:02
---
Did you check for DRs filed and resolved after C++03? As an additional data
point, the behavior with the current Intel compiler is exactly the same as GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-03 03:30
---
As far as I can tell, we are already implementing correctly the resolution of
DR 539, I went through it one month ago or so:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#539
If you disagree
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-01 16:20
---
Let's minimally fix this for 4.5.0, we have a (still confidential) draft of the
de-conceptualized specifications.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-01 17:25
---
Jon, is there a thread on the reflector about related issues? I spotted
something but couldn't exactly remember...
Anyway, just want to add that I do not see why the C++ front-end, for some
reason, decides
--- Comment #7 from paolo dot carlini at oracle dot com 2010-02-01 17:38
---
Ok, agreed...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-01 17:39
---
Let's keep this open for one sec, in case Jason believes that list of
candidates could be actually made less confusing to the user.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-01 19:40
---
I see. In principle I think the user would like to see only
operator!=(int, int) built-in
and indeed:
templatetypename _Tp, typename _Tp_Deleter,
typename _Up, typename _Up_Deleter
bool
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-01 19:48
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2010-02-02 01:04
---
Ok, I guess we can close this.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-29 10:08
---
Thanks Jakub, let's see what submitter has to say.
Just want to add here that I'm building submitter' app **exactly** in the same
way with g++ / icc, on the very same machine indeed, and in the former case
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-29 13:40
---
I can see that exception_ptr.h doesn't have the system header pragma, I think
on purpose, some time ago we briefly discussed that and decided to not add it
to the libsupc++ user-visible headers, if possible
--- Comment #45 from paolo dot carlini at oracle dot com 2010-01-28 09:45
---
Thanks HJ and Dodji.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-28 09:50
---
Many thanks Jakub. I have to give this issue much more thought. For the time
being I'm going to add Jason in CC in case he wants to suggest something in
particular, I see he was involved in the STB_GNU_UNIQUE
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-28 15:23
---
If I understand correctly at least part of this issue, now the situation should
be somewhat better, because a few days after the original conversation in the
audit trail, I enabled extern templates
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-28 16:27
---
In the meanwhile I have been able to build and run make check-parallel on a
x86_64-apple-darwin10.2.0, and indeed the specific problem seems fixed.
Beyond that, I'm pretty sure a judicious use
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-28 17:16
---
Roger told me in private that he doesn't mean to actively work on this issue
any time soon. Unassigning.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-28 17:51
---
I don't know the details frankly, but at minimum we should be *very* careful
and make sure we do the right thing also in the special cases, eg, on i386 when
the atomic builtins are not available.
--
http
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-28 22:35
---
Jakub, Jason, thanks for the additional info, hopefully we can make progress on
this issue. By the way, I'm not sure if you noticed that we have an actual
reproducer in Comment #2, is it consistent with your
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-28 22:59
---
Good. Now, if I can have a little bit more of your time, I have two main
curiosities: can you guess why the same 4.4.x *.so + headers don't lead to a
crash with ICC? Then, we should of course come
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-29 00:46
---
This is the LD_DEBUG output for Icc 11.1, thus no crash.
17439: symbol=_ZSt4cerr; lookup in file=./a.out [0]
17439: binding file /usr/lib64/libstdc++.so.6 [0] to ./a.out [0]:
normal symbol
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-27 10:57
---
I'm seeing two problems here: on x86_64-linux I can see only the last error,
about specialization / redefinition, can well be a non-bug but can also be a
regression, I'm CC-ing Dodji about it; plus, apparently
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-27 11:08
---
Ok. If you could figure out more precisely *when* the first problem started on
cygwin, it would be very useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-27 12:12
---
Thanks Dave. Thus, essentially, is submitter wrong that the problem is new?
(the other issue, which I can reproduce on x86_64-linux, stays)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-27 12:21
---
Also note: something is going on with char16_t / char32_t which I do not
understand at all, at the moment: in that tr1_impl code I did not setup the
specializations for char16_t / char32_t conditionally
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-27 12:33
---
Then say that explicitly, *always*. Actually, the complete command line is part
of the requirements for PRs.
But, anyway, that error with char16_t and char32_t doesn't make *any* sense to
me. We have plenty
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-27 12:35
---
Dave, please grep the C++ testsuite for char16_t and char32_t: you will find
tons of testcases using those types + -std=c++0x on the command line, no
special target-dependent treatments, no includes
--- Comment #17 from paolo dot carlini at oracle dot com 2010-01-27 12:42
---
So, as a matter of fact, char16_t and char32_t normally work on cygwin too.
Then, what the heck is boost doing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42880
701 - 800 of 2536 matches
Mail list logo
