* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <bug-9679-4059@http.gcc.gnu.org/bugzilla/>
@ 2010-02-12 0:08 ` paolo dot carlini at oracle dot com
2010-02-12 0:20 ` gdr at integrable-solutions dot net
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-12 0:08 UTC (permalink / raw)
To: gcc-bugs
------- 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 at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo dot carlini at oracle
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <bug-9679-4059@http.gcc.gnu.org/bugzilla/>
2010-02-12 0:08 ` [Bug libstdc++/9679] Strange behaviour of valarray::apply method paolo dot carlini at oracle dot com
@ 2010-02-12 0:20 ` gdr at integrable-solutions dot net
2010-02-12 0:22 ` paolo dot carlini at oracle dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2010-02-12 0:20 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
------- Comment #10 from gdr at integrable-solutions dot net 2010-02-12 00:20 -------
Subject: Re: Strange behaviour of valarray::apply method
On Thu, Feb 11, 2010 at 6:08 PM, paolo dot carlini at oracle dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- 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.
at the moment, I believe fixing this means throwing away the
current valarray implementation. I'm fine with that if someone
proposes a better implementation performance-wise.
Personal opinion: I do not think that the case submitted is
an examplar of the usage envisioned for valarray. If you want
to take address into a valarray object, create a valarray object.
Don't stick references into the middle temporaries.
But, that is - again - a personal opinion.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <bug-9679-4059@http.gcc.gnu.org/bugzilla/>
2010-02-12 0:08 ` [Bug libstdc++/9679] Strange behaviour of valarray::apply method paolo dot carlini at oracle dot com
2010-02-12 0:20 ` gdr at integrable-solutions dot net
@ 2010-02-12 0:22 ` paolo dot carlini at oracle dot com
2010-02-12 10:43 ` paolo dot carlini at oracle dot com
2010-02-12 11:06 ` gdr at integrable-solutions dot net
4 siblings, 0 replies; 14+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-12 0:22 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <bug-9679-4059@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-02-12 0:22 ` paolo dot carlini at oracle dot com
@ 2010-02-12 10:43 ` paolo dot carlini at oracle dot com
2010-02-12 11:06 ` gdr at integrable-solutions dot net
4 siblings, 0 replies; 14+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-12 10:43 UTC (permalink / raw)
To: gcc-bugs
------- 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 in this limbo state further, without
progress for years, it doesn't make any sense.
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <bug-9679-4059@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2010-02-12 10:43 ` paolo dot carlini at oracle dot com
@ 2010-02-12 11:06 ` gdr at integrable-solutions dot net
4 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2010-02-12 11:06 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 516 bytes --]
------- Comment #13 from gdr at integrable-solutions dot net 2010-02-12 11:06 -------
Subject: Re: Strange behaviour of valarray::apply method
On Thu, Feb 11, 2010 at 6:22 PM, paolo dot carlini at oracle dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
> ------- Comment #11 from paolo dot carlini at oracle dot com 2010-02-12 00:22 -------
> Thanks. Thus, would you support closing this as WONTFIX?
if that is agreable to you, that is fine by me.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
@ 2003-06-02 23:50 ` reichelt@gcc.gnu.org
2003-06-02 23:53 ` reichelt@gcc.gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 14+ messages in thread
From: reichelt@gcc.gnu.org @ 2003-06-02 23:50 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
reichelt@gcc.gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2003-06-02 23:50:40
date| |
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
2003-06-02 23:50 ` reichelt@gcc.gnu.org
@ 2003-06-02 23:53 ` reichelt@gcc.gnu.org
2004-03-19 17:06 ` pcarlini at suse dot de
` (5 subsequent siblings)
7 siblings, 0 replies; 14+ messages in thread
From: reichelt@gcc.gnu.org @ 2003-06-02 23:53 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
reichelt@gcc.gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |SUSPENDED
------- Additional Comments From reichelt@gcc.gnu.org 2003-06-02 23:53 -------
Let's wait for the resolution of the DR.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
2003-06-02 23:50 ` reichelt@gcc.gnu.org
2003-06-02 23:53 ` reichelt@gcc.gnu.org
@ 2004-03-19 17:06 ` pcarlini at suse dot de
2004-03-19 17:32 ` Gabriel Dos Reis
2004-03-19 17:32 ` gdr at integrable-solutions dot net
` (4 subsequent siblings)
7 siblings, 1 reply; 14+ messages in thread
From: pcarlini at suse dot de @ 2004-03-19 17:06 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-03-19 17:06 -------
Gaby, could you please provide an update about this PR?
Volker mentions a DR: which one? Not 389, which you already implemented.
I'm puzzled.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [Bug libstdc++/9679] Strange behaviour of valarray::apply method
2004-03-19 17:06 ` pcarlini at suse dot de
@ 2004-03-19 17:32 ` Gabriel Dos Reis
0 siblings, 0 replies; 14+ messages in thread
From: Gabriel Dos Reis @ 2004-03-19 17:32 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| Gaby, could you please provide an update about this PR?
I think I gave all necessary information in the initial analysis I
made. Did you find something is out of date?
Personally, I would resolve this as won't fix, or at least suspend.
There is a trivial workaround
char some = foo(&valarray<char>(y.apply(bar))[0]);
-- Gaby
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
` (2 preceding siblings ...)
2004-03-19 17:06 ` pcarlini at suse dot de
@ 2004-03-19 17:32 ` gdr at integrable-solutions dot net
2004-03-19 18:02 ` pcarlini at suse dot de
` (3 subsequent siblings)
7 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-03-19 17:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2004-03-19 17:32 -------
Subject: Re: Strange behaviour of valarray::apply method
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| Gaby, could you please provide an update about this PR?
I think I gave all necessary information in the initial analysis I
made. Did you find something is out of date?
Personally, I would resolve this as won't fix, or at least suspend.
There is a trivial workaround
char some = foo(&valarray<char>(y.apply(bar))[0]);
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
` (3 preceding siblings ...)
2004-03-19 17:32 ` gdr at integrable-solutions dot net
@ 2004-03-19 18:02 ` pcarlini at suse dot de
2004-03-19 18:11 ` pcarlini at suse dot de
` (2 subsequent siblings)
7 siblings, 0 replies; 14+ messages in thread
From: pcarlini at suse dot de @ 2004-03-19 18:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-03-19 18:02 -------
Sorry, you are right that your explanations is very detailed.
However, what I'm missing is why "won't fix" or, even more weird to me, "suspend"
Usually "suspend" is used when waiting for something to happen. What, in this
case? Not the resolution of a DR, right?
And also "won't fix": it would imply that actually we acknowledge the library is
buggy wrt the standard but for some reason we don't want to fix. Is really like
that?
Isn't simply "not a bug"???
Thanks again for your patience, I would really reach closure on some too long
standing PRs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
` (4 preceding siblings ...)
2004-03-19 18:02 ` pcarlini at suse dot de
@ 2004-03-19 18:11 ` pcarlini at suse dot de
2004-03-19 19:12 ` gdr at integrable-solutions dot net
2004-03-20 9:27 ` pcarlini at suse dot de
7 siblings, 0 replies; 14+ messages in thread
From: pcarlini at suse dot de @ 2004-03-19 18:11 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-03-19 18:11 -------
Forgot to add:
> And also "won't fix": it would imply that actually we acknowledge the library is
> buggy wrt the standard but for some reason we don't want to fix. Is really like
> that?
I see two possible reasons for that: either we want to file a DR - do we? - or
we want to fix the problem later - do we?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
` (5 preceding siblings ...)
2004-03-19 18:11 ` pcarlini at suse dot de
@ 2004-03-19 19:12 ` gdr at integrable-solutions dot net
2004-03-20 9:27 ` pcarlini at suse dot de
7 siblings, 0 replies; 14+ messages in thread
From: gdr at integrable-solutions dot net @ 2004-03-19 19:12 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From gdr at integrable-solutions dot net 2004-03-19 19:12 -------
Subject: Re: Strange behaviour of valarray::apply method
"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:
| However, what I'm missing is why "won't fix" or, even more weird to
| me, "suspend" Usually "suspend" is used when waiting for something
| to happen. What, in this case? Not the resolution of a DR, right?
|
| And also "won't fix": it would imply that actually we acknowledge
| the library is buggy wrt the standard but for some reason we don't
| want to fix. Is really like that?
|
| Isn't simply "not a bug"???
It is clearly "Not a bug" with current C++ (either 98 or 2003 would do).
With the DR I submitted, and that would be accepted as part of C++0x,
it would become a bug in the lirbary ; but it would be a bug only
because I did not anticipate that part when making the new proposed
wording. Let me be clear: Before my proposal, the PR is invalid
because the code is ill-formed. With my proposal as currently worded,
the code would become valid (but I did not intend it to be valid).
The reason I did not intend it to be valid is that if it were valid it
would rule out possibility to use expression templates to implement
<valarray> and that would result in huge performance loss.
I said "won't fix" because, the program was invalid and should stay
invalid, but I didn't have wording for that right now. That is a very
optimistic anticipation. The pessimistic anticipation is to wait and
see. Which means "suspend".
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug libstdc++/9679] Strange behaviour of valarray::apply method
[not found] <20030212221600.9679.dens@stl.sarov.ru>
` (6 preceding siblings ...)
2004-03-19 19:12 ` gdr at integrable-solutions dot net
@ 2004-03-20 9:27 ` pcarlini at suse dot de
7 siblings, 0 replies; 14+ messages in thread
From: pcarlini at suse dot de @ 2004-03-20 9:27 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pcarlini at suse dot de 2004-03-20 09:27 -------
Hi again, and thanks for the additional details.
> It is clearly "Not a bug" with current C++ (either 98 or 2003 would do).
Ok.
> With the DR I submitted, and that would be accepted as part of C++0x,
> it would become a bug in the lirbary ; but it would be a bug only
> because I did not anticipate that part when making the new proposed
> wording. Let me be clear: Before my proposal, the PR is invalid
> because the code is ill-formed. With my proposal as currently worded,
> the code would become valid (but I did not intend it to be valid).
Indeed, you already pointed out this issue in your old message but
I didn't fully understand it, sorry.
Now, March, 2004, your DR is in the [Ready] status! Since its implications
are quite important (for this PR too), first I want to document that in
the sources, and point to 389. Moreover, as you often repeated in the past,
[Ready] resolutions must be implemented and, for all practical purposes,
must be considered part of the standard we are implementing. This means,
the status of this PR, strictly speaking, right now seems to me more a
plain "Open". But I fully get your point about the need for a follow up to
your DR 389, so let's keep it Suspended. Could you please keep us up to
date about the iter of the issue with the committee?
Thanks again
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9679
^ permalink raw reply [flat|nested] 14+ messages in thread