--- Comment #3 from sebor at roguewave dot com 2006-09-11 21:25 ---
This sounds like it might be related to
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#309. If so, and if
this case is important to you (the submitter) it might be helpful to give the
committee a little
--- Comment #5 from sebor at roguewave dot com 2006-09-12 00:16 ---
The reason why I think library issue 309 may be relevant is because while the
arithmetic extraction operator() is a formatted input function (and thus
subject to 27.6.1.1, p4, and required to begin by constructing
--- Comment #5 from sebor at roguewave dot com 2006-09-12 16:16 ---
(In reply to comment #4)
Shouldn't the output be:
6
azerty123
9
--
sebor at roguewave dot com changed:
What|Removed |Added
--- Comment #8 from sebor at roguewave dot com 2006-09-12 17:24 ---
No, I'm not sure. I got the output with our implementation but the latest
working paper doesn't seem to support it (I had misread the text in 27.7.1.2,
p2 to require that pptr() == epptr() uncoditionally rather than
--- Comment #10 from sebor at roguewave dot com 2006-09-12 17:44 ---
I think you're right. Even my own issue 562 is clear on this. I must have a bug
in the implementation of the resolution of the issue.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562
--
http
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
--- Comment #2 from sebor at roguewave dot com 2006-09-22 16:57 ---
Yes, but 5.3.5, p1 says The operand shall have a pointer type, or a class
type having a single conversion function (12.3.2) to a pointer type. and
not shall be convertible to a pointer type. Note that gcc issues a hard
--- Comment #3 from sebor at roguewave dot com 2006-09-26 16:31 ---
The response I got from EDG is that the expression is well-formed because of
5, p8. They do agree that issuing a warning would be useful and opened an
enhancement request.
FWIW, I think it should be ill-formed
--- Comment #5 from sebor at roguewave dot com 2006-09-26 18:56 ---
You mean something like: if (is_pointer (p)) delete p;
I suppose that could happen but why should it be any different than other
non-sensical but lexically valid constructs with undefined behavior that
require
--- Comment #7 from sebor at roguewave dot com 2006-09-26 21:43 ---
You're right, those weren't the best examples, but I still think they
illustrate the point. The code in them is plain ill-formed even though
it never gets executed, because it just doesn't make sense. deleting
an array
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29273
--- Comment #8 from sebor at roguewave dot com 2006-09-28 16:16 ---
The EDG guys don't think this is worth spending the committee's time on so I
won't
be proposing any change to the standard. Issuing just a warning rather than an
error is good enough for me.
Also, I opened bug 29273
--- Comment #5 from sebor at roguewave dot com 2006-10-02 19:19 ---
Interesting. The vanilla EDG front end rejects it as expected. I wonder why
Intel
accepts it when neither EDG nor gcc does. Maybe we should open a bug with them
to
find out ;-)
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from sebor at roguewave dot com 2006-10-13 21:02 ---
You're right, I missed that. I confess I don't quite understand the rationale
for this in the standard and I'm not aware of any plaform that causes problems
for such calls but based on Doug Gwyn's response to my query
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29465
--- Comment #4 from sebor at roguewave dot com 2006-10-13 21:09 ---
I opened bug 29465 with a request for the new warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20644
--- Additional Comments From sebor at roguewave dot com 2005-03-26 01:08
---
I can imagine that it may not be straightforward to fix but I can't think of a
reason why a warning could ever be useful in this case (i.e., when the code is
provably safe). I could of course be missing
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-redhat-linux
GCC host triplet
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33
---
(In reply to comment #1)
Right. I understand why it doesn't compile and how to work around it (with gcc
at least). What I'm still not convinced of is that it's not a strict conformance
bug. The same point
--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:51
---
Yes, I read that comment but I still don't see anything in the standard the
footnote is in conflict with and I don't see it on the WG14 DR list(*). If the
footnote is bogus and va_list can't be universally
--- Additional Comments From sebor at roguewave dot com 2005-04-13 22:06
---
(In reply to comment #5)
Thanks for the pointer. Let me try again to explain why I object to the
footnote:
The footnote assumes that the reader will make the extrapolation that 1) since
va_list is an object
--- Additional Comments From sebor at roguewave dot com 2005-04-19 15:39
---
I discussed this with Mike Miller of EDG. His response to my query on the issue
(copied with his permission) is below.
Mike Miller wrote:
...
There were a couple of different examples in that thread,
so
--- Additional Comments From sebor at roguewave dot com 2005-04-19 15:41
---
Here's a followup email from Mike with some calarifying comments:
Mike Miller wrote:
Martin Sebor wrote:
Thanks a lot for the detailed analysis! I wonder if your reasoning
would be the same given
-defined conversion in a template
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
http
: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22131
--- Additional Comments From sebor at roguewave dot com 2005-06-24 17:11
---
Yes, sorry for being too terse. The value is supposed to be stored even if the
placement of the thousands separators is invalid, just as long as the input
sequence matches the grammar in 22.2.3.1, p2
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host
--- Comment #5 from sebor at roguewave dot com 2006-02-09 17:29 ---
Here's my analysis copied from the post on the Sun C++ Forum.
According to 27.6.1.3, p36a, tellg() behaves as an unformatted input function
(as described in 27.6.1.3, p1).
From 27.6.1.3, p1: Each unformatted input
--- Comment #7 from sebor at roguewave dot com 2006-02-09 17:43 ---
Sure, whatever works for you :)
FWIW, I find the current behavior in this specific case quite reasonable (i.e.,
it seems reasonable to expect to be able to get the current position even when
the stream has reached
: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
--- Comment #4 from sebor at roguewave dot com 2006-02-13 18:12 ---
(In reply to comment #3)
[...]
keeping get area and put area separate as much as possible (consistently with
filebuf, by the way): this implies not only that egptr() is not updated to
match epptr() upon overflow
--- Comment #7 from sebor at roguewave dot com 2006-02-13 18:36 ---
Subject: Re: stringbuf::overflow() fails to set egptr()
same as epptr()
pcarlini at suse dot de wrote:
--- Comment #6 from pcarlini at suse dot de 2006-02-13 18:30 ---
By the way, in my reading
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27527
--- Comment #1 from sebor at roguewave dot com 2006-05-10 01:07 ---
Here's a test case designed to exhaustively exercise all cases mentioned in
14.8.2, p2. Hope it helps.
$ cat ~/tmp/t.cpp (c=1; while [ $c -lt 15 ]; do printf %s: $c; gcc
-DCASE=$c ~/tmp/t.cpp 2/dev/null; if [ $? -eq
--- Comment #2 from sebor at roguewave dot com 2006-05-12 16:27 ---
EDG points out to me that both the original test case and the one from comment
#1 are ambiguous because only the declaration of the signature of the function
(and thus only the declaration of its return type and its
--- Comment #3 from sebor at roguewave dot com 2006-05-12 16:30 ---
Created an attachment (id=11446)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11446action=view)
Corrected test program exercising SFINAE.
After modifying the test program from comment #1 to correct these problems
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
--- Comment #2 from sebor at roguewave dot com 2006-05-16 17:35 ---
I'm not sure what you find wrong with my attitude but yes, I did send Sun a
note about it pointing them to this problem report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
--- Comment #4 from sebor at roguewave dot com 2006-05-17 15:12 ---
Here's the verbose output from the compiler driver:
$ gcc -v t.c
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: /build/sebor/gcc-4.1.0/configure --enable-languages=c,c++
--prefix=/usr/local/gcc
--- Comment #5 from sebor at roguewave dot com 2006-05-17 17:43 ---
I'm told that the fault is due to a known problem in the Sun libc:
6372620 printstack() segfaults when called from static function
It this doesn't provide sufficient detail to work around the bug in gcc
(assuming you
--- Comment #7 from sebor at roguewave dot com 2006-05-17 18:34 ---
Maybe it's one of the runtime library functions that's static (maybe _start?).
The diff between the two .s files is empty.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
--- Comment #9 from sebor at roguewave dot com 2006-05-17 21:35 ---
Here's what I learned from Sun:
Here is the test case from that bug report:
[Makefile]
main: main.o libshibby.so
gcc -L. -lshibby -Wl,-R. -o main main.o
main.o: main.c
gcc -c -o main.o main.c
at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27788
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28103
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: powerpc-suse-linux
GCC host
--- Comment #2 from sebor at roguewave dot com 2006-07-11 21:42 ---
Libc says it's 2.3.3 (20040412).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28351
--- Comment #2 from sebor at roguewave dot com 2006-07-13 19:07 ---
If it is in our (Rogue Wave) current code, could you please let us know where
so we can look into fixing it? (It's doesn't matter whther gcc does the right
thing here or not, our code should be portable either way
: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http
--- Comment #7 from sebor at roguewave dot com 2005-12-08 00:08 ---
FWIW, I think Andrew makes a good point in comment #1. The algorithms really
should return the iterator, otherwise the caller may not be able to find out
the state of the iterator after the algorithm returns (e.g., when
: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
--- Comment #10 from sebor at roguewave dot com 2005-12-08 15:51 ---
No, I don't. The standard is clear and most of us seem to think it's by
design. Rather I am suggesting is that we might want to discuss with the whole
LWG changing the return type as an enhancement.
--
http
--- Comment #15 from sebor at roguewave dot com 2005-12-08 16:27 ---
(In reply to comment #11)
Okay, I see your concern.
Well, IMO, your signatures are better than those required by the standard so if
you care about 100% compliance you (or Paolo -- and I promise not to beat him
--- Comment #3 from sebor at roguewave dot com 2006-01-10 16:14 ---
(In reply to comment #2)
I'm not sure what you mean. Could you show what one of the algorithms would
look like with a Size that's not convertible to an integer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25306
--- Comment #2 from sebor at roguewave dot com 2006-02-01 16:47 ---
Subject: Re: New: Class object(); is not interpreted as
a call to default constructor
sylvain dot joyeux at m4x dot org wrote:
The following testcase
#include iostream
bool flag = true;
class guardian
--- Additional Comments From sebor at roguewave dot com 2004-12-28 01:32
---
Subject: Re: strcpy bug? or mine?
rolosworld at gmail dot com wrote:
--- Additional Comments From rolosworld at gmail dot com 2004-12-28
01:00 ---
(In reply to comment #1)
You forgot C strings
--- Additional Comments From sebor at roguewave dot com 2004-11-03 00:49 ---
FWIW, if you missed it there was a discussion of this issue
on [EMAIL PROTECTED], starting with c++std-core-10643. Mike
Miller said he'd open an issue for it. I don't see it on the
list yet but I assume
--- Additional Comments From sebor at roguewave dot com 2004-11-03 16:42 ---
(In reply to comment #10)
I think it's clear that gcc is wrong in not returning true in the initializer
of the exception object in the catch handler (the second invocation of the copy
ctor in the test case
: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc
--- Additional Comments From sebor at roguewave dot com 2005-06-30 23:36
---
Sorry about the duplicate PR. I searched Bugzilla for an existing report but
obviously not thoroughly enough.
I'm afraid I disagree with the analysis in both PRs. From 14.7.2, p7:
The explicit instantiation
--- Additional Comments From sebor at roguewave dot com 2005-06-30 23:56
---
I don't believe you are reading the paragraph correctly.
The paragraph applies to explicit instantiation. The reference to explicit
specialization allows members of the class template that is being explicitly
--- Additional Comments From sebor at roguewave dot com 2005-07-01 00:06
---
Further, in response to comment 2 from bug 22263:
I agree that 14.7.2, p3 applies to that case but since the definition of class b
is in scope at the point of the explicit instantiation of the class template I
--- Additional Comments From sebor at roguewave dot com 2005-07-21 20:33
---
(In reply to comment #13)
...
* g++.dg/lookup/two-stage2.C: New.
FWIW, the following comment in this patch is wrong:
+ g(2);// f(char) followed by f(int
--- Additional Comments From sebor at roguewave dot com 2005-09-11 21:34
---
In reply to comment #6:
The vanilla EDG eccp 3.5 compiles the test case w/o an error:
$ eccp -v t.cpp ./a.out; echo $?
Edison Design Group C/C++ Front End, version 3.5 (Nov 9 2004 20:00:33)
Copyright 1988
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http
--- Comment #3 from sebor at roguewave dot com 2005-10-28 20:34 ---
Jason, I respectfully disagree. In bug 22263 I explained why I believe gcc is
wrong. Do you see a problem with my reasoning there? If not, you must surely
agree that this is just another example of the same bug
--- Comment #2 from sebor at roguewave dot com 2006-11-27 17:37 ---
Here are some other cases to consider:
#include typeinfo
struct S;
int main ()
{
typeid (void);
typeid (int []);
typeid (S);
typeid (S);
}
--
sebor at roguewave dot com changed:
What
--- Comment #3 from sebor at roguewave dot com 2006-11-27 19:07 ---
Never mind. The last two cases in my comment #2 are disallowed by the second to
last sentence in 5.2.8, p4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29928
org
ReportedBy: sebor at roguewave dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30020
++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30127
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
--- Comment #2 from sebor at roguewave dot com 2006-12-22 20:22 ---
(In reply to comment #1)
This was gcc 4.1.0 on sparc-sun-solaris2.9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
--- Comment #5 from sebor at roguewave dot com 2006-12-22 22:25 ---
Regardless of whether the program aborts with SIGSEGV or SIGABRT, the point is
that it should either not compile or it should run succesfully to completion.
Here's the output of g++ -v if it helps:
$ g++ -v
Using
--- Comment #10 from sebor at roguewave dot com 2006-12-23 20:46 ---
Created an attachment (id=12840)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12840action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30378
array
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla
--- Comment #4 from sebor at roguewave dot com 2007-01-09 22:34 ---
(In reply to comment #3)
The standard refers to (l+n)%size(), so if size()=0, that seems to be
undefined. On the other hand, it seems fairly obvious what should happen in
this case (ie nothing).
The requirement
--- Comment #9 from sebor at roguewave dot com 2007-01-10 05:55 ---
Even if the spec did permit undefined behavior it would make sense to implement
something reasonable if it's easy (as Paolo suggests it might be) and if the
cost
is acceptable. But just to put your mind at ease I'll
--- Comment #1 from sebor at roguewave dot com 2007-01-22 16:25 ---
Even better, this works too:
template void X1::X2::X3::X4::f();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30539
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30561
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
GCC build triplet: sparc-sun-solaris
GCC host triplet: sparc-sun-solaris
GCC target triplet: sparc
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
specification in
__PRETTY_FUNCTION__
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave
--- Comment #2 from sebor at roguewave dot com 2007-02-15 21:29 ---
No, I'm not aware of any such paper. AFAIK, neither __FUNCTION__ nor
__PRETTY_FUNCTION__ is specified by either C or C++, or proposed for inclusion
either of them (I could be wrong). They're gcc extensions, aren't
--- Comment #4 from sebor at roguewave dot com 2007-02-15 23:06 ---
The wording proposed in N1970 for the C++ __func__ indentifier reads:
-1- The identifier __func__ shall be implicitly declared by the translator
as if, immediately following the opening brace of each function
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 ---
(In reply to comment #5)
Good point! I hadn't thought of that. Since that option is out and __FUNCTION__
should simply behave identically to __func__ and be disallowed in global or
namespace scope function argument
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
space waste
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org
--- Comment #3 from sebor at roguewave dot com 2007-03-14 19:04 ---
(In reply to comment #1)
Interesting. Do the attributes apply to derived classes automatically?
I would say no.
[...]
Is D also allowed to reorder members a and b? even with an explicit
__attribute__((reorder
--- Comment #4 from sebor at roguewave dot com 2007-03-14 19:05 ---
(In reply to comment #2)
Note actually some compilers actually do this even without an attribute. This
is related to the art hack.
Out of curiosity, which compiler does it? And what's the art hack?
--
http
--- Comment #6 from sebor at roguewave dot com 2007-03-15 19:54 ---
(In reply to comment #5)
I've checked all three but none of them seems to achieve an optimal layout in a
modified template case. Let me attach my test program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #7 from sebor at roguewave dot com 2007-03-15 19:55 ---
Created an attachment (id=13212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13212action=view)
test case for data member reordering
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31176
--- Comment #8 from sebor at roguewave dot com 2007-03-15 23:51 ---
Some additional comments on the request precipitated by a discussion with the
implementers of another compiler:
The rationale for allowing the attribute on individual members is to provide
fine-grained control over
--- Comment #2 from sebor at roguewave dot com 2009-01-04 22:37 ---
Some additional background on the problem: it's likely that the gcc binary
used to reproduce the problem on Red Hat Enterprise Linux AS release 4 has
been configured and built on SUSE Linux Enterprise Server 10. Should
--- Comment #12 from sebor at roguewave dot com 2009-01-09 16:57 ---
(In reply to comment #3)
Created an attachment (id=17044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17044action=view) [edit]
As others have mentioned, the codecvt facet in your test case is broken
on const char format string
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org
1 - 100 of 180 matches
Mail list logo
