http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51234
Bug #: 51234
Summary: ambiguity in mangling function attribute
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority:
--- Comment #6 from s__nakayama at infoseek dot jp 2009-01-02 14:52 ---
> If T is the name of a class, then each of the following shall have a name
> different from T:
> - every data member of class T;
This description is the one in "ISO/IEC 14882:1998".
It was
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 19:39 ---
Sorry, my code is undefined.
By 12.1/7, member of foo is not initialized. I
--
s__nakayama at infoseek dot jp changed:
What|Removed |Added
--- Comment #3 from s__nakayama at infoseek dot jp 2008-04-24 08:05 ---
(In reply to comment #2)
> The program has undefined semantics. By 12.1/5, the default constructor of
> B initializes the pointer as if it was default initialized as if a user
> specified constructor had
y: Wrong initialization in operator new.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek d
--- Comment #1 from s__nakayama at infoseek dot jp 2008-02-23 16:20 ---
This is a duplicate of #13399.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34049
--- Comment #2 from s__nakayama at infoseek dot jp 2007-10-11 13:50 ---
(In reply to comment #1)
> This code is invalid, and we should reject both of them.
Why do you think that this is invalid?
Member with same name as class have restrictions(ISO/IEC 14882:2003 9.2
p13/13a).
But
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33677
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
Summary: wrong POD type initialization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at in
Summary: bit-field: optimization BUG
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infose
--- Comment #7 from s__nakayama at infoseek dot jp 2007-05-17 06:04 ---
Fixed already in 4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29927
--- Comment #7 from s__nakayama at infoseek dot jp 2007-02-21 02:25 ---
(In reply to comment #6)
> This is not a bug. The C++ standard says:
>
> [expr.post.incr]
>
> the value of the object is modified by adding 1 to it, unless the object is of
> type bool, in which
--- Comment #3 from s__nakayama at infoseek dot jp 2007-01-22 18:28 ---
(In reply to comment #1)
> I only have the C99 standard, and there I read in 6.3.1.1 p2 that only
> those variables are promoted to int that are of smaller size.
>
> Similarly, in 6.3.1.8, integer pro
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30332
ormal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30328
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30313
roduct: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277
--- Comment #3 from s__nakayama at infoseek dot jp 2006-12-22 08:39 ---
(In reply to comment #2)
> When is the justification that we expect a value of 2? Bool in C++ is
> a one-bit type and when you do x.x++ I would imagine that you overflow
> the range of that type. The fact
ty: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30274
dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30195
--- Comment #7 from s__nakayama at infoseek dot jp 2006-12-11 19:21 ---
Is this still active?
gcc 4.1.1 accept Andrew's testcase in comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
r lookup in template.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30144
--- Comment #2 from s__nakayama at infoseek dot jp 2006-12-04 08:11 ---
I seem this is same as Bug 29733.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30046
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29993
--- Comment #5 from s__nakayama at infoseek dot jp 2006-11-23 14:34 ---
(In reply to comment #4)
> In any case, can you clarify why exactly you think the code should be
> rejected?
ISO 14882:2003 14.3.1 p3
> If a declaration acquires a function type through a type depen
--- Comment #3 from s__nakayama at infoseek dot jp 2006-11-22 14:57 ---
(In reply to comment #2)
(In reply to comment #2)
> What exactly do you expect the code to do?
> foo();
> leads to an instantiation of foo with
> T= int()()
> i.e. reference to "no-arg fu
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29318
cc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28213
ion: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26534
--- Additional Comments From s__nakayama at infoseek dot jp 2005-07-09
18:23 ---
(In reply to comment #4)
> Huh? I cannot reproduce it at all.
> with all of the versions of GCC I tried from 2.95.3 to 4.1.0 I get the
following:
> "\"\\\" \\\"\""
--- Additional Comments From s__nakayama at infoseek dot jp 2005-06-23
15:35 ---
(In reply to comment #1)
> I don't see why this is really a bug because if you output the string, it
will look the same.
NO! Your guess is wrong.
I never report, if the output always looks the
--
What|Removed |Added
Known to fail||3.0.4 3.2.3 3.3.3 3.3.6
||3.4.4 4.0.0
Known to work|
--- Additional Comments From s__nakayama at infoseek dot jp 2005-06-14
07:20 ---
(In reply to comment #1)
Hmm, it does't look the same.
// test code
#define S(X) S2(X)
#define S2(X) #X
#define TAB " " /* 0x09 */
main()
{
puts(S(S(TAB)));
}
// GCC 4.0.0 result
&qu
e non-printable characters to octal.
But this behavior is non standard.
--
Summary: stringification BUG
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at
36 matches
Mail list logo
